New IP Technologies PDF

New IP Technologies
Issue draft 07
Date 2020-10-09
HUAWEI TECHNOLOGIES CO., LTD.

Copyright © Huawei Technologies Co., Ltd. 2020. All rights reserved.
No part of this document may be reproduced or transmitted in any form or by any means without prior
written consent of Huawei Technologies Co., Ltd.
Trademarks and Permissions
and other Huawei trademarks are trademarks of Huawei Technologies Co., Ltd.
All other trademarks and trade names mentioned in this document are the property of their respective
holders.
Notice
The purchased products, services and features are stipulated by the contract made between Huawei and
the customer. All or part of the products, services and features described in this document may not be
within the purchase scope or the usage scope. Unless otherwise specified in the contract, all statements,
information, and recommendations in this document are provided "AS IS" without warranties, guarantees
or representations of any kind, either express or implied.
The information in this document is subject to change without notice. Every effort has been made in the
preparation of this document to ensure accuracy of the contents, but all statements, information, and
recommendations in this document do not constitute a warranty of any kind, express or implied.
Huawei Technologies Co., Ltd.

Address: Huawei Industrial Base
Bantian, Longgang
Shenzhen 518129
People's Republic of China
Website: https://www.huawei.com
Email: support@huawei.com
Issue draft 07 Copyright © Huawei Technologies Co., Ltd. i

(2020-10-09)
New IP Technologies Contents
Contents
1 Segment Routing MPLS......................................................................................................... 1

1.1 Segment Routing MPLS Description................................................................................................................................. 1
1.1.1 Overview of Segment Routing MPLS............................................................................................................................ 1
1.1.2 Understanding Segment Routing MPLS.......................................................................................................................3
1.1.2.1 Segment Routing MPLS Fundamentals.................................................................................................................... 3
1.1.2.2 IS-IS for SR-MPLS............................................................................................................................................................. 7
1.1.2.3 OSPF for SR-MPLS......................................................................................................................................................... 17
1.1.2.4 BGP for SR-MPLS............................................................................................................................................................ 24
1.1.2.5 SR-MPLS BE...................................................................................................................................................................... 29
1.1.2.5.1 SR-MPLS BE and LDP Communication................................................................................................................ 34
1.1.2.6 SR-MPLS TE...................................................................................................................................................................... 37
1.1.2.6.1 Topology Collection and Label Allocation..........................................................................................................38
1.1.2.6.2 SR-MPLS TE Tunnel Establishment....................................................................................................................... 40
1.1.2.6.3 SR-MPLS TE Data Forwarding................................................................................................................................ 42
1.1.2.6.4 SR-MPLS TE Tunnel Reliability............................................................................................................................... 45
1.1.2.6.5 BFD for SR-MPLS TE.................................................................................................................................................. 46
1.1.2.6.6 SR-MPLS TE Load Balancing................................................................................................................................... 48
1.1.2.6.7 DSCP-based Tunneling for IP Packets to Enter SR-MPLS TE Tunnels....................................................... 49
1.1.2.7 Inter-AS E2E SR-MPLS TE............................................................................................................................................ 51
1.1.2.7.1 Binding SID................................................................................................................................................................... 51
1.1.2.7.2 E2E SR-MPLS TE Tunnel Creation......................................................................................................................... 52
1.1.2.7.3 Data Forwarding on an E2E SR-MPLS TE Tunnel............................................................................................ 54
1.1.2.7.4 Reliability of E2E SR-MPLS TE Tunnels............................................................................................................... 56
1.1.2.7.5 One-Arm BFD for E2E SR-MPLS TE...................................................................................................................... 58
1.1.2.7.6 Cross-Multi-AS E2E SR-MPLS TE........................................................................................................................... 60
1.1.2.8 Importing Traffic............................................................................................................................................................ 61
1.1.2.8.1 Public IP Routes Recursive to an SR Tunnel...................................................................................................... 63
1.1.2.8.2 L3VPN Recursive to an SR Tunnel.........................................................................................................................66
1.1.2.8.3 L2VPN Recursive to an SR Tunnel.........................................................................................................................70
1.1.2.8.4 EVPN Recursive to an SR Tunnel........................................................................................................................... 72
1.1.2.9 SBFD for SR-MPLS......................................................................................................................................................... 74
1.1.2.10 SR-MPLS TE Policy....................................................................................................................................................... 77
1.1.2.10.1 SR-MPLS TE Policy Creation................................................................................................................................. 85
Issue draft 07 Copyright © Huawei Technologies Co., Ltd. ii

(2020-10-09)
1.1.2.10.2 Traffic Steering into an SR-MPLS TE Policy.................................................................................................... 87

1.1.2.10.3 SR-MPLS TE Policy-based Data Forwarding....................................................................................................89
1.1.2.10.4 SBFD for SR-MPLS TE Policy................................................................................................................................. 93
1.1.2.10.5 SR-MPLS TE Policy Failover...................................................................................................................................95
1.1.2.10.6 SR-MPLS TE Policy OAM........................................................................................................................................ 96
1.1.2.11 TI-LFA FRR...................................................................................................................................................................... 98
1.1.2.12 Anycast FRR.................................................................................................................................................................104
1.1.2.13 SR-MPLS Microloop Avoidance............................................................................................................................ 106
1.1.2.14 SR-MPLS OAM............................................................................................................................................................ 114
1.1.2.15 MPLS in UDP............................................................................................................................................................... 118
1.1.2.16 SR-MPLS TTL............................................................................................................................................................... 120
1.1.3 Application Scenarios for Segment Routing MPLS..............................................................................................121
1.1.3.1 Single-AS SR-MPLS TE............................................................................................................................................... 121
1.1.3.2 Inter-AS E2E SR-MPLS TE.......................................................................................................................................... 123
1.1.3.3 SR-MPLS TE Policy Application............................................................................................................................... 125
1.1.4 Terminology for Segment Routing MPLS............................................................................................................... 125
1.2 Segment Routing MPLS Configuration....................................................................................................................... 126
1.2.1 Overview of Segment Routing MPLS....................................................................................................................... 126
1.2.2 Segment Routing MPLS Licensing Requirements and Configuration Precautions................................... 127
1.2.3 Configuring an IS-IS SR-MPLS BE Tunnel............................................................................................................... 137
1.2.3.1 Enabling MPLS.............................................................................................................................................................. 138
1.2.3.2 Configuring Basic SR-MPLS BE Functions........................................................................................................... 138
1.2.3.3 (Optional) Configuring a Policy for Triggering SR-MPLS BE LSP Establishment...................................140
1.2.3.4 (Optional) Configuring a Policy for Preferentially Selecting an SR-MPLS BE Tunnel.......................... 140
1.2.3.5 Verifying the IS-IS SR-MPLS BE Tunnel Configuration....................................................................................141
1.2.4 Configuring an OSPF SR-MPLS BE Tunnel..............................................................................................................141
1.2.4.1 Enabling MPLS.............................................................................................................................................................. 142
1.2.4.2 Configuring Basic SR-MPLS BE Functions........................................................................................................... 142
1.2.4.3 (Optional) Configuring a Policy for Triggering SR-MPLS BE LSP Establishment...................................143
1.2.4.4 (Optional) Configuring a Policy for Preferentially Selecting an SR-MPLS BE Tunnel.......................... 144
1.2.4.5 Verifying the OSPF SR-MPLS BE Tunnel Configuration.................................................................................. 145
1.2.5 Configuring Traffic Steering into SR-MPLS BE Tunnels..................................................................................... 145
1.2.6 Configuring an IS-IS SR-MPLS TE Tunnel (Path Computation on the Controller)................................... 149
1.2.6.1 Enabling MPLS TE........................................................................................................................................................150
1.2.6.2 Globally Enabling the SR Capability......................................................................................................................151
1.2.6.3 Configuring the IS-IS SR-MPLS TE Capability and Topology Report Function....................................... 151
1.2.6.4 Configuring an SR-MPLS TE Tunnel Interface................................................................................................... 153
1.2.6.5 Configuring the UCMP Function of the SR-MPLS TE Tunnel....................................................................... 154
1.2.6.6 (Optional) Configuring SR on a PCC.................................................................................................................... 155
1.2.6.7 (Optional) Enabling a Device to Simulate an SR-MPLS TE Transit Node to Perform Adjacency
Label-based Forwarding.......................................................................................................................................................... 156
1.2.6.8 Verifying the IS-IS SR-MPLS TE Tunnel Configuration....................................................................................156
1.2.7 Configuring an OSPF SR-MPLS TE Tunnel (Path Computation on the Controller)..................................157
Issue draft 07 Copyright © Huawei Technologies Co., Ltd. iii

(2020-10-09)
1.2.7.1 Enabling MPLS TE........................................................................................................................................................158

1.2.7.3 Configuring the OSPF SR-MPLS TE Capability and Topology Report Function......................................159
1.2.7.6 (Optional) Configuring SR on a PCC.................................................................................................................... 162
1.2.7.7 (Optional) Enabling a Device to Simulate an SR-MPLS TE Transit Node to Perform Adjacency
Label-based Forwarding.......................................................................................................................................................... 163
1.2.7.8 Verifying the OSPF SR-MPLS TE Tunnel Configuration.................................................................................. 164
1.2.8 Configuring an IS-IS SR-MPLS TE Tunnel (Explicit Path Used)....................................................................... 164
1.2.8.1 Enabling MPLS TE........................................................................................................................................................165
1.2.8.3 Configuring Basic SR-MPLS TE Functions........................................................................................................... 166
1.2.8.4 Configuring an SR-MPLS TE Explicit Path........................................................................................................... 167
1.2.8.7 Verifying the IS-IS SR-MPLS TE Tunnel Configuration....................................................................................171
1.2.9 Configuring an OSPF SR-MPLS TE Tunnel (Explicit Path Used)..................................................................... 171
1.2.9.1 Enabling MPLS TE........................................................................................................................................................172
1.2.9.3 Configuring Basic SR-MPLS TE Functions........................................................................................................... 173
1.2.9.4 Configuring an SR-MPLS TE Explicit Path........................................................................................................... 175
1.2.9.7 Verifying the OSPF SR-MPLS TE Tunnel Configuration.................................................................................. 178
1.2.10 Configuring an IS-IS SR-MPLS TE Tunnel (Path Computation on a Forwarder).................................... 179
1.2.10.1 Enabling MPLS TE..................................................................................................................................................... 179
1.2.10.2 Globally Enabling the SR Capability................................................................................................................... 180
1.2.10.3 Configuring Basic SR-MPLS TE Functions......................................................................................................... 180
1.2.10.4 Enabling the Ingress to Compute a Path.......................................................................................................... 181
1.2.10.5 Configuring an SR-MPLS TE Tunnel Interface................................................................................................. 182
1.2.10.6 Configuring the UCMP Function of the SR-MPLS TE Tunnel..................................................................... 183
1.2.10.7 Verifying the IS-IS SR-MPLS TE Tunnel Configuration................................................................................. 184
1.2.11 Configuring an OSPF SR-MPLS TE Tunnel (Path Computation on a Forwarder)...................................185
1.2.11.1 Enabling MPLS TE..................................................................................................................................................... 185
1.2.11.2 Globally Enabling the SR Capability................................................................................................................... 186
1.2.11.3 Configuring Basic SR-MPLS TE Functions......................................................................................................... 186
1.2.11.4 Enabling the Ingress to Compute a Path.......................................................................................................... 187
1.2.11.5 Configuring an SR-MPLS TE Tunnel Interface................................................................................................. 188
1.2.11.6 Configuring the UCMP Function of the SR-MPLS TE Tunnel..................................................................... 189
1.2.11.7 Verifying the OSPF SR-MPLS TE Tunnel Configuration................................................................................190
1.2.12 Configuring BGP SR..................................................................................................................................................... 190
1.2.13 Configuring an Inter-AS E2E SR-MPLS TE Tunnel (Path Computation on the Controller)................. 192
Issue draft 07 Copyright © Huawei Technologies Co., Ltd. iv

(2020-10-09)
1.2.13.1 Setting a Binding SID............................................................................................................................................... 193

1.2.13.2 Configuring an E2E SR-MPLS TE Tunnel Interface........................................................................................ 194
1.2.13.3 (Optional) Configuring SR on a PCC.................................................................................................................. 195
1.2.13.4 Verifying the Configuration of an Inter-AS E2E SR-MPLS TE Tunnel...................................................... 196
1.2.14 Configuring an Inter-AS E2E SR-MPLS TE Tunnel (Explicit Path Used)..................................................... 197
1.2.14.1 Setting a Binding SID............................................................................................................................................... 198
1.2.14.2 Configuring an SR-MPLS TE Explicit Path......................................................................................................... 198
1.2.14.3 Configuring an E2E SR-MPLS TE Tunnel Interface........................................................................................ 199
1.2.14.4 Verifying the Configuration of an Inter-AS E2E SR-MPLS TE Tunnel...................................................... 201
1.2.15 Configuring Traffic Steering into SR-MPLS TE Tunnels................................................................................... 201
1.2.16 Configuring IS-IS SR to Communicate with LDP............................................................................................... 206
1.2.17 Configuring OSPF SR to Communicate with LDP..............................................................................................208
1.2.18 Configuring IS-IS TI-LFA FRR.................................................................................................................................... 210
1.2.19 Configuring OSPF TI-LFA FRR...................................................................................................................................212
1.2.20 Configuring SBFD for SR-MPLS BE Tunnel...........................................................................................................214
1.2.21 Configuring SBFD for SR-MPLS TE LSP................................................................................................................. 215
1.2.22 Configuring SBFD for SR-MPLS TE Tunnel........................................................................................................... 217
1.2.23 Configuring BFD for SR-MPLS BE............................................................................................................................218
1.2.24 Configuring BFD for SR-MPLS BE (SR and LDP Interworking Scenario)................................................... 220
1.2.25 Configuring Static BFD for SR-MPLS TE Tunnel................................................................................................. 222
1.2.26 Configuring Static BFD for SR-MPLS TE LSP....................................................................................................... 225
1.2.27 Configuring Dynamic BFD for SR-MPLS TE LSP.................................................................................................229
1.2.28 Configuring One-Arm BFD for E2E SR-MPLS TE Tunnel................................................................................. 233
1.2.29 Configuring One-Arm BFD for E2E SR-MPLS TE LSP....................................................................................... 236
1.2.30 Configuring a Device as the Egress of an MPLS-in-UDP Tunnel..................................................................238
1.2.31 Configuring SR-MPLS BE Traffic Statistics Collection...................................................................................... 239
1.2.32 Configuring an SR-MPLS TE Policy (Manual Configuration).........................................................................240
1.2.32.1 Configuring IGP SR................................................................................................................................................... 240
1.2.32.2 Configuring an SR-MPLS TE Policy......................................................................................................................242
1.2.32.3 Configuring a BGP Extended Community.........................................................................................................243
1.2.32.4 Configuring Traffic Steering.................................................................................................................................. 247
1.2.32.5 Verifying the SR-MPLS TE Policy Configuration............................................................................................. 253
1.2.33 Configuring an SR-MPLS TE Policy (Dynamic Delivery by a Controller)...................................................253
1.2.33.1 Configuring IGP SR................................................................................................................................................... 254
1.2.33.2 Configuring BGP Peer Relationships Between the Controller and Forwarder..................................... 256
1.2.33.3 Configuring a BGP Extended Community.........................................................................................................258
1.2.33.4 Configuring Traffic Steering.................................................................................................................................. 261
1.2.33.5 Verifying the SR-MPLS TE Policy Configuration............................................................................................. 267
1.2.34 Configuring SBFD for SR-MPLS TE Policy.............................................................................................................268
1.2.35 Configuring Hot Standby for SR-MPLS TE Policy.............................................................................................. 270
1.2.36 Configuring SR-MPLS TE Policy-related Alarm Thresholds............................................................................ 271
1.2.37 Configuring SR-MPLS TE Policy Traffic Statistics Collection..........................................................................272
Issue draft 07 Copyright © Huawei Technologies Co., Ltd. v

(2020-10-09)
1.2.38 Redirecting a Public IPv4 BGP FlowSpec Route to an SR-MPLS TE Policy................................................273

1.2.38.1 Redirecting a Public IPv4 BGP FlowSpec Route to an SR-MPLS TE Policy (Manual Configuration)
......................................................................................................................................................................................................... 273
1.2.38.2 Redirecting a Public IPv4 BGP FlowSpec Route to an SR-MPLS TE Policy (Dynamic Delivery by a
Controller).................................................................................................................................................................................... 275
1.2.39 Configuring Examples for SR-MPLS BE................................................................................................................. 276
1.2.39.1 Example for Configuring L3VPN over IS-IS SR-MPLS BE............................................................................. 277
1.2.39.2 Example for Configuring L3VPN over OSPF SR-MPLS BE........................................................................... 289
1.2.39.3 Example for Configuring Non-Labeled Public BGP Routes to Recurse to an SR-MPLS BE tunnel302
1.2.39.4 Example for Configuring IS-IS SR to Communicate with LDP................................................................... 308
1.2.39.5 Example for Configuring IS-IS Anycast FRR..................................................................................................... 314
1.2.39.6 Example for Configuring SBFD to Monitor SR-MPLS BE Tunnels.............................................................320
1.2.39.7 Example for Configuring TI-LFA FRR for an SR-MPLS BE Tunnel............................................................. 328
1.2.40 Configuring Examples for SR-MPLS TE................................................................................................................. 339
1.2.40.1 Example for Configuring L3VPN over SR-MPLS TE....................................................................................... 339
1.2.40.2 Example for Configuring VPLS over SR-MPLS TE...........................................................................................350
1.2.40.3 Example for Configuring BD EVPN IRB over SR-MPLS TE...........................................................................360
1.2.40.4 Example for Configuring EVPN L3VPNv6 over SR-MPLS TE...................................................................... 376
1.2.40.5 Example for Configuring the Controller to Run NETCONF to Deliver Configurations to Create an
SR-MPLS TE Tunnel................................................................................................................................................................... 390
1.2.40.6 Example for Configuring Static BFD for SR-MPLS TE................................................................................... 397
1.2.40.7 Example for Configuring Dynamic BFD for SR-MPLS TE LSP.................................................................... 404
1.2.40.8 Example for Configuring TI-LFA FRR for a Loose SR-MPLS TE Tunnel................................................... 413
1.2.40.9 Example for Configuring an E2E SR-MPLS TE Tunnel (Explicit Path Used).......................................... 426
1.2.40.10 Example for Configuring CBTS in an L3VPN over SR-MPLS TE Scenario............................................ 441
1.2.40.11 Example for Configuring CBTS in an L3VPN over LDP over SR-MPLS TE Scenario......................... 457
1.2.40.12 Example for Configuring DSCP-Based IP Service Recursion to SR-MPLS TE Tunnels......................474
1.2.41 Configuration Examples for SR-MPLS TE Policy................................................................................................ 488
1.2.41.1 Example for Configuring L3VPN Routes to Be Recursed to Manually Configured SR-MPLS TE
Policies (Color-Based).............................................................................................................................................................. 488
1.2.41.2 Example for Configuring L3VPN Routes to Be Recursed to Manually Configured SR-MPLS TE
Policies (DSCP-Based).............................................................................................................................................................. 502
1.2.41.3 Example for Configuring L3VPN Routes to Be Recursed to Dynamically Delivered SR-MPLS TE
Policies (Color-Based).............................................................................................................................................................. 517
1.2.41.4 Example for Configuring L3VPNv6 Routes to Be Recursed to Manually Configured SR-MPLS TE
Policies........................................................................................................................................................................................... 533
1.2.41.5 Example for Configuring Non-labeled Public BGP Routes to Be Recursed to Manually Configured
SR-MPLS TE Policies.................................................................................................................................................................. 548
1.2.41.6 Example for Configuring BGP4+ 6PE Routes to Be Recursed to Manually Configured SR-MPLS TE
Policies........................................................................................................................................................................................... 559
1.2.41.7 Example for Configuring EVPN Route Recursion Based on an SR-MPLS TE Policy............................574
1.2.41.8 Example for Redirecting Public IPv4 BGP FlowSpec Routes to SR-MPLS TE Policies.........................589
2 Segment Routing IPv6....................................................................................................... 600

2.1 Segment Routing IPv6...................................................................................................................................................... 600
Issue draft 07 Copyright © Huawei Technologies Co., Ltd. vi

(2020-10-09)
2.1.1 Overview of Segment Routing IPv6..........................................................................................................................600

2.1.2 Understanding Segment Routing IPv6.................................................................................................................... 601
2.1.2.1 SRv6 Fundamentals.................................................................................................................................................... 601
2.1.2.2 SRv6 Segments............................................................................................................................................................. 604
2.1.2.3 SRv6 Nodes.................................................................................................................................................................... 610
2.1.2.4 IS-IS for SRv6................................................................................................................................................................. 611
2.1.2.5 BGP for SRv6................................................................................................................................................................. 619
2.1.2.6 SRv6 BE........................................................................................................................................................................... 624
2.1.2.6.1 L3VPNv4 over SRv6 BE........................................................................................................................................... 624
2.1.2.6.2 EVPN L3VPNv4 over SRv6 BE............................................................................................................................... 628
2.1.2.6.3 EVPN L3VPNv6 over SRv6 BE............................................................................................................................... 630
2.1.2.6.4 EVPN VPWS over SRv6 BE..................................................................................................................................... 632
2.1.2.6.5 EVPN VPLS over SRv6 BE....................................................................................................................................... 636
2.1.2.6.6 Public IP over SRv6 BE............................................................................................................................................ 642
2.1.2.7 SRv6 TE Policy............................................................................................................................................................... 645
2.1.2.7.1 SRv6 TE Policy Creation......................................................................................................................................... 646
2.1.2.7.2 Traffic Steering into an SRv6 TE Policy............................................................................................................ 648
2.1.2.7.3 SRv6 TE Policy-based Data Forwarding............................................................................................................651
2.1.2.7.4 SBFD for SRv6 TE Policy......................................................................................................................................... 652
2.1.2.7.5 SRv6 TE Policy Failover...........................................................................................................................................655
2.1.2.7.6 TTL Processing by an SRv6 TE Policy.................................................................................................................660
2.1.2.8 SRv6 TI-LFA FRR........................................................................................................................................................... 660
2.1.2.9 SRv6 Midpoint Protection......................................................................................................................................... 662
2.1.2.10 SRv6 Microloop Avoidance.....................................................................................................................................665
2.1.2.11 SRv6 OAM.................................................................................................................................................................... 673
2.1.2.11.1 SRv6 OAM Extensions.......................................................................................................................................... 673
2.1.2.11.2 SRv6 SID Ping and Tracert.................................................................................................................................. 674
2.1.2.11.3 SRv6 TE Policy Ping/Tracert................................................................................................................................ 676
2.1.2.12 SRv6 SFC....................................................................................................................................................................... 678
2.1.2.12.1 SRv6 SFC Implementation.................................................................................................................................. 678
2.1.2.12.2 SRv6 SFC Reliability............................................................................................................................................... 682
2.1.3 Terminology for Segment Routing IPv6.................................................................................................................. 686
2.2 Segment Routing IPv6 Configuration.......................................................................................................................... 687
2.2.1 Overview of Segment Routing IPv6..........................................................................................................................687
2.2.2 Segment Routing IPv6 Licensing Requirements and Configuration Precautions......................................688
2.2.3 Activating an SRv6 Port License for a Board......................................................................................................... 699
2.2.4 Configuring SRv6 BE...................................................................................................................................................... 699
2.2.4.1 Configuring L3VPNv4 over SRv6 BE...................................................................................................................... 699
2.2.4.2 Configuring EVPN L3VPN over SRv6 BE.............................................................................................................. 703
2.2.4.3 Configuring EVPN VPWS over SRv6 BE................................................................................................................ 710
2.2.4.4 Configuring EVPN VPLS over SRv6 BE..................................................................................................................715
2.2.4.5 Configuring Public IPv4 over SRv6 BE.................................................................................................................. 719
Issue draft 07 Copyright © Huawei Technologies Co., Ltd. vii

(2020-10-09)
2.2.4.6 Configuring Public IPv6 over SRv6 BE.................................................................................................................. 722

2.2.4.7 Configuring L3VPNv4 HoVPN over SRv6 BE...................................................................................................... 725
2.2.5 Configuring an SRv6 TE Policy (Manual Configuration)................................................................................... 728
2.2.5.1 Configuring SRv6 SIDs............................................................................................................................................... 728
2.2.5.2 Configuring an SRv6 TE Policy................................................................................................................................ 731
2.2.5.3 Configuring a BGP Extended Community........................................................................................................... 732
2.2.5.4 Configuring Traffic Steering.....................................................................................................................................734
2.2.5.5 Verifying the SRv6 TE Policy Configuration........................................................................................................ 738
2.2.6 Configuring an SRv6 TE Policy (Dynamic Delivery by a Controller)............................................................. 739
2.2.6.1 Configuring SRv6 SIDs............................................................................................................................................... 739
2.2.6.2 Configuring TE Attributes......................................................................................................................................... 741
2.2.6.3 Configuring IS-IS Topology Advertisement to BGP-LS.................................................................................... 744
2.2.6.4 Configuring BGP Peer Relationships Between the Controller and Forwarder........................................ 745
2.2.6.5 Configuring SRv6 TE Policy Status Advertisement to BGP-LS...................................................................... 746
2.2.6.6 Configuring a BGP Extended Community........................................................................................................... 747
2.2.6.7 Configuring Traffic Steering.....................................................................................................................................749
2.2.6.8 Verifying the SRv6 TE Policy Configuration........................................................................................................ 753
2.2.7 Configuring SRv6 TE Policy-related Services......................................................................................................... 753
2.2.7.1 Configuring L3VPNv4 over SRv6 TE Policy......................................................................................................... 753
2.2.7.2 Configuring EVPN L3VPNv4 over SRv6 TE Policy............................................................................................. 759
2.2.7.3 Configuring EVPN L3VPNv6 over SRv6 TE Policy............................................................................................. 763
2.2.7.4 Configuring EVPN VPWS over SRv6 TE Policy................................................................................................... 768
2.2.7.5 Configuring EVPN VPLS over SRv6 TE Policy..................................................................................................... 774
2.2.7.6 Configuring L3VPNv4 HoVPN over SRv6 TE Policy..........................................................................................778
2.2.7.7 Configuring a Device to Redirect IPv4 Public Network Traffic to an SRv6 TE Policy Through Multi-
Field Classification..................................................................................................................................................................... 781
2.2.7.8 Configuring a Device to Redirect IPv6 Public Network Traffic to an SRv6 TE Policy Through Multi-
Field Classification..................................................................................................................................................................... 782
2.2.8 Redirecting a Public IPv4 BGP FlowSpec Route to an SRv6 TE Policy.......................................................... 784
2.2.8.1 Redirecting a Public IPv4 BGP FlowSpec Route to an SRv6 TE Policy (Manual Configuration)...... 784
2.2.8.2 Redirecting a Public IPv4 BGP FlowSpec Route to an SRv6 TE Policy (Dynamic Delivery by a
Controller).................................................................................................................................................................................... 786
2.2.9 Configuring a TTL Processing Mode for an SRv6 TE Policy..............................................................................788
2.2.10 Configuring Headend-based Fault Detection for SRv6 TE Policies............................................................. 788
2.2.11 Configuring SBFD for SRv6 TE Policy..................................................................................................................... 790
2.2.12 Configuring Hot Standby for SRv6 TE Policy...................................................................................................... 792
2.2.13 Configuring IS-IS SRv6 TI-LFA FRR......................................................................................................................... 793
2.2.14 Configuring SRv6 Midpoint Protection..................................................................................................................795
2.2.15 Configuring SRv6 Egress Protection....................................................................................................................... 798
2.2.16 Configuring an SRv6 Path MTU............................................................................................................................... 801
2.2.17 Configuring BGP SRv6................................................................................................................................................. 803
2.2.18 Configuring OSPFv3 to Advertise a Locator Route........................................................................................... 808
2.2.19 Configuring SRv6 SFC.................................................................................................................................................. 809
Issue draft 07 Copyright © Huawei Technologies Co., Ltd. viii

(2020-10-09)
2.2.19.1 Configuring Basic SRv6 SFC Functions............................................................................................................... 809

2.2.19.2 Configuring SRv6 SFC Reliability..........................................................................................................................813
2.2.20 Using Ping/Tracert to Test an SRv6 Network...................................................................................................... 817
2.2.20.1 Using Ping to Test the Connectivity of an SRv6 Network........................................................................... 818
2.2.20.2 Using Tracert to Test the Path Information of an SRv6 Network.............................................................819
2.2.21 Maintaining SRv6..........................................................................................................................................................820
2.2.21.1 Configuring SRv6 TE Policy-related Alarm Thresholds.................................................................................820
2.2.21.2 Configuring SRv6 TE Policy Traffic Statistics Collection.............................................................................. 821
2.2.22 Configuration Examples for SRv6 BE..................................................................................................................... 822
2.2.22.1 Example for Configuring L3VPNv4 over SRv6 BE...........................................................................................822
2.2.22.2 Example for Configuring L3VPNv4 over SRv6 BE ECMP.............................................................................. 833
2.2.22.3 Example for Configuring VPN FRR for L3VPNv4 over SRv6 BE................................................................. 845
2.2.22.4 Example for Configuring EVPN L3VPNv4 over SRv6 BE.............................................................................. 857
2.2.22.5 Example for Configuring EVPN L3VPNv6 over SRv6 BE.............................................................................. 866
2.2.22.6 Example for Configuring EVPN L3VPNv6 over SRv6 BE ECMP..................................................................873
2.2.22.7 Example for Configuring VPN FRR for EVPN L3VPNv6 over SRv6 BE.....................................................885
2.2.22.8 Example for Configuring EVPN VPWS over SRv6 BE.................................................................................... 898
2.2.22.9 Example for Configuring EVPN VPWS over SRv6 BE (CE Dual-Homing in Active-Active Mode)..906
2.2.22.10 Example for Configuring EVPN VPWS over SRv6 BE (CE Dual-Homing in Single-Active Mode)
......................................................................................................................................................................................................... 920
2.2.22.11 Example for Configuring EVPN VPLS over SRv6 BE.................................................................................... 933
2.2.22.12 Example for Configuring EVPN VPLS over SRv6 BE (CE Dual-Homing)..............................................941
2.2.22.13 Example for Configuring Inter-AS L3VPNv4 over SRv6 BE....................................................................... 959
2.2.22.14 Example for Configuring L3VPNv4 HoVPN over SRv6 BE Plus SRv6 BE.............................................. 971
2.2.22.15 Example for Configuring Public IPv4 over SRv6 BE.................................................................................... 980
2.2.22.16 Example for Configuring Public IPv6 over SRv6 BE.................................................................................... 988
2.2.23 Configuration Examples for SRv6 TE Policy.........................................................................................................996
2.2.23.1 Example for Configuring L3VPNv4 over SRv6 TE Policy (Manual Configuration)............................. 996
2.2.23.2 Example for Configuring L3VPNv4 over SRv6 TE Policy to Achieve DSCP-based Traffic Steering
(Manual Configuration)........................................................................................................................................................ 1010
2.2.23.3 Example for Configuring EVPN L3VPNv4 over SRv6 TE Policy (Manual Configuration)...............1026
2.2.23.4 Example for Configuring EVPN L3VPNv6 over SRv6 TE Policy (Manual Configuration)...............1038
2.2.23.5 Example for Configuring EVPN VPWS over SRv6 TE Policy (Manual Configuration).....................1052
2.2.23.6 Example for Configuring EVPN VPLS over SRv6 TE Policy (Manual Configuration).......................1064
2.2.23.7 Example for Configuring L3VPNv4 over SRv6 TE Policy Egress Protection........................................ 1077
2.2.23.8 Example for Configuring Inter-AS L3VPNv4 over SRv6 TE Policy.......................................................... 1095
2.2.23.9 Example for Configuring an SRv6 SFC to Carry IPv4 Services (SFF-to-SF Packets Are Forwarded at
Layer 3)....................................................................................................................................................................................... 1110
2.2.23.10 Example for Configuring an SRv6 SFC to Carry IPv4 Services (SFF-to-SF Packets Are Forwarded
at Layer 2)................................................................................................................................................................................. 1122
2.2.23.11 Example for Configuring L3VPNv4 HoVPN over MPLS Plus SRv6 TE Policy....................................1130
3 EVPN.................................................................................................................................... 1146
3.1 EVPN Description............................................................................................................................................................. 1146
Issue draft 07 Copyright © Huawei Technologies Co., Ltd. ix

(2020-10-09)
3.1.1 Overview of EVPN........................................................................................................................................................ 1146

3.1.2 EVPN Fundamentals.................................................................................................................................................... 1147
3.1.3 EVPN-MPLS..................................................................................................................................................................... 1156
3.1.3.1 EVPN Multi-Homing.................................................................................................................................................1156
3.1.3.2 Fundamentals of EVPN Seamless MPLS........................................................................................................... 1159
3.1.3.3 EVPN's Service Modes............................................................................................................................................. 1174
3.1.4 EVPN-VXLAN.................................................................................................................................................................. 1177
3.1.4.1 EVPN VXLAN Fundamentals..................................................................................................................................1177
3.1.5 EVPN VPWS.................................................................................................................................................................... 1182
3.1.5.1 EVPN VPWS Fundamentals................................................................................................................................... 1182
3.1.6 PBB-EVPN........................................................................................................................................................................ 1187
3.1.6.1 PBB-EVPN Fundamentals....................................................................................................................................... 1187
3.1.6.2 Migration from an HVPLS Network to a PBB-EVPN.....................................................................................1197
3.1.7 EVPN E-Tree.................................................................................................................................................................... 1197
3.1.8 MAC Duplication Suppression for EVPN............................................................................................................... 1200
3.1.9 EVPN ORF........................................................................................................................................................................ 1203
3.1.10 IGMP Snooping over EVPN MPLS.........................................................................................................................1205
3.1.11 Application Scenarios for EVPN............................................................................................................................ 1214
3.1.11.1 Using EVPN to Interconnect Other Networks...............................................................................................1214
3.1.11.2 EVPN L3VPN HVPN................................................................................................................................................ 1214
3.1.11.3 EVPN 6VPE................................................................................................................................................................ 1219
3.1.11.4 EVPN Splicing Scenarios....................................................................................................................................... 1222
3.1.11.5 Inter-AS EVPN Option C....................................................................................................................................... 1227
3.1.11.6 DCI Scenarios........................................................................................................................................................... 1229
3.1.11.7 NFVI Distributed Gateway (SR Tunnels).........................................................................................................1243
3.1.11.8 NFVI Distributed Gateway Function (BGP VPNv4/v6 over E2E SR Tunnels)......................................1257
3.1.11.9 NFVI Distributed Gateway Function (BGP EVPN over E2E SR Tunnels).............................................. 1268
3.1.11.10 Application Scenarios for EVPN E-LAN Accessing L3VPN...................................................................... 1279
3.2 EVPN Configuration........................................................................................................................................................ 1280
3.2.1 Overview of EVPN........................................................................................................................................................ 1281
3.2.2 EVPN Licensing Requirements and Configuration Precautions.................................................................... 1282
3.2.3 Activating EVPN Interface Licenses on a Board................................................................................................. 1305
3.2.4 Configuring Common EVPN Functions................................................................................................................. 1306
3.2.4.1 Configuring an EVPN Instance............................................................................................................................. 1307
3.2.4.2 Configuring an EVPN Source Address................................................................................................................ 1309
3.2.4.3 Binding an Interface to an EVPN Instance....................................................................................................... 1310
3.2.4.4 Configuring an ESI.................................................................................................................................................... 1310
3.2.4.5 Establishing a BGP EVPN Peer Relationships.................................................................................................. 1311
3.2.4.6 (Optional) Configuring the Global Redundancy Mode............................................................................... 1314
3.2.4.7 (Optional) Configuring a BGP EVPN RR........................................................................................................... 1315
3.2.4.8 (Optional) Setting a Redundancy Mode and DF Priority per ESI Instance........................................... 1316
3.2.4.9 (Optional) Associating DF with BFD.................................................................................................................. 1318
Issue draft 07 Copyright © Huawei Technologies Co., Ltd. x

(2020-10-09)
3.2.4.10 (Optional) Improving the switching performance of broadcast traffic if the master board fails
....................................................................................................................................................................................................... 1320
3.2.4.11 Verifying the EVPN Configuration.................................................................................................................... 1320
3.2.5 Configuring BD-EVPN Functions............................................................................................................................. 1321
3.2.5.1 Configuring an EVPN Instance in BD Mode.....................................................................................................1322
3.2.5.2 Configuring an EVPN Source Address................................................................................................................ 1324
3.2.5.3 Configuring an ESI.................................................................................................................................................... 1324
3.2.5.4 Configuring a BD and Binding an EVPN Instance to the BD..................................................................... 1325
3.2.5.5 Creating an L3VPN Instance and Binding It to a VBDIF Interface........................................................... 1327
3.2.5.6 Configuring an EVPN BGP Peer Relationship.................................................................................................. 1329
3.2.5.7 (Optional)Configuring a PE's Global RedundancyMode............................................................................. 1332
3.2.5.8 (Optional) Setting a Redundancy Mode and DF Priority per ESI Instance........................................... 1333
3.2.5.9 (Optional) Configuring a BGP EVPN RR........................................................................................................... 1336
3.2.5.10 (Optional) Configuring Proxy ARP.................................................................................................................... 1337
3.2.5.11 Checking the Configurations.............................................................................................................................. 1338
3.2.6 Configuring EVPN VPWS over MPLS Functions................................................................................................. 1339
3.2.6.1 Configuring EVPN Functions................................................................................................................................. 1340
3.2.6.2 (Optional) Configuring the Global Redundancy Mode............................................................................... 1343
3.2.6.3 Configuring an EVPL Instance...............................................................................................................................1345
3.2.6.4 Configuring an AC Interface.................................................................................................................................. 1346
3.2.6.5 Configuring an MPLS LDP Tunnel....................................................................................................................... 1347
3.2.6.6 (Optional) Configuring a DF Election Mode for EVPN VPWS................................................................... 1348
3.2.6.7 (Optional) Configuring FRR...................................................................................................................................1349
3.2.6.8 Verifying the Configuration................................................................................................................................... 1351
3.2.7 Configuring an EVPN to Carry Layer 3 Services.................................................................................................1351
3.2.7.1 Configuring an L3VPN Instance........................................................................................................................... 1353
3.2.7.2 Configuring BGP EVPN Peer Relationships.......................................................................................................1355
3.2.7.3 Configuring Route Exchange Between a PE and an Access-side Device................................................1357
3.2.7.4 (Optional) Re-Encapsulating IRB (v6) Routes into the desired Routes................................................. 1358
3.2.7.5 Verifying the Configuration of an EVPN to Carry Layer 3 Services......................................................... 1358
3.2.8 Splicing a Common L3VPN with an EVPN L3VPN............................................................................................ 1359
3.2.9 Splicing a VPLS in PW Redundancy Mode with an Anycast VXLAN in an EVPN Active-Active Scenario
....................................................................................................................................................................................................... 1363
3.2.10 Configuring EVPN E-LAN over mLDP P2MP Tunnels.................................................................................... 1364
3.2.11 Configuring an EVPN Route-Policy...................................................................................................................... 1367
3.2.12 Configuring BGP EVPN Soft Reset........................................................................................................................ 1372
3.2.13 Configuring VLAN-based DF Election................................................................................................................. 1373
3.2.14 Configuring EVPN Reliability Functions..............................................................................................................1374
3.2.15 Configuring MAC Duplication Suppression for EVPN.................................................................................... 1379
3.2.16 Configuring EVPN E-Tree......................................................................................................................................... 1382
3.2.17 Configuring EVPN ORF............................................................................................................................................. 1384
3.2.18 Setting a Delay in Releasing an Obtained Label in a BGP EVPN FRR Switchover Scenario............ 1385
3.2.19 Splicing a VLL with a Common EVPN E-LAN................................................................................................... 1387
Issue draft 07 Copyright © Huawei Technologies Co., Ltd. xi

(2020-10-09)
3.2.20 Splicing a VLL with an MPLS EVPN E-Line........................................................................................................ 1389

3.2.21 Splicing VPLS and MPLS EVPN E-LAN................................................................................................................ 1392
3.2.22 Configuring EVPN E-LAN Accessing L3VPN...................................................................................................... 1395
3.2.22.1 Creating an L2VE Interface..................................................................................................................................1395
3.2.22.3 (Optional) Configuring MAC Addresses for L2VE and L3VE Interfaces............................................... 1397
3.2.22.4 Adding an L2VE Interface to a BD.................................................................................................................... 1398
3.2.22.5 Associating an L3VE Interface with a VPN Instance...................................................................................1398
3.2.22.6 Verifying the configuration of EVPN E-LAN accessing L3VPN................................................................1399
3.2.23 Configuring EVPN HVPN to Carry Layer 2 Services....................................................................................... 1399
3.2.24 Configuring MPLS EVPN Splicing with Static VXLAN.................................................................................... 1401
3.2.25 Splicing a VXLAN EVPN with a VPLS................................................................................................................... 1405
3.2.25.1 Creating VSIs and Configuring PW Connections..........................................................................................1406
3.2.25.2 Configuring a VXLAN EVPN................................................................................................................................ 1407
3.2.25.3 Establishing BGP Peer Relationships................................................................................................................ 1408
3.2.25.4 Binding EVPN Instances and VSIs to BDs....................................................................................................... 1409
3.2.25.5 (Optional) Configuring BFD for VPLS PW......................................................................................................1410
3.2.25.6 Verifying the Configuration of Splicing a VXLAN EVPN with a VPLS................................................... 1411
3.2.26 Configuring MPLS EVPN E-LAN Option B......................................................................................................... 1412
3.2.26.1 Configuring MP-IBGP Between a PE and an ASBR in the Same AS......................................................1413
3.2.26.2 Configuring MP-EBGP Between ASBRs in Different ASs........................................................................... 1414
3.2.26.3 Configuring ASBRs Not to Filter EVPN Routes Based on VPN Targets................................................ 1415
3.2.26.4 (Optional) Configuring One-Label-per-Next-Hop Label Distribution on an ASBR......................... 1416
3.2.26.5 (Optional) Configuring the Protection Switching Function..................................................................... 1416
3.2.26.6 (Optional) Configuring BGP-EVPN Route Reflection on an ASBR.........................................................1417
3.2.26.7 Verifying the Configuration MPLS EVPN E-Lan OptionB.......................................................................... 1419
3.2.27 Configuring an EVPN L3VPN HVPN.................................................................................................................... 1419
3.2.27.1 Configuring an EVPN L3VPN HoVPN...............................................................................................................1421
3.2.27.2 Configuring an EVPN L3VPN H-VPN................................................................................................................1423
3.2.27.3 Splicing an EVPN L3VPN HoVPN with a Common L3VPN.......................................................................1424
3.2.27.4 Splicing an L3VPN HoVPN with an EVPN L3VPN........................................................................................1426
3.2.27.5 Verifying the EVPN L3VPN HVPN Configuration......................................................................................... 1427
3.2.28 Configuring IGMP Snooping over EVPN MPLS................................................................................................ 1428
3.2.28.1 Configuring IGMP Snooping and Proxy.......................................................................................................... 1428
3.2.28.2 Configuring the Access Side................................................................................................................................ 1429
3.2.28.3 Verifying the Configuration................................................................................................................................. 1431
3.2.29 Splicing an EVPN L3VPN over SRv6 with a Common L3VPN over MPLS............................................... 1432
3.2.30 Configuring a Border Leaf Node to Splice an EVPN L3VPN over SRv6 TE Policy with a Common
L3VPN over MPLS .................................................................................................................................................................. 1434
3.2.31 Configuring EVPN VPLS over SRv6 Access to Each BRAS.............................................................................1437
3.2.31.3 (Optional) Configuring MAC Addresses for the L2VE and L3VE Interfaces....................................... 1439
Issue draft 07 Copyright © Huawei Technologies Co., Ltd. xii

(2020-10-09)
3.2.31.4 Associating an L2VE Interface with a BD....................................................................................................... 1439

3.2.31.5 Configuring an L3VE Interface as a BAS Interface...................................................................................... 1440
3.2.31.6 Verifying the Configuration of Configuring EVPN VPLS over SRv6 Access to BRASs......................1441
3.2.32 Configuring DCI Functions...................................................................................................................................... 1441
3.2.32.1 Configuring E2E VXLAN EVPN in a DCI scenario with Gateways Deployed...................................... 1442
3.2.32.2 Configuring a DCI Scenario with a VLAN Layer 3 Sub-interface Accessing a Common L3VPN. 1443
3.2.32.3 Configuring a DCI Scenario with a VXLAN EVPN L3VPN Accessing a Common L3VPN................1445
3.2.32.4 Configuring a DCI Scenario with a VLAN Base Accessing an MPLS EVPN IRB................................. 1448
3.2.32.5 Configuring a DCI Scenario with a VXLAN EVPN Accessing an MPLS EVPN IRB............................. 1455
3.2.32.6 Verifying the Configuration of DCI Functions...............................................................................................1459
3.2.33 Configuring the NFVI Distributed Gateway Function (SR Tunnels)......................................................... 1460
3.2.33.1 Configuring Route Recursion over SR Tunnels............................................................................................. 1463
3.2.33.2 Configuring Route Advertisement on DC-GWs............................................................................................ 1463
3.2.33.3 Configuring Route Advertisement on L2GW/L3GWs................................................................................. 1467
3.2.33.4 (Optional) Configuring the Load Balancing Function............................................................................... 1469
3.2.33.5 Verifying the Configurations of the NFVI Distributed Gateway Function...........................................1472
3.2.34 Configuring the NFVI Distributed Gateway Function (BGP VPNv4/VPNv6 over E2E SR Tunnels) 1472
3.2.34.2 Configuring Route Advertisement on PEs...................................................................................................... 1475
3.2.34.5 Configuring the Load Balancing Function......................................................................................................1482
3.2.34.6 Verifying the Configurations of the NFVI DistributedGateway Function............................................ 1484
3.2.35 Configuring the NFVI Distributed Gateway Function (BGP EVPN over E2E SR Tunnels)................. 1485
3.2.35.2 Configuring Route Advertisement on PEs...................................................................................................... 1488
3.2.35.5 Configuring the Load Balancing Function......................................................................................................1495
3.2.35.6 Verifying the Configurations of the NFVI DistributedGateway Function............................................ 1497
3.2.36 Configuration Examples for EVPN........................................................................................................................1498
3.2.36.1 Example for Configuring an Eth-Trunk Sub-Interface to Access a BD EVPN (Dual-Homing Active-
Active)......................................................................................................................................................................................... 1498
3.2.36.2 Example for Configuring an Eth-Trunk Sub-Interface to Access a BD EVPN (Dual-Homing Single-
Active)......................................................................................................................................................................................... 1513
3.2.36.3 Example for Configuring EVPN VPWS over MPLS (Dual-Homing Active-Active)............................ 1528
3.2.36.4 Example for Configuring EVPN VPWS over MPLS (Dual-Homing Single-Active)............................ 1538
3.2.36.5 Example for Setting a Redundancy Mode per ESI Instance..................................................................... 1549
3.2.36.6 Example for Configuring EVPN E-Tree............................................................................................................. 1558
3.2.36.7 Example for Configuring EVPN ORF................................................................................................................ 1567
3.2.36.8 Example for Configuring a DCI Scenario with an E2E VXLAN EVPN Deployed................................ 1580
3.2.36.9 Example for Configuring a DCI Scenario with a VXLAN EVPN L3VPN Accessing a Common L3VPN
....................................................................................................................................................................................................... 1591
Issue draft 07 Copyright © Huawei Technologies Co., Ltd. xiii

(2020-10-09)
3.2.36.10 Example for Configuring MPLS EVPN E-LAN Option B.......................................................................... 1601
3.2.36.11 Example for Configuring MPLS EVPN L3VPN E-LAN Option B............................................................ 1607
3.2.36.12 Example for Configuring Inter-AS EVPN Option C................................................................................... 1613
3.2.36.13 Example for Splicing a VXLAN EVPN with a VPLS.................................................................................... 1622
3.2.36.14 Example for Configuring EVPN E-LAN over mLDP P2MP Tunnels......................................................1631
3.2.36.15 Example for Splicing a VLL with a Common EVPN E-LAN.................................................................... 1642
3.2.36.16 Example for Splicing a VLL with an MPLS EVPN E-Line......................................................................... 1648
3.2.36.17 Example for Accessing a BD EVPN E-LAN over an MPLS Tunnel in VLAN-Aware Mode............1654
3.2.36.18 Example for Splicing VPLS with MPLS EVPN E-LAN................................................................................ 1668
3.2.36.19 Example for Configuring Co-Existence of a VPLS and an EVPN.......................................................... 1679
3.2.36.20 Example for Configuring a DCI Scenario with a VXLAN EVPN Accessing an MPLS EVPN IRB..1688
3.2.36.21 Example for Configuring a DCI Scenario with a VLAN Base Accessing an MPLS EVPN IRB (Using
EVPN-MPLS as the Bearer and PE as a GW)................................................................................................................. 1698
3.2.36.22 Example for Splicing a Common L3VPN with an EVPN L3VPN........................................................... 1707
3.2.36.23 Example for Splicing a VPLS in PW Redundancy Mode with an Anycast VXLAN in an EVPN
Active-Active Scenario........................................................................................................................................................... 1714
3.2.36.24 Example for Configuring an EVPN L3VPN HoVPN................................................................................... 1722
3.2.36.25 Example for Configuring an EVPN L3VPN H-VPN.................................................................................... 1729
3.2.36.26 Example for Splicing an EVPN L3VPN HoVPN with a Common L3VPN........................................... 1735
3.2.36.27 Example for Splicing an L3VPN HoVPN with an EVPN L3VPN............................................................ 1743
3.2.36.28 Example for Configuring IGMP Snooping over EVPN MPLS................................................................. 1751
3.2.36.29 Example for Configuring BD EVPN IRB over SR-MPLS TE......................................................................1765
3.2.36.30 Example for Configuring the IPv4 NFVI Distributed Gateway Function (SR Tunnels).................1780
3.2.36.31 Example for Configuring the IPv6 NFVI Distributed Gateway Function (SR Tunnels).................1811
3.2.36.32 Example for Configuring the IPv4 NFVI Distributed Gateway Function (BGP VPNv4 over E2E SR
Tunnels)...................................................................................................................................................................................... 1844
3.2.36.33 Example for Configuring the IPv6 NFVI Distributed Gateway Function (BGP VPNv6 over E2E SR
Tunnels)...................................................................................................................................................................................... 1873
3.2.36.34 Example for Configuring the IPv4 NFVI Distributed Gateway Function (BGP EVPN over E2E SR
Tunnels)...................................................................................................................................................................................... 1905
3.2.36.35 Example for Configuring the IPv6 NFVI Distributed Gateway Function (BGP EVPN over E2E SR
Tunnels)...................................................................................................................................................................................... 1935
3.2.36.36 Example for Configuring EVPN L3VPNv6 over SR-MPLS TE..................................................................1966
3.2.36.37 Example for Configuring an EVPN L3VPNv6 HoVPN...............................................................................1981
3.2.36.38 Example for Configuring an EVPN L3VPNv6 H-VPN................................................................................1988
3.2.36.39 Example for Splicing an EVPN L3VPNv6 HoVPN with a Common L3VPNv6.................................. 1995
3.2.36.40 Example for Configuring a DCI Scenario of VXLAN EVPN L3VPNv6 Accessing Common L3VPNv6
....................................................................................................................................................................................................... 2003
3.2.36.41 Example for Configuring a DCI Scenario with a VLAN Base Accessing MPLS EVPN IRBv6 (with a
PE Functioning as a DC-GW).............................................................................................................................................. 2014
3.2.36.42 Example for Configuring a DCI Scenario with a VXLAN EVPN Accessing MPLS EVPN IRBv6... 2023
4 VXLAN..................................................................................................................................2033
4.1 VXLAN Description.......................................................................................................................................................... 2033
4.1.1 VXLAN Introduction..................................................................................................................................................... 2033
Issue draft 07 Copyright © Huawei Technologies Co., Ltd. xiv

(2020-10-09)
4.1.2 VXLAN Basics..................................................................................................................................................................2035

4.1.2.1 VXLAN Basic Concepts............................................................................................................................................. 2035
4.1.2.2 Combinations of Underlay and Overlay Networks....................................................................................... 2038
4.1.2.3 VXLAN Packet Format............................................................................................................................................. 2039
4.1.2.4 EVPN VXLAN Fundamentals..................................................................................................................................2042
4.1.2.5 VXLAN Gateway Deployment............................................................................................................................... 2047
4.1.3 Functional Scenarios.................................................................................................................................................... 2049
4.1.3.1 Centralized VXLAN Gateway Deployment in Static Mode..........................................................................2049
4.1.3.2 Establishment of a VXLAN in Centralized Gateway Mode Using BGP EVPN....................................... 2059
4.1.3.3 Establishment of a VXLAN in Distributed Gateway Mode Using BGP EVPN....................................... 2071
4.1.4 Function Enhancements............................................................................................................................................. 2088
4.1.4.1 Establishment of a Three-Segment VXLAN for Layer 3 Communication Between DCs...................2088
4.1.4.2 Using Three-Segment VXLAN to Implement Layer 2 Interconnection Between DCs........................2093
4.1.4.3 VXLAN Active-Active Reliability............................................................................................................................2097
4.1.4.4 NFVI Distributed Gateway (Asymmetric Mode).............................................................................................2103
4.1.5 Application Scenarios for VXLAN............................................................................................................................ 2117
4.1.5.1 Application for Communication Between Terminal Users on a VXLAN................................................. 2117
4.1.5.2 Application for Communication Between Terminal Users on a VXLAN and Legacy Network.......2119
4.1.5.3 Application in VM Migration Scenarios............................................................................................................. 2120
4.1.5.4 Application for BRAS Access Through VXLAN................................................................................................. 2121
4.1.6 Terminology for VXLAN.............................................................................................................................................. 2124
4.2 VXLAN Configuration......................................................................................................................................................2124
4.2.1 Overview of VXLAN..................................................................................................................................................... 2124
4.2.2 VXLAN Licensing Requirements and Configuration Precautions................................................................. 2130
4.2.3 Activating VXLAN Interface Licenses..................................................................................................................... 2134
4.2.4 Configuring VXLAN in Centralized Gateway Mode for Static Tunnel Establishment............................2134
4.2.4.1 Configuring a VXLAN Service Access Point...................................................................................................... 2136
4.2.4.2 Configuring a VXLAN Tunnel................................................................................................................................ 2139
4.2.4.3 Configuring a Layer 3 VXLAN Gateway.............................................................................................................2140
4.2.4.4 (Optional) Configuring Static MAC Address Entries and MAC Address Limiting............................... 2141
4.2.4.5 Verifying the Configuration of VXLAN in Centralized Gateway Mode................................................... 2142
4.2.5 Configuring IPv6 VXLAN in Centralized Gateway Mode for Static Tunnel Establishment.................. 2143
4.2.5.2 Configuring an IPv6 VXLAN Tunnel.................................................................................................................... 2147
4.2.5.3 (Optional) Configuring a Layer 3 Gateway on an IPv6 VXLAN................................................................ 2148
4.2.5.4 (Optional) Configuring a Static MAC Address Entry.................................................................................... 2149
4.2.5.5 (Optional) Configuring a Limit on the Number of MAC Addresses Learned by an Interface........2149
4.2.6 Configuring VXLAN in Centralized Gateway Mode Using BGP EVPN........................................................ 2151
4.2.6.3 Configuring a Layer 3 VXLAN Gateway.............................................................................................................2161
Issue draft 07 Copyright © Huawei Technologies Co., Ltd. xv

(2020-10-09)
4.2.6.5 Verifying the Configuration of VXLAN in Centralized Gateway Mode Using BGP EVPN.................2164
4.2.7 Configuring IPv6 VXLAN in Centralized Gateway Mode Using BGP EVPN...............................................2164
4.2.7.3 (Optional) Configuring a Layer 3 Gateway on an IPv6 VXLAN................................................................ 2173
4.2.8 Configuring VXLAN in Distributed Gateway Mode Using BGP EVPN........................................................ 2176
4.2.8.3 (Optional) Configuring a VPN Instance for Route Leaking with an EVPN Instance......................... 2188
4.2.8.4 (Optional) Configuring a Layer 3 Gateway on the VXLAN........................................................................ 2190
4.2.8.5 (Optional) Configuring VXLAN Gateways to Advertise Specific Types of Routes...............................2192
4.2.8.7 Verifying the Configuration of VXLAN in Distributed Gateway Mode Using BGP EVPN................. 2196
4.2.9 Configuring IPv6 VXLAN in Distributed Gateway Mode Using BGP EVPN...............................................2196
4.2.9.3 (Optional) Configuring a VPN Instance for Route Leaking with an EVPN Instance......................... 2205
4.2.9.4 (Optional) Configuring a Layer 3 Gateway on the IPv6 VXLAN...............................................................2208
4.2.9.5 (Optional) Configuring IPv6 VXLAN Gateways to Advertise Specific Types of Routes.....................2210
4.2.10 Configuring Three-Segment VXLAN to Implement DCI................................................................................2213
4.2.10.1 Configuring Three-Segment VXLAN to Implement Layer 3 Interworking.......................................... 2214
4.2.10.2 Configuring Three-Segment VXLAN to Implement Layer 2 Interworking.......................................... 2216
4.2.10.3 Verifying the Configuration of Using Three-Segment VXLAN to Implement DCI............................2218
4.2.11 Configuring the Static VXLAN Active-Active Scenario...................................................................................2219
4.2.12 Configuring the Dynamic VXLAN Active-Active Scenario............................................................................ 2223
4.2.13 Configuring the Dynamic IPv6 VXLAN Active-Active Scenario...................................................................2226
4.2.14 Configuring BRAS Access Through a PW and a VXLAN Tunnel................................................................. 2230
4.2.15 Configuring NFVI Distributed Gateway.............................................................................................................. 2233
4.2.15.1 Configuring an L3VPN Instance on a DCGW................................................................................................ 2236
4.2.15.2 Configuring Route Advertisement on a DC-GW.......................................................................................... 2238
4.2.15.3 Configuring Route Advertisement on an L2GW/L3GW............................................................................. 2241
4.2.15.4 Configuring Load Balancing................................................................................................................................ 2243
4.2.15.5 Verifying the NFVI Distributed Gateway Configuration............................................................................ 2244
4.2.16 Maintaining VXLAN................................................................................................................................................... 2245
4.2.16.1 Configuring the VXLAN Alarm Function......................................................................................................... 2245
4.2.16.2 Collecting and Checking VXLAN Packet Statistics....................................................................................... 2246
4.2.16.3 Clearing VXLAN Packet Statistics...................................................................................................................... 2247
Issue draft 07 Copyright © Huawei Technologies Co., Ltd. xvi

(2020-10-09)
4.2.16.4 Checking Statistics about MAC Address Entries in a BD........................................................................... 2248

4.2.16.5 Clearing Statistics about Dynamic MAC Address Entries in a BD..........................................................2248
4.2.17 Configuration Examples for VXLAN..................................................................................................................... 2248
4.2.17.1 Example for Configuring Users on the Same Network Segment to Communicate Through a
VXLAN Tunnel........................................................................................................................................................................... 2248
4.2.17.2 Example for Configuring Users on Different Network Segments to Communicate Through a
VXLAN Layer 3 Gateway....................................................................................................................................................... 2253
4.2.17.3 Example for Configuring VXLAN in Centralized Gateway Mode Using BGP EVPN......................... 2258
4.2.17.4 Example for Configuring VXLAN in Distributed Gateway Mode Using BGP EVPN..........................2266
4.2.17.5 Example for Configuring IPv6 VXLAN in Distributed Gateway Mode Using BGP EVPN................2273
4.2.17.6 Example for Configuring Three-Segment VXLAN to Implement Layer 3 Interworking................. 2281
4.2.17.7 Example for Configuring Three-Segment VXLAN to Implement Layer 2 Interworking................. 2292
4.2.17.8 Example for Configuring Static VXLAN in an Active-Active Scenario (Layer 2 Communication)
....................................................................................................................................................................................................... 2300
4.2.17.9 Example for Configuring Dynamic VXLAN in an Active-Active Scenario (Layer 3 Communication)
....................................................................................................................................................................................................... 2308
4.2.17.10 Example for Configuring VXLAN over IPsec in an Active-Active Scenario........................................2319
4.2.17.11 Example for Configuring the Static VXLAN Active-Active Scenario (in VLAN-Aware Bundle
Mode).......................................................................................................................................................................................... 2332
4.2.17.12 Example for Configuring IPv4 NFVI Distributed Gateway..................................................................... 2341
4.2.17.13 Example for Configuring IPv6 NFVI Distributed Gateway..................................................................... 2360
4.2.17.14 Example for Configuring the NFVI Distributed Gateway Function (Quad-Active DC-GWs)..... 2382
4.2.17.15 Example for Configuring Three-Segment VXLAN to Implement Layer 3 Interworking (IPv6
Services)..................................................................................................................................................................................... 2415
5 Multicast VPN.................................................................................................................... 2428

5.1 Rosen MVPN Feature Description.............................................................................................................................. 2428
5.1.1 Overview of Rosen MVPN......................................................................................................................................... 2428
5.1.2 Understanding Rosen MVPN.................................................................................................................................... 2428
5.1.2.1 Concepts Related to Rosen MVPN...................................................................................................................... 2428
5.1.2.2 Inter-domain Multicast Implemented by MVPN............................................................................................ 2429
5.1.2.3 PIM Neighbor Relationships Between CEs, PEs, and Ps............................................................................... 2431
5.1.2.4 Share-MDT Setup Process...................................................................................................................................... 2433
5.1.2.5 MT Transmission Along a Share-MDT............................................................................................................... 2434
5.1.2.6 Switch-MDT Switchover.......................................................................................................................................... 2437
5.1.2.7 Multicast VPN Extranet........................................................................................................................................... 2439
5.1.2.8 BGP A-D MVPN.......................................................................................................................................................... 2445
5.1.3 Application Scenarios for Rosen MVPN................................................................................................................ 2447
5.1.3.1 Single-AS MD VPN....................................................................................................................................................2447
5.1.4 Terminology for Rosen MVPN.................................................................................................................................. 2448
5.2 NG MVPN Feature Description....................................................................................................................................2449
5.2.1 Overview of NG MVPN............................................................................................................................................... 2450
5.2.2 Understanding NG MVPN......................................................................................................................................... 2452
5.2.2.1 NG MVPN Control Messages................................................................................................................................ 2452
5.2.2.2 NG MVPN Routing.................................................................................................................................................... 2464
Issue draft 07 Copyright © Huawei Technologies Co., Ltd. xvii

(2020-10-09)
5.2.2.2.1 PIM (S, G) Join/Prune........................................................................................................................................... 2466

5.2.2.2.2 PIM (*, G) Join/Prune............................................................................................................................................2470
5.2.2.3 NG MVPN Public Network Tunnel Principle.................................................................................................... 2483
5.2.2.3.1 MVPN Membership Autodiscovery.................................................................................................................. 2486
5.2.2.3.2 I-PMSI Tunnel Establishment............................................................................................................................. 2487
5.2.2.3.3 Switching Between I-PMSI and S-PMSI Tunnels......................................................................................... 2494
5.2.2.3.4 Multicast Traffic Transmission Using NG MVPN........................................................................................ 2499
5.2.2.3.5 NG MVPN Typical Deployment Scenarios on the Public Network....................................................... 2502
5.2.2.4 NG MVPN Extranet................................................................................................................................................... 2504
5.2.2.5 UMH Route Selection Fundamentals................................................................................................................. 2508
5.2.2.6 NG MVPN Reliability................................................................................................................................................ 2509
5.2.3 Application Scenarios for NG MVPN......................................................................................................................2520
5.2.3.1 Application of NG MVPN to IPTV Services....................................................................................................... 2520
5.2.4 Terminology for NG MVPN....................................................................................................................................... 2522
5.3 BIER Description............................................................................................................................................................... 2525
5.3.1 Overview of BIER.......................................................................................................................................................... 2525
5.3.2 Understanding BIER..................................................................................................................................................... 2526
5.3.2.1 IS-IS for BIER............................................................................................................................................................... 2526
5.3.2.2 BIER Forwarding Plane Fundamentals............................................................................................................... 2528
5.3.2.3 NG MVPN over BIER................................................................................................................................................ 2530
5.3.2.3.1 Introduction to NG MVPN over BIER.............................................................................................................. 2530
5.3.2.3.2 NG MVPN over BIER Control Message...........................................................................................................2531
5.3.2.3.3 Public Network Tunnels of NG MVPN over BIER ...................................................................................... 2532
1. BIER I-PMSI Tunnel Establishment............................................................................................................................... 2532
2. BIER S-PMSI Tunnel Establishment.............................................................................................................................. 2535
5.3.2.3.4 MVPN Traffic Forwarding Through NG MVPN over BIER........................................................................2539
5.3.2.4 Application Scenarios for BIER..............................................................................................................................2541
5.3.2.4.1 BIER Application to MVPN Services.................................................................................................................2541
5.3.3 Terminology for BIER................................................................................................................................................... 2542
5.4 Rosen MVPN Configuration..........................................................................................................................................2543
5.4.1 Overview of IPv4 Multicast VPNs........................................................................................................................... 2543
5.4.2 IPv4 Multicast VPN in Rosen mode Licensing Requirements and Configuration Precautions.......... 2545
5.4.3 Configuring an MD VPN............................................................................................................................................ 2546
5.4.3.1 (Optional) Enabling IP Multicast VPN............................................................................................................... 2546
5.4.3.2 Enabling IP Multicast Routing.............................................................................................................................. 2547
5.4.3.3 Configuring a Share-Group and Binding it to an MTI..................................................................................2548
5.4.3.4 Configuring an MTI.................................................................................................................................................. 2549
5.4.3.5 (Optional) Configuring a Switch-MDT.............................................................................................................. 2551
5.4.3.6 Verifying the MD VPN Configuration................................................................................................................. 2552
5.4.4 Configuring BGP A-D Multicast VPN..................................................................................................................... 2553
5.4.5 Configuring MVPN Extranet......................................................................................................................................2555
5.4.6 Maintaining an IPv4 Multicast VPN....................................................................................................................... 2558
Issue draft 07 Copyright © Huawei Technologies Co., Ltd. xviii

(2020-10-09)
5.4.6.1 Deleting IPv4 Multicast VPN Statistics.............................................................................................................. 2558

5.4.6.2 Monitoring the Running Status of an IPv4 Multicast VPN......................................................................... 2558
5.4.6.3 Controlling the Generation of Logs.................................................................................................................... 2559
5.4.7 Configuration Examples for an IPv4 Multicast VPN......................................................................................... 2560
5.4.7.1 Example for Configuring Single-AS MD VPNs................................................................................................ 2560
5.4.7.2 Example for Configuring Multicast VPN in MDT-SAFI A-D Mode............................................................2583
5.4.7.3 Example for Configuring MVPN Extranet in the Remote Route Leaking Scenario Where a Source
VPN Instance Needs to Be Configured on a Receiver PE.......................................................................................... 2596
5.4.7.4 Example for Configuring MVPN Extranet in the Remote Route Leaking Scenario Where a Receiver
VPN Instance Needs to Be Configured on a Source PE............................................................................................. 2609
5.4.7.5 Example for Configuring MVPN Extranet in the Local Route leaking Scenario Where the Source
and Receiver VPN Instances Reside on the Same PE..................................................................................................2622
5.4.7.6 Example for Configuring MVPN Extranet in the Local Route leaking Scenario Where the Multicast
Source Belongs to the Public Network Instance.......................................................................................................... 2634
5.5 NG MVPN Configuration............................................................................................................................................... 2643
5.5.1 Overview of NG MVPN............................................................................................................................................... 2643
5.5.2 IPv4 Multicast VPN in NG MVPN mode Licensing Requirements and Configuration Precautions.. 2643
5.5.3 Configuring an Intra-AS NG MVPN........................................................................................................................ 2646
5.5.3.1 Configuring BGP MVPN Peers.............................................................................................................................. 2648
5.5.3.2 Configuring a P2MP LSP to Carry Multicast Traffic...................................................................................... 2648
5.5.3.3 Configuring PIM......................................................................................................................................................... 2652
5.5.3.4 (Optional) Configuring IGMP............................................................................................................................... 2652
5.5.3.5 (Optional) Configuring Switching Between I-PMSI and S-PMSI Tunnels..............................................2653
5.5.3.6 (Optional) Configuring NG MVPN ORF............................................................................................................ 2655
5.5.3.7 Verifying the Intra-AS NG MVPN Configuration............................................................................................ 2656
5.5.4 Configuring Intra-AS Segmented NG MVPN...................................................................................................... 2657
5.5.4.1 Configuring Route Reflection on an ABR..........................................................................................................2658
5.5.4.2 Establishing BGP MVPN Peer Relationships.................................................................................................... 2660
5.5.4.3 Configuring P2MP Tunnels to Carry Multicast Traffic..................................................................................2660
5.5.4.4 Configuring the Support for Segmented Tunnels in an AS........................................................................ 2664
5.5.4.6 Configuring PIM......................................................................................................................................................... 2667
5.5.4.8 Verifying the Configuration of Intra-AS Segmented NG MVPN............................................................... 2668
5.5.5 Configuring an Inter-AS or Inter-Area NG MVPN............................................................................................. 2669
5.5.5.1 Configuring Inter-AS NG MVPN Option B........................................................................................................ 2669
5.5.5.1.1 Configuring Global MPLS LDP Functions and Enabling MPLS LDP on Interfaces.......................... 2670
5.5.5.1.2 Configuring an Automatic mLDP P2MP Tunnel..........................................................................................2671
5.5.5.1.3 Configuring a Static RP........................................................................................................................................ 2672
5.5.5.1.4 Configuring MP-IBGP Between a PE and an ASBR in the Same AS.....................................................2674
5.5.5.1.5 Configuring MP-EBGP Between ASBRs in Different ASs.......................................................................... 2674
5.5.5.1.6 Configuring BGP MVPN Peers........................................................................................................................... 2675
5.5.5.1.7 (Optional) Configuring Intra-AS MSDP Peers............................................................................................. 2676
Issue draft 07 Copyright © Huawei Technologies Co., Ltd. xix

(2020-10-09)
5.5.5.1.8 Configuring a P2MP LSP to Carry Multicast Traffic...................................................................................2676

5.5.5.1.9 (Optional) Configuring Switching Between I-PMSI and S-PMSI Tunnels.......................................... 2679
5.5.5.1.10 Configuring PIM................................................................................................................................................... 2681
5.5.5.1.11 Configuring Route Exchange Between PEs and CEs................................................................................2682
5.5.5.2 Configuring Inter-AS NG MVPN Option C........................................................................................................ 2692
5.5.5.2.4 Configuring MP-IBGP Between a PE and an ASBR in the Same AS.....................................................2693
5.5.5.2.5 Configuring MP-EBGP for PEs and ASBRs in Different ASs.....................................................................2694
5.5.5.2.6 Configuring a Routing Policy to Control Label Distribution on ASBRs............................................... 2695
5.5.5.2.10 Configuring PIM................................................................................................................................................... 2701
5.5.5.2.11 Configuring Route Exchange Between PEs and CEs................................................................................2702
5.5.5.3 Configuring NG MVPN Option B in an Inter-AS Seamless MPLS Scenario...........................................2702
5.5.5.3.4 Configuring MP-IBGP Among PEs, ABRs, and ASBRs in the Same AS................................................ 2704
5.5.5.3.5 Configuring MP-EBGP Between ASBRs in Different ASs.......................................................................... 2705
5.5.5.3.6 Configuring a Routing Policy to Control Label Distribution on ASBRs............................................... 2706
5.5.5.3.7 Configuring Route Reflection on an ABR...................................................................................................... 2706
5.5.5.3.10 (Optional) Configuring Switching Between I-PMSI and S-PMSI Tunnels........................................ 2710
5.5.5.4 Configuring NG MVPN Option C in Inter-AS Seamless MPLS Scenarios............................................... 2712
5.5.5.4.4 Configuring MP-IBGP Among PEs, ABRs, and ASBRs in the Same AS................................................ 2714
5.5.5.4.5 Configuring MP-EBGP for PEs and ASBRs in Different ASs.....................................................................2715
5.5.5.4.6 Configuring a Routing Policy to Control Label Distribution................................................................... 2716
5.5.5.4.10 (Optional) Configuring Switching Between I-PMSI and S-PMSI Tunnels........................................ 2722
5.5.5.4.11 Configuring PIM................................................................................................................................................... 2724
5.5.5.5 Configuring Inter-Area Seamless NG MVPN................................................................................................... 2725
Issue draft 07 Copyright © Huawei Technologies Co., Ltd. xx

(2020-10-09)

5.5.5.5.7 Configuring PIM..................................................................................................................................................... 2733
5.5.5.5.8 Configuring Route Exchange Between PEs and CEs.................................................................................. 2733
5.5.6 Configuring NG MVPN Extranet.............................................................................................................................. 2733
5.5.7 Configuring UMH Route Selection Rules............................................................................................................. 2736
5.5.8 Configuring Dual-Root 1+1 Protection................................................................................................................. 2737
5.5.9 Configuration Examples for NG MVPN.................................................................................................................2740
5.5.9.1 Example for Configuring an Intra-AS NG MVPN with an mLDP P2MP LSP.........................................2740
5.5.9.2 Example for Configuring Intra-AS NG MVPN over an mLDP P2MP Tunnel Passing Through Ps. 2756
5.5.9.3 Example for Configuring an Intra-AS NG MVPN with an RSVP-TE P2MP LSP.................................... 2765
5.5.9.4 Example for Configuring Dual-Root 1+1 Protection for RSVP-TE P2MP LSPs......................................2782
5.5.9.5 Example for Configuring Dual-Root 1+1 Protection for mLDP P2MP LSPs.......................................... 2799
5.5.9.6 Example for Configuring an NG MVPN (PIM-SM MDT Setup Across the Public Network) with (*,
G) Join to Carry Multicast Traffic over an mLDP P2MP LSP.................................................................................... 2814
5.5.9.7 Example for Configuring an NG MVPN (PIM-SM MDT Setup Across the Public Network) with (*,
G) Join to Carry Multicast Traffic over an RSVP-TE P2MP LSP............................................................................... 2828
5.5.9.8 Example for Configuring an NG MVPN (PIM-SM MDT Setup Not Across the Public Network) with
(*, G) Join to Carry Multicast Traffic over an mLDP P2MP LSP.............................................................................. 2843
5.5.9.9 Example for Configuring an NG MVPN (PIM-SM MDT Setup Not Across the Public Network) with
(*, G) Join to Carry Multicast Traffic over an RSVP-TE P2MP LSP..........................................................................2854
5.5.9.10 Example for Configuring an Intra-AS NG MVPN with Segmented Tunnels.......................................2865
5.5.9.11 Example for Configuring Intra-AS Segmented Tunnel Transport (Through mLDP and RSVP-TE
P2MP Tunnel Stitching)........................................................................................................................................................ 2880
5.5.9.12 Example for Configuring Intra-AS Segmented Tunnel Transport (Through mLDP P2MP Tunnel
Stitching).................................................................................................................................................................................... 2892
5.5.9.13 Example for Configuring Intra-AS Segmented Tunnel Transport (Through RSVP-TE P2MP Tunnel
Stitching).................................................................................................................................................................................... 2903
5.5.9.14 Example for Configuring Dual-Root 1+1 Protection for Intra-AS Segmented Tunnels.................. 2916
5.5.9.15 Example for Configuring an Inter-AS NG MVPN Option B...................................................................... 2938
5.5.9.16 Example for Configuring an Inter-AS NG MVPN in Option C................................................................. 2952
5.5.9.17 Example for Configuring an Inter-AS Seamless MPLS NG MVPN Option B...................................... 2963
5.5.9.18 Example for Configuring an Inter-AS Seamless MPLS NG MVPN Option C...................................... 2976
5.5.9.19 Example for Configuring an Inter-Area Seamless MPLS NG MVPN..................................................... 2990
5.5.9.20 Example for Configuring an Inter-area NG MVPN......................................................................................3005
5.5.9.21 Example for Configuring NG MVPN Extranet in the Remote Route Leaking Scenario Where a
Source VPN Instance Needs to Be Configured on a Receiver PE............................................................................3016
5.5.9.22 Example for Configuring NG MVPN Extranet in the Remote Route Leaking Scenario (BAS
Multicast)................................................................................................................................................................................... 3028
5.5.9.23 Example for Configuring NG MVPN Extranet in the Local Cross Scenario Where the Source and
Receiver VPN Instances Reside on the Same PE.......................................................................................................... 3039
5.5.9.24 Example for Enabling the Highest IP Address to Be Selected as the UMH on an NG MVPN..... 3047
5.6 BIER Configuration.......................................................................................................................................................... 3059
Issue draft 07 Copyright © Huawei Technologies Co., Ltd. xxi

(2020-10-09)
5.6.1 Overview of BIER.......................................................................................................................................................... 3059

5.6.2 BIER Licensing Requirements and Configuration Precautions...................................................................... 3060
5.6.3 Configuring NG MVPN over BIER........................................................................................................................... 3062
5.6.3.1 Configuring BIER on the Public Network.......................................................................................................... 3064
5.6.3.2 Enabling BIER for an IGP........................................................................................................................................ 3064
5.6.3.3 Configuring BGP MVPN Peer Relationships..................................................................................................... 3065
5.6.3.4 Configuring a BIER Tunnel to Carry Multicast Traffic.................................................................................. 3066
5.6.3.6 Configuring PIM......................................................................................................................................................... 3070
5.6.3.8 Verifying the NG MVPN over BIER Configuration......................................................................................... 3072
5.6.4 Configuring the BIER Loopback Board Enhancement Function................................................................... 3072
5.6.5 Configuring a Mode for BIER-MPLS to Process and Adjust TTLs................................................................. 3073
5.6.6 Configuration Examples for NG MVPN over BIER.............................................................................................3074
5.6.6.1 Example for Configuring NG MVPN over BIER............................................................................................... 3074
5.6.6.2 Example for Configuring NG MVPN over BIER Dual-Root 1+1 Protection........................................... 3086
6 Telemetry............................................................................................................................ 3098
6.1 Telemetry Description..................................................................................................................................................... 3098
6.1.1 Overview of Telemetry................................................................................................................................................3098
6.1.2 Understanding Telemetry.......................................................................................................................................... 3099
6.1.2.1 Service Process of Static Telemetry Subscription........................................................................................... 3099
6.1.2.2 Service process of Telemetry dynamic subscription...................................................................................... 3101
6.1.2.3 Key Telemetry Technologies.................................................................................................................................. 3103
6.1.3 Application Scenarios for Telemetry...................................................................................................................... 3115
6.1.3.1 Telemetry Applications in a Traffic Adjustment Scenario........................................................................... 3115
6.1.3.2 Telemetry Application in a Microburst Traffic Detection Scenario.......................................................... 3116
6.1.4 Terminology for Telemetry........................................................................................................................................ 3117
6.2 Telemetry Configuration................................................................................................................................................ 3118
6.2.1 Overview of Telemetry................................................................................................................................................3118
6.2.2 Telemetry Licensing Requirements and Configuration Precautions............................................................3119
6.2.3 Configuring Whitelist Session-CAR for gRPC Protocol Packets.................................................................... 3126
6.2.4 Configuring Static Telemetry Subscription (IPv4 Collector).......................................................................... 3127
6.2.4.1 Configuring a Destination Collector................................................................................................................... 3128
6.2.4.2 Configuring the Data to Be Sampled or a Customized Event................................................................... 3129
6.2.4.3 Creating a Subscription........................................................................................................................................... 3131
6.2.4.4 Verifying the Telemetry Configuration.............................................................................................................. 3134
6.2.5 Configuring Dynamic Telemetry Subscription (IPv4 Collector).................................................................... 3135
6.2.6 Configuring Static Telemetry Subscription (IPv6 Collector).......................................................................... 3137
6.2.6.1 Configuring an IPv6 Destination Collector....................................................................................................... 3137
6.2.6.2 Configuring the Data to Be Sampled or a Customized Event................................................................... 3138
6.2.6.3 Creating a Subscription........................................................................................................................................... 3141
6.2.6.4 Verifying the Telemetry Configuration.............................................................................................................. 3144
Issue draft 07 Copyright © Huawei Technologies Co., Ltd. xxii

(2020-10-09)
6.2.7 Configuring Dynamic Telemetry Subscription (IPv6 Collector).................................................................... 3144

6.2.8 Configuration Examples for Telemetry..................................................................................................................3146
6.2.8.1 Example for Configuring Static Telemetry Subscription Based on gRPC............................................... 3146
6.2.8.2 Example for Configuring Static Telemetry Subscription Based on UDP.................................................3149
6.2.8.3 Example for Configuring Dynamic Telemetry Subscription Based on gRPC (IPv4 Collector).........3151
6.2.8.4 Example for Configuring Dynamic Telemetry Subscription Based on gRPC (IPv6 Collector).........3153
Issue draft 07 Copyright © Huawei Technologies Co., Ltd. xxiii

(2020-10-09)
New IP Technologies 1 Segment Routing MPLS
1 Segment Routing MPLS
1.1 Segment Routing MPLS Description
1.1.1 Overview of Segment Routing MPLS
Definition
Segment Routing (SR) is a protocol designed to forward data packets using the
source routing model. Segment Routing MPLS (SR-MPLS) is implemented based
on the MPLS forwarding plane and is referred to as SR hereinafter. SR divides a
network path into several segments and assigns a segment ID (SID) to each
segment and forwarding node. The segments and nodes are then sequentially
arranged into segment lists to form a forwarding path.
SR encapsulates segment list information that identifies a forwarding path into a

data packet header for transmission. After receiving a packet, the receive end
parses the segment list. If the SID at the top of the segment list identifies the local
node, the node removes the SID and executes the follow-up procedure. If the SID
at the top does not identify the local node, the node forwards the packet to the
next hop in equal cost multiple path (ECMP) mode.
Purpose
Network services are becoming more diverse, and their network requirements
vary. For example, real-time teleconference and live video broadcast applications
preferentially select paths with low latency and jitter, whereas big data
applications prefer high bandwidth channels with a low packet loss rate. In this
situation, the model that requires networks to adapt to services cannot keep up
with rapid service development and even complicates network deployment and
maintenance.
The solution to this issue is to enable services to drive network development and
define the network architecture. Specifically, once applications raise service
requirements, such as latency, bandwidth, and packet loss rate, a controller
Issue draft 07 Copyright © Huawei Technologies Co., Ltd. 1

(2020-10-09)
collects information covering the network topology, bandwidth usage, and latency,
and then computes explicit paths based on these requirements.
Figure 1-1 Service-driven network
For this reason, SR was introduced to help easily define an explicit path. With SR,
nodes on a network only need to maintain SR information, which enables the
network to keep up with real-time and rapid service development. SR has the
following characteristics:
● Extends existing protocols (for example, IGP) to facilitate network evolution.
● Supports both controller-based centralized control and forwarder-based
distributed control, providing a balance between the two control modes.
● Enables networks to quickly interact with upper-layer applications through the
source routing technique.
Benefits
SR offers the following benefits:
● Simplified control plane of the MPLS network
SR uses a controller or an IGP to uniformly compute paths and distribute
labels, without the need for tunneling protocols such as RSVP-TE and LDP. In
addition, it can be directly used in the MPLS architecture, without requiring
any changes to the forwarding plane.
● Efficient Topology-Independent Loop-free Alternate (TI-LFA) FRR protection
for fast path failure recovery
On the basis of remote loop-free alternate (RLFA) FRR, SR provides TI-LFA
FRR, which offers node and link protection for all topologies and addresses
the weaknesses in conventional tunnel protection techniques.
● Higher network capacity expansion capabilities
MPLS TE is a connection-oriented technology. To maintain connection status,
MPLS TE requires devices to exchange and process numerous keepalive

(2020-10-09)
packets, straining the control plane. Unlike MPLS TE, SR can control any
service path by merely performing label operations on the ingress. It does not
require transit nodes to maintain path information, thereby freeing up the
control plane.
Moreover, the SR label quantity on a network is the sum of the node quantity
and local adjacency quantity, meaning that it is related only to the network
scale, rather than the tunnel quantity or service volume.
● Smoother evolution to SDN networks
As SR is designed based on the source routing concept, it enables the ingress
node to control packet forwarding paths on a network. Moreover, it can work
with the centralized path computation module to flexibly and easily control
and adjust paths.
SR supports both legacy and SDN networks and is compatible with existing
devices, allowing existing networks to evolve smoothly to SDN networks
instead of subverting existing networks.
1.1.2 Understanding Segment Routing MPLS
1.1.2.1 Segment Routing MPLS Fundamentals
Basic Concepts
Segment Routing MPLS involves the following concepts:
● Segment routing domain: is a set of SR nodes.
● Segment ID (SID): uniquely identifies a segment. A SID is mapped to an MPLS
label on the forwarding plane.
● Segment Routing global block (SRGB): a set of user-specified global labels
reserved for Segment Routing MPLS
● Segment Routing local block (SRLB): a set of user-specified local labels
reserved for Segment Routing MPLS. These labels are configured and valid
only on the local device. However, they are advertised through an IGP.
Therefore, they are globally visible. The SRLB is mainly used for binding SIDs.

(2020-10-09)
Segment Category
Table 1-1 Segment category

Label Generation Function
Mode
Prefix Manually Identifies the prefix of a destination address.

Segment configured. An IGP floods the prefix segment to the other NEs.
The prefix segment is visible globally and takes
effect globally.
The prefix segment is identified by the prefix
segment ID (SID). A prefix SID is an offset within
the SRGB range and advertised by a source node.
The receive end uses the local SRGB to compute
label values and generate forwarding entries.
Adjacency Allocated by Identifies an adjacency on a network.

Segment the ingress An IGP floods the adjacency segment to the other
using a NEs. The adjacency segment is visible globally and
dynamic takes effect locally.
protocol. It
can also be Adjacency segment identified by the adjacency
manually segment ID (SID). The adjacency SID is a local SID
configured. out of the SRGB range.
Node Manually The node segment, a special prefix segment,

Segment configured. identifies a specific node. When an IP address is
configured for a loopback interface, the IP address
functions as the prefix SID that is a type of node
SID.
An example of Prefix SIDs, Adjacency SIDs, and Node SIDs is shown in Figure 1-2.
Figure 1-2 Prefix SID, Adjacency SID and Node SID
In simple words, a prefix SID indicates a destination address, and an adjacency SID
indicates a link over which data packets travel. The prefix and adjacency SIDs are

(2020-10-09)
similar to the destination IP address and outbound interface, respectively, in

conventional IP forwarding. In an IGP area, a network element (NE) sends
extended IGP messages to flood its own node SID and adjacency SID. Upon receipt
of the message, any NE can obtain information about the other NEs.
Combining prefix (node) SIDs and adjacency SIDs in sequence can construct any
network path. Every hop on a path identifies a next hop based on the segment
information on the top of the label stack. The segment information is stacked in
sequence at the top of the data header.
● If segment information at the stack top contains the identifier of another
node, the receive end forwards a data packet to a next hop using ECMP.
● If segment information at the stack identifies the local node, the receive end
removes the top segment and proceeds with the follow-up procedure.
In actual application, the prefix SID, adjacency SID, and node SID can be used
independently or in combinations. The following three main cases are involved.
Prefix SID
A prefix SID-based forwarding path is computed by an IGP using the SPF
algorithm. In Figure 1-3, node Z is a destination, and its prefix SID is 100. After an
IGP floods the prefix SID, all nodes in the IGP area learn the prefix SID of node Z.
Each node runs SPF to compute the shortest path to node Z. Such a path is a
smallest-cost path.
Figure 1-3 Prefix SID-based forwarding paths
If there are several paths having the same cost, they perform ECMP. If they have
different costs, they perform link backup. The prefix SID-based forwarding paths
are not fixed, and the ingress cannot control the whole forwarding path.
Adjacency SID
In Figure 1-4, an adjacency SID is assigned to each adjacency. The adjacency SIDs
are contained in a segment list defined on the ingress. The segment list is used to
strictly specify any explicit path. This mode can better implement SDN.

(2020-10-09)
Figure 1-4 Adjacency SID-based forwarding path
Adjacency SID + Node SID
In Figure 1-5, adjacency and node SIDs are combined to forcibly include a specific
adjacency into a path. Nodes can use node SIDs to compute the shortest path
based on SPF or to load-balance traffic among paths. In this mode, paths are not
strictly fixed, and therefore, they are also called loose explicit paths.
Figure 1-5 Adjacency SID + node SID-based forwarding path
SR Forwarding Mechanism
SR can be used directly in the MPLS architecture, where the forwarding
mechanism remains unchanged. SIDs are encoded as MPLS labels. The segment
list is encoded as a label stack. The segment to be processed is at the stack top.
Once a segment is processed, its label is removed from a label stack.
SR based on MPLS forwarding mechanism is also commonly called SR-MPLS.

(2020-10-09)
Label Conflicts and Handling Rules

Prefix SIDs are manually set on different devices, which may result in label
conflicts. Label conflicts consist of prefix conflicts and SID conflicts. A prefix
conflict indicates that the same prefix is associated with different SIDs, whereas a
SID conflict indicates that the same SID is associated with different prefixes.
If label conflicts occur, prefix conflicts are handled prior to SID conflicts. Then, the
following rules are observed to preferentially select a SID or prefix:
1. A prefix with a larger mask is preferred.
2. A prefix of a smaller value is preferred.
3. A smaller SID is preferred.
For example, label conflicts occur in the following four routes (in the form of
prefix/mask SID):
● a. 1.1.1.1/32 1
● b. 1.1.1.1/32 2
● c. 2.2.2.2/32 3
● d. 3.3.3.3/32 1
The process of handling the label conflicts is as follows:
1. Prefix conflicts are handled. Routes a and b encounter a prefix conflict. Route
a has a smaller SID than route b. Therefore, route a is preferred. After the
conflict is handled, the following three routes are left:
– a. 1.1.1.1/32 1
– c. 2.2.2.2/32 3
– d. 3.3.3.3/32 1
2. SID conflicts are handled. Routes a and d encounter a SID conflict. Route a
has a smaller prefix than route d. Therefore, route a is preferred. After the
conflict is handled, the following two routes are left:
– a. 1.1.1.1/32 1
– c. 2.2.2.2/32 3
1.1.2.2 IS-IS for SR-MPLS

SR-MPLS uses an IGP to advertise topology information, prefix information, a
segment routing global block (SRGB), and label information. To complete the
preceding functions, the IGP extends some TLVs of protocol packets. IS-IS mainly
defines sub-TLVs for SID and NE SR-MPLS capabilities. Table 1-2 lists the details.

(2020-10-09)
Table 1-2 IS-IS Sub-TLV extension for SID and NE SR-MPLS capabilities
Item Function Position
Prefix-SID Sub- Advertises the SR-MPLS ● IS-IS Extended IPv4

TLV prefix SID. Reachability TLV-135
● IS-IS Multitopology IPv4
Reachability TLV-235
● IS-IS IPv6 IP Reachability
TLV-236
● IS-IS Multitopology IPv6 IP
Reachability TLV-237
● SID/Label Binding TLV and
so on
Adj-SID Sub-TLV Advertises SR-MPLS ● IS-IS Extended IS reachability

Adjacency SIDs on a P2P TLV-22
network. ● IS-IS IS Neighbor Attribute
TLV-23
● IS-IS inter-AS reachability
information TLV-141
● IS-IS Multitopology IS
TLV-222
Neighbor Attribute TLV-223
LAN-Adj-SID Advertises SR-MPLS ● IS-IS Extended IS reachability

Sub-TLV Adjacency SIDs on a LAN. TLV-22
● IS-IS IS Neighbor Attribute
TLV-23
● IS-IS inter-AS reachability
information TLV-141
TLV-222
Neighbor Attribute TLV-223
SID/Label Sub- Advertises the SR-MPLS SR-Capabilities Sub-TLV and SR

TLV SID or MPLS Label. Local Block Sub-TLV
SID/Label Advertises a mapping IS-IS LSP

Binding TLV between the prefix and
SID.
SR-Capabilities Advertises the SR-MPLS IS-IS Router Capability TLV-242

Sub-TLV capabilities.
SR-Algorithm Advertises the used IS-IS Router Capability TLV-242

Sub-TLV algorithm.

(2020-10-09)
Item Function Position
SR Local Block Advertises the label scope IS-IS Router Capability TLV-242
Sub-TLV that an NE reserves for
the local SID.
IS-IS SID TLV Extensions

Prefix-SID Sub-TLV
The Prefix-SID sub-TLV carries IGP-Prefix-SID information. Figure 1-6 shows the
format of the Prefix-SID sub-TLV.
Figure 1-6 Prefix-SID Sub-TLV format
Table 1-3 Meanings of fields in the Prefix-SID Sub-TLV

Field Length Description
Name
Type 8 bits Unassigned. The recommended value is 3.
Length 8 bits Packet length.

(2020-10-09)

Name
Flags 8 bits Flags field. Figure 1-7 shows its format.
Figure 1-7 Flags field
The meaning of each flag is as follows:

● R: re-advertised flag. If this flag is set, a prefix is
imported from another protocol or is penetrated
from another level (for example, a prefix is
penetrated from an IS-IS Level 1 area to a Level 2
area).
● N: node SID flag. If this flag is set, a prefix SID
identifies a node. If a prefix SID is set to a loopback
interface address, this flag bit is set.
● P: no-PHP flag. If this flag is set, PHP is disabled so
that the penultimate node sends a labeled packet
to the egress.
● E: explicit null label flag. If this flag is set, the
explicit null label function is enabled. An upstream
neighbor must replace an existing label with an
explicit null label before forwarding a packet.
● V: value flag. If this flag is set, a prefix SID carries a
value, instead of an index. By default, the flag is
not set.
● L: local flag. If this flag is set, the value or index
carried in a prefix SID is of local significance. By
default, the flag is not set.
A node must compute an outgoing prefix label based
on the P and E flags in a prefix SID advertised by a
next hop, regardless whether the optimal path to the
prefix SID passes through the next hop. When a node
advertises reachability messages (for example, from
Level-1 to Level-2 or from Level-2 to Level-1)
generated by another IS-IS Speaker, the local node
must set the P flag and clear the E flag in a prefix SID.
The following behavior is related to P and E flags:
● If the P flag is not set, any upstream node of the
prefix SID producer must strip off the prefix SID,
which is similar to PHP in MPLS forwarding. The
MPLS EXP bit is also cleared. In addition, if the P
flag is not set, the received E flag bit is ignored.
● If the P flag is set, the following situations occur:

(2020-10-09)

Name
– If the E flag is not set, any upstream node of

the prefix SID producer must reserve the prefix
SID on the top of the label stack. This method is
used in path stitching. For example, a prefix SID
producer may use this label to forward a packet
to another MPLS LSP.
– If the E flag is set, any upstream node of the
prefix SID producer must replace the prefix SID
label with an explicit null label. In this mode,
the MPLS EXP flag is retained. If the prefix SID
producer is the destination, the node can receive
the original MPLS EXP field value. The MPLS
EXP flag can be used in QoS services.
Algorithm 8 bits Algorithm:

● 0: Shortest Path First
● 1: Strict Shortest Path First
SID/Index/ Variable This field contains either of the following information

Label length based on the V and L flags:
(variable) ● 4-byte label offset value, within an ID/label range.
In this case, V and L flags are not set.
● 3-byte local label: The 20 rightmost bits are a label
value. In this case, the V and L flags must be set.
Adj-SID Sub-TLV
An Adj-SID Sub-TLV is optional and carries IGP Adjacency SID information. Figure
1-8 shows its format.
Figure 1-8 Adj-SID Sub-TLV format
Table 1-4 Meanings of fields in the Adj-SID Sub-TLV

Name

(2020-10-09)

Name

● F: address family flag.
– 0: IPv4
– 1: IPv6
● B: backup flag. If the flag is set, an Adj-SID is used
to protect another node.
● V: value flag. If this flag is set, an Adj-SID carries a
label value. The flag is set by default.
● L: local flag. If this flag is set, the Adj-SID value or
index is of local significance. The flag is set by
default.
● S: sequence flag. If this flag is set, an Adj-SID is an
adjacency sequence.
● P: permanent label. If this flag is set, an Adj-SID is
a permanently assigned SID, which is unchanged,
regardless of a device restart or interface flapping.
Weight 8 bits Weight. The Adj-SID weight is used for load

balancing.

(variable) ● 3-byte local label: The 20 rightmost bits are a label
● 4-byte label offset value, within an ID/label range.
A designated intermediate system (DIS) is elected as a medium during IS-IS

communication on a LAN. On the LAN, an NE merely needs to advertise a link
message to the DIS and obtain all link information from the DIS, but does not
need to exchange link information between NEs.
In segment routing implementation, each NE advertises Adj-SIDs to all neighbors.
On the LAN, each NE advertises only an IS-IS Extended IS reachability TLV-22 to
the DIS and encapsulates neighbors' Adj-SIDs in a new TLV, which is a LAN-Adj-
SID Sub-TLV. The TLV contains all Adj-SID that the NE allocates to all LAN
neighbors.

(2020-10-09)
Figure 1-10 shows the format of the LAN-Adj-SID Sub-TLV.
Figure 1-10 LAN-Adj-SID Sub-TLV format
SID/Label Sub-TLV
A SID/Label Sub-TLV includes a SID or an MPLS label. The SID/Label Sub-TLV is a
part of the SR-Capabilities Sub-TLV.
Figure 1-11 shows the format of the SID/Label Sub-TLV.
Figure 1-11 SID/Label Sub-TLV format
Table 1-5 Meanings of fields in the SID/Label Sub-TLV

Name
SID/Label Variable If the Length field value is set to 3, the 20 rightmost

(variable) length bits indicate an MPLS label.
SID/Label Binding TLV

The SID/Label Binding TLV is used in communication between SR and LDP. It
defines the mapping between a prefix and a SID.
Figure 1-12 shows the SID/Label Binding TLV format.
Figure 1-12 SID/Label Binding TLV format

(2020-10-09)
Table 1-6 Meanings of fields in the SID/Label Binding TLV

Name
Flags 8 bits Flags field.

+-+-+-+-+-+-+-+-+
|F|M|S|D|A| |
+-+-+-+-+-+-+-+-+
Range 16 bits Prefix address and range of SIDs associated with the
prefix.
Prefix 8 bits Prefix length

Length
Prefix Variable Prefix.

length
SubTLVs Variable Sub-TLV, such as SID Sub-TLV and Label Sub-TLV

length
IS-IS SR Capability TLV Extension

SR-Capabilities Sub-TLV
In segment routing, each NE must be able to advertise its SR capability and global
SID range (or global label index). To meet the preceding requirement, an SR-
Capabilities Sub-TLV is defined and embed in the IS-IS Router Capability TLV-242
for transfer. The SR-Capabilities Sub-TLV can be propagated only within the same
IS-IS level area.
Figure 1-13 shows the format of the SR-Capabilities Sub-TLV.
Figure 1-13 SR-Capabilities Sub-TLV format
Table 1-7 Meanings of fields in the SR-Capabilities Sub-TLV

Name

(2020-10-09)

Name

● I: MPLS IPv4 flag. If the flag is set, SR-MPLS IPv4
packets received by all interfaces can be processed.
● V: MPLS IPv6 flag. If the flag is set, SR-MPLS IPv6
packets received by all interfaces can be processed.
Range 24 bits SRGB range.

The advertising end releases the following SR-
Capabilities in the following ranges.
SR-Capability 1:Range: 100, SID value: 100
SR-Capability 2: Range: 100, SID value: 1000
SR-Capability 3: Range: 100, SID value: 500
The receive end links the preceding ranges and

generates an SRGB.
SRGB = [100, 199]
[1000, 1099]
[500, 599]
Different label indexes may span multiple ranges.

Index 0: label 100
...
Index 99: label 199
Index 100: label 1000
...
...
SID/Label Variable See SID/Label Sub-TLV. The SRGB start value is

Sub-TLV length included. When multiple SRGBs are configured, ensure
(variable) that the SRGB sequence is correct and the SRGBs do
not overlap.
SR-Algorithm Sub-TLV
NEs use different algorithms, for example, the SPF algorithm and various SPF
variant algorithms, to compute paths to the other nodes or prefixes. The newly
defined SR-Algorithm Sub-TLV enables an NE to advertise its own algorithm. The
SR-Algorithm Sub-TLV is also carried in the IS-IS Router Capability TLV-242 for
transfer. The SR-Algorithm Sub-TLV can be propagated within the same IS-IS level.
Figure 1-15 shows the format of the SR-Algorithm Sub-TLV.

(2020-10-09)
Figure 1-15 SR-Algorithm Sub-TLV format
Table 1-8 Meanings of fields in the SR-Algorithm Sub-TLV

Name
Algorithm 8 bits Algorithm.
SR Local Block Sub-TLV

The SR Local Block Sub-TLV contains a label range that an NE reserves for local
SIDs. The local SIDs are used as adjacency SIDs or are allocated by the other
components. For example, an application (App) or a controller instructs the NE to
assign a special local SID. To notify the App or controller of available local SIDs,
the NE must advertise an SR local block SRLB.
Figure 1-16 shows the format of the SR Local Block Sub-TLV.
Figure 1-16 SR Local Block Sub-TLV format
Table 1-9 Meanings of fields in the SR Local Block Sub-TLV

Name
Flags 8 bits Flags field. This field is not defined.
Range 8 bits SRLB range.
SID/Label Variable See SID/Label Sub-TLV. The SRLB start value is

Sub-TLV length included. When multiple SRLBs are configured, ensure
(variable) that the SRLB sequence is correct and the SRLBs do
not overlap.

(2020-10-09)
The SRLB TLV advertised by the NE may contain a label range that is out of the
SRLB. Such a label range is assigned locally and is not advertised in the SRLB. For
example, an adjacency SID is assigned a local label, not a label within the SRLB
range.
1.1.2.3 OSPF for SR-MPLS
SR-MPLS uses an IGP to advertise topology information, prefix information, a

segment routing global block (SRGB), and label information. To complete the
preceding functions, the IGP extends some TLVs of protocol packets. OSPF mainly
defines sub-TLVs for SID and NE SR-MPLS capabilities. Table 1-10 describes TLVs
of the OSPF SR-MPLS extension.
Table 1-10 TLVs of the OSPF SR-MPLS extension
Type Item Function Position
TLV SR-Algorithm Advertises the used Type 10 Opaque LSA

TLV algorithm.
SID/Label Advertises the SR- Type 10 Opaque LSA

Range TLV MPLS SID or MPLS
label scope.
SRMS Advertises the priority Type 10 Opaque LSA

Preference of SR mapping server
TLV as which a local NE
functions
Sub-TLV SID/Label Advertises SR-MPLS ● SID/Label Range TLV

Sub-TLV SIDs or MPLS labels. ● OSPFv2 Extended Prefix
Opaque LSA's OSPFv2
Extended Prefix TLV
and OSPF Extended
Prefix Range TLV
● OSPFv2 Extended Link
Opaque LSA's OSPFv2
Extended Link TLV
Prefix SID Advertises the SR- OSPFv2 Extended Prefix

Sub-TLV MPLS prefix SID. Opaque LSA's OSPFv2
Extended Prefix TLV and
OSPF Extended Prefix
Range TLV
Adj-SID Sub- Advertises SR-MPLS OSPFv2 Extended Link

TLV Adjacency SIDs on a Opaque LSA's OSPFv2
P2P network. Extended Link TLV
LAN Adj-SID Advertises SR-MPLS OSPFv2 Extended Link

Sub-TLV Adjacency SIDs on a Opaque LSA's OSPFv2
LAN. Extended Link TLV

(2020-10-09)
SR-Algorithm TLV
NEs use different algorithms, for example, the SPF algorithm and various SPF
variant algorithms, to compute paths to the other nodes or prefixes. The newly
defined SR-Algorithm TLV allows an NE to advertise an algorithm in use.
Figure 1-17 shows the format of the SR-Algorithm TLV.
Figure 1-17 SR-Algorithm TLV format
Table 1-11 Fields in the SR-Algorithm TLV

Name
Type 16 bits TLV type value.
Algorithm 8 bits Algorithm.
SID/Label Range TLV

The SID/Label Range TLV is used to advertise multiple SIDs or labels at a time, or
a SID or label range.
Figure 1-18 shows the format of the SID/Label Range TLV.
Figure 1-18 SID/Label Range TLV format
Table 1-12 Fields in the SID/Label Range TLV

Name
Range Size 24 bits SRGB range.
Reserved 8 bits Reserved field.

(2020-10-09)

Name
Sub-TLV Variable The SID/Label Sub-TLV is mainly involved. The start

(variable) length value in the SID or label range is included.
This field and the Range Size field jointly determine a
SID or label range.
SRMS Preference TLV

The SRMS Preference TLV advertises the priority of the SR mapping server as
which the local node functions. The TLV is used in Sr mapping server election.
Figure 1-19 shows the format of the SRMS Preference TLV.
Figure 1-19 SRMS Preference TLV format
Table 1-13 Fields in the SRMS Preference TLV

Name
Length 4 bytes Packet length.
Preference 8 bits Priority of the SR mapping server.
SID/Label Sub-TLV
A SID/Label Sub-TLV includes a SID or an MPLS label. Figure 1-20 shows the
format of the SID/Label Sub-TLV.
Figure 1-20 SID/Label Sub-TLV format

(2020-10-09)
Table 1-14 Field in the SID/Label Sub-TLV

Name
SID/Label Variable If the Length field value is set to 3, the 20 rightmost

(variable) length bits indicate an MPLS label.
If the Length field value is set to 4, the field indicates
a 32-bit SID.
Prefix SID Sub-TLV

The Prefix-SID sub-TLV carries IGP-Prefix-SID information in the format shown in
Figure 1-21.
Figure 1-21 Prefix-SID Sub-TLV format
Table 1-15 Fields in the Prefix-SID Sub-TLV

Name

(2020-10-09)

Name

● NP: no-PHP flag. If this flag is set, PHP is disabled
so that the penultimate node sends a labeled
packet to the egress.
● M: Mapping server flag. If the flag is set, a SID is
advertised by a mapping server.
● E: explicit null label flag. If this flag is set, the
explicit null label function is enabled. An upstream
neighbor must replace an existing label with an
explicit null label before forwarding a packet.
● V: value flag. If this flag is set, a prefix SID carries a
value, instead of an index. By default, the flag is
not set.
carried in a prefix SID is of local significance. By
default, the flag is not set.
A node must compute an outgoing prefix label based
on the NP and E flags in a prefix SID advertised by a
next hop, regardless whether the optimal path to the
prefix SID passes through the next hop.
The following behavior is related to P and E flags:
● If the NP flag is not set, any upstream node of the
prefix SID producer must strip off the prefix SID,
which is similar to PHP in MPLS forwarding. The
MPLS EXP bit is also cleared. In addition, if the P
flag is not set, the received E flag bit is ignored.
● If the NP flag is set, the following situations occur:
– If the E flag is not set, any upstream node of
the prefix SID producer must reserve the prefix
SID on the top of the label stack. This method is
used in path stitching. For example, a prefix SID
producer may use this label to forward a packet
to another MPLS LSP.
– If the E flag is set, any upstream node of the
prefix SID producer must replace the prefix SID
label with an explicit null label. In this mode,

(2020-10-09)

Name
the MPLS EXP flag is retained. If the prefix SID

producer is the destination, the node can receive
the original MPLS EXP field value. The MPLS
EXP flag can be used in QoS services.
MT-ID 8 bits Multi-topology ID.
Algorithm 8 bits Algorithm:

● 0: Shortest Path First
● 1: Strict Shortest Path First

(variable) ● 4-byte label offset value, within an ID/label range.
● 3-byte local label: The 20 rightmost bits are a label
Adj-SID Sub-TLV
An Adj-SID Sub-TLV is optional and carries IGP Adjacency SID information. Figure
1-23 shows its format.
Figure 1-23 Adj-SID Sub-TLV format
Table 1-16 Field in the Adj-SID Sub-TLV

Name

(2020-10-09)

Name

● B: backup flag. If the flag is set, an Adj-SID is used
to protect another node.
● V: Value/Index flag. If this flag is set, an Adj-SID
carries a label value. If this flag is not set, an Adj-
SID carries a relative index.
● L: Local/Global flag. If this flag is set, the Adj-SID
value or index is of local significance. If this flag is
not set, the Adj-SID value or index is of global
significance.
● G: group flag. If this flag is set, an Adj-SID is an
adjacency group.
● P: permanent label. If this flag is set, an Adj-SID is
a permanently assigned SID, which is unchanged,
regardless of a device restart or interface flapping.
MT-ID 8 bits Multi-topology ID.
Weight 8 bits Weight. The Adj-SID weight is used for load

balancing.

(variable) ● 3-byte local label: The 20 rightmost bits are a label
● 4-byte label offset value, within an ID/label range.
LAN Adj-SID Sub-TLV

In segment routing implementation, each NE advertises Adj-SIDs to all neighbors.
On a broadcast, NBMA, or mixed network, the LAN-Adj-SID Sub-TLV is used to
send SID or label information to non-DR devices.

(2020-10-09)
Figure 1-25 shows the format of the LAN-Adj-SID Sub-TLV. Compared with the
Adj-SID Sub-TLV, the LAN Adj-SID Sub-TLV has an additional Neighbor ID field that
represents the router ID of a device that advertises the LAN Adj-SID Sub-TLV.
Figure 1-25 LAN-Adj-SID Sub-TLV format
1.1.2.4 BGP for SR-MPLS
IGP for SR-MPLS allocates SIDs only within an autonomous system (AS). Proper
SID orchestration in an AS facilitates the planning of an optimal path in the AS.
However, IGP for SR-MPLS does not work if paths cross multiple ASs on a large-
scale network. BGP for SR-MPLS is an extension of BGP for Segment Routing. This
function enables a device to allocate BGP peer SIDs based on BGP peer
information and report the SID information to a controller. SR-MPLS TE uses BGP
peer SIDs for path orchestration, thereby obtaining the optimal inter-AS E2E SR-
MPLS TE path. BGP for SR-MPLS involves the BGP egress peer engineering (EPE)
extension and BGP-LS extension.
BGP EPE
BGP EPE allocates BGP peer SIDs to inter-AS paths. BGP-LS advertises the BGP
peer SIDs to the controller. A forwarder that does not establish a BGP-LS peer
relationship with the controller can run BGP-LS to advertise a peer SID to a BGP
peer that has established a BGP-LS peer relationship with the controller. The BGP
peer then runs BGP-LS to advertise the peer SID to the network controller. As
shown in Figure 1-26, BGP EPE can allocate peer node segments (Peer-Node
SIDs), peer adjacency segments (Peer-Adj SIDs), and Peer-Set SIDs to peers.
● A Peer-Node SID identifies a peer node. The peers at both ends of each BGP
session are assigned Peer-Node SIDs. An EBGP peer relationship established
based on loopback interfaces may traverse multiple physical links. In this case,
the Peer-Node SID of a peer is mapped to multiple outbound interfaces.
● A Peer-Adj SID identifies an adjacency to a peer. An EBGP peer relationship
established based on loopback interfaces may traverse multiple physical links.
In this case, each adjacency is assigned a Peer-Adj SID. Only a specified link
(mapped to a specified outbound interface) can be used for forwarding.
● A Peer-Set SID identifies a group of peers that are planned as a set. BGP
allocates a Peer-Set SID to the set. Each Peer-Set SID can be mapped to
multiple outbound interfaces during forwarding. Because one peer set consists
of multiple peer nodes and peer adjacencies, the SID allocated to a peer set is
mapped to multiple Peer-Node SIDs and Peer-Adj SIDs.

(2020-10-09)
Figure 1-26 BGP EPE networking
On the network shown in Figure 1-26, ASBR1 and ASBR3 are directly connected
through two physical links. An EBGP peer relationship is established between
ASBR1 and ASBR3 through loopback interfaces. ASBR1 runs BGP EPE to assign the
Peer-Node SID 28001 to its peer (ASBR3) and to assign the Peer-Adj SIDs 18001
and 18002 to the physical links. For an EBGP peer relationship established
between directly connected physical interfaces, BGP EPE allocates a Peer-Node SID
rather than a Peer-Adj SID. For example, on the network shown in Figure 1-26,
BGP EPE allocates only Peer-Node SIDs 28002, 28003, and 28004 to the ASBR1-
ASBR5, ARBR2-ASBR4, and ASBR2-ASBR5 peer relationships, respectively.
Peer-Node SIDs and Peer-Adj SIDs are effective only on local devices. Different
devices can have the same Peer-Node SID or Peer-Adj SID. Currently, BGP EPE
supports only EBGP peers. Multi-hop EBGP peers must be directly connected
through physical links.
BGP EPE allocates SIDs to BGP peers and links, but cannot be used to construct a
forwarding tunnel. BGP peer SIDs must be used with IGP SIDs to establish an E2E
tunnel. SR-MPLS mainly involves SR LSPs (SR-MPLS BE) and SR-MPLS TE.
● SR LSPs are dynamically computed by forwarders based on intra-AS IGP SIDs.
Because peer SIDs allocated by BGP EPE cannot be used by an IGP, inter-AS SR
LSPs are not supported.
● E2E SR-MPLS TE tunnels can be established by manually specifying an explicit
path. They can also be orchestrated by a network controller provided that the
specified path contains inter-AS link information.

(2020-10-09)
Fault Association
On the network shown in Figure 1-27, intra-AS SR-MPLS TE tunnels are deployed
for AS 65001, and SBFD for SR-MPLS TE tunnel is configured. BGP EPE is
configured among ASBR1, ASBR2, and ASRB3.
Two inter-AS SR-MPLS TE tunnels are deployed between CSG1 and ASBR3. The
tunnels are orchestrated using intra-AS SIDs and inter-AS BGP SIDs. If a BGP EPE
link between ASBRs fails, CSG1, the ingress of the SR-MPLS TE tunnel, cannot
detect the failure, and therefore a traffic black hole may occur.
Currently, two methods are available for you to solve the preceding problem:
1. If a link between ASBR1 and ASBR3 fails, BGP EPE triggers SBFD for SR-MPLS
TE tunnel in the local AS to go down. This enables the ingress of the SR-MPLS
TE tunnel to rapidly detect the failure and switch traffic to another normal
tunnel, such as tunnel 2.
2. If a link between ASBR1 and ASBR3 fails, ASBR1 pops the BGP EPE label from
the received SR packet and searches the IP routing table based on the
destination address of the packet. In this way, the packet may be forwarded
to ASBR3 through the IP link ARBR1-ASBR2-ASBR3. This method applies when
no backup inter-AS SR-MPLS TE tunnels exist on the network.
NOTE
1. You can select either method as needed. Selecting both of the methods is not allowed.
2. The preceding methods are also supported if all the links corresponding to a BGP Peer-
Set SID fail.
Figure 1-27 BGP EPE fault association
BGP-LS
Inter-AS E2E SR-MPLS TE tunnels can be established by manually specifying
explicit paths, or they can be orchestrated by a controller. In a controller-based
orchestration scenario, intra- and inter-AS SIDs are reported to the controller using
BGP-LS. Inter-AS links must support TE link attribute configuration and reporting
to the controller. This enables the controller to compute primary and backup paths
based on link attributes. BGP EPE discovers network topology information and
allocates SID information. BGP-LS then packages this information into the Link
network layer reachability information (NLRI) field and reports it to the controller.
Figure 1-28 and Figure 1-29 show Link NLRI formats.

(2020-10-09)
Figure 1-28 Link NLRI format for Peer-Node and Peer-Adj SIDs advertised by BGP-
LS
Figure 1-29 Link NLRI format for Peer-Set SIDs advertised by BGP-LS

(2020-10-09)
Table 1-17 Link NLRI fields
Field Description
NLRI Network layer reachability

information. It consists of the
following parts:
● LocalDescriptor: local descriptor,
which contains a local router ID, a
local AS number, and a BGP-LS ID
● RemoteDescriptor: remote
descriptor, which contains a peer
router ID and a peer AS number
● LinkDescriptor: link descriptor,
which contains addresses used by a
BGP session
LinkAttribute Link information. It is a part of the

Link NLRI.
● Peer-Node SID: Peer-Node SID TLV
● Peer-Adj SID: Peer-Adj SID TLV
● Peer-Set SID: Peer-Set SID TLV
● Administrative Group: link
management group attribute
● Max Link BW: maximum link
bandwidth
● Max Reservable Link BW: maximum
reservable link bandwidth
● Unreserved BW: remaining link
bandwidth
● Shared Risk Link Group: SRLG
A Peer-Node SID TLV and a Peer-Adj SID TLV have the same format, Figure 1-30
shows the format of the Peer-Node SID TLV and Peer-Adj SID TLV.
Figure 1-30 Peer-Node SID TLV and Peer-Adj SID TLV format
Table 1-18 Peer-Node SID TLV and Peer-Adj SID TLV fields
Type 16 bits TLV type.

(2020-10-09)
Flags 8 bits Flags field used in a Peer-Adj SID TLV. Figure 1-31
shows the format of this field.
In this field:
● V: value flag. If this flag is set, an Adj-SID carries a
label value. By default, the flag is set.
carried by the Adj-SID has local significance. By
default, the flag is set.
Weight 8 bits Weight of the Peer-Adj SID, used for load balancing
purposes.
SID/Label/ Variable This field contains either of the following information

Index length based on the V and L flags:
(variable) ● A 3-octet local label where the 20 rightmost bits
are used for encoding the label value. In this case,
the V and L flags must be set.
● A 4-octet index defining the offset in the Segment
Routing global block (SRGB).
1.1.2.5 SR-MPLS BE
SR LSPs are established using the segment routing technique, and uses prefix or
node SIDs to guide data packet forwarding. Segment Routing Best Effort (SR-
MPLS BE) uses an IGP to run the shortest path algorithm to compute an optimal
SR LSP.
The establishment and data forwarding of SR LSPs are similar with those of LDP
LSPs. SR LSPs have no tunnel interfaces.
Creating an SR LSP
Creating an SR LSP involves the following operations:
● Devices report topology information to a controller (if the controller is used to

create an LSP) and are assigned labels.

(2020-10-09)
● The devices compute paths.

SR LSPs are created primarily using prefix labels. A destination node runs an IGP
to advertise prefix SIDs, and forwarders parse them and compute label values
based on local SRGBs. Each node then runs an IGP to collect topology information,
runs the SPF algorithm to calculate a label forwarding path, and delivers the
computed next hop and outgoing label (OuterLabel) to the forwarding table to
guide data packet forwarding.
Figure 1-32 Prefix label-based LSP establishment
Table 1-19 describes the process of using prefix labels to create an LSP shown in
Figure 1-32.
Table 1-19 LSP creation process

St Devi Operation
e ce
p
1 D An SRGB is configured on D and a prefix SID is configured on the

loopback interface of D for generation and delivery of forwarding
entries. D then encapsulates the SRGB and prefix SID into an LSP
(for example, IS-IS Router Capability TLV-242 that contains the SR-
Capabilities Sub-TLV) and floods the LSP across the whole network
through an IGP.
After receiving the LSP, other devices on the network parse the prefix
SID advertised by D, calculate the label values based on their own
SRGBs, and calculate the OuterLabel values based on the SRGBs
advertised by the next hops. They then, based on the IGP topology,
calculate label forwarding paths and generate forwarding entries.

(2020-10-09)
St Devi Operation
e ce
p
2 C C parses the prefix SID released by device D and computes a label

value based on the local SRGB (36000 to 65535). The value is
calculated using the following formula: Label = SRGB start value +
Prefix SID value = 36000 + 100 = 36100
IS-IS calculates an outgoing label based on the following formula:
OuterLabel = SRGB start value advertised by the next hop devices +
Prefix SID value = 16000 + 100 = 16100
Here, the next-hop device is device D, and device D releases the
SRGB (16000 to 65535).
3 B The calculation process is similar to C:

Label = 26000 + 100 = 26100
OuterLabel = 36000 + 100 = 36100
4 A The calculation process is similar to C:

Label = 20000 + 100 = 20100
OuterLabel = 26000 + 100 = 26100
Creating an inter-IGP area SR LSP

The following uses IS-IS as an example to describe how to establish an SR LSP in
the inter-IGP area scenario. In Figure 1-33, to establish an inter-area SR LSP, the
prefix SID must be advertised across areas by penetrating these areas. This
overcomes the restriction on IS-IS's flooding scope within each area.
Figure 1-33 Inter-IGP area SR LSP
Devices A and D are deployed in different areas, all devices run IS-IS, and Segment
Routing is deployed. An SR LSP from Device A to Device D needs to be established.
An SRGB is configured on Device D. A prefix SID is set on the loopback interface of
Device D. Device D generates and delivers forwarding entries. It encapsulates the

(2020-10-09)
SRGB and prefix SID into an LSP (for example, IS-IS Router Capability TLV-242
containing SR-Capabilities Sub-TLV) and floods the LSP across the network. Upon
receipt of the LSP, Device C parses the LSP to obtain the prefix SID, calculates and
delivers forwarding entries, and penetrates the prefix SID and prefix address to the
Level-2 area. Device B parses the LSP to obtain the prefix SID, calculates and
delivers forwarding entries, and penetrates the prefix SID and prefix address to the
Level-1 area. Device A parses the LSP and obtains the prefix SID, uses IS-IS to
collect topology information, and runs the Dijkstra algorithm to compute a label
switched path and tunnel forwarding entries.
Data Forwarding
Similar to MPLS, SR-MPLS TE operates labels by pushing, swapping, or popping
them.
● Push: After a packet enters an SR LSP, the ingress adds a label between the
Layer 2 and IP header. Alternatively, the ingress adds a label stack above the
existing label stack.
● Swap: When packets are forwarded in an SR domain, a node searches the
label forwarding table for a label assigned by a next hop and swaps the label
on the top of the label stack with the matching label in each SR packet.
● Pop: After the packets leave out of an SR-MPLS TE tunnel, a node finds an
outbound interface mapped to the label on the top of the label stack and
removes the top label.
Figure 1-34 Prefix label-based data forwarding
Table 1-20 describes the data forwarding process on the network shown in Figure
1-34.
Table 1-20 Packet forwarding process
St Devi Operation
e ce
p
1 A Receives a data packet, adds label 26100 to the packet, and

forwards the packet.
2 B Receives the labeled packet, swaps label 26100 for label 36100, and

(2020-10-09)
St Devi Operation
e ce
p
3 C Receives the labeled packet, swaps label 36100 for label 16100, and
4 D Removes label 16100 and forwards the packet along a matching

route.
PHP, MPLS QoS, and TTL

Penultimate hop popping (PHP) is enabled on the egress on which a label
becomes useless. The egress assigns a label to a penultimate node on an LSP so
that the label is removed to relieve the burden on the egress. The egress then
forwards the packet over an IP route or based on the next label.
PHP is configured on the egress. In Figure 1-34, PHP is not enabled, and NE-C is a
penultimate hop of an SR tunnel. NE-C uses a valid label to reach NE-D. If PHP is
enabled, NE-C sends a packet without an SR label to NE-D. If PHP is enabled, the
packet sent by NE-C NE-D does not carry SR labels.
Enabling PHP affects both the MPLS QoS and TTL functions on the egress. For
details, see Table 1-21.
Table 1-21 PHP, MPLS QoS, and TTL

Label Type Description MPLS EXP MPLS TTL on Scenario
(QoS) on the the Egress
Egress
explicit-null PHP is not The MPLS The MPLS TTL Label

supported. EXP field is processing is resources on
The egress reserved. QoS normal. the egress are
assigns an is supported. saved. If E2E
explicit-null services carry
label. The QoS
IPv4 explicit- attributes to
null label be contained
value is 0. in the EXP
field in a
label, an
explicit-null
can be used.

(2020-10-09)
Label Type Description MPLS EXP MPLS TTL on Scenario

(QoS) on the the Egress
Egress
implicit-null PHP is There is no There is no The

supported. MPLS EXP MPLS TTL forwarding
The egress field on the field on the burden on the
assigns an egress, and egress, so it egress is
implicit-null QoS is not cannot be reduced, and
label. The supported. copied to the forwarding
implicit-null IP TTL field. efficiency is
label value is improved.
3.
If an implicit-
null label is
distributed to
an NE, the NE
directly pops
the label
without
having to
swap an
existing label
at the top of
the stack for
it. The egress
then forwards
the packet
over an IP
route or
based on the
next label.
non-null PHP is not The MPLS The MPLS TTL Using a non-
supported. EXP field is processing is null label
The egress reserved. QoS normal. consumes a
assigns a is supported. great number
common label of resources
to a on the egress
penultimate and is not
hop. recommended
. The non-null
label helps
the egress
identify
various types
of services.
1.1.2.5.1 SR-MPLS BE and LDP Communication
As an emerging technology, SR-MPLS has received more and more attention. SR-
MPLS is introduced to simplify network deployment and management and reduce

(2020-10-09)
capital expenditure (CAPEX) and operating expenditure (OPEX). MPLS LDP is a

mainstream tunneling technique that is widely used on bearer networks. Before
LDP is completely replaced by SR-MPLS BE, LDP and SR-MPLS BE will coexist for a
long time. Interworking between an LDP network and an SR-MPLS BE network,
therefore, becomes a problem that must be addressed.
The SR-MPLS BE and LDP interworking technique allows both segment routing
and LDP to work within the same network. This technique connects an SR-MPLS
BE network to an LDP network to implement MPLS forwarding.
To implement the interworking between the LDP and SR-MPLS BE networks, the
SR-MPLS BE network must have devices that replace SR-incapable LDP devices to
advertise SIDs. Such devices are mapping servers.
● Mapping server: supports mapping between prefixes and SIDs and advertises
the mapping to a mapping client.
● Mapping client: receives mapping between prefixes and SIDs sent by the
mapping server and creates mapping entries.
Since LSPs are unidirectional, SR-MPLS BE and LDP interworking involves two
directions: SR to LDP and LDP to SR.
SR-MPLS to LDP
Figure 1-35 describes the process of creating an E2E SR-MPLS-to-LDP LSP.
Figure 1-35 Process of creating an E2E SR-MPLS-to-LDP LSP
1. The process of creating an E2E SR-MPLS-to-LDP LSP is as follows: On PE2, an

IP address prefix is configured. LDP assigns a label to the prefix. PE2 sends a
Label Mapping message upstream to P3.
2. Upon receipt of the message, P3 assigns a label to the prefix and sends a
Label Mapping message upstream to P2.

(2020-10-09)
3. Upon receipt of the message, P2 creates an LDP LSP to PE2.

4. On P2, the mapping server function is enabled so that P2 maps an LDP label
carried in the IP address prefix to a SID.
5. P2 advertises a Mapping TLV upstream to P1.
6. P1 advertises a Mapping TLV upstream to PE1.
7. PE1 parses the Mapping TLV and creates an SR LSP to P2.
8. P2 creates mapping between the SR and LDP LSPs.
During data forwarding, P2 has no SR-MPLS label destined for PE2 and
encapsulates an SR-MPLS label to an LDP label based on the mapping between
the prefix and SID.
LDP to SR-MPLS
Figure 1-36 describes the process of creating an E2E LDP-to-SR-MPLS LSP.
Figure 1-36 Process of creating an E2E LDP-to-SR-MPLS LSP
1. The process of creating an E2E LDP-to-SR-MPLS LSP is as follows: An IP

address prefix is assigned to PE1 and a SID is set for the prefix. PE1 advertises
the prefix and SID to P1 using an IGP.
2. Upon receipt of the information, P1 advertises the prefix and SID to P2 using
an IGP.
3. Upon receipt of the prefix and SID, P2 creates an SR LSP to PE1.
4. On P2, proxy LDP egress is configured P2 maps a SID carried in the IP address
prefix to an LDP label. Once proxy LDP egress is configured and the route to
the peer is reachable, a local node sends a Label Mapping message upstream.

(2020-10-09)
5. P2 sends a Label Mapping message upstream to P3, and P3 sends a Label

Mapping message upstream to PE2.
6. PE2 parses the received Label Mapping message and creates an LDP LSP to
P2.
7. P2 creates mapping between the SR and LDP LSPs.
During data forwarding, P2 has no LDP label destined for PE1 and encapsulates an
LDP label to an SR-MPLS label based on the mapping between the prefix and SID.
1.1.2.6 SR-MPLS TE
Segment Routing-MPLS Traffic Engineering (SR-MPLS TE) is a new Multiprotocol

Label Switching (MPLS) Traffic Engineering (TE) tunneling technique implemented
based on an Interior Gateway Protocol (IGP) extension. The controller calculates a
path for an SR-MPLS TE tunnel and forwards a computed label stack to the
ingress configured on a forwarder. The ingress uses the label stack to generate an
LSP in the SR-MPLS TE tunnel. Therefore, the label stack is used to control the
path along which packets are transmitted on a network.
SR-MPLS TE Advantages
SR-MPLS TE tunnels are capable of meeting the requirements for rapid
development of software-defined networking (SDN), which Resource Reservation
Protocol-TE (RSVP-TE) tunnels are unable to meet. Table 1-22 describes the
comparison between SR-MPLS TE and RSVP-TE.
Table 1-22 Comparison between SR-MPLS TE and RSVP-TE tunnels
Item SR-MPLS TE RSVP-TE
Label The extended IGP assigns and MPLS allocates and distributes
allocatio distributes labels. Each link is labels. Each LSP is assigned a
n assigned only a single label, and label, which consumes a great
all LSPs share the label, which number of labels resources and
reduces resource consumption results in heavy workloads
and maintenance workload of maintaining label forwarding
label forwarding tables. tables.
Control An IGP is used, which reduces the RSVP-TE is used, and the control
plane number of protocols to be used. plane is complex.
Scalabili High scalability. Tunnel Poor scalability. It needs to

ty information is carried in packets, maintain tunnel status
so an intermediate device cannot information and forwarding
discern an SR-MPLS TE tunnel. entries.
This eliminates the need to
maintain tunnel status
information. Forwarding entries
are only maintained, improving
scalability.

(2020-10-09)
Item SR-MPLS TE RSVP-TE
Path A service path can be controlled Whether it is a normal service

adjustm by operating a label only on the adjustment or a passive path
ent and ingress. Configurations do not adjustment of a fault scenario,
control need to be delivered to each the configurations must be
node, which improves delivered to each node.
programmability.
When a node in the path fails,
the controller recalculates the
path and updates the label stack
of the ingress node to complete
the path adjustment.
Related Concepts
Label Stack
A label stack is a set of Adjacency Segment labels in the form of a stack stored in
a packet header. Each Adjacency SID label in the stack identifies an adjacency to a
local node, and the label stack describes all adjacencies along an SR-MPLS TE LSP.
In packet forwarding, a node searches for an adjacency mapped to each Adjacency
Segment label in a packet, removes the label, and forwards the packet. After all
labels are removed from the label stack, the packet is sent out of an SR-MPLS TE
tunnel.
Stick Label and Stick Node
If a label stack depth exceeds that supported by a forwarder, the label stack
cannot carry all adjacency labels on a whole LSP. In this situation, the controller
assigns multiple label stacks to the forwarder. The controller delivers a label stack
to an appropriate node and assigns a special label to associate label stacks to
implement segment-based forwarding. The special label is a stitching label, and
the appropriate node is a stitching node.
The controller assigns a stitching label at the bottom of a label stack to a stitching
node. After a packet arrives at the stitching node, the stitching node swaps a label
stack associated with the stitching label based on the label-stack mapping. The
stitching node forwards the packet based on the label stack for the next segment.
1.1.2.6.1 Topology Collection and Label Allocation
Network Topology Collection

After a BGP-LS peer relationship is established between a controller and a
forwarder, the forwarder collects network topology information through an IGP
and then reports the information to the controller through BGP-LS.
Label Allocation
A forwarder allocates labels through an IGP and then reports them to a controller
through BGP-LS. SR-MPLS TE mainly uses adjacency labels (adjacency segments),

(2020-10-09)
which are allocated by the ingress, and are valid locally and unidirectional. SR-
MPLS TE can also use node labels, which are configured manually and valid
globally. Adjacency and node labels can both be propagated through an IGP. Use
the network shown in Figure 1-37 as an example. Adjacency label 9003 identifies
the PE1-to-P3 adjacency and is allocated by PE1. Adjacency label 9004 identifies
the P3-to-PE1 adjacency and is allocated by P3.
Figure 1-37 IGP-based label allocation
IGP SR is enabled on PE1, P1, P2, P3, P4, and PE2, and an IGP neighbor
relationship is established between each pair of directly connected nodes. In SR-
capable IGP instances, all IGP-enabled outbound interfaces are allocated SR
adjacency labels. These labels are flooded to the entire network through an IGP SR
extension. Taking P3 on the network shown in Figure 1-37 as an example, the
process of label allocation through an IGP is as follows:
1. P3 allocates a local dynamic label to an adjacency through an IGP. For
example, P3 allocates the adjacency label 9002 to the P3-to-P4 adjacency.
2. P3 propagates the adjacency label to the entire network through the IGP.
3. P3 generates a label forwarding entry based on the adjacency label.
4. Other nodes on the network learn the P3-propagated adjacency label through
the IGP, but do not generate label forwarding entries.
PE1, P1, P2, P3, and P4 all allocate and propagate adjacency labels and generate
label forwarding entries in the same way as P3 does. After establishing a BGP-LS
peer relationship with the controller, the nodes report collected topology
information (including SR labels) to the controller through BGP-LS.

(2020-10-09)
1.1.2.6.2 SR-MPLS TE Tunnel Establishment
SR-MPLS TE Tunnel
Segment Routing Traffic Engineering (SR-MPLS TE) runs the SR protocol and uses
TE constraints to create a tunnel.
Figure 1-38 SR-MPLS TE Tunnel
In Figure 1-38, a primary LSP is established along the path PE1->P1->P2->PE2,

and a backup path is established along the path PE1->P3->P4->PE2. The two LSPs
have the same tunnel ID of an SR-MPLS TE tunnel. The LSP originates from the
ingress, passes through transit nodes, and is terminated at the egress.
SR-MPLS TE tunnel establishment involves configuring and establishing an SR-

MPLS TE tunnel. Before an SR-MPLS TE tunnel is created, IS-IS/OSPF neighbor
relationships must be established between forwarders to implement network-layer
connectivity, to assign labels, and to collect network topology information.
Forwarders send label and network topology information to the controller, and the
controller uses the information to calculate paths. If no controller is available,
enable the CSPF path computation function on the ingress of an SR-MPLS TE
tunnel so that a forwarder runs CSPF to compute a path.
SR-MPLS TE Tunnel Configuration

SR-MPLS TE tunnel attributes are used to create tunnels. An SR-MPLS TE tunnel
can be configured on a controller or a forwarder.
● An SR-MPLS TE tunnel is configured on a controller.

The controller runs NETCONF to deliver tunnel attributes to a forwarder (as
shown in Figure 1-39). The forwarder runs PCEP to delegate the tunnel to the
controller for management.
● An SR-MPLS TE tunnel is manually configured on a forwarder.
The forwarder delegates LSPs to the controller for management.

(2020-10-09)
SR-MPLS TE Tunnel Establishment

If a service (for example, VPN) needs to be bound to an SR-MPLS TE tunnel, a
device establishes an SR-MPLS TE tunnel based on the following process, as shown
in Figure 1-39.
Figure 1-39 Networking for SR-MPLS TE tunnels established using configurations

that a controller runs NETCONF to deliver to a forwarder
The process of establishing an SR-MPLS TE tunnel is as follows:

1. The controller uses SR-MPLS TE tunnel constraints and Path Computation
Element (PCE) to calculate paths that are similar to common TE paths. Based
on the topology and Adj-SIDs, the controller combines the Adj-SIDs of the
entire path into a label stack. The label stack is the calculation result.
If the label stack depth exceeds the upper limit supported by a forwarder, the
label stack can only carry some labels, and the controller needs to divide a
label stack into multiple stacks for an entire path.
In Figure 1-39, the controller calculates a path PE1->P3->P1->P2->P4->PE2
for an SR-MPLS TE tunnel. The path is mapped to two label stacks {1003,
1006, 100} and {1005, 1009, 1010}. Label 100 is a stitching label, and the
others are adjacency labels.
2. The controller delivers the tunnel configuration information and label stack to
the forwarder through NETCONF and PCEP, respectively.
In Figure 1-39, the process of delivering label stacks on the controller is as
follows:

(2020-10-09)
a. The controller delivers label stack {1005, 1009, 1010} to P1 and assigns a
stitching label of value 100 associated with the label stack. Label 100 is
the bottom label in the label stack on PE1.
b. The controller delivers label stack {1003, 1006, 100} to the ingress PE1.
3. The forwarder uses the delivered tunnel configurations and label stacks to
establish an LSP for an SR-MPLS TE tunnel.
NOTE
An SR-MPLS TE tunnel does not support MTU negotiation. Therefore, the MTUs configured
on nodes along the SR-MPLS TE tunnel must be the same. For a manually configured SR-
MPLS TE tunnel, you can use the mtu command to manually configure the MTU under the
tunnel. If you do not manually configure the MTU, the default MTU value is 1500 bytes. On
the manual SR-MPLS TE tunnel, the smallest value in the following values takes effect:
MTU of the tunnel, MPLS MTU of the tunnel, MTU of the outbound interface, and MPLS
MTU of the outbound interface.
1.1.2.6.3 SR-MPLS TE Data Forwarding

A forwarder operates a label in a packet based on the label stack mapped to the
SR-MPLS TE LSP, searches for an outbound interface hop by hop based on the top
label of the label stack, and uses the label to guide the packet to the tunnel
destination address.
SR-MPLS TE Data Forwarding (Adjacency)

In Figure 1-40, an example is provided to describe the process of forwarding SR-
MPLS TE data with manually specified adjacency labels.

(2020-10-09)
Figure 1-40 SR-MPLS TE data packet forwarding (based on adjacency labels)
In Figure 1-40, the SR-MPLS TE path calculated by the controller is A -> B -> C ->
D -> E -> F. The path is mapped to two label stacks {1003, 1006, 100} and {1005,
1009, 1010}. The two label stacks are delivered to ingress A and stitching node C,
respectively. Label 100 is a stitching label and is associated with label stack {1005,
1009, 1010}. The other labels are adjacency labels. Process of forwarding data
packets along an SR-MPLS TE tunnel is shown as following:
1. The ingress A adds a label stack of <1003, 1006, 100>. The ingress A uses the
outer label of 1003 in the label stack to match against an adjacency and finds
A-B adjacency as an outbound interface. The ingress A then strips off label
1003 from the label stack <1003, 1006, 100> and forwards the packet
carrying the label stack <1006, 100> to downstream node B through the
outbound interface.
2. Node B uses the outer label of 1006 in the label stack to match against an
adjacency and finds B-C adjacency as an outbound interface. Node B strips off
label 1006 from the label stack {1006, 100}. The pack carrying the label stack
{100} travels through the B-to-C adjacency to the downstream node C.
3. After stitching node C receives the packet, it identifies stitching label 100 by
querying the stitching label entries, swaps the label for the associated label
stack {1005, 1009, 1010}. Stitching node C uses the top label 1005 to search
for an outbound interface connected to the C-to-D adjacency and removes
label 1005. Stitching node C forwards the packet carrying the label stack
{1009, 1010} along the C-to-D adjacency to the downstream node D. For
more details about stick label and stick node, see 1.1.2.6 SR-MPLS TE.

(2020-10-09)
4. After nodes D and E receive the packet, they treat the packet in the same way
as node B. Node E removes the last label 1010 and forwards the data packet
to node F.
5. Egress F receives the packet without a label and forwards the packet along a
route that is found in a routing table.
The preceding information shows that after adjacency labels are manually
specified, devices strictly forward the data packets hop by hop along the explicit
path designated in the label stack. This forwarding method is also called strict
explicit-path SR-MPLS TE.
SR-MPLS TE Data Forwarding (Node+Adjacency)

SR-MPLS TE in strict path mode does not support load balancing if equal-cost
paths exist. To overcome these drawbacks, node labels are introduced to SR-MPLS
TE paths.
The node+adjacency mixed label stack can be manually specified. With this stack
used, the inter-node node labels can be set. The controller runs PCEP or NETCONF
to deliver the stack to the forwarder ingress, and forwarders use the label stack to
forward packets through outbound interfaces to the destination IP address of an
LSP.
Figure 1-41 SR-MPLS TE forwarding principles (node+adjacency)
On the network shown in Figure 1-41, a node+adjacency mixed label stack is

configured. On the ingress node A, the mixed label stack is {1003, 1006, 1005,
101}. Labels 1003, 1006 and 1005 are adjacency labels, and label 101 is a node
label.

(2020-10-09)
1. Node A finds an A-B outbound interface based on label 1003 on the top of
the label stack. Node A removes label 1003 and forwards the packet to the
next hop node B.
2. Similar to node A, node B finds the outbound interface mapped to label 1006
on the top of the label stack. Node B removes label 1006 and forwards the
packet to the next hop node C.
3. Similar to node A, node C finds the outbound interface mapped to label 1005
on the top of the label stack. Node C removes label 1005 and forwards the
packet to the next hop node D.
4. Node D processes label 101 on the top of the label stack. This label is to
perform load balancing. Traffic packets are balanced on links based on 5-
tuple information.
5. After receiving node label 101, nodes E and G that are at the penultimate
hops removes labels and forwards packets to node F to complete the E2E
traffic forwarding.
The preceding information shows that after adjacency and node labels are
manually specified, a device can forward the data packets along the shortest path
or load-balance the data packets over paths. The paths are not fixed, and
therefore, this forwarding method is called loose explicit-path SR-MPLS TE.
1.1.2.6.4 SR-MPLS TE Tunnel Reliability

SR-MPLS TE tunnel reliability techniques include hot standby (HSB), in addition to
TI-LFA FRR.
SR-MPLS TE Hot-Standby
HSB indicates that once a primary LSP is established, an HSB LSP is established
immediately. The HSB LSP remains in the hot backup state. The HSB LSP protects
an entire LSP and is an E2E traffic protection measure.
In Figure 1-42, HSB is configured on the ingress A. After the ingress A creates the
primary LSP, the ingress A immediately creates an HSB LSP. An SR-MPLS TE tunnel
contains two LSPs. If the ingress detects a primary LSP fault, the ingress switches
traffic to the HSB LSP. After the primary LSP recovers, the ingress A switches traffic
back to the primary LSP. During the process, the SR-MPLS TE tunnel remains Up.

(2020-10-09)
Figure 1-42 SR-MPLS TE HSB networking
1.1.2.6.5 BFD for SR-MPLS TE

An SR-MPLS TE LSP can be successfully established after a label stack is delivered.
Moreover, it does not encounter the protocol down event, except for situations
where the label stack is withdrawn. Therefore, bidirectional forwarding detection
(BFD) needs to be deployed to help detect SR-MPLS TE LSP faults, which, if
detected, triggers a primary/backup SR-MPLS TE LSP switchover. BFD for SR-MPLS
TE is an E2E detection mechanism that rapidly detects SR-MPLS TE LSP/tunnel
faults.
Category of BFD for SR-MPLS TE

The following BFD for SR-MPLS TE modes are available:
BFD for SR-MPLS TE LSP
BFD for SR-MPLS TE LSP: With this function, traffic can be quickly switched to the
backup LSP if the primary SR-MPLS TE LSP fails. BFD for SR-MPLS TE LSP supports
both static and dynamic BFD sessions.
● Static BFD session: established by manually specifying local and remote
discriminators. The local discriminator of the local node must be equal to the
remote discriminator of the remote node, and vice versa. After such a session
is established, the intervals at which BFD packets are received and sent can be
modified.
● Dynamic BFD session: The local and remote discriminators do not need to be
manually specified. After an SR-MPLS TE tunnel goes up, a BFD session is
triggered. The devices on both ends of the BFD session negotiate the local
discriminator, remote discriminator, and intervals at which BFD packets are
received and sent.

(2020-10-09)
A BFD session is bound to an SR-MPLS TE LSP, meaning that the session is

established between the ingress and egress. In this session, the ingress sends a
BFD packet to the egress through the LSP. After receiving the packet, the egress
replies, enabling the ingress to quickly detect the link status of the LSP.
If a link fault is detected, BFD notifies the forwarding plane of the fault. The
forwarding plane then searches for a backup SR-MPLS TE LSP and switches traffic
to the LSP.
BFD for SR-MPLS TE Tunnel
BFD for SR-MPLS TE tunnel: This function works with BFD for SR-MPLS TE LSP to
achieve SR-MPLS TE tunnel status detection.
● BFD for SR-MPLS TE LSP determines whether a primary/backup LSP
switchover needs to be performed, whereas BFD for SR-MPLS TE tunnel
checks the actual tunnel status.
– If BFD for SR-MPLS TE tunnel is not configured, a device cannot detect
the actual tunnel status because the tunnel status is up by default.
– If BFD for SR-MPLS TE tunnel is configured but BFD is administratively
down, the tunnel interface status is unknown because BFD is not working
in this case.
– If BFD for SR-MPLS TE tunnel is configured and BFD is not
administratively down, the tunnel interface status is the same as the BFD
status.
● The interface status of an SR-MPLS TE tunnel is consistent with the status of
BFD for SR-MPLS TE tunnel. As BFD negotiation needs to be performed, it
takes time for BFD to go up. In general, if a new label stack is delivered for a
tunnel in the down state, it takes approximately 10 to 20 seconds for BFD to
go up. This consequently slows down hard convergence when other protection
functions are not configured for the tunnel.
BFD for SR-MPLS TE (One-Arm Mode)
If the egress does not support BFD for SR-MPLS TE, BFD sessions cannot be
created. To address this issue, configure one-arm BFD for SR-MPLS TE.
On the ingress, enable BFD and specify the one-arm mode to establish a BFD
session. After the BFD session is established, the ingress sends BFD packets to the
egress through transit nodes along an SR-MPLS TE tunnel. After receiving the BFD
packets, the forwarding plane of the egress removes MPLS labels, searches for a
route based on the destination IP address of the BFD packets, and then directly
loops back the BFD packets to the ingress for processing, thereby achieving
detection in one-arm mode.
NOTE
BFD for SR-MPLS TE packets are forwarded along a path specified using label stacks in the
forward direction, whereas their return packets are forwarded along the shortest IP path in
the reverse direction. This means that the return path of the packets is not fixed.
Furthermore, if the route of BFD return packets is unreachable, the involved tunnel may go
down. Therefore, you need to ensure that the route of BFD return packets is reachable.
Additionally, BFD does not need to be configured for the backup SR-MPLS TE LSP. This is
because the involved route re-recurses to the primary LSP after the primary LSP recovers
and the tunnel goes up again.

(2020-10-09)
Application of BFD for SR-MPLS TE

The following uses the network shown in Figure 1-43 as an example to describe
how BFD for SR-MPLS TE LSP is implemented in a scenario where VPN traffic
recurses to an SR-MPLS TE LSP.
Figure 1-43 BFD for SR-MPLS TE
Devices A, CE1, CE2, and E are deployed on the same VPN. CE2 advertises a route
to E. PE2 assigns a VPN label to E and advertises the route to PE1. PE1 installs the
route to E and the VPN label. The SR-MPLS TE LSP from PE1 to PE2 is PE1 -> P4 ->
P3 -> PE2, which is the primary LSP with the label stack <9004, 9003, 9005>.
After PE1 receives a packet sent from A to E, it finds the outbound interface of the
packet based on label 9004 and adds label 9003, label 9005, and the innermost
VPN label to the packet. If BFD is configured and a link or P device on the primary
SR-MPLS TE LSP fails, PE1 can rapidly detect the fault and switch traffic to the
backup SR-MPLS TE LSP PE1 -> P1 -> P2 -> PE2.
1.1.2.6.6 SR-MPLS TE Load Balancing
SR-MPLS TE Load Balancing

SR-MPLS TE guides data packet forwarding based on the label stack that the
ingress encapsulates into the data packets. Each adjacency label by default
identifies a specified adjacency, which means that load balancing cannot be
performed if equal-cost links exist. To address the preceding problem, SR-MPLS TE
introduces a parallel adjacency label to identify multiple equal-cost links.

(2020-10-09)
In Figure 1-44, two links between nodes B and C and the link between nodes B
and D are three equal-cost links. The same adjacency SID (for example, 1001 in
Figure 1-44) can be assigned to these links. Such an adjacency SID is called a
parallel adjacency label. Like common labels, the parallel adjacency label is also
used to compute a path.
When the data packets carrying the parallel label arrive at node B, node B parses
the parallel adjacency label and performs the hash algorithm to load-balance the
traffic over the three links, which efficiently uses network resources and prevents
network congestion.
Figure 1-44 SR-MPLS TE parallel adjacency label
A parallel adjacency label is generated without affecting the allocation of existing

adjacency labels between IGP neighbors. After the parallel adjacency label is
configured, the device advertises multiple adjacency labels to the same adjacency.
If BFD for SR-MPLS TE is used and an SR-MPLS TE parallel adjacency label is used,
BFD packets can be load-balanced, whereas each BFD packet is hashed to a single
link. If the link fails, BFD detects a link Down event even if the other links keep
working, which poses the risk of false alarms.
1.1.2.6.7 DSCP-based Tunneling for IP Packets to Enter SR-MPLS TE Tunnels

LDP over SR-MPLS TE
Background
Devices can divert packets to SR-MPLS TE tunnels with matching differentiated
service code points (DSCPs), which is a TE tunnel selection method. Unlike the
traditional method of load balancing services on TE tunnels, DSCP priority-based
forwarding gives higher-priority services higher service quality.
Existing networks face a challenge that they may fail to provide exclusive high-
quality transmission resources for higher-priority services. This is because the
policy for selecting TE tunnels is based on public network routes or VPN routes,
which causes a node to select the same tunnel for services with the same
destination IP or VPN address but with different priorities.
With this function enabled, a PE can forward IP packets to tunnels based on DSCP
values. Class-of-service based tunnel selection (CBTS) supports only eight
priorities: BE, AF1, AF2, AF3, AF4, EF, CS6, and CS7. CBTS maps service traffic
against eight priorities based on a configured traffic policy. Compared with the
CBTS-based tunneling, DSCP-based tunneling maps IP traffic's DSCP values to SR-

(2020-10-09)
MPLS TE tunnels and supports more refined priority management (0 to 63) so

that SR-MPLS TE can be more flexibly deployed based on services.
Implementation
DSCP values can be specified on the tunnel interface of a tunnel to which services
recurse so that the tunnel carries services of one or more priorities. Services with
specified priorities can only be transmitted on such tunnels, not be load-balanced
by all tunnels to which they may recurse. The service class attribute of a tunnel
can also be set to "default" so that the tunnel transmits mismatching services with
other priorities that are not specified.
Figure 1-45 illustrates DSCP-based tunneling. SR-MPLS TE tunnels between LSRA
and LSRB balance services, including high-priority video services, medium-priority
voice data services, and common Ethernet data services. The implementation of
transmitting services of each priority on a specific tunnel is as follows:
● Set the DSCP attribute for the SR-MPLS TE tunnel. Assume that the DSCP
attributes of SR-MPLS TE tunnels are 15 through 20, 5 through 10, and
default.
● Based on traffic characteristics of video services (DSCP value in IP packets),
the PE maps video traffic to SR-MPLS TE 1 and voice traffic to SR-MPLS TE 2.
According to the characteristics of Ethernet data services (DSCP values in IP
packets), the PE forwards traffic with the DSCP value set to "default" along
SR-MPLS TE 3.
NOTE
The default DSCP attribute is not a mandatory setting. If the default attribute is not
configured, mismatching services will be transmitted along a tunnel that is assigned
no DSCP attribute. If such a tunnel does not exist, these services will be transmitted
along a tunnel that is assigned the smallest DSCP value.
Figure 1-45 DSCP-based tunneling for IP packets
Usage Scenario
● SR-MPLS TE tunnel load balancing on the public network, LDP over SR-MPLS
TE, or SR-MPLS TE tunnels (non-load balancing) are configured on a PE.
● IP/L3VPN, including IPv4 and IPv6 services, is configured on a PE.
● In the VLL, VPLS, and BGP LSP over SR-MPLS TE scenarios, DSCP-based
tunneling for IP packets is not supported.

(2020-10-09)
● This function is not supported on a P.
1.1.2.7 Inter-AS E2E SR-MPLS TE
1.1.2.7.1 Binding SID
Similar to RSVP-TE tunnels, SR-MPLS TE tunnels can be used as forwarding

adjacencies. If an SR-MPLS TE tunnel is used as a forwarding adjacency and
assigned an adjacency SID (Adj-SID), the Adj-SID identifies the SR-MPLS TE tunnel
and is used to import data traffic into the SR-MPLS TE tunnel, implementing a TE
policy. The Adj-SID of the SR-MPLS TE tunnel is called a binding SID. Traffic that
uses the binding SID is bound to an SR-MPLS TE tunnel or a TE policy.
Binding SIDs are set on forwarders within an AS domain. Each binding SID
represents an intra-AS SR-MPLS TE tunnel. In Figure 1-46, a binding SID is set on
the ingress within an AS domain.
● Set binding SIDs to 6000 and 7000 on CSG1, representing label stacks {102,
203} and {110, 112, 213}, respectively.
● Set a binding SID to 8000 on ASBR3 to represent a label stack {405, 506}.
● Set a binding SID to 9000 on ASBR4 to represent a label stack {415, 516, 660}.
After binding SIDs are generated, the controller can calculate an inter-AS E2E SR-
MPLS TE tunnel using the binding SIDs and BGP peer SIDs. A static explicit path
can be configured so that an inter-AS E2E SR-MPLS TE tunnel is established over
the path. In Figure 1-46, the label stacks of the primary and backup LSPs in an
inter-AS E2E SR-MPLS TE are {6000, 3040, 8000} and {7000, 3140, 9000},
respectively. The complete label stacks are {102, 203, 3040, 405, 506} and {110,
112, 213, 3140, 415, 516, 660}.

(2020-10-09)
Figure 1-46 Binding SID schematic diagram
A binding SID is associated with a local forwarding path by specifying a local label,
and is used for NE forwarding and encapsulation. Using binding SIDs reduces the
number of labels in a label stack on an NE, which helps build an inter-AS E2E SR-
MPLS TE network.
1.1.2.7.2 E2E SR-MPLS TE Tunnel Creation
E2E SR-MPLS TE Tunnel Configuration

E2E SR-MPLS TE tunnel attributes are used to create tunnels. An E2E SR-MPLS TE
tunnel can be configured on a controller or a forwarder.
● Configure tunnels on the controller.

After an E2E SR-MPLS TE tunnel is configured on the controller, the controller
runs NETCONF to deliver tunnel attributes to a forwarder (as shown in Figure
1-47). The forwarder runs PCEP to delegate the tunnel to the controller for
management.
● Configure tunnels on a forwarder.
On the forwarder, you can specify a tunnel label stack based on an explicit
path to manually establish an E2E SR-MPLS TE tunnel. Manual E2E SR-MPLS
TE tunnel configuration is complex and cannot be automatically adjusted

(2020-10-09)
based on the network status. You are advised to configure a tunnel on the
controller.
E2E SR-MPLS TE Tunnel Establishment

If a service (for example, VPN) needs to be bound to an SR-MPLS TE tunnel, a
device establishes an E2E SR-MPLS TE tunnel based on the following process, as
shown in Figure 1-47. In the following example, the tunnel configuration on the
controller is described.
Figure 1-47 E2E SR-MPLS TE Tunnel Establishment
The process of creating a tunnel is as follows:

1. Before creating an E2E SR-MPLS TE tunnel, the controller needs to create an
SR-MPLS TE tunnel within an AS domain and has a binding SID specified for
the intra-AS tunnel. Configure BGP EPE between AS domains to generate BGP
peer SIDs. Then, each ASBR reports a BGP EPE label and network topology
information using BGP-LS.
2. The controller uses SR-MPLS TE tunnel constraints and Path Computation
Element (PCE) to calculate paths that are similar to a TE path. Based on the
topology and Adj-SIDs, the controller combines labels of the entire path into a
label stack. The label stack is the calculation result.

(2020-10-09)
In Figure 1-47, the controller calculates an SR-MPLS TE tunnel path CSG1-

>AGG1->ASBR1->ASBR3->P1->PE1. The label stack of the path is {6000, 3040,
8000}, where 6000 and 8000 are binding SID labels, and 3040 is a BGP peer
SID.
3. The controller runs NETCONF and PCEP to deliver tunnel configurations and
the label stack to the forwarder.
In Figure 1-47, the process of delivering label stacks on the controller is as
follows:
a. The controller delivers the label stacks {102, 203} and {405, 506} within
the AS domain to the ingress CSG1 and ASBR3, respectively.
b. The controller delivers the E2E SR-MPLS TE tunnel label stack {6000,
3040, 8000} to CSG1 that is the ingress of an inter-AS E2E SR-MPLS TE
tunnel.
4. CSG1 establishes an inter-AS E2E SR-MPLS TE tunnel based on the tunnel
configuration and label stack information delivered by the controller.
1.1.2.7.3 Data Forwarding on an E2E SR-MPLS TE Tunnel
A forwarder operates a label in a packet based on the label stack mapped to the
SR-MPLS TE LSP, searches for an outbound interface hop by hop based on the top
label of the label stack, and uses the label to guide the packet to the tunnel
In Figure 1-48, the controller calculates an SR-MPLS TE tunnel path CSG1->AGG1-
>ASBR1->ASBR3->P1->PE1. The label stack of the path is {6000, 3040, 8000},
where 6000 and 8000 are binding SID labels, and 3040 is a BGP peer SID.

(2020-10-09)
Figure 1-48 Data forwarding on an E2E SR-MPLS TE tunnel
The E2E SR-MPLS TE data packet forwarding process is as follows:

1. The ingress CSG1 adds a label stack {6000, 3040, 8000} to a data packet and
searches the My Local SID table based on label 6000 on the top of the label
stack. 6000 is a binding SID label and mapped to a label stack {102, 203}.
CSG1 searches for an outbound interface based on label 102, maps the label
to the CSG1->AGG1 adjacency, and then removes label 102. The packet
carries the label stack {203, 3040, 8000} and passes through the CSG1->AGG1
adjacency to the downstream AGG1.
2. After receiving the packet, AGG1 matches an adjacency against label 203 on
the top of the label stack, finds an outbound interface as the AGG1->ASBR1
adjacency, and removes label 203. The packet carries a label stack {3040,
8000} and passes through the AGG1->ASBR1 adjacency to the downstream
ASBR1.
3. After receiving the packet, AGG1 matches an adjacency against label 3040 on
the top of the label stack, finds an outbound interface as the AGG1->ASBR3
adjacency, and removes label 3040. The packet carries a label stack {8000}
and passes through the ASBR1->ASBR3 adjacency to the downstream ASBR3.
4. After receiving the packet, ASBR3 searches the My Local SID table based on
label 8000 on the top of the label stack. 8000 is a binding SID label and
mapped to a label stack {405, 506}. ASBR3 searches for an outbound interface
based on label 405, maps the label to the ASBR3->P1 adjacency, and then
removes label 405. The packet carries a label stack {506} and passes through
the ASBR3->P1 adjacency to the downstream P1.

(2020-10-09)
5. After receiving the packet, P1 matches an adjacency against label 506 on the
top of the label stack, finds an outbound interface as the P1->PE1 adjacency,
and removes label 506. The packet without a label is forwarded to the
destination PE1 through the P1->PE1 adjacency.
1.1.2.7.4 Reliability of E2E SR-MPLS TE Tunnels
E2E SR-MPLS TE Hot-Standby

Hot standby (HSB) is supported by E2E SR-MPLS TE tunnels. With HSB enabled, a
device creates an HSB LSP once creating a primary LSP. The HSB LSP remains in
the hot standby state. The HSB LSP protects an entire LSP and provides an E2E
traffic protection measure.
In Figure 1-49, HSB is configured on the ingress CGS1. After CSG1 creates the
primary LSP, it immediately creates an HSB LSP. An SR-MPLS TE tunnel contains
two LSPs. If the ingress detects a primary LSP fault, the ingress switches traffic to
the HSB LSP. After the primary LSP recovers, the ingress switches traffic back to
the primary LSP. During the process, the SR-MPLS TE tunnel remains Up.
Figure 1-49 E2E SR-MPLS TE HSB networking
In Figure 1-49, the controller calculates a path CSG1->AGG1->ASBR1->ASBR3-

>P1->PE1 for the primary LSP of an E2E SR-MPLS TE tunnel. The path is mapped
to a label stack {6000, 3040, 8000}, where 6000 and 8000 are binding SID labels,

(2020-10-09)
and 3040 is a BGP peer SID. The HSB LSP of the E2E SR-MPLS TE tunnel is
established over the path CSG1->CSG2->AGG2->ASBR2->ASBR4->P2->PE2->PE1.
This path is mapped to a label stack {7000, 3140, 9000}, where 7000 and 9000 are
binding SID labels, and 3140 is a BGP peer SID.
E2E SR-MPLS TE Tunnel Protection

In Figure 1-50, E2E SR-MPLS TE tunnel protection functions are as follows:
1. Within an AS domain: If an E2E SR-MPLS TE LSP is faulty in an AS domain, a
protection function of an intra-AS SR-MPLS TE tunnel is preferred. For
example, intra-AS SR-MPLS TE hot standby and SR-MPLS TE FRR is used. For
details, see Reliability of E2E SR-MPLS TE Tunnels.
2. E2E LSP level: Within an E2E SR-MPLS TE tunnel, an HSB LSP protects the
primary LSP to ensure that the E2E SR-MPLS TE tunnel status remains Up. The
primary LSP is monitored using one-arm BFD for E2E SR-MPLS TE LSP that
can rapidly detect faults.
3. E2E tunnel level protection: If both the primary and HSB LSPs in an E2E SR-
MPLS TE tunnel fail, one-arm BFD for E2E SR-MPLS TE tunnel quickly detects
the faults and instructs the system to set the E2E SR-MPLS TE tunnel to
Down. In this case, upper-layer applications, for example, VPN, can be
switched to another E2E SR-MPLS TE tunnel using VPN FRR.
Figure 1-50 E2E SR-MPLS TE tunnel protection networking

(2020-10-09)
1.1.2.7.5 One-Arm BFD for E2E SR-MPLS TE
E2E SR-MPLS TE does not use a protocol to establish tunnels. Once a label stack is
delivered to an SR-MPLS TE node, the node establishes an SR-MPLS TE LSP. The
LSP does not encounter the protocol Down state, except for the situation when a
label stack is withdrawn. Therefore, BFD must be used to monitor faults in the E2E
SR-MPLS TE LSP. A fault detected by BFD triggers a primary/backup SR-MPLS TE
LSP switchover. BFD for E2E SR-MPLS TE is an E2E rapid detection mechanism that
rapidly detects faults in links of an SR-MPLS TE tunnel. BFD for E2E SR-MPLS TE
modes are as follows:
● One-arm BFD for E2E SR-MPLS TE LSP: When an E2E SR-MPLS TE LSP is
established and a BFD session fails to be negotiated, the SR-MPLS TE LSP
cannot go Up. BFD for E2E SR-MPLS TE LSP rapidly triggers a primary/HSB
LSP switchover if the primary LSP fails.
● BFD for E2E SR-MPLS TE tunnel: The E2E SR-MPLS TE tunnel status is
monitored using both BFD for E2E SR-MPLS TE tunnel and BFD for E2E SR-
MPLS TE LSP.
– BFD for E2E SR-MPLS TE LSP controls the primary/HSB LSP switchover
and switchback status, whereas BFD for E2E SR-MPLS TE tunnel controls
the effective status of a tunnel. If BFD for E2E SR-MPLS TE tunnel is not
configured, the default tunnel status keeps Up, and the effective status
cannot be determined.
– The interface status of an E2E SR-MPLS TE tunnel keeps consistent with
the status of BFD for E2E SR-MPLS TE tunnel. The BFD session goes Up
slowly because of BFD negotiation. In general, if a new label stack is
delivered for a tunnel in the down state, it takes approximately 10 to 20
seconds for BFD to go up. This consequently slows down hard
convergence when other protection functions are not configured for the
tunnel.
In Figure 1-51, the implementation of one-arm BFD for E2E SR-MPLS TE is as
follows:
1. Enable BFD and specify the one-arm mode to establish a BFD session on the
ingress.
2. Establish a reverse E2E SR-MPLS TE tunnel in advance on the egress and set a
binding SID for the tunnel.
3. Bind the BFD session to the binding SID of the reverse E2E SR-MPLS TE tunnel
on the ingress.

(2020-10-09)
Figure 1-51 One-arm BFD for E2E SR-MPLS TE (BFD loopback packets are
forwarded through a tunnel.)
After the one-arm BFD session is established, the ingress sends a one-arm BFD
packet that carries the binding SID of the reverse tunnel. After the one-arm BFD
packet arrives at the egress through a transit node along the SR-MPLS TE tunnel,
the forwarding plane removes the MPLS label from the BFD packet and associates
it with the reverse SR-MPLS TE tunnel based on the binding SID carried in the
one-arm BFD packet. The reverse BFD packet is attached with a label stack of the
E2E SR-MPLS TE tunnel and looped back to the ingress through the transit node
along the SR-MPLS TE tunnel. The ingress processes the detection packet to
implement the one-arm loopback detection mechanism.
If the egress does not have a reverse E2E SR-MPLS TE tunnel, the egress searches
for an IP route based on the destination address of the BFD packet to loop back
the packet, as shown in Figure 1-52.

(2020-10-09)
Figure 1-52 One-arm BFD for E2E SR-MPLS TE (BFD loopback packets are
forwarded over IP links.)
1.1.2.7.6 Cross-Multi-AS E2E SR-MPLS TE
Theoretically, binding SIDs and BGP peer SIDs can be used to establish an explicit
path across multiple AS domains (greater than or equal to three). AS domains,
however, are subject to management of various organizations. When a path
crosses multiple AS domains, the path also crosses the networks of multiple
management organizations, which may hinder network deployment.
In Figure 1-53, the network is connected to three AS domains. If PE1 establishes
an E2E SR-MPLS TE network over a multi-hop explicit path to PE3, the traffic path
from AS y to AS z can be determined in AS x. AS y and AS z, however, may belong
to different management organizations than AS x. In this situation, the traffic path
may not be accepted by AS y or AS z, and the great depth of the label stack
decreases forwarding efficiency. AS y and AS z may be connected to a controller
different than AS x, leading to a difficult in establishing an E2E SR-MPLS TE
network from PE1 to PE3.
To tackle the preceding problem, a restriction is implemented on a device. If the
first hop of the explicit path is a binding SID, the explicit path supports a
maximum of three hops. In this way, PE1 can establish an inter-AS E2E SR-MPLS
TE explicit path at most to ASBR5 or ASBR6, not to AS z. The hierarchical mode
can only be used to establish an inter-AS domain E2E SR-MPLS TE tunnel from AS
x to AS z.

(2020-10-09)
Figure 1-53 Cross-Multi-AS E2E SR-MPLS TE
The process of hierarchically establishing a cross-multi-AS E2E SR-MPLS TE tunnel

is as follows:
1. Layer 1: Establish an E2E SR-MPLS TE tunnel from AS y to AS z. Create an SR-
MPLS TE tunnel within each of AS y and AS z. Set binding SIDs for the intra-
AS tunnels, that is, binding SID3 and binding SID5, respectively. Configure BGP
EPE between AS y and AS z to generate BGP peer SID4. The controller
establishes an inter-AS E2E SR-MPLS TE Tunnel1 from AS y to AS z using the
preceding SIDs. Set binding SID6 for this tunnel.
2. Layer 2: Establish an E2E SR-MPLS TE tunnel from AS x to AS z. Create an SR-
MPLS TE tunnel within AS x. Set a binding SID for the intra-AS tunnel, that is,
binding SID1. Configure BGP EPE between AS x and AS y to generate BGP
peer SID2. The controller establishes a unidirectional inter-AS E2E SR-MPLS TE
Tunnel2 from AS x to AS z using binding SID1, peer SID2, and binding SID6.
An E2E SR-MPLS TE tunnel across three AS domains is established. If there are
more than three AS domains, a new binding SID can be allocated to E2E SR-MPLS
TE Tunnel2, and the SID participates in path computation. Repeat the preceding
process to construct an E2E SR-MPLS TE tunnel that spans more AS domains.
1.1.2.8 Importing Traffic
After an SR LSP (SR-MPLS BE) or SR-MPLS TE tunnel is established, service traffic

needs to be imported to the SR LSP or SR-MPLS TE tunnel. The common methods

(2020-10-09)
are to use a static route, tunnel policies, or an automatic route. Services include
public network services, EVPN, L2VPN, and L3VPN.
Table 1-23 Support for tunnels
Traffic Direction SR LSP SR-MPLS TE Tunnel

Mode/Tunnel
Type
Static route No tunnel interface is A tunnel interface is

available. Therefore, you available. A static route can
can configure a static route direct traffic to an SR-MPLS
to specify the next hop, TE tunnel.
then the static route iterates
SR LSP based on the next
hop.
Tunnel policy The tunnel select-sequence Either the tunnel select-

method can be used, sequence method or a
whereas a tunnel binding tunnel binding policy can be
policy cannot be used. used.
Auto route No tunnel interface is A tunnel interface is

available. Therefore, auto available. An auto route can
routes cannot be used to direct traffic to an SR-MPLS
direct traffic to SR LSPs. TE tunnel.
Policy-Based No tunnel interface is A tunnel interface is

Routing available. Therefore, policy- available. Policy-based
based routing cannot be routing can direct traffic to
used to direct traffic to SR an SR-MPLS TE tunnel.
LSPs.
Static Route
No tunnel interface is available for SR LSP. Therefore, you can configure a static
route to specify the next hop, then the static route iterates SR LSP based on the
next hop.
Static routes on an SR-MPLS TE tunnel work in the same way as common static
routes. When configuring a static route, set the outbound interface of a static
route to an SR-MPLS TE tunnel interface so that traffic transmitted over the route
is directed to the SR-MPLS TE tunnel.
Tunnel Policy
By default, VPN traffic is forwarded through LDP LSPs, not SR LSPs or SR-MPLS TE
tunnels. If the default LDP LSPs cannot meet VPN traffic requirements, a tunnel
policy is used to direct VPN traffic to an SR LSP or an SR-MPLS TE tunnel.
The tunnel policy may be a tunnel type prioritizing policy or a tunnel binding
policy. Select either of the following policies as needed:

(2020-10-09)
● Select-seq mode: This policy changes the type of tunnel selected for VPN
traffic. An SR LSP or SR-MPLS TE tunnel is selected as a public tunnel for VPN
traffic based on the prioritized tunnel types. If no LDP LSPs are available, SR
LSPs are selected by default.
● Tunnel binding mode: This policy defines a specific destination IP address, and
this address is bound to an SR-MPLS TE tunnel for VPN traffic to guarantee
QoS.
Auto Route
An IGP uses an auto route related to an SR-MPLS TE tunnel that functions as a
logical link to compute a path. The tunnel interface is used as an outbound
interface in the auto route. According to the network plan, a node determines
whether an LSP link is advertised to a neighbor node for packet forwarding. An
auto route is configured using either of the following methods:
● Forwarding shortcut: The node does not advertise an SR-MPLS TE tunnel to its
neighbor nodes. The SR-MPLS TE tunnel can be involved only in local route
calculation, but cannot be used by the other nodes.
● Forwarding adjacency: The node advertises an SR-MPLS TE tunnel to its
neighbor nodes. The SR-MPLS TE tunnel is involved in global route calculation
and can be used by the other nodes.
NOTE
● Forwarding shortcut and forwarding adjacency are mutually exclusive, and cannot be
used simultaneously.
● When the forwarding adjacency is used, a reverse tunnel must be configured for a
routing protocol to perform bidirectional check after a node advertises LSP links to the
other nodes. The forwarding adjacency must be enabled for both tunnels in opposite
directions.
Policy-Based Routing
The policy-based routing (PBR) allows a device to select routes based on user-
defined policies, which improves traffic security and balances traffic. If PBR is
enabled on an SR network, IP packets are forwarded over specific LSPs based on
PBR rules.
SR-MPLS TE PBR, the same as IP unicast PBR, is implemented by defining a set of
matching rules and behaviors. The rules and behaviors are defined using the apply
clause with an SR-MPLS TE tunnel interface used as an outbound interface. If
packets do not match PBR rules, they are properly forwarded using IP; if they
match PBR rules, they are forwarded over specific tunnels.
1.1.2.8.1 Public IP Routes Recursive to an SR Tunnel
Public Network BGP Route Recursive to an SR Tunnel

If an Internet user performs IP forwarding to access the Internet, core devices on a
forwarding path must learn many Internet routes. This imposes a heavy load on
the core devices and deteriorates their performance. To tackle the problems, a user
access device can be configured to recurse non-labeled public network BGP or
static routes to a segment routing (SR) tunnel. User packets travel through the SR

(2020-10-09)
tunnel to access the Internet. The recursion to the SR tunnel prevents the
problems induced by insufficient performance, heavy burdens, and service
transmission on the core devices on the network.
In Figure 1-54, the deployment of public network BGP route recursive to an SR
LSP is as follows:
● An E2E IGP neighbor relationship is established between each pair of directly
connected devices, and segment routing is configured on PEs and Ps. An SR
LSP is established between PEs.
● A BGP peer relationship between PEs is established to enable the PEs to learn
the peer routes.
● A BGP route recurses to an SR LSP on each PE.
Figure 1-54 Public network BGP route recursive to an SR LSP
In Figure 1-55, the deployment of public network BGP route recursive to an SR-
MPLS TE tunnel is as follows:
connected devices, and segment routing is configured on PEs and Ps. An SR-
MPLS TE tunnel is established between PEs.
● A BGP peer relationship between PEs is established to enable the PEs to learn
the peer routes.
● Configure a tunnel policy on the PE to make the BGP service route iterate
over the SR-MPLS TE tunnel at PE1.

(2020-10-09)
Figure 1-55 Public network BGP route recursive to an SR-MPLS TE tunnel
Static Route Recursive to an SR Tunnel

The next hop of a static route may be unreachable. Such a route must recurse to a
path. If such a static route recurses to an SR tunnel, packets over the static route
are forwarded based on labels.
In Figure 1-56, the deployment of static route recursive to an SR LSP is as follows:

connected devices, and segment routing is configured on PEs and Ps. PE1
establishes an SR LSP destined for PE2's loopback IP address.
● A static route is configured on PE1. The next-hop IP address is set to PE2's
loopback IP address.
● After receiving an IP packet, PE1 adds a label into the packet and forwards
the packet along the SR LSP.
Figure 1-56 Static route recursive to an SR LSP

(2020-10-09)
In Figure 1-57, the deployment of static route recursive to an SR-MPLS TE tunnel

is as follows:
connected devices, and segment routing is configured on PEs and Ps. PE1
establishes an SR-MPLS TE tunnel destined for PE2's loopback IP address.
● A static route is configured on PE1. The next-hop IP address is set to PE2's
loopback IP address.
● Configure a tunnel policy on the PE to allow the PE to iterate to the SR-MPLS
TE tunnel. After receiving the IP packet, PE1 encapsulates the packet with SR-
MPLS TE tunnel labels and then forwards the packet.
Figure 1-57 Static route recursive to an SR-MPLS TE tunnel
1.1.2.8.2 L3VPN Recursive to an SR Tunnel
Basic VPN Recursive to an SR tunnel

If an Internet user performs IP forwarding to access the Internet, core devices on a
forwarding path must learn many Internet routes. This imposes a heavy load on
the core devices and affects the performance of these devices. To tackle the
problems, a VPN instance can recurse to a segment routing (SR) tunnel, and users
access the Internet through the SR tunnel.
The network shown in Figure 1-58 consists of inconsecutive L3VPN subnets with a
backbone network in between. PEs establish an SR LSP to forward L3VPN packets.
PEs run BGP to learn VPN routes. The deployment is as follows:
● An IS-IS neighbor relationship is established between each pair of directly
connected devices on the public network to implement route reachability.
● A BGP peer relationship is established between the two PEs to learn peer VPN
routes of each other.
● The PEs establish an IS-IS SR LSP to assign public network labels and compute
a label switched path.

(2020-10-09)
● BGP is used to assign a private network label, for example, label Z, to a VPN
instance.
● VPN routes recurse to the SR LSP.
● PE1 receives an IP packet, adds the private network label and SR public
network label to the packet, and forwards the packet along the label switched
path.
Figure 1-58 Basic VPN recursive to an SR LSP
The network shown in Figure 1-59 consists of inconsecutive L3VPN subnets with a
backbone network in between. PEs establish an SR-MPLS TE tunnel to forward
L3VPN packets. PEs run BGP to learn VPN routes. The deployment is as follows:
● An IS-IS neighbor relationship is established between each pair of directly
connected devices on the public network to implement route reachability.
● A BGP peer relationship is established between the two PEs to learn peer VPN
routes of each other.
● The PEs establish an IS-IS SR-MPLS TE tunnel to assign public network labels
and compute a label switched path.
● BGP is used to assign a private network label, for example, label Z, to a VPN
instance.
● A tunnel policy is configured on the PE to allow the private network route to
recurse to the SR-MPLS TE tunnel.
● PE1 receives an IP packet, adds the private network label and SR public
network label to the packet, and forwards the packet along the label switched
path.

(2020-10-09)
Figure 1-59 Basic VPN recursive to an SR-MPLS TE tunnel
HVPN Recursive to an SR tunnel

On a growing network with increasing types of services, PEs encounter scalability
problems, such as insufficient access or routing capabilities, which reduces
network performance and scalability. In this situation, VPNs cannot be deployed in
a large scale. In Figure 2, on a hierarchical VPN (HVPN), PEs play different roles
and provide various functions. These PEs form a hierarchical architecture to
provide functions that are provided by one PE on a non-hierarchical VPN. HVPNs
lower the performance requirements for PEs.
Figure 1-60 HVPN recursive to an SR LSP
In Figure 1-60, the deployment is as follows:

(2020-10-09)
● BGP peer relationships are established between the UPE and SPE and
between the SPE and NPE. A segment routing LSP is established between the
UPE and NPE.
● The UPE recurses VPNv4 routes to the SR LSP.
The process of forwarding HVPN packets that CE1 sends to CE2 is as follows:
1. CE1 sends a VPN packet to the UPE.
2. After receiving the packet, the UPE searches its VPN forwarding table for an
LSP to forward the packet based on the destination address of the packet.
Then, the UPE adds an inner label L4 and an outer SR public network label Lv
to the packet and sends the packet to the SPE over the corresponding LSP.
The label stack is L4/Lv.
3. After receiving the packet, the SPE replaces the outer SR public network label
Lv with Lu and the inner label L2 with L3. Then, the SPE sends the packet to
the NPE over the same LSP.
4. After receiving the packet, the NPE removes the outer SR public network label
Lu, searches for a VPN instance corresponding to the packet based on the
inner label L3, and removes the inner label L3 after the VPN instance is found.
Then, the NPE searches the VPN forwarding table of this VPN instance for the
outbound interface of the packet based on the destination address of the
packet. The NPE sends the packet through this outbound interface to CE2. The
packet sent by the NPE is a pure IP packet with no label.
VPN FRR
In Figure 1-61, PE1 adds the optimal route advertised by PE3 and less optimal
route advertised by PE4 into a forwarding entry. The optimal route is used to
guide traffic forwarding, and the less optimal route is used as a backup route.
Figure 1-61 VPN FRR networking

(2020-10-09)
Table 1-24 Typical fault-triggered switching scenarios

Faulty Point Protection Switching
P1-to-P3 link The TI-LFA local protection takes effect and the traffic is
failure switched to the path LSP2 in Figure 1-61.
PE3 node BFD for SR-MPLS TE or SBFD for SR-MPLS can detect the fault
failure of the PE3 node. The BFD or SBFD triggers the VPN FRR to
switch to the path LSP3 in Figure 1-61.
1.1.2.8.3 L2VPN Recursive to an SR Tunnel

Figure 1-62 shows a typical VPLS networking mode. In this networking, users
located in various geographical regions communicate with each other through
different PEs. From the perspective of users, a VPLS network is a Layer 2 switched
network that allows them to communicate with each other in a way similar to
communication over a LAN. The VPLS service can recurse to a segment routing
(SR) tunnel. Sites in each VPN establish virtual connections, and public network SR
tunnels are established to forward Layer 2 packets.
VPLS Recursive to an SR LSP

As shown in Figure 1-62, the process of recursing VPLS services to an SR LSP is as
follows:
● CE1 sends a packet with Layer 2 encapsulation to PE1.
● PE1 establishes an E2E SR LSP to PE2.
● A tunnel policy is configured on PE1 to select the SR LSP, and the VSI
forwarding entries are associated with the SR forwarding entries.
● PE1 receives the packet, searches for a VSI entry, and selects an LSP and a PW
based on the entry. PE1 adds outer LSP label and inner VC label to the packet
based on the selected LSP and PW, performs Layer 2 encapsulation, and
forwards the packet to PE2.
● Upon receipt of the packet, PE2 decapsulates the packet.
● PE2 forwards the original packet to CE2.

(2020-10-09)
Figure 1-62 VPLS recursive to an SR LSP
The process of recursing HVPLS services to an SR LSP is similar to that of recursing

VLL and VPLS services to an SR LSP. The process is not described.
VPLS Recursive to an SR-MPLS TE Tunnel

As shown in Figure 1-63, the process of recursing VPLS services to an SR-MPLS TE
tunnel is as follows:
● CE1 sends a packet with Layer 2 encapsulation to PE1.
● PE1 establishes an E2E SR-MPLS TE tunnel to PE2.
● A tunnel policy is configured on PE1 to select the SR-MPLS TE tunnel, and the
VSI forwarding entries are associated with the SR forwarding entries.
● PE1 receives the packet, searches for a VSI entry, and selects an SR-MPLS TE
tunnel and a PW based on the entry. PE1 adds outer SR-MPLS TE tunnel label
and inner VC label to the packet based on the selected SR-MPLS TE tunnel
and PW, performs Layer 2 encapsulation, and forwards the packet to PE2.
● Upon receipt of the packet, PE2 decapsulates the packet.
● PE2 forwards the original packet to CE2.

(2020-10-09)
Figure 1-63 VPLS recursive to an SR-MPLS TE tunnel
The process of recursing HVPLS services to an SR-MPLS TE tunnel is similar to that

of recursing VLL and VPLS services to an SR-MPLS TE tunnel. The process is not
described.
1.1.2.8.4 EVPN Recursive to an SR Tunnel

Ethernet virtual private network (EVPN) is a Layer 2/3 interworking VPN
technique. EVPN uses a mechanism similar to BGP/MPLS IP VPN. EVPN extends
the BGP protocol and uses extended reachability information to move the process
of learning and advertising MAC addresses between Layer 2 networks at various
sites from the data plane to the control plane. Compared with VPLS, EVPN tackles
the load imbalance and high network resource consumption problems occurring
on VPLS networks.
EVPN Recursive to an SR LSP

In Figure 1-64, after the PEs learn the MAC addresses of VPN sites and establish a
public network SR LSP, the PEs can transmit unicast packets to other sites. The
packet transmission process is as follows:
1. CE1 sends unicast packets based on Layer 2 forwarding to PE1.
2. After PE1 receives the packets, PE1 encapsulates a VPN label carried in a MAC
entry and a public network SR LSP label in sequence and sends the packets to
PE2.
3. After PE2 receives the encapsulated unicast packets, PE1 performs
decapsulation, removes the VPN label, and searches the private network MAC
table for a matching outbound interface.

(2020-10-09)
Figure 1-64 Unicast traffic transmission in EVPN recursive to an SR LSP scenario
EVPN Recursive to an SR-MPLS TE Tunnel

In Figure 1-65, after the PEs learn the MAC addresses of VPN sites and establish a
public network SR-MPLS TE tunnel, the PEs can transmit unicast packets to other
sites. The packet transmission process is as follows:
1. CE1 sends unicast packets based on Layer 2 forwarding to PE1.
2. After PE1 receives the packets, PE1 encapsulates a VPN label carried in a MAC
entry and a public network SR-MPLS TE tunnel label in sequence and sends
the packets to PE2.
3. After PE2 receives the encapsulated unicast packets, PE1 performs
decapsulation, removes the VPN label, and searches the private network MAC
table for a matching outbound interface.
Figure 1-65 Unicast traffic transmission in EVPN recursive to an SR-MPLS TE

tunnel scenario

(2020-10-09)
1.1.2.9 SBFD for SR-MPLS
Bidirectional forwarding detection (BFD) techniques are mature. When a large

number of BFD sessions are configured to monitor links, the negotiation time of
the existing BFD state machine is lengthened. In this situation, seamless
bidirectional forwarding detection (SBFD) can be configured to monitor SR
tunnels. It is a simplified BFD state machine that shortens the negotiation time
and improves network-wide flexibility.
SBFD Principles
Figure 1-66 shows SBFD principles. Before link detection, an initiator and a
reflector exchange SBFD control packets to notify each other of SBFD parameters,
for example, discriminators. In link detection, the initiator proactively sends an
SBFD Echo packet, and the reflector loops this packet back. The initiator
determines the local status based on the looped packet.
● The initiator that performs detection runs the SBFD state machine and
mechanism. The state machine has only the Up and Down states. The initiator
sends packets only in the Up or Down state and receives packets only in the
Up or Admin Down state.
An SBFD packet is first sent from the initiator to the reflector. The initial state
of the packet is Down. The destination and source port numbers of the packet
are 7784 and 4784, respectively, the destination IP address is a 127-network
address configured by the user, and the source IP address is the LSR ID
configured on the local device.
● The reflector runs no SBFD state machine or mechanism. It does not
proactively send SBFD Echo packets. The reflector only loops SBFD packets to
the initiator.
The reflector receives the SBFD packet sent by the initiator and checks
whether the received SBFD discriminator is the same as the locally configured
global SBFD discriminator. If they do not match, the packet is discarded. If
they match and the reflector is in the working state, the reflector constructs a
loopback SBFD packet. If they match and the reflector is not in the working
state, the reflector sets the status to Admin Down in the packet.
The destination and source port numbers in the loopback SBFD packet are
4784 and 7784, respectively, source IP address is the LSR ID locally configured,
and destination IP address is the source IP address of the initiator.

(2020-10-09)
Figure 1-66 SBFD Principles
SBFD State Machine on the Initiator

The SBFD state machine running on the initiator has only the Up and Down states
and shifts between the two states. Figure 1-67 shows the SBFD state machine
running on the initiator.
Figure 1-67 SBFD initial state machine
● Initial state: The initiator sets the initial state to Down in an SBFD packet to
be sent to the reflector.
● Status migration: After receiving a looped packet carrying the Up state, the
initiator sets the local status to Up. After the initiator receives a looped packet
carrying the Admin Down state, the initiator sets the local status to Down. If
the initiator does not receive a packet looped by the reflector before the timer
expires, the initiator also sets the local status to Down.
● Status holding: When the initiator is in the Up state and receives a looped
packet carrying the Up state, the initiator remains the local state of Up. When
the initiator is in the Down state and receives a looped packet carrying the
Admin Down state or receives no packet after the timer expires, the initiator
remains the local state of Down.
Typical SBFD Applications

When SBFD applies to SR scenarios, SBFD for SR LSP (SR-MPLS BE) and SBFD for
SR-MPLS TE can be used. In an SBFD for SR-MPLS scenario, the packet from an
SBFD initiator to an SBFD reflector is forwarded along an SR-MPLS LSP, and the
return packet from the SBFD reflector to the SBFD initiator is forwarded along a
multi-hop IP path.

(2020-10-09)
SBFD for SR LSP

In the following example, VPN traffic recurses to an SR LSP. SBFD for SR LSP is
configured, as shown in Figure 1-68.
Assume that the SRGB scope [16000-16100] is set on each PE and P on the
network shown in Figure 1-68. A, CE1, CE2, and E are deployed on the same VPN,
and CE2 advertises a route to E. PE2 assigns a VPN label to the route to E, and
then advertises it to PE1 through the MP-BGP neighbor. PE1 receives the VPN
route carrying the VPN label and installs the route to the forwarding table.
When A sends packets destined for E and the packets arrive at PE1, PE1 adds a
VPN label into the packets based on the VPN to which the packets belong,
recurses the packets to an SR LSP based on the destination IP address carried in
the packets, adds an SR label of 16100, and forwards the packets hop by hop
along the path PE1->P4->P3->PE2.
After SBFD is configured, PE1 rapidly detects a fault and switch traffic to a backup
SR LSP once a link or P on the primary LSP fails.
Figure 1-68 SBFD for SR LSP networking
SBFD for SR-MPLS TE LSP

In the following example, VPN traffic recurses to an SR-MPLS TE LSP, in the
scenario where SBFD for SR-MPLS TE LSP is used.

(2020-10-09)
Figure 1-69 SBFD for SR-MPLS TE LSP networking
A, CE1, CE2, and E are deployed on the same VPN, and CE2 advertises a route to E.
PE2 assigns the VPN label to E. PE1 installs the route to E and the VPN label.
The path of the SR-MPLS TE tunnel from PE1 to PE2 is PE1 -> P4 -> P3 -> PE2, and
the label stack is {9004, 9003, 9005}. When A sends a packet destined for E, PE1
finds the packet's outbound interface based on label 9004 and adds label 9003,
label 9005, and the inner VPN label assigned by PE2. After SBFD is configured, PE1
rapidly detects a fault and switches traffic to a backup SR-MPLS TE LSP once a link
or P on the primary LSP fails.
SBFD for SR-MPLS TE Tunnel
SBFD for SR-MPLS TE tunnel must be used with SBFD for SR-MPLS TE LSP.
SBFD for SR-MPLS TE LSP controls the status of the primary/backup LSP
switchover. SBFD for SR-MPLS TE tunnel checks actual status of tunnels.
● If SBFD for SR-MPLS TE tunnel is not configured, the default tunnel status
keeps Up, and the effective status cannot be determined.
● If SBFD for SR-MPLS TE tunnel is configured and the SBFD status is set to
administrative Down, the SBFD session does not work, and the tunnel
interface status is unknown.
● If SBFD for SR-MPLS TE tunnel is configured and SBFD is not administratively
down, the tunnel interface status is the same as the BFD status.
1.1.2.10 SR-MPLS TE Policy

(2020-10-09)
Segment Routing Policy (SR-MPLS TE Policy) is a tunneling technology developed

based on SR. An SR-MPLS TE Policy is a set of candidate paths consisting of one or
more segment lists, that is, segment ID (SID) lists. Each SID list identifies an end-
to-end path from the source to the destination, instructing a device to forward
traffic through the path rather than the shortest path computed using an IGP. The
header of a packet steered into an SR-MPLS TE Policy is augmented with an
ordered list of segments associated with that SR Policy, so that other devices on
the network can execute the instructions encapsulated into the list.
An SR-MPLS TE Policy consists of the following parts:
● Headend: node where an SR-MPLS TE Policy is generated.
● Color: extended community attribute of an SR-MPLS TE Policy. A BGP route
can recurse to an SR-MPLS TE Policy if the route has the same color attribute
as the policy.
● Endpoint: destination address of an SR-MPLS TE Policy.
Color and endpoint information is added to an SR-MPLS TE Policy through
configuration. In path computation, a forwarding path is computed based on the
color attribute that meets SLA requirements. The headend steers traffic into an
SR-MPLS TE Policy whose color and endpoint attributes match the color value and
next-hop address in the associated route, respectively. The color attribute defines
an application-level network SLA policy. This allows network paths to be planned
based on specific SLA requirements for services, realizing service value in a refined
manner and helping build new business models.
SR-MPLS TE Policy Model

Figure 1-70 shows the SR-MPLS TE Policy model. One SR-MPLS TE Policy can
contain multiple candidate paths with the preference attribute. The valid
candidate path with the highest preference functions as the primary path of the
SR-MPLS TE Policy, and the valid candidate path with the second highest
preference functions as the hot-standby path.
A candidate path can contain multiple segment lists, each of which carries a
Weight attribute. Currently, this attribute cannot be set and is defaulted to 1. Each
segment list is an explicit label stack that instructs a network device to forward
packets. Multiple segment lists can work in load balancing mode.

(2020-10-09)
Figure 1-70 SR-MPLS TE Policy model
BGP SR-MPLS TE Policy Extension

The BGP SR-MPLS TE Policy extension provides the following functions:
1. Transmits the SR-MPLS TE Policy dynamically generated on a controller to a
forwarder. This function is implemented through the newly defined BGP SR-
MPLS TE Policy subsequent address family identifier (SAFI). By establishing a
BGP SR-MPLS TE Policy address family-specific peer relationship between the
controller and forwarder, this function enables the controller to deliver the SR-
MPLS TE Policy to the forwarder, enhancing the capability of automatic SR-
MPLS TE Policy deployment.
2. Supports the new extended community attribute (color attribute) and
transmits the attribute between BGP peers. This function is implemented
through the BGP network layer reachability information (NLRI) extension.
The format of the NLRI used by a BGP SR-MPLS TE Policy address family is as
follows:
+------------------+
| NLRI Length | 1 octet
+------------------+
| Distinguisher | 4 octets
+------------------+
| Policy Color | 4 octets
+------------------+
| Endpoint | 4 or 16 octets
+------------------+
The meaning of each field is as follows:
● NLRI Length: length of the NLRI
● Distinguisher: distinguisher of the NLRI
● Policy Color: color value of the associated SR-MPLS TE Policy
● Endpoint: endpoint information about the associated SR-MPLS TE Policy

(2020-10-09)
The NLRI containing SR-MPLS TE Policy information is carried in a BGP Update

message. The Update message must carry mandatory BGP attributes and can also
carry any optional BGP attributes.
The content of an SR-MPLS TE Policy is encoded using the new Tunnel-Type TLV in
tunnel encapsulation attributes. The encoding format is as follows:
SR-MPLS TE Policy SAFI NLRI: <Distinguisher, Policy Color, Endpoint>
Attributes:
Tunnel Encaps Attribute (23)
Tunnel Type: SR-MPLS TE Policy
Binding SID
Preference
Priority
Policy Name
...
Segment List
Weight
Segment
Segment
...
...
● Binding SID: binding SID of an SR-MPLS TE Policy.
● Preference: SR-MPLS TE Policy selection preference based on which SR Policies
are selected.
● Priority: SR-MPLS TE Policy convergence priority based on which the sequence
of SR-MPLS TE Policy re-computation is determined in the case of a topology
change.
● Policy Name: SR-MPLS TE Policy name.
● Segment List: list of segments, which contains Weight attribute and segment
information. One SR-MPLS TE Policy can contain multiple segment lists, and
one segment list can contain multiple segments.
The Tunnel-Type TLV consists of the following sub-TLVs.
Preference Sub-TLV
Figure 1-71 shows the format of the Preference sub-TLV.
Figure 1-71 Preference Sub-TLV
Table 1-25 Fields in the Preference sub-TLV
Flags 8 bits Flags bit. Currently, this field is not in use.
Preference 32 bits SR-MPLS TE Policy preference.

(2020-10-09)
Binding SID Sub-TLV

Figure 1-72 shows the format of the Binding SID sub-TLV.
Figure 1-72 Binding SID Sub-TLV
Table 1-26 Fields in the Binding SID sub-TLV

Length 8 bits Packet length. It does not contain Type and Length
fields. Available values are as follows:
● 2: No binding SID is contained.
● 6: An IPv4 binding SID is contained.
Flags 8 bits Flags bit. The encoding format is as follows:
● S: S-Flag encoding the Specified-BSID-only

behavior
● I: I-Flag encoding the Drop Upon Invalid behavior
Binding SID 32 bits Binding SID of the SR-MPLS TE Policy. The following
figure shows the format.
Figure 1-74 Binding SID
The Label field indicates a label that occupies 20 bits.

The other field occupies 12 bits and is not in use
currently.
Segment List Sub-TLV

(2020-10-09)
Figure 1-75 shows the format of the Segment List sub-TLV.
Figure 1-75 Segment List Sub-TLV
Table 1-27 Fields in the Segment List sub-TLV


(2020-10-09)
sub-TLVs Variable Sub-TLVs that contain an optional Weight sub-TLV and

length zero or more Segment sub-TLVs.
The format of the Weight sub-TLV is as follows.
Figure 1-76 Weight sub-TLV

● Type: TLV type of 8 bits
● Length: TLV length of 8 bits
● Flags: flags of 8 bits (not in use currently)
● Weight: weight value of a segment list
The format of the Segment sub-TLV is as follows.
Figure 1-77 Segment sub-TLV in the form of MPLS

label

● Type: TLV type of 8 bits
● Length: TLV length of 8 bits
● Flags: flags of 8 bits (not in use currently)
● Label: label value of 24 bits
● TC: traffic class of 3 bits
● S: bottom of stack of 1 bit
● TTL: TTL value of 8 bits
Policy Priority Sub-TLV

Figure 1-78 shows the format of the Policy Priority sub-TLV.
Figure 1-78 Policy Priority Sub-TLV

(2020-10-09)
Table 1-28 Fields in the Policy Priority sub-TLV

Length 8 bits Packet length. It does not contain Type and Length
fields.
Priority 8 bits SR-MPLS TE Policy priority.
Extended Color Community

Figure 1-79 shows the format of the Extended Color Community.
Figure 1-79 Extended Color Community
Table 1-29 Fields in the Extended Color Community

CO 8 bits Color-Only bits indicating that the Extended Color

Community is used to steer traffic into an SR-MPLS TE
Policy. The current value is 00, indicating that traffic
can be steered into an SR-MPLS TE Policy only when
the color value and next-hop address in the route
match the color and endpoint attributes of the SR-
MPLS TE Policy, respectively.
Color Value 32 bits Extended Color Community attribute value.
BGP itself does not generate SR Policies. Instead, it receives NLRIs containing SR-
MPLS TE Policy information from a controller to generate SR Policies. Upon
reception of an NLRI, BGP must determine whether the NLRI is acceptable based
on the following rules:
● The NLRI must contain Distinguisher, Policy Color, and Endpoint attributes.
● The Update message carrying the NLRI must have either the NO_ADVERTISE
community or at least one route-target extended community in IPv4 address
format.
● The Update message carrying the NLRI must have one Tunnel Encapsulation
Attribute.
SR-MPLS TE Policy MTU

If the actual forwarding path of an SR-MPLS TE Policy involves different physical
link types, the links may support different MTUs. If this is the case, the headend

(2020-10-09)
must implement MTU control properly to prevent packets from being fragmented
or discarded during transmission. Currently, no IGP/BGP-oriented MTU
transmission or negotiation mechanism is available. You can configure MTUs for
SR-MPLS TE Policies as needed.
MBB and Delayed Deletion for SR-MPLS TE Policies

SR-MPLS TE Policies support make-before-break (MBB). With the MBB function, a
forwarder can establish a new segment list before removing the original one
during a segment list update. In the establishment process, traffic is still forwarded
through the original segment list, preventing packet loss upon a segment list
switchover.
SR-MPLS TE Policies also support delayed deletion. With a segment list deletion
delay being configured for an SR-MPLS TE Policy, if the SR-MPLS TE Policy has a
segment list with a higher preference, a segment list switchover may be
performed. In this case, the original segment list that is up can still be used and is
deleted only when the delay expires. This prevents traffic interruptions during the
segment list switchover.
Delayed deletion takes effect only for up segment lists (including backup segment
lists) in an SR-MPLS TE Policy. If seamless bidirectional forwarding detection
(SBFD) detects a segment list fault or does not obtain the segment list status, the
segment list is considered invalid and then immediately deleted without any delay.
1.1.2.10.1 SR-MPLS TE Policy Creation
An SR-MPLS TE Policy can be manually configured on a forwarder through CLI or

NETCONF. Alternatively, it can be delivered to a forwarder after being dynamically
generated by a protocol, such as BGP, on a controller. The dynamic mode
facilitates network deployment. If SR Policies generated in both modes exist, the
forwarder selects an SR-MPLS TE Policy based on the following rules in descending
order:
● Protocol-Origin: The default value of Protocol-Origin is 20 for a BGP-delivered
SR-MPLS TE Policy and is 30 for a manually configured SR-MPLS TE Policy. A
larger value indicates a higher preference.
● <ASN, node-address> tuple: ASN indicates an AS number. For both ASN and
node-address, a smaller value indicates a higher preference. The ASN and
node-address values of a manually configured SR-MPLS TE Policy are fixed at
0 and 0.0.0.0, respectively.
● Discriminator: A larger value indicates a higher preference. For a manually
configured SR-MPLS TE Policy, the value of Discriminator is the same as the
preference value.
Manual SR-MPLS TE Policy Configuration

You can manually configure an SR-MPLS TE Policy through CLI or NETCONF. For a
manually configured SR-MPLS TE Policy, information, such as the endpoint and
color attributes, the preference values of candidate paths, and segment lists, must
be configured. Moreover, the preference values must be unique. The first-hop label
of a segment list can be a node, adjacency, BGP EPE, parallel, or anycast SID, but
cannot be any binding SID. Ensure that the first-hop label is a local incoming

(2020-10-09)
label, so that the forwarding plane can use this label to search the local
forwarding table for the corresponding forwarding entry.
Figure 1-80 Manually configured SR-MPLS TE Policy
SR-MPLS TE Policy Delivery by a Controller

Figure 1-81 shows the process in which a controller dynamically generates and
delivers an SR-MPLS TE Policy to a forwarder. The process is as follows:
1. The controller collects information, such as network topology and label
information, through BGP-LS.
2. The controller and headend forwarder establish a BGP peer relationship in the
IPv4 SR-MPLS TE Policy address family.
3. The controller computes an SR-MPLS TE Policy and delivers it to the headend
forwarder through the BGP peer relationship. The headend forwarder then
generates SR-MPLS TE Policy entries.

(2020-10-09)
Figure 1-81 Controller-delivered SR-MPLS TE Policy
1.1.2.10.2 Traffic Steering into an SR-MPLS TE Policy
Route Coloring
Route coloring is to add the Color Extended Community to a route through a
route-policy, enabling the route to recurse to an SR-MPLS TE Policy based on the
color value and next-hop address in the route.
The route coloring process is as follows:
1. Configure a route-policy and set a specific color value for the desired route.
2. Apply the route-policy to a BGP peer or a VPN instance as an import or export
policy.
Color-based Traffic Steering

Color-based traffic steering is to steer traffic into an SR-MPLS TE Policy by
recursing the traffic route to the SR-MPLS TE Policy based on the color value and
next-hop address in the route. Figure 1-82 shows the traffic steering process.

(2020-10-09)
Figure 1-82 Color-based traffic steering
The color-based traffic steering process is as follows:

1. The controller delivers an SR-MPLS TE Policy to headend device A. The SR-
MPLS TE Policy's color value is 123 and its endpoint value is the address
10.1.1.3 of device B.
2. A BGP or VPN export policy is configured on device B, or a BGP or VPN import
policy is configured on device A, with the color value being set to 123 for
route prefix 10.1.1.0/24 and the next-hop address in the route being set to
address 10.1.1.3 of device B. Then, the route is delivered to device A through
the BGP peer relationship.
3. A tunnel policy is configured on device A. After receiving BGP route
10.1.1.0/24, device A recurses the route to the SR-MPLS TE Policy based on
color value 123 and next-hop address 10.1.1.3. During forwarding, the label
stack <C,E,G,B> is added to the packets destined for 10.1.1.0/24.
DSCP-based Traffic Steering

DSCP-based traffic steering does not support color-based route recursion. Instead,
it recurses a route into an SR-MPLS TE Policy based on the next-hop address in the
route. Specifically, it searches for the SR-MPLS TE Policy group matching specific
endpoint information and then finds the corresponding SR-MPLS TE Policy based
on the DSCP value of packets. Figure 1-83 shows the DSCP-based traffic steering
process.

(2020-10-09)
Figure 1-83 DSCP-based traffic steering
The DSCP-based traffic steering process is as follows:

1. The controller sends two SR Policies to headend device A. SR-MPLS TE Policy
1's color value is 123 and its endpoint value is address 10.1.1.3 of device B.
SR-MPLS TE Policy 2's color value is 124 and its endpoint value is also address
10.1.1.3 of device B.
2. Device B delivers BGP route 10.1.1.0/24 to headend device A through the BGP
peer relationship.
3. Tunnel policy configuration is performed on the head device A. Specifically, an
SR-MPLS TE Policy group is configured, with its endpoint being address
10.1.1.3 of device B. Color value 123 is mapped to DSCP value 10, and color
value 124 is mapped to DSCP value 20. Then, a tunnel policy is configured on
device A to bind the SR-MPLS TE Policy group and the next-hop address in the
route.
4. Device A implements tunnel recursion based on the destination address of
packets and finds the SR-MPLS TE Policy group bound to the destination
address. After the color value matching the DSCP value of the packets and the
specific SR-MPLS TE Policy matching the color value are found, the packets
can be steered into the SR-MPLS TE Policy.
1.1.2.10.3 SR-MPLS TE Policy-based Data Forwarding

(2020-10-09)
Intra-AS Data Forwarding

Intra-AS data forwarding depends on the establishment of intra-AS SR-MPLS TE
Policy forwarding entries. Figure 1-84 shows the process of establishing intra-AS
SR-MPLS TE Policy forwarding entries.
Figure 1-84 Establishment of intra-AS SR-MPLS TE Policy forwarding entries
The process of establishing intra-AS SR-MPLS TE Policy forwarding entries is as

follows:
1. The controller delivers an SR-MPLS TE Policy to headend device A.
2. Endpoint device B advertises BGP route 10.1.1.0/24 to device A, and the next-
hop address in the BGP route is address 10.1.1.3/32 of device B.
3. A tunnel policy is configured on ingress A. After receiving the BGP route,
device A recurses the route to the SR-MPLS TE Policy based on the color and
next-hop address in the route. The label stack of the SR-MPLS TE Policy is
<20003, 20005, 20007, 20002>.
Figure 1-85 shows the intra-AS data forwarding process. Headend device A finds
the SR-MPLS TE Policy and pushes label stack <20003,20005,20007,20002> on the
packet destined for 10.1.1.0/24. After receiving an SR-MPLS TE packet, devices C,

(2020-10-09)
E, and G all pop the outer label in the SR-MPLS TE packet. Finally, device G
forwards the received packet to device B. After receiving the packet, device B
further processes it based on the packet destination address.
Figure 1-85 Intra-AS data forwarding
Inter-AS Data Forwarding

Inter-AS data forwarding depends on the establishment of inter-AS SR-MPLS TE
Policy forwarding entries. Figure 1-86 shows the process of establishing inter-AS
SR-MPLS TE Policy forwarding entries.
Figure 1-86 Establishment of inter-AS SR-MPLS TE Policy forwarding entries

(2020-10-09)
The process of establishing inter-AS SR-MPLS TE Policy forwarding entries is as

follows:
1. The controller delivers an intra-AS SR-MPLS TE Policy to headend device
ASBR3 in AS 200. The SR-MPLS TE Policy's color value is 123, endpoint is IP
address 10.1.1.3 of PE1, and binding SID is 30028.
2. The controller delivers an inter-AS E2E SR-MPLS TE Policy to headend device
CSG1 in AS 100. The SR-MPLS TE Policy's color value is 123, and endpoint is
address 10.1.1.3 of PE1. The segment list combines the intra-AS label of AS
100, the inter-AS BGP Peer-Adj label, and the binding SID of AS 200, forming
<102,203,3040,30028>.
3. A BGP or VPN export policy is configured on PE1, with the color value being
set to 123 for route prefix 10.1.1.0/24 and the next-hop address in the route
being set to address 10.1.1.3 of PE1. Then, the route is advertised to CSG1
through the BGP peer relationship.
4. A tunnel policy is configured on headend device CSG1. After receiving BGP
route 10.1.1.0/24, CSG1 recurses the route to the E2E SR-MPLS TE Policy
based on the color value and next-hop address in the route. The label stack of
the SR-MPLS TE Policy is <102,203,3040,30028>.
Figure 1-87 shows the inter-AS data forwarding process.
Figure 1-87 Inter-AS SR-MPLS TE Policy data forwarding
The inter-AS SR-MPLS TE Policy data forwarding process is as follows:

1. Headend device CSG1 adds label stack <102,203,3040,30028> to the data
packet. Then, the device searches for the outbound interface according to
label 102 of the CSG1->AGG1 adjacency and removes the label. The packet
carrying label stack <203,3040,30028> is forwarded to downstream device
AGG1 through the CSG1->AGG1 adjacency.
2. After receiving the packet, AGG1 searches for the adjacency matching top
label 203 in the label stack, finds that the corresponding outbound interface is
the AGG1->ASBR1 adjacency, and removes the label. The packet carrying
label stack <3040,30028> is forwarded to downstream device ASBR1 through
the AGG1->ASBR1 adjacency.

(2020-10-09)
3. After receiving the packet, ASBR1 searches for the adjacency matching top
label 3040 in the label stack, finds that the corresponding outbound interface
is the ASBR1->ASBR3 adjacency, and removes the label. The packet carrying
label stack <30028> is forwarded to downstream device ASBR3 through the
ASBR1->ASBR3 adjacency.
4. After receiving the packet, ASBR3 searches the forwarding table based on top
label 30028 in the label stack. 30028 is a binding SID that corresponds to
label stack <405,506>. Then, the device searches for the outbound interface
based on label 405 of the ASBR3->P1 adjacency and removes the label. The
packet carrying label stack <506> is forwarded to downstream device P1
through the ASBR3->P1 adjacency.
5. After receiving the packet, P1 searches for the adjacency matching top label
506 in the label stack, finds that the corresponding outbound interface is the
P1->PE1 adjacency, and removes the label. In this case, the packet does not
carry any label and is forwarded to destination device PE1 through the P1-
>PE1 adjacency. After receiving the packet, PE1 further processes it based on
the packet destination address.
1.1.2.10.4 SBFD for SR-MPLS TE Policy
Unlike RSVP-TE, which exchanges Hello messages between forwarders to maintain

tunnel status, an SR-MPLS TE Policy cannot maintain its status in the same way.
An SR-MPLS TE Policy is established immediately after the headend delivers a
label stack. The SR-MPLS TE Policy remains up only unless the label stack is
revoked. Therefore, seamless bidirectional forwarding detection (SBFD) for SR-
MPLS TE Policy is introduced for SR-MPLS TE Policy fault detection. SBFD for SR-
MPLS TE Policy is an end-to-end fast detection mechanism that quickly detects
faults on the link through which an SR-MPLS TE Policy passes.
Figure 1-88 shows the SBFD for SR-MPLS TE Policy detection process.

(2020-10-09)
Figure 1-88 SBFD for SR-MPLS TE Policy
The SBFD for SR-MPLS TE Policy detection process is as follows:

1. After SBFD for SR-MPLS TE Policy is enabled on the headend, the endpoint
uses the endpoint address (IPv4 address only) as the remote discriminator of
the SBFD session corresponding to the segment list in the SR-MPLS TE Policy
by default. If multiple segment lists exist in the SR-MPLS TE Policy, the remote
discriminators of the corresponding SBFD sessions are the same.
2. The headend sends an SBFD packet encapsulated with a label stack
corresponding to the SR-MPLS TE Policy.
3. After the endpoint device receives the SBFD packet, it returns a reply through
the shortest IP link.
4. If the headend receives the reply, it considers that the corresponding segment
list in the SR-MPLS TE Policy is normal. Otherwise, it considers that the
segment list is faulty. If all the segment lists referenced by a candidate path
are faulty, SBFD triggers a candidate path switchover.
SBFD return packets are forwarded over IP. If the primary paths of multiple SR-
MPLS TE Policies between two nodes differ due to different path constraints but
SBFD return packets are transmitted over the same path, a fault in the return path
may cause all involved SBFD sessions to go down. As a result, all the SR-MPLS TE
Policies between the two nodes go down. The SBFD sessions of multiple segment
lists in the same SR-MPLS TE Policy also have this problem.
By default, if HSB protection is not enabled for an SR-MPLS TE Policy, SBFD
detects all the segment lists only in the candidate path with the highest
preference in the SR-MPLS TE Policy. With HSB protection enabled, SBFD can
detect all the segment lists of candidate paths with the highest and second
highest priorities in the SR-MPLS TE Policy. If all the segment lists of the candidate
path with the highest preference are faulty, a switchover to the HSB path is
triggered.

(2020-10-09)
1.1.2.10.5 SR-MPLS TE Policy Failover
SBFD for SR-MPLS TE Policy checks the connectivity of segment lists. If a segment
list is faulty, an SR-MPLS TE Policy failover is triggered.
On the networks shown in Figure 1-89 and Figure 1-90, the headend and
endpoint of SR-MPLS TE Policy 1 are PE1 and PE2, respectively. In addition, the
headend and endpoint of SR-MPLS TE Policy 2 are PE1 and PE3, respectively. VPN
FRR can be deployed for SR-MPLS TE Policy 1 and SR-MPLS TE Policy 2. Primary
and HSB paths are established for SR-MPLS TE Policy 1. Segment list 1 contains
node labels to P1, P2, and PE2. It can directly use all protection technologies of
SR-MPLS, for example, TI-LFA.
Figure 1-89 SR-MPLS TE Policy Failover

(2020-10-09)
Figure 1-90 SR-MPLS TE Policy label stack
In Figure 1-89:
● If point 1, 3, or 5 is faulty, TI-LFA local protection takes effect only on PE1, P1,
or P2. If the SBFD session corresponding to segment list 1 on PE1 detects a
fault before traffic is restored through local protection, SBFD automatically
sets segment list 1 to down and instructs SR-MPLS TE Policy 1 to switch to
segment list 2.
● If point 2 or 4 is faulty, no local protection is available. SBFD detects node
faults, sets segment list 1 to down, and instructs SR-MPLS TE Policy 1 to
switch to segment list 2.
● If PE2 is faulty and all the candidate paths of SR-MPLS TE Policy 1 are
unavailable, SBFD can detect the fault, set SR-MPLS TE Policy 1 to down, and
trigger a VPN FRR switchover to switch traffic to SR-MPLS TE Policy 2.
1.1.2.10.6 SR-MPLS TE Policy OAM
SR-MPLS TE Policy operations, administration and maintenance (OAM) is used to

monitor SR-MPLS TE Policy connectivity and quickly detect SR-MPLS TE Policy
faults. Currently, SR-MPLS TE Policy OAM is implemented through ping and tracert
tests.
SR-MPLS TE Policies implement policy control on paths, whereas paths are real
paths with SID stacks. There are two levels of SR-MPLS TE Policy detection.
1. SR-MPLS TE Policy-level detection: You can configure multiple candidate
paths for an SR-MPLS TE Policy. The valid path with the highest preference is
the primary path, and the valid path with the second highest preference is the
backup path. Multiple segment lists of a candidate path work in load
balancing mode. The same candidate path can be configured for different SR
Policies. SR-MPLS TE Policy-level detection is to detect the primary and
backup paths in an SR-MPLS TE Policy.
2. Candidate path-level detection: This detection is basic and does not involve
upper-layer policy services. It only detects whether a candidate path is
normal.

(2020-10-09)
Policy-level detection is equivalent to candidate path-level detection if the

preferred primary and backup paths are found. If the primary and backup paths
have multiple segment lists, the ping and tracert tests check all the segment lists
through the same process and generate test results.
SR-MPLS TE Policy Ping

On the network shown in Figure 1-91, SR is enabled on the PE and P devices on
the public network. An SR-MPLS TE Policy is established from PE1 to PE2. The SR-
MPLS TE Policy has only one primary path, and its segment list is PE1->P1->P2-
>PE2.
Figure 1-91 SR-MPLS TE Policy Ping/Tracert
The process of initiating a ping test on the SR-MPLS TE Policy from PE1 is as
follows:
1. PE1 constructs an MPLS Echo Request packet. In the IP header of the packet,
the destination IP address is 127.0.0.0/8, and the source IP address is the
MPLS LSR ID of PE1. MPLS labels are encapsulated as a SID label stack in
segment list form.
Note that, if an adjacency SID is configured, headend device PE1 only detects
the FEC of P1. As a result, after the ping packet reaches PE2, the FEC of PE2
fails to be verified. Therefore, to ensure that the FEC verification on the
endpoint device succeeds in this scenario, the MPLS Echo Request packet must
be encapsulated with nil_FEC.
2. PE1 forwards the packet to P1 and P2 hop by hop based on the segment list
label stack of the SR-MPLS TE Policy.
3. P2 removes the outer label from the received packet and forwards the packet
to PE2. In this case, all labels of the packet are removed.

(2020-10-09)
4. PE2 sends the packet to the host transceiver for processing, constructs an
MPLS Echo Reply packet, and sends the packet to PE1. The destination
address of the packet is the MPLS LSR ID of PE1. Because no SR-MPLS TE
Policy is bound to the destination address of the reply packet, IP forwarding is
implemented for the packet.
5. After receiving the reply packet, PE1 generates ping test results.
If there are primary and backup paths with multiple segment lists, the ping test
checks all the segment lists.
SR-MPLS TE Policy Tracert

On the network in Figure 1-91, the process of initiating a tracert test on the SR-
MPLS TE Policy from PE1 is as follows:
1. PE1 constructs an MPLS Echo Request packet. In the IP header of the packet,
the destination IP address is 127.0.0.0/8, and the source IP address is an MPLS
LSR ID. MPLS labels are encapsulated as a SID label stack in segment list
form.
2. PE1 forwards the packet to P1. After receiving the packet, P1 determines
whether the outer TTL minus one is zero.
– If the outer TTL minus one is zero, an MPLS TTL timeout occurs and P1
sends the packet to the host transceiver for processing.
– If the outer TTL minus one is greater than zero, P1 removes the outer
MPLS label, buffers the value (outer TTL minus one), copies and pastes
the value to the new outer MPLS label, searches the forwarding table for
the outbound interface, and forwards the packet to P2.
3. Similar to P1, P2 also determines whether the outer TTL minus one is zero.
– If the outer TTL minus one is zero, an MPLS TTL timeout occurs and P2
sends the packet to the host transceiver for processing.
– If the outer TTL minus one is greater than zero, P2 removes the outer
MPLS label, buffers the value (outer TTL minus one), copies and pastes
the value to the new outer MPLS label, searches the forwarding table for
the outbound interface, and forwards the packet to PE2.
4. After receiving the packet, PE2 removes the outer MPLS label and sends the
packet to the host transceiver for processing. In addition, PE2 returns an MPLS
Echo Reply packet to PE1, with the destination address of the packet being
the MPLS LSR ID of PE1. Because no SR-MPLS TE Policy is bound to the
destination address of the reply packet, IP forwarding is implemented for the
packet.
5. After receiving the reply packet, PE1 generates tracert test results.
If there are primary and backup paths with multiple segment lists, the tracert test
checks all the segment lists.
1.1.2.11 TI-LFA FRR

Topology-independent loop-free alternate (TI-LFA) fast reroute (FRR) provides link
and node protection for Segment Routing (SR) tunnels. If a link or node fails, TI-
LFA FRR rapidly switches traffic to a backup path, minimizing traffic loss.
SR-MPLS TI-LFA FRR applies to both SR-MPLS BE and loose SR-MPLS TE scenarios.

(2020-10-09)
Related Concepts
Table 1-30 TI-LFA FRR-related concepts

Concep Definition
t
P space The P space is a set of nodes reachable from the source node of a
protected link using the shortest path tree (SPT) rooted at the source
node without traversing the protected link.
Extende The extended P space is a set of nodes reachable from all the
dP neighbors of a protected link's source node using SPTs rooted at the
space neighbors without traversing the protected link. A node in the P space
or extended P space is called a P node.
Q space The Q space is a set of nodes reachable from the destination node of
a protected link using the reverse SPT rooted at the destination node
without traversing the protected link. A node in the Q space is called
a Q node.
PQ A PQ node resides in both the (extended) P space and Q space and

node functions as the destination node of a protected tunnel.
LFA With LFA, a device runs the SPF algorithm to compute the shortest
paths to the destination, using each neighbor that can provide a
backup link as a root node. The device then computes a group of
loop-free backup links with the minimum cost. For more information
about LFA, see IS-IS Auto FRR.
RLFA Remote LFA (RLFA) computes a PQ node based on a protected link

and establishes a tunnel between the source and PQ nodes to offer
alternate next hop protection. If the protected link fails, traffic is
automatically switched to the backup path, improving network
reliability. For more information about RLFA, see IS-IS Auto FRR.
NOTE
When computing an RLFA FRR backup path, Huawei devices compute the
extended P space by default.
TI-LFA In some LFA FRR and RLFA scenarios, the extended P space and Q
space neither intersect nor have direct neighbors. Consequently, no
backup path can be computed, failing to meet reliability
requirements. TI-LFA solves this problem by computing the extended
P space, Q space, and post-convergence SPT based on the protected
path, computing a repair list, and establishing an SR tunnel from the
source node to a P node and then to a Q node to offer alternate next
hop protection. If the protected link fails, traffic is automatically
switched to the backup path, improving network reliability.
NOTE
When computing a TI-LFA FRR backup path, Huawei devices compute the
extended P space by default.

(2020-10-09)
Background
Traditional LFA requires that at least one neighbor be a loop-free next hop to the
destination, and RLFA requires that at least one node be connected to the source
and destination nodes without traversing the failure point. Unlike LFA and RLFA,
TI-LFA uses an explicit path to represent a backup path, which enhances FRR
reliability without any topology constraints.
As an example, assume that packets need to be forwarded from DeviceA to
DeviceF on the network shown in Figure 1-92. If the extended P space and Q
space do not intersect, RLFA requirements are not met. Consequently, no backup
path (also called a remote LDP LSP) can be computed using RLFA. If the link
between DeviceB and DeviceE fails, DeviceB forwards the packets to DeviceC,
which is not a Q node and therefore cannot directly forward the packets to the
destination address. In this situation, DeviceC has to recompute a path. Because
the cost of the link between DeviceC and DeviceD is 100, DeviceC considers that
the optimal path to DeviceF traverses DeviceB. As a result, DeviceC forwards the
packets back to DeviceB, forming a loop and leading to a forwarding failure.
Figure 1-92 RLFA networking
TI-LFA can be used to solve the preceding problem. On the network shown in
Figure 1-93, if the link between DeviceB and DeviceE fails, DeviceB adds new path
information (node SID of DeviceC and adjacency SID for the C-D adjacency) to the
packets based on TI-LFA FRR backup entries. This ensures that the packets can be
forwarded along the backup path.

(2020-10-09)
Figure 1-93 TI-LFA networking
TI-LFA FRR Principles

On the network shown in Figure 1-94, PE1 and PE3 are source and destination
nodes, respectively, and link costs are configured. This example assumes that P1 is
faulty.
TI-LFA provides both link and node protection.
● Link protection: protects traffic traversing a specific link.
● Node protection: protects traffic traversing a specific node. Node protection
takes precedence over link protection.
Figure 1-94 Typical TI-LFA networking

(2020-10-09)
The following uses node protection as an example to describe how to implement

TI-LFA. Assume that traffic travels along the PE1 -> P1 -> P3 -> PE3 path on the
network shown in Figure 1-94. If P1 fails, TI-LFA computes the extended P space,
Q space, post-convergence SPT, backup outbound interface, and repair list, and
then generates backup forwarding entries.
The TI-LFA FRR computation process is as follows:
1. Computes the extended P space {PE2, P2} with PE1's neighbor PE2 as the root
node.
2. Computes the Q space {P3, P4, PE3, PE4} with P3 as the root node.
3. Computes the post-convergence SPT by excluding the primary next hop.
4. Computes a backup outbound interface and a repair list.
– Backup outbound interface: If the extended P space and Q space neither
intersect nor have direct neighbors, the post-convergence next-hop
outbound interface functions as the backup outbound interface.
– Repair list: a constrained path through which traffic can be directed to a
Q node. The repair list consists of a P node label (SID) and a P-to-Q
adjacency label. In Figure 1-94, the repair list consists of P2's node label
100 and the P2-to-P4 adjacency label 9204.
During backup path computation, a SID advertised by the repair node needs to be
selected according to the following rules so that a forwarding label can be
generated:
● The node SID advertised by the repair node is preferentially selected. If the
repair node does not advertise a node SID, a prefix SID advertised by the
repair node is preferentially selected. The smaller the prefix SID, the higher
the priority.
● A node that does not support SR or does not advertise any prefix or node SID
cannot function as the repair node.
TI-LFA FRR Forwarding

After a TI-LFA backup path is computed, if the primary path fails, traffic is
switched to the backup path, preventing packet loss.
Assume that a packet carrying the prefix SID 16100 of PE3 needs to be forwarded
from PE1 to PE3 over the PE1 -> P1 -> P3 -> PE3 path shown in Figure 1-95.
When the primary next hop P1 fails, TI-LFA FRR is triggered, switching traffic to
the backup path.

(2020-10-09)
Figure 1-95 Forwarding over a TI-LFA FRR backup path
The process of forwarding a packet over a TI-LFA FRR backup path is as follows:
1. PE1 encapsulates a label stack into the packet based on the repair list, using
P2's node label 100 as the outer label and the P2-to-P4 adjacency label 9204
as the inner label.
2. After receiving the packet, PE2 searches its label forwarding table according
to the outer label 100 and then forwards the packet to P2.
3. After receiving the packet, P2 searches its label forwarding table according to
the outer label. Because P2 is the egress node, it removes the label 100 to
expose the label 9204, which is an adjacency SID allocated by P2. As such, P2
finds the corresponding outbound interface according to the label 9204,
removes the label, and then forwards the remaining packet content to P4.
the outer label 16100 and then forwards the packet to P3.
the outer label 16100 and then forwards the packet to PE3.
6. After receiving the packet, PE3 searches its label forwarding table according
to the outer label and determines that the label 16100 is a local label.
Therefore, PE3 removes the label. As 16100 is the bottommost label, PE3
performs further packet processing according to IP packet header information.

(2020-10-09)
TI-LFA FRR Usage Scenarios
Table 1-31 TI-LFA FRR usage scenarios

TI-LFA FRR Description Deployment
Protection
TI-LFA FRR Traffic is transmitted 1. Establish an IS-IS neighbor

protects traffic over the primary path in relationship between each
transmitted in IP IP forwarding mode, pair of directly connected
forwarding mode. and a TI-LFA FRR nodes, deploy SR
backup path is networkwide, and configure a
computed. prefix SID for the specified P
node.
2. Enable TI-LFA FRR on the
source node.
TI-LFA FRR Traffic is transmitted 1. Establish an IS-IS neighbor

protects traffic over a primary SR relationship between each
transmitted over tunnel, and a TI-LFA pair of directly connected
an SR tunnel. FRR backup path is nodes, deploy SR
computed. networkwide, and configure
prefix SIDs on P and
destination nodes.
2. Enable TI-LFA FRR on the
source node.
Advantages of TI-LFA FRR

SR-based TI-LFA FRR has the following advantages:
1. Meets basic requirements for IP FRR fast convergence.
2. Theoretically supports all scenarios.
3. Uses an algorithm of moderate complexity.
4. Directly uses a post-convergence path as the backup forwarding path,
involving no intermediate convergence state like other FRR technologies.
1.1.2.12 Anycast FRR
Anycast SID
The anycast SID is the same SID advertised by all routers within a group. On the
network shown in Figure 1-96, Device D and Device E reside on the egress of an
SR area. Traffic can reach the non-SR area through either Device D or Device E.
The two devices can back up each other. In this situation, Device D and Device E
can be configured in the same group and advertise the same prefix SID, the so
called anycast SID.
An anycast SID's next hop directs to Device D that has the smallest IGP cost in the
router group. Device D is called the optimal source that advertises the anycast SID,
and the other device in the router group is the backup source. If the primary next-

(2020-10-09)
hop link or direct neighbor node of Device D fails, traffic can reach the anycast SID
device through the other protection path. The anycast SID device can be the
source that has the same primary next hop or another anycast source. When VPN
traffic passes through an SR LSP, the same VPN private-network label must be
configured for anycast.
Figure 1-96 Anycast SID
Anycast FRR
Anycast FRR allows multiple nodes to advertise the same prefix SID to form FRR.
Common FRR algorithms use the SPT to compute a backup next hop. This applies
to scenarios where a route is advertised by a single node instead of multiple
nodes.
When a route is advertised by multiple nodes, these nodes must be converted to a
single node before a backup next hop is computed for a prefix SID. Anycast FRR
constructs a virtual node to represent the multiple nodes that advertise the same
route and uses the TI-LFA algorithm to compute a backup next hop to the virtual
node. The anycast prefix SID inherits the backup next hop from the created virtual
node. This solution does not involve any modification of the algorithm for
computing the backup next hop. The solution retains the loop-free trait so that no
loop occurs between the computed backup next hop and the primary next hop of
the peripheral node before convergence.

(2020-10-09)
Figure 1-97 IGP FRR networking in a scenario where multiple nodes advertise the
same route
As shown in Figure 1-97 (a), the cost of the Device A-to-Device B link is 5, and
that of the Device A-to-Device C link is 10. Device B and Device C advertise the
same route 10.1.1.0/24 simultaneously. TI-LFA FRR is enabled on Device A.
Because the TI-LFA condition is not met, Device A cannot compute a backup next
hop for the route 10.1.1.0/24. To address this problem, TI-LFA FRR can be used in
scenarios where multiple nodes advertise the same route.
The implementation is as follows on the network shown in Figure 1-97 (b):
1. A virtual node is constructed between Device B and Device C. The virtual node
is connected to both Device B and Device C. The costs of links from Device B
and Device C to the virtual node are 0. The costs of links from the virtual
node to Device B and Device C are infinite.
2. The virtual node advertises a prefix of 10.1.1.0/24. This means that the route
is advertised by a single node.
3. Device A uses the TI-LFA algorithm to compute a backup next hop to the
virtual node. The route 10.1.1.0/24 inherits the computation result. On the
network shown in Figure 1-97 (b), Device A computes two links to the virtual
node. The primary link is from Device A to Device B, and the backup link is
from Device A to Device C.
1.1.2.13 SR-MPLS Microloop Avoidance
Because IGP link state databases (LSDBs) are distributed, network nodes running
an IGP may converge at different times. This may in turn result in microloops, a
kind of transient loop that disappears after all the nodes on the forwarding path
have converged. Microloops result in a series of issues, including packet loss, jitter,
and out-of-order packets, and therefore must be avoided.

(2020-10-09)
SR uses a method with minimal impact on the network to effectively avoid

potential loops. Specifically, if a network topology change may cause a loop, SR
allows network nodes to insert loop-free segment lists to guide traffic to the
destination address. Normal traffic forwarding is restored only when all the
involved network nodes complete convergence.
SR-MPLS Local Microloop Avoidance in a Traffic Switchover Scenario

In a traffic switchover scenario, a local microloop is formed when a node adjacent
to the faulty node converges earlier than the other nodes on the network. On the
network shown in Figure 1-98, TI-LFA is deployed on all nodes. If node B is faulty,
node A undergoes the following process to perform convergence for the route to
node C:
1. Node A detects the fault and enters the TI-LFA FRR process, during which
node A inserts the repair list <16056> into the packet to direct the packet to
the TI-LFA-computed PQ node, that is, node E. To direct the packet to node E,
node A needs to forward the packet to the next-hop node D first. The SIDs
encapsulated into the packet are <16056, 103>.
2. After performing route convergence, node A searches for the route to node C
and forwards the packet to the next-hop node D through the route. In this
case, the packet does not carry any repair list and is directly forwarded based
on the node SID 103.
3. If node D has not completed convergence when receiving the packet, its
routing table has node A as the next hop of the route to node C. As a result,
node D forwards the packet back to node A, which in turn causes a microloop
between the two nodes.
Figure 1-98 SR-MPLS local microloop in a traffic switchover scenario
According to the preceding convergence process, node A completes convergence,

exits the TI-LFA FRR process, and implements normal forwarding before other
nodes on the network complete convergence, resulting in a microloop. The issue is
that node A converges earlier than the other nodes, so by postponing its
convergence, the microloop can be avoided. As TI-LFA backup paths are loop-free,

(2020-10-09)
the packet can be forwarded along a TI-LFA backup path for a period of time.
Node A can then wait for the other nodes to complete convergence before exiting
the TI-LFA FRR process and performing convergence, thereby avoiding the
microloop.
Figure 1-99 SR-MPLS local microloop avoidance in a traffic switchover scenario
After microloop avoidance is deployed on the network shown in Figure 1-99, the
convergence process is as follows:
1. After node A detects the fault, it enters the TI-LFA FRR process, encapsulating
the repair list <16056> into the packet and forwarding the packet along the
TI-LFA backup path, with node D as the next hop.
2. Node A starts the timer T1. During T1, node A does not respond to topology
changes, the forwarding table remains unchanged, and the TI-LFA backup
path continues to be used for packet forwarding. Other nodes on the network
converge properly.
3. When T1 expires, other nodes on the network have completed convergence.
Node A can now perform convergence and exit the TI-LFA FRR process to
forward the packet along a post-convergence path.
The preceding solution can protect only a point of local repair (PLR) against
microloops in a traffic switchover scenario. This is because only a PLR can enter
the TI-LFA FRR process and forward packets along a TI-LFA backup path. In
addition, this solution applies only to single point of failure. In a multiple-point
fault scenario, the TI-LFA backup path may also be adversely affected and
therefore cannot be used for packet forwarding.
For a traffic switchover scenario, if microloop avoidance is configured on a source

node, a delayed route switchover can be performed only when the following
conditions are met:
● A local interface fails, or BFD goes down.
● No network topology change occurs during the delay.
● A backup next hop is available for the involved route.

(2020-10-09)
● The outbound interface of the primary next hop of the involved route is the
faulty interface.
● During the multi-node route convergence delay, if the source node advertising
the route is changed, delay measurement stops.
SR-MPLS Local Microloop Avoidance in a Traffic Switchback Scenario

In addition to traffic switchover scenarios, microloops may also occur in traffic
switchback scenarios. The following uses the network shown in Figure 1-100 as
an example to describe how a microloop occurs in a traffic switchback scenario.
The process is as follows:
1. Node A sends a packet to destination node F along the path A->B->C->E->F. If
the B-C link fails, node A sends the packet to destination node F along the
post-convergence path A->B->D->E->F.
2. After the B-C link recovers, a node (for example, node D) first completes
convergence.
3. When receiving the packet sent from node A, node B has not completed
convergence and therefore continues to forward the packet to node D along
the pre-recovery path, as shown in Figure 1-100.
4. Because node D has completed convergence, it forwards the packet to node B
along the post-recovery path, resulting in a microloop between the two
nodes.
Traffic switchback does not involve the TI-LFA FRR process. Therefore, delayed
convergence cannot be used for microloop avoidance in such scenarios.
Figure 1-100 SR-MPLS local microloop in a traffic switchback scenario
According to the preceding process, a transient loop occurs when node D

converges earlier than node B during fault recovery. Node D is unable to predict

(2020-10-09)
link up events on the network and so is unable to pre-compute any loop-free path
for such events. To avoid loops that may occur during traffic switchback, node D
needs to be able to converge to a loop-free path.
On the network shown in Figure 1-101, after node D detects that the B-C link
goes up, it re-converges to the D->B->C->E->F path.
In addition, the B-C link up event does not affect the path from node D and node
B, proving that the path is loop-free.
NOTICE
Topology changes triggered by a link up event affect only the post-convergence

forwarding path that passes through the link. As such, if the post-convergence
forwarding path from node D to node B does not pass through the B-C link, it is
not affected by the B-C link up event. Similarly, topology changes triggered by a
link down event affect only the pre-convergence forwarding path that passes
through the link.
A loop-free path from node D to node F can be constructed without specifying the
path from node D to node B. Because the path from node C to node F is not
affected by the B-C link up event, it is definitely loop-free. In this scenario, only
the path from node B to node C is affected. Given this, to compute a loop-free
path from node D to node F, you only need to specify a path from node B to node
C. According to the preceding analysis, a loop-free path from node D to node F
can be formed by inserting only an adjacency SID that instructs packet forwarding
from node B to node C into the post-convergence path of node D.
Figure 1-101 SR-MPLS local microloop avoidance in a traffic switchback scenario
After microloop avoidance is deployed, the convergence process is as follows:

(2020-10-09)
convergence.
2. Node D starts the timer T1. Before T1 expires, node D computes a microloop
avoidance segment list <16023> for the packet destined for node F.
the pre-recovery path.
4. Node D inserts the microloop avoidance segment list <16023> into the packet
and forwards the packet to node B.
NOTICE
Although the packet is sent from node B to node D and then back to node B,
no loop occurs because node D has inserted the adjacency SID 16023 into the
packet.
5. According to the instruction bound to the adjacency SID 16023, node B

forwards the packet to node C through the outbound interface specified by
the SID and then removes the outer label 16023.
6. According to the node SID 106, node C forwards the packet to destination
node F along the shortest path.
As previously described, node D inserts the microloop avoidance segment list
<16023> into the packet, avoiding loops.
When T1 of node D expires, other nodes on the network have completed
convergence, allowing node A to forward the packet along the post-convergence
path A->B->C->E->F.
SR-MPLS Remote Microloop Avoidance in a Traffic Switchover Scenario

In a traffic switchover scenario, a remote microloop may also occur between two
nodes on a packet forwarding path if the node close to the point of failure
converges earlier than one farther from the point. The following uses the network
shown in Figure 1-102 as an example to describe how a remote microloop occurs
in a traffic switchover scenario. The process is as follows:
1. After detecting a C-E link fault, a node (for example, node G) first completes
convergence, whereas node B has not converged.
2. Nodes A and B forward the packet to node G along the path used before the
fault occurs.
3. Because node G has completed convergence, it forwards the packet to node B
according to the next hop of the corresponding route, resulting in a microloop

(2020-10-09)
Figure 1-102 SR-MPLS remote microloop in a traffic switchover scenario
To minimize computation workload, generally, a network node can pre-compute a

loop-free path only when a directly connected link or node fails. That is, no loop-
free path can be pre-computed against any other potential fault on the network.
Given this, the microloop can be avoided only by installing a loop-free path after
node G converges.
As mentioned above, topology changes triggered by a link down event affect only
the pre-convergence forwarding path that passes through the link. If the path
from a node to the destination node does not pass through the faulty link before
convergence, the path is not affected by the link fault. In the topology shown in
Figure 1-102, the path from node G to node D is not affected by the C-E link
fault, and therefore does not need to be specified for computing a loop-free path
from node G to node F. Similarly, the path from node E to node F is not affected
by the C-E link fault, and therefore does not need to be specified, either. Because
only the path from node D to node E is affected by the C-E link fault, you only
need to specify the adjacency SID 16045 identifying the path from node D to node
E to determine the loop-free path, as shown in Figure 1-103.

(2020-10-09)
Figure 1-103 SR-MPLS remote microloop avoidance in a traffic switchover

scenario

convergence.
2. Node G starts the timer T1. Before T1 expires, node G computes a microloop
avoidance segment list <16045> for the packet destined for node F.
convergence and therefore continues to forward the packet to node G along
the path used before the fault occurs.
4. Node G inserts the microloop avoidance segment list <16045> into the packet
NOTICE
Although the packet is sent from node B to node G and then back to node B,
no loop occurs because node G has inserted the adjacency SID 16045 into the
packet.
5. According to the instruction bound to the adjacency SID 16045, node B

forwards the packet to node D.
6. According to the instruction bound to the adjacency SID 16045, node D
forwards the packet to node E through the outbound interface specified by
the SID and then removes the outer label 16045.
7. According to the node SID 106, node E forwards the packet to destination
node F along the shortest path.
As previously described, node G inserts the microloop avoidance segment list
<16045> into the packet, avoiding loops.

(2020-10-09)
When T1 of node G expires, other nodes on the network have completed

path A->B->D->E->F.
SR-MPLS Remote Microloop Avoidance in a Traffic Switchback Scenario

how a remote microloop occurs in a traffic switchback scenario. The process is as
follows:
1. After the C-E link recovers, a node (for example, node B) first completes
convergence, whereas node G has not converged.
2. Node B forwards the packet to node G.
3. Because node G has not completed convergence, it continues to forward the
packet to node B along the pre-recovery path, resulting in a microloop
To avoid the microloop, start the timer T1 on node B. Then, before T1 expires,
node B inserts an adjacency SID identifying the path between nodes G and C into
the packet destined for node F to ensure that the packet can be forwarded to
node C. In this way, node C can forward the packet to destination node F
according to the node SID 106 along the shortest path.
1.1.2.14 SR-MPLS OAM
SR-MPLS Operation, Administration, and Maintenance (OAM) monitors LSP

connectivity and rapidly detects faults. SR-MPLS OAM is implemented using ping
and tracert.
SR-MPLS ping and tracert send MPLS Echo Request packets during forward
detection based on MPLS label forwarding. The SR-MPLS ping and tracert
backhaul MPLS Echo Reply message is forwarded using multi-hop IP path. Ping
and tracert can specify the source IP address. If no source IP address is specified,
the local MPLS LSR-ID is used as the source IP address. The source IP address in
the MPLS Echo Request packet is used as the destination IP address for the MPLS
Echo Reply packet.
SR-MPLS BE Ping
On the network shown in Figure 1-104, PE1, P1, P2, and PE2 are all capable of
SR-MPLS. An SR LSP is established between PE1 and PE2.

(2020-10-09)
Figure 1-104 SR-MPLS BE ping/tracert
The process of initiating an SR-MPLS BE ping test from PE1 is as follows:

1. PE1 initiates a ping test and checks whether the specified tunnel type is SR-
MPLS BE IPv4.
– If the specified tunnel type is not SR-MPLS BE IPv4, PE1 reports an error
message indicating a tunnel type mismatch and stops the ping test.
– If the specified tunnel type is SR-MPLS BE IPv4, the following operations
are performed:
2. PE1 constructs an MPLS Echo Request packet encapsulating the outer label of
the initiator and carrying destination address 127.0.0.0/8 in the IP header of
the packet.
3. PE1 forwards the packet to P1. After receiving the packet, P1 swaps the outer
MPLS label of the packet and forwards the packet to P2.
4. Similar to P1, P2 swaps the outer MPLS label of the received packet and
determines whether it is the penultimate hop. If yes, P2 removes the outer
label and forwards the packet to PE2. PE2 sends the packet to the Rx/Tx
module for processing.
5. PE2 returns an MPLS Echo Reply packet to PE1 and generates the ping test
result.
SR-MPLS BE Tracert
On the network shown in Figure 1-104, the process of initiating an SR-MPLS BE
tracert test from PE1 is as follows:
MPLS BE IPv4.
– If the specified tunnel type is not SR-MPLS BE IPv4, PE1 reports an error
message indicating a tunnel type mismatch and stops the tracert test.

(2020-10-09)
– If the specified tunnel type is SR-MPLS BE IPv4, the following operations

are performed:
2. PE1 constructs an MPLS Echo Request packet encapsulating the outer label of
the initiator and carrying destination address 127.0.0.0/8 in the IP header of
the packet.
whether the TTL–1 value in the outer label of the received packet is 0.
– If the TTL–1 value is 0, an MPLS TTL timeout occurs. P1 sends the packet
to the Rx/Tx module for processing and returns a reply packet to PE1.
– If the TTL–1 value is greater than 0, P1 swaps the outer MPLS label of the
packet, searches the forwarding table for the outbound interface, and
forwards the packet to P2.
4. Similar to P1, P2 also performs the following operations:
– If the TTL–1 value is 0, an MPLS TTL timeout occurs. P2 sends the packet
to the Rx/Tx module for processing and returns a reply packet to PE1.
– If the TTL–1 value is greater than 0, P2 swaps the outer MPLS label of the
received packet and determines whether it is the penultimate hop. If yes,
P2 removes the outer label, searches the forwarding table for the
outbound interface, and forwards the packet to PE2.
5. PE2 sends the packet to the Rx/Tx module for processing, returns an MPLS
Echo Reply packet to PE1, and generates the tracert test result.
SR-MPLS TE Ping
On the network shown in Figure 1-105, PE1, P1, and P2all support SR-MPLS. An
SR-MPLS TE tunnel is established between PE1 and PE2. The devices assign
adjacency labels as follows:
● PE1 assigns adjacency label 9001 to PE1-P1 adjacency.
● P1 assigns adjacency label 9002 to P1-P2 adjacency.
● P2 assigns adjacency label 9005 to P2-PE2 adjacency.
Figure 1-105 SR-MPLS TE ping and tracert

(2020-10-09)
The process of initiating an SR-MPLS TE ping test from PE1 is as follows:

MPLS TE.
– If the specified tunnel type is not SR-MPLS TE, PE1 reports an error
message indicating a tunnel type mismatch and stops the ping test.
– If the specified tunnel type is SR-MPLS TE, the following operations are
performed.
2. PE1 constructs an MPLS Echo Request packet encapsulating label information
about the entire tunnel and carrying destination address 127.0.0.0/8 in the IP
header of the packet.
3. PE1 forwards the packet to P1. P1 removes the outer label (9002) of the
received packet and forwards the packet to P2.
4. P2 removes the outer label (9005) of the received packet and forwards the
packet to PE2 for processing.
5. PE2 returns an MPLS Echo Reply packet to PE1.
SR-MPLS TE Tracert
On the network shown in Figure 1-105, the process of initiating an SR-MPLS TE
tracert test from PE1 is as follows:
1. PE1 initiates a tracert test and checks whether the specified tunnel type is SR-
MPLS TE.
– If the specified tunnel type is not SR-MPLS TE, PE1 reports an error
message indicating a tunnel type mismatch and stops the tracert test.
– If the specified tunnel type is SR-MPLS TE, the following operations are
performed.
2. PE1 constructs an MPLS Echo Request packet encapsulating label information
about the entire tunnel and carrying destination address 127.0.0.0/8 in the IP
header of the packet.
whether the TTL-1 value in the outer label is 0.
– If the TTL-1 value is 0, an MPLS TTL timeout occurs. P1 sends the packet
to the Rx/Tx module for processing and returns an MPLS Echo Reply
packet to PE1.
– If the TTL-1 value is greater than 0, P1 removes the outer MPLS label of
the packet, buffers the TTL-1 value, copies the value to the new outer
MPLS label, searches the forwarding table for the outbound interface,
and forwards the packet to P2.
4. Similar to P1, P2 also determines whether the TTL-1 value in the outer label
of the received packet is 0.
– If the TTL-1 value is 0, an MPLS TTL timeout occurs. P2 sends the packet
to the Rx/Tx module for processing and returns an MPLS Echo Reply
packet to P1.
– If the TTL-1 value is greater than 0, P2 removes the outer MPLS label of
the packet, buffers the TTL-1 value, copies the value to the new outer
MPLS label, searches the forwarding table for the outbound interface,
and forwards the packet to PE2.

(2020-10-09)
5. P2 forwards the packet to PE2, and PE2 returns an MPLS Echo Reply packet to
PE1.
1.1.2.15 MPLS in UDP
MPLS in UDP Fundamentals

In Figure 1-106, the controller manages both the DCN and DCI WAN. A gateway
(GW) sends a request to establish an E2E optimal path to the controller, and the
controller returns path computation results to the GW. To simplify network
deployment and management, SR-MPLS technology has been used on the DCN. If
DCN A and DCN B need to communicate with each other, they need to traverse
through the MAN and DCI WAN. The DCI WAN is a new network and has the SR
capability. However, the MAN is a legacy network and does not have the SR
capability. The MAN cannot forward the SR-MPLS traffic.
Figure 1-106 Typical MPLS in UDP scenario
MPLS in UDP is a DCN overlay technology that encapsulates MPLS packets (or SR-
MPLS packets) into UDP packets to traverse through some networks that do not
support MPLS or SR-MPLS. MPLS in UDP solves the problem of bearer protocol
conversion between the DCN and WAN and unifies the tunnel protocols run on
the DCN and WAN.
In Figure 1-106, an MPLS-in-UDP tunnel is established between GW1 and DCI-

PE1 using MPLS-in-UDP technology. With this tunnel, traffic from DCN A to DCN B
is carried over the SR protocol, implementing end-to-end traffic optimization. The
data forwarding process is as follows:

(2020-10-09)
1. Device 1 encapsulates VMa1-to-VMb1 packets and sends them to DCN GW1.

2. Upon receipt of the packets, GW1 on DCN A encapsulates SR-MPLS
information into VXLAN packets based on the path computation results of the
controller. Because MAN A does not support SR, GW1 has to encapsulate the
SR-MPLS packets using UDP and diverts the UDP packets to the MPLS-in-UDP
tunnel. The MAN forwards the UDP packets to DCI-PE1.
3. After receiving the SR-MPLS packets, DCI-PE1 forwards the packets to DCI-PE2
using SR-MPLS TE.
4. DCI-PE2 forwards the packets to MAN B over IP routes.
5. MAN B forwards the packets to GW2 over IP routes.
6. GW2 forwards the packets to Device 3 over IP routes. Upon receipt of the
packets, Device 3 decapsulates the packets and sends them to VMb1.
To prevent UDP packets from being attacked, MPLS in UDP technology supports
source IP address verification. The source IP address is the IP address of the ingress
of the MPLS-in-UDP tunnel. The packets are accepted only when the source IP
addresses are successfully verified. Otherwise, the packets are discarded. In Figure
1-106, source IP address verification is enabled on DCI-PE1 that is the egress of
the MPLS-in-UDP tunnel. After DCI-PE1 receives the MPLS-in-UDP packets, DCI-
PE1 verifies the contained source IP addresses, which improves transmission
security.
If a device serves as the egress nodes of different MPLS-in-UDP tunnels, a valid

source IP address list must be configured based on specified local IP addresses.
Format of an MPLS-in-UDP Packet

Figure 1-107 shows the MPLS-in-UDP packet format.
Figure 1-107 Format of an MPLS-in-UDP packet
Table 1-32 Description of fields in an MPLS-in-UDP packet

Name
Source Port 16 bits Source interface number, which is generated by a

= Entropy device that encapsulates packets
Dest Port = 16 bits Destination interface number, which is fixed at 6635

MPLS indicating an MPLS-in-UDP interface

(2020-10-09)

Name
UDP 16 bits UDP packet size

Length
UDP 16 bits UDP checksum

Checksum
MPLS Label Variable Depth of an MPLS label stack

Stack length
Message Variable Size of MPLS packet content

Body length
1.1.2.16 SR-MPLS TTL
The TTL field in MPLS packets transmitted over public SR-MPLS TE and SR-MPLS
BE tunnels are processed in either of the following modes:
● Uniform mode
When an IP packet passes through an SR-MPLS network, the IP TTL decreases
by 1 on the ingress and is mapped to the MPLS TTL field. Then, the MPLS TTL
decreases by 1 each time the packet passes through a node on the SR-MPLS
network. After the packet arrives at the egress, the MPLS TTL decreases by 1
and is compared with the IP TTL value. Then, the smaller value is mapped to
the IP TTL field. Figure 1-108 shows how the TTL is processed in uniform
mode.
Figure 1-108 TTL processing in uniform mode
● Pipe mode
When an IP packet passes through an SR-MPLS network, the IP TTL decreases
by 1 on the ingress, and the MPLS TTL is a fixed value. Then, the MPLS TTL
decreases by 1 each time the packet passes through a node on the SR-MPLS
network. After the packet arrives at the egress, the IP TTL decreases by 1. To
summarize, in pipe mode, the IP TTL in a packet decreases by 1 only on the

(2020-10-09)
ingress and egress no matter how many hops exist between the ingress and
egress on an SR-MPLS network. Figure 1-109 shows how the TTL is processed
in pipe mode.
Figure 1-109 TTL processing in pipe mode
1.1.3 Application Scenarios for Segment Routing MPLS
1.1.3.1 Single-AS SR-MPLS TE
Manual Configuration + PCEP Delegation

On the network shown in Figure 1-110, labels are allocated by devices and
advertised through an IGP SR extension; network topology and label information
is collected through BGP-LS. On each forwarder, a strict explicit path is manually
configured to establish an SR-MPLS TE tunnel, and the tunnel is delegated to the
controller. The controller runs PCEP to deliver associated label stack information,
instructing the forwarders to forward data.

(2020-10-09)
Figure 1-110 Manual configuration + PCEP delegation
Controller-based Path Computation

On the network shown in Figure 1-111, labels are allocated by devices and
advertised through an IGP SR extension. Network topology and label information
is collected through BGP-LS and then sent to the controller for path computation.
After computing an SR tunnel path, the controller runs NETCONF to deliver
associated label stack information, instructing the forwarders to forward data.
Figure 1-111 Controller-based path computation
DCI services on the network are carried over an L3VPN in per tenant per VPN
mode. Within each DC, tenants are isolated, and the DC gateway accesses the

(2020-10-09)
L3VPN through a VLAN sub-interface. The VPN services of tenants are carried over
the primary and backup SR-MPLS TE paths.
1.1.3.2 Inter-AS E2E SR-MPLS TE
Service Overview
The future network is oriented to the 5G era. Bearer networks also need to adapt
to the trend by simplifying networks, providing low latency, and implementing
software-defined networking (SDN) and network functions virtualization (NFV).
E2E SR-MPLS TE can carry VPN services through a complete inter-AS tunnel, which
greatly reduces networking and O&M costs and meets carriers' unified O&M
requirements.
Networking Description
Figure 1-112 illustrates the typical application of the inter-AS E2E SR-MPLS TE
technology on a bearer network. The overall service model is EVPN over SR-MPLS
TE. An E2E SR-MPLS TE tunnel is used for unified transmission. The data service
model is EVPN. The network is oriented to 5G and has the features of simplified
solution, protocol, and tunnel, and unified reliability solution. It works with the
network controller to quickly respond to upper-layer service requirements.

(2020-10-09)
Figure 1-112 Application of inter-AS E2E SR-MPLS TE on the bearer network
Feature Deployment
When an inter-AS E2E SR-MPLS TE network is used to carry EVPN services, the
service deployment is as follows:
● Configure IGP SR within an AS domain to establish an intra-AS SR-MPLS TE
tunnel and BGP EPE between AS domains to assign inter-AS SIDs. Binding
SIDs are used to combine SR-MPLS TE tunnels in multiple AS domains into an
inter-AS E2E SR-MPLS TE tunnel.
● EVPN is deployed to carry various services, including EVPN VPWS, EVPN VPLS,
and EVPN L3VPN. In addition to EVPN, the traditional BGP L3VPN can be
smoothly switched to the E2E SR-MPLS TE tunnel.
● In terms of reliability, intra-AS SR-MPLS TE tunnels are monitored by BFD or
SBFD. TE hot standby (HSB) technology switches traffic between the primary

(2020-10-09)
and HSB TE LSPs. Inter-AS E2E SR-MPLS TE tunnels are monitored by one-arm
BFD. TE HSB is used to switch traffic between the primary and HSB TE LSPs.
VPN FRR is used to switch traffic between the primary and HSB E2E SR-MPLS
TE tunnels.
1.1.3.3 SR-MPLS TE Policy Application
On the network shown in Figure 1-113, DCI services are carried over L3VPN, with
per tenant per VPN instance as the service model, achieving tenant isolation in the
data center (DC). DC gateways use VLAN sub-interfaces to access the L3VPN. The
VPN services of tenants are carried using different SR Policies.
Figure 1-113 SR-MPLS TE Policy application
This solution requires the following key items to be configured:

● IGP SR: The IGP extension supports SR for advertising SR capabilities, assigns
labels, and spreads label information.
● BGP-LS: BGP-LS collects network topology and label information and sends
the information to the controller for SR-MPLS TE Policy computation.
● BGP SR-MPLS TE Policy address family-specific BGP peer relationship: ABGP
SR-MPLS TE Policy address family-specific BGP peer relationship needs to be
established between the controller and PE, so that the controller can deliver
an SR-MPLS TE Policy route to the PE through the BGP peer relationship. A
NETCONF neighbor relationship can also be configured between the
controller and PE, so that you can configure an SR-MPLS TE Policy through
NETCONF.
1.1.4 Terminology for Segment Routing MPLS

(2020-10-09)
Terms
Term Definition
SR-MPLS BE A technology that allows an IGP to run the shortest

path first algorithm to compute an optimal SR LSP on
an SR-MPLS network.
SR-MPLS TE A technology that allows SR tunnels to be created

based on TE constraints on an SR-MPLS network.
Acronyms and Abbreviations

Acronym and Full Name
Abbreviation
BGP-LS BGP Link-State
E2E End to End
FRR fast re-route
NETCONF Network Configuration Protocol
PCE path computation element
PCEP Path Computation Element Communication Protocol
SID segment ID
SR Segment Routing
SRGB Segment Routing global block
TE traffic engineering
TI-LFA FRR topology-independent loop-free alternate FRR
1.2 Segment Routing MPLS Configuration

This chapter describes the basic principles, configuration procedures, and
configuration examples of Segment Routing (SR) MPLS.
1.2.1 Overview of Segment Routing MPLS

Segment Routing (SR) is a protocol designed to forward data packets using the
source routing model. Segment Routing MPLS (SR-MPLS) is implemented based
on the MPLS forwarding plane and is referred to as SR hereinafter. SR divides a
network path into several segments and assigns a segment ID (SID) to each
segment and forwarding node. The segments and nodes are then sequentially
arranged into segment lists to form a forwarding path.
SR encapsulates segment list information that identifies a forwarding path into a
data packet header for transmission. After receiving a packet, the receive end

(2020-10-09)
parses the segment list. If the SID at the top of the segment list identifies the local
node, the node removes the SID and executes the follow-up procedure. If the SID
at the top does not identify the local node, the node forwards the packet to the
next hop in equal cost multiple path (ECMP) mode.
SR offers the following benefits:
● Simplified control plane of the MPLS network
SR uses a controller or an IGP to uniformly compute paths and distribute
labels, without the need for tunneling protocols such as RSVP-TE and LDP. In
addition, it can be directly used in the MPLS architecture, without requiring
any changes to the forwarding plane.
● Efficient Topology-Independent Loop-free Alternate (TI-LFA) FRR protection
for fast path failure recovery
On the basis of remote loop-free alternate (RLFA) FRR, SR provides TI-LFA
FRR, which offers node and link protection for all topologies and addresses
the weaknesses in conventional tunnel protection techniques.
● Higher network capacity expansion capabilities
MPLS TE is a connection-oriented technology. To maintain connection status,
MPLS TE requires devices to exchange and process numerous keepalive
packets, straining the control plane. Unlike MPLS TE, SR can control any
service path by merely performing label operations on the ingress. It does not
require transit nodes to maintain path information, thereby freeing up the
control plane.
Moreover, the SR label quantity on a network is the sum of the node quantity
and local adjacency quantity, meaning that it is related only to the network
scale, rather than the tunnel quantity or service volume.
● Smoother evolution to SDN networks
As SR is designed based on the source routing concept, it enables the ingress
node to control packet forwarding paths on a network. Moreover, it can work
with the centralized path computation module to flexibly and easily control
and adjust paths.
SR supports both legacy and SDN networks and is compatible with existing
devices, allowing existing networks to evolve smoothly to SDN networks
instead of subverting existing networks.
1.2.2 Segment Routing MPLS Licensing Requirements and

Configuration Precautions
Licensing Requirements
For details, see "Licensing Requirements" in Feature Description.

(2020-10-09)
Restrictions Guidelines Impact
● For an inter-AS SR- Plan services properly. Services are interrupted.

MPLS TE tunnel in
Binding SID mode, if
the number of labels
in a label stack
exceeds three, the
tunnel cannot go Up.
● If a label is configured
for an inter-AS SR-
MPLS TE tunnel in
Binding SID mode and
the label type is
Binding SID, the
following functions
are not supported for
the tunnel: packet
priority-based
mapping, statistics,
MTU, TTL, and so on.
For an SR-MPLS TE Plan services properly. Services are interrupted.

tunnel with the BGP-EPE
label as the first label,
when the BGP-EPE label
corresponds to multiple
outbound interfaces, TE
bandwidth limit is not
supported.
Anycast protection Deploy anycast Anycast protection does

cannot be deployed on protection only on P not take effect.
segment routing MPLS nodes.
ingress and egress nodes.
Anycast protection
means that the same
prefix SID is configured
for multiple devices.
Traffic over Segment None NetStream sampling on

Routing tunnels can be the ingress (network-to-
sampled by NetStream user) or transit node is
on the ingress (user-to- unavailable for traffic
network) and by transmitted over
NetStream on the egress. Segment Routing
NetStream sampling on tunnels.
the ingress (network-to-
user) or transit node is
not supported.

(2020-10-09)
An SR-MPLS BE Prefix/ If prefix SIDs conflict, the The labeled forwarding

Node SID must be IGP mechanism can be path computation is
unique on an entire used to preferentially affected.
network. The SID value select a prefix SID.
must be within the SRGB
range.
SR-MPLS TE Policies do Properly plan paths If relevant configurations

not support inter-tunnel using a controller. are incorrect, traffic is
recursion. interrupted.
1. SR-MPLS TE Policies
cannot be recursed to
other types of tunnels,
including SR-MPLS TE
Policy tunnels.
2. Other types of tunnels
cannot be recursed to
SR-MPLS TE Policy
tunnels.
SR-MPLS TE ingress Deploy hot-standby TI-LFA protection does

nodes do not support TI- protection. not take effect.
LFA protection on
LPUF-50/LPUF-50-L/
LPUI-21-L/LPUI-51-L/
LPUF-51/LPUF-51-B/
LPUI-51/LPUI-51-B/
LPUS-51/LPUF-101/
LPUF-101-B/LPUI-101/
LPUI-101-B/
LPUS-101boards.
When the outer label in None No impact.

the label stack of an SR-
MPLS TE explicit path is
a Binding SID, the
maximum SID depth
(MSD) cannot exceed
three.
The bandwidth limit The controller None

function is not supported guarantees the
on Segment Routing bandwidth of the
tunnels using node SIDs. delivered Segment
Routing tunnels
established using node
SIDs.

(2020-10-09)
Path verification cannot Do not run the mpls te Path verification cannot
be enabled on the path verification enable be enabled on the
ingress of an inter-AS command to enable path ingress of an inter-AS
SR-MPLS TE tunnel. If verification on the SR-MPLS TE tunnel. If
path verification is ingress of an inter-AS path verification is
enabled, LSP creation SR-MPLS TE tunnel. enabled, LSP creation
fails in the case of a fails in the case of a
verification failure. verification failure.
Ensure that the mpls te
path verification enable
command is not run to
enable path verification.
By default, the function
is disabled.
If BFD is configured on Configure a tunnel A BFD session cannot go

the ingress and the mapped to the Binding Up.
reverse BFD path is over SID on the egress to
a Binding SID tunnel but ensure that the reverse
the tunnel mapped to BFD path can go Up.
the Binding SID on the
egress does not exist, the
BFD session goes Down.
Link-type SR-MPLS TE Deploy anycast Anycast protection does

tunnels consisting of protection for SR-MPLS not take effect.
adjacency SIDs do not TE tunnels consisting of
support SR-MPLS TE node SIDs.
anycast protection.
After a Binding SID is None No impact.

configured for a tunnel
and is referenced by an
explicit path, the Binding
SID of the tunnel cannot
be modified or deleted.
If a Binding SID is None No impact.

configured for a tunnel
and is referenced by an
explicit path, the tunnel
cannot be deleted.

(2020-10-09)
If you enable SBFD after You are advised to If SBFD is not enabled,
configuring an SR-MPLS enable SBFD and then traffic forwarding may
TE Policy under which configure an SR-MPLS TE fail even when the
candidate paths and the Policy. protocol-side tunnel
segment lists of the state is up.
candidate paths are up,
the candidate paths and
segment lists keep up,
and traffic can be
properly steered into the
SR-MPLS TE Policy.
If you enable SBFD and
then configure an SR-
MPLS TE Policy whose
initial state is down,
traffic can be steered
into the SR-MPLS TE
Policy only when SBFD
detects that the SR-MPLS
TE Policy is up.
If SBFD is enabled after You are advised to If SBFD is enabled after

SR-MPLS TE Policy enable SBFD before SR- SR-MPLS TE Policy
configuration, the MPLS TE Policy configuration, traffic
candidate paths under configuration. In forwarding is normal at
the SR-MPLS TE Policy addition, configure SBFD the beginning. However,
and the segment lists of on the reflector end. because SBFD is not
the candidate paths are configured on the
initially up. However, if reflector end, BFD
SBFD is not configured negotiation times out,
on the reflector end, the interrupting forwarding-
segment list state is set plane traffic.
to down after the BFD
negotiation timeout
period (5 minutes)
expires.
If the first hop of an None No impact.

explicit path is assigned
a Binding SID (indicating
that the tunnel that
references the explicit
path needs to be
forwarded through a
tunnel assigned the
Binding SID), the first
hop of the explicit path
used by the tunnel
assigned the Binding SID
cannot be assigned a
Binding SID.

(2020-10-09)
When a Binding SID Configure BFD. The tunnel is Up but fails

label is configured for an to forward traffic,
explicit path, the system affecting service traffic.
does not check whether
the tunnel mapped to
the Binding SID exists or
is Up. If the tunnel does
not exist or is not Up, a
tunnel established over
the explicit path can go
Up but fails to forward
traffic. Therefore, ensure
that the configuration is
correct.
A single binding sid None No impact.

(BSID) is configured for
each tunnel. Each BSID
can be referenced by
only a single tunnel.

(2020-10-09)
The SID forwarding entry Properly plan the Service traffic fails to be
corresponding to the network. forwarded.
prefix of the IP route of
the involved process is
generated only when the
IP route is active. Ensure
that the following
requirements are met if
multiple processes or
protocols are deployed.
Otherwise, SR-MPLS BE
and SR-MPLS TE traffic
may fail to be forwarded.
The IP route prefix used
for SID advertisement is
not concurrently
advertised through
multiple processes or
protocols.
If an IP route prefix is
required to be
concurrently advertised
through multiple
processes or protocols,
the IP routes to be
advertised by the process
or protocol that
advertises the
corresponding SID must
have the highest priority
among all the routes on
the devices in the SID
advertisement scope.

(2020-10-09)
The function of detecting None If SBFD for SR-MPLS TE

BGP EPE outbound tunnel is disabled, the
interface faults and ingress of an SR-MPLS
triggering service TE tunnel cannot detect
switching through SBFD BGP EPE outbound
for SR-MPLS TE tunnel interface faults, causing
can be used only when unicast traffic on the
the following conditions public IP network to be
are met: continuously lost.
1. The destination of an
SR-MPLS TE tunnel is the
local ASBR of BGP EPE.
2. The innermost label in
an SR-MPLS TE label
stack is a BGP EPE label.
3. SBFD for SR-MPLS TE
tunnel has been
deployed.
The function of detecting When this function is If the type of the BGP
BGP EPE outbound deployed, ensure that EPE outbound interface
interface faults and the BGP EPE outbound is not supported, traffic
triggering service interface is an Ethernet cannot rapidly recover in
switching through SBFD main interface, Ethernet the case of a BGP EPE
for SR-MPLS TE tunnel sub-interface, Eth-Trunk outbound interface fault.
can be used only when main interface, Eth-Trunk
the BGP EPE outbound sub-interface, or POS
interface is an Ethernet interface.
main interface, Ethernet
sub-interface, Eth-Trunk
main interface, Eth-Trunk
sub-interface, or POS
interface.

(2020-10-09)
The function of detecting Do not use LPUF-50/ If the BGP EPE inbound
BGP EPE outbound LPUF-50-L/LPUI-21-L/ interface resides on the
interface faults and LPUI-51-L/LPUF-51/ LPUF-50/LPUF-50-L/
triggering service LPUF-51-B/LPUI-51/ LPUI-21-L/LPUI-51-L/
switching through SBFD LPUI-51-B/LPUS-51/ LPUF-51/LPUF-51-B/
for SR-MPLS TE tunnel LPUF-101/LPUF-101-B/ LPUI-51/LPUI-51-B/
does not support LPUI-101/LPUI-101-B/ LPUS-51/LPUF-101/
LPUF-50/LPUF-50-L/ LPUS-101 boards. LPUF-101-B/LPUI-101/
LPUI-21-L/LPUI-51-L/ LPUI-101-B/LPUS-101
LPUF-51/LPUF-51-B/ board, the function of
LPUI-51/LPUI-51-B/ detecting BGP EPE
LPUS-51/LPUF-101/ outbound interface faults
LPUF-101-B/LPUI-101/ and triggering service
LPUI-101-B/LPUS-101 switching through SBFD
boards. for SR-MPLS TE tunnel
does not take effect, and
traffic cannot rapidly
recover.
The function of detecting Do not deploy seven or If seven or more BGP

BGP EPE outbound more BGP EPE links for EPE links fail at the same
interface faults and load balancing. time in BGP EPE load
triggering service balancing scenarios, the
switching through SBFD following risks exist:
for SR-MPLS TE tunnel 1. Although traffic can
poses the following risks continue to be
if seven or more BGP EPE forwarded, SR-MPLS TE
links fail at the same SBFD goes down,
time in BGP EPE load triggering traffic
balancing scenarios: convergence or switching
1. Although traffic can on the ingress of an SR-
continue to be MPLS TE tunnel.
forwarded, SR-MPLS TE 2. Data packets are
SBFD goes down, discarded, but SBFD is
triggering traffic still up. As a result,
convergence or switching traffic recovers until BGP
on the ingress of an SR- EPE convergence is
MPLS TE tunnel. complete.
2. Data packets are
discarded, but SBFD is
still up. As a result,
traffic recovers until BGP
EPE convergence is
complete.

(2020-10-09)
The function of detecting 1. Disable the MPLS TE 1. Unexpected public

BGP EPE outbound IGP shortcut function on traffic is forwarded
interface faults and SR-MPLS TE tunnel across ASs, which may
triggering service interfaces to prevent cause traffic loss.
switching through SBFD unexpected public IP 2. VPN traffic loss occurs.
for SR-MPLS TE tunnel traffic from recursing to
applies only to scenarios inter-AS SR-MPLS TE
where inter-AS public IP tunnels.
unicast packets are 2. Configure redirection
transmitted over SR- to steer inter-AS traffic
MPLS TE tunnels. to inter-AS SR-MPLS TE
tunnels.
3. Run the mpls te
reserved-for-binding
command on SR-MPLS
TE tunnel interfaces to
prevent VPN traffic from
recursing to inter-AS SR-
MPLS TE tunnels.
A maximum of 64 BGP None None

EPE links can be
configured for load
balancing. If more than
64 BGP EPE links exist,
the first 64 links are
selected based on the
OutIfIndex values of
outbound interfaces in
descending order. If the
sixty-fourth and sixty-
fifth links have the same
OutIfIndex value, the
one with the largest
NextHop value is
selected.

(2020-10-09)
The function of enabling When this function is If the type of the BGP
BGP EPE outbound deployed, ensure that EPE outbound interface
interface faults to trigger the BGP EPE outbound is not supported, traffic
routing table lookups interface is an Ethernet cannot rapidly recover in
due to the rollback of main interface, Ethernet the case of a BGP EPE
public IP unicast traffic sub-interface, Eth-Trunk outbound interface fault.
can be used when the main interface, Eth-Trunk
outbound interface of a sub-interface, or POS
BGP EPE link is an interface.
Ethernet, ETH-Trunk, or
POS interface. Other
types of interfaces do
not support fast
switching.
The function of enabling None If the BGP EPE inbound

BGP EPE outbound interface resides on the
interface faults to trigger LPUF-50/LPUF-50-L/
routing table lookups LPUI-21-L/LPUI-51-L/
due to the rollback of LPUF-51/LPUF-51-B/
public IP unicast traffic LPUI-51/LPUI-51-B/
does not support LPUS-51/LPUF-101/
LPUF-50/LPUF-50-L/ LPUF-101-B/LPUI-101/
LPUI-21-L/LPUI-51-L/ LPUI-101-B/LPUS-101
LPUF-51/LPUF-51-B/ board, the function of
LPUI-51/LPUI-51-B/ enabling BGP EPE
LPUS-51/LPUF-101/ outbound interface faults
LPUF-101-B/LPUI-101/ to trigger routing table
LPUI-101-B/LPUS-101 lookups due to the
boards. rollback of public IP
unicast traffic does not
take effect, and traffic
cannot rapidly recover.
1.2.3 Configuring an IS-IS SR-MPLS BE Tunnel

This section describes the detail steps for configuring an IS-IS SR-MPLS BE tunnel.
Usage Scenario
Creating an IS-IS SR-MPLS BE tunnel involves the following operations:
create a tunnel) and are assigned labels.
Pre-configuration Tasks
Before configuring an IS-IS SR-MPLS BE tunnel, complete the following tasks:

(2020-10-09)
● Configure IS-IS to implement network layer connectivity for NEs.
1.2.3.1 Enabling MPLS

Enabling MPLS on each node in an SR-MPLS domain is the prerequisites for
configuring an SR-MPLS BE tunnel.
Procedure
Step 1 Run system-view
The system view is displayed.
Step 2 Run mpls lsr-id lsr-id
An LSR ID is set for the local node.
Note the following when configuring an LSR ID:

● LSR IDs must be set before other MPLS commands are run.
● By default, no LSR ID is set for an LSR, and an LSR ID can only be manually
set.
● Using the IP address of a loopback interface as the LSR ID is recommended
for an LSR.
Step 3 Run mpls
The MPLS view is displayed.
Step 4 Run commit
The configuration is committed.
----End
1.2.3.2 Configuring Basic SR-MPLS BE Functions

This section describes how to configure basic SR-MPLS BE functions.
Context
Basic SR-MPLS BE function configurations involve enabling the global Segment
Routing capability, configuring a label range for a segment routing global block
(SRGB), and setting a prefix segment ID (SID).
Procedure
Step 1 Globally enable the Segment Routing capability.
1. Run system-view

2. Run segment-routing
Segment Routing is globally enabled, and the Segment Routing view is

displayed.

(2020-10-09)
3. Run commit

4. Run quit
Return to the system view.
Step 2 Configure an SRGB label range.

1. Run system-view

2. Run isis [ process-id ]
The IS-IS view is displayed.

3. Run network-entity net
The network entity title (NET) is configured.

4. Run cost-style { wide | compatible | wide-compatible }
The IS-IS wide metric function is enabled.

5. Run segment-routing mpls
The IS-IS Segment Routing function is enabled.

6. Run segment-routing global-block begin-value end-value
An SRGB label range is specified for the current IS-IS instance.

7. Run commit

8. Run quit
Step 3 Set an SR prefix SID.

1. Run system-view

2. Run interface loopback loopback-number
A loopback interface is created, and the loopback interface view is displayed.

3. Run isis enable [ process-id ]
The IS-IS interface is enabled.

4. Run ip address ip-address { mask | mask-length }
The IP address is configured for the loopback interface.

5. Run isis prefix-sid { absolute sid-value | index index-value } [ node-disable ]
The IP address of the loopback interface is configured as an SR prefix SID.

6. Run commit
----End

(2020-10-09)
1.2.3.3 (Optional) Configuring a Policy for Triggering SR-MPLS BE LSP

Establishment
A policy can be configured to allow the ingress node to establish SR-MPLS BE LSPs
based on eligible routes.
Context
After SR is enabled, a large number of SR-MPLS BE LSPs will be established if
policy control is not configured. As a result, resources are wasted. To prevent
resource wastes, a policy for establishing SR-MPLS BE LSPs can be configured. The
policy allows the ingress to use only allowed routes to establish SR-MPLS BE LSPs.
Procedure
Step 2 Run isis [ process-id ]
Step 3 Run segment-routing lsp-trigger { none | host | ip-prefix ip-prefix-name }
A policy is configured for the ingress to establish SR-MPLS BE LSPs.
● host: Host IP routes with 32-bit masks are used as the policy for the ingress
to establish SR-MPLS BE LSPs.
● ip-prefix: FECs that match an IP prefix list are used as the policy for the
ingress to establish SR-MPLS BE LSPs.
● none: The ingress is not allowed to establish SR-MPLS BE LSPs.
Step 4 Run commit
----End
1.2.3.4 (Optional) Configuring a Policy for Preferentially Selecting an SR-

MPLS BE Tunnel
A policy for preferentially selecting an SR-MPLS BE tunnel is configured to allow a
device to select an SR tunnel, not an LDP tunnel.
Context
In a tunnel recursion scenario, an LDP tunnel is preferentially selected to forward
traffic by default. To enable a device to preferentially select an SR-MPLS BE tunnel,
improve the SR-MPLS BE tunnel priority so that the SR-MPLS BE tunnel takes
preference over the LDP tunnel.
Procedure

(2020-10-09)
Step 2 Run segment-routing
The SR view is displayed.
Step 3 Run tunnel-prefer segment-routing
SR-MPLS BE tunnels are configured to take precedence over LDP tunnels.
Step 4 Run commit
----End
1.2.3.5 Verifying the IS-IS SR-MPLS BE Tunnel Configuration

After configuring an SR-MPLS BE tunnel, verify the configuration of the SR-MPLS
BE tunnel.
Prerequisites
The SR-MPLS BE functions have been configured.
Procedure
After completing the configurations, you can run the following commands to
check the configurations.
● Run the display isis lsdb [ { level-1 | level-2 } | verbose | { local | lsp-id | is-
name symbolic-name } ] * [ process-id | vpn-instance vpn-instance-name ]
command to check IS-IS LSDB information.
● Run the display segment-routing prefix mpls forwarding command to
check the label forwarding information base for Segment Routing.
1.2.4 Configuring an OSPF SR-MPLS BE Tunnel

This section describes how to configure an OSPF SR-MPLS BE tunnel.
Usage Scenario
Creating an OSPF SR-MPLS BE tunnel involves the following operations:

create a tunnel) and are assigned labels.
Before configuring an OSPF SR-MPLS BE tunnel, complete the following tasks:
● Configure OSPF to implement the connectivity of NEs at the network layer.

(2020-10-09)
1.2.4.1 Enabling MPLS

Enabling MPLS on each node in an SR-MPLS domain is the prerequisites for
configuring an SR-MPLS BE tunnel.
Procedure
An LSR ID is set for the local node.
Note the following when configuring an LSR ID:
● By default, no LSR ID is set for an LSR, and an LSR ID can only be manually
set.
for an LSR.
Step 3 Run mpls
Step 4 Run commit
----End
1.2.4.2 Configuring Basic SR-MPLS BE Functions

This section describes how to configure basic SR-MPLS BE functions.
Context
Basic SR-MPLS BE function configurations involve enabling the global Segment
Routing capability, configuring a label range for a segment routing global block
(SRGB), and setting a prefix segment ID (SID).
Procedure
Step 1 Globally enable the Segment Routing capability.
1. Run system-view
Segment Routing is globally enabled, and the Segment Routing view is
displayed.
3. Run commit

(2020-10-09)
4. Run quit

1. Run ospf [ process-id ]
The OSPF view is displayed.

2. Run opaque-capability enable
The Opaque LSA capability is enabled.

OSPF SR is enabled.
An SRGB label range is specified for OSPF.

5. Run commit

6. Run quit


2. Run ospf enable [ process-id ] area area-id
OSPF is enabled on the interface.


4. Run ospf prefix-sid { absolute sid-value | index index-value } [ node-
disable ]
The IP address of the interface is configured as an SR prefix SID.

5. Run commit
----End
1.2.4.3 (Optional) Configuring a Policy for Triggering SR-MPLS BE LSP

Establishment
A policy can be configured to allow the ingress node to establish SR-MPLS BE LSPs
based on eligible routes.
Context
After SR is enabled, a large number of SR-MPLS BE LSPs will be established if
policy control is not configured. As a result, resources are wasted. To prevent

(2020-10-09)
resource wastes, a policy for establishing SR-MPLS BE LSPs can be configured. The
policy allows the ingress to use only allowed routes to establish SR-MPLS BE LSPs.
Procedure
Step 2 Run ospf [ process-id ]
Step 3 Run segment-routing lsp-trigger { none | host | ip-prefix ip-prefix-name }
A policy is configured for the ingress to establish SR-MPLS BE LSPs.
● host: Host IP routes with 32-bit masks are used as the policy for the ingress
to establish SR-MPLS BE LSPs.
● ip-prefix: FECs that match an IP prefix list are used as the policy for the
ingress to establish SR-MPLS BE LSPs.
● none: The ingress is not allowed to establish SR-MPLS BE LSPs.
Step 4 Run commit
----End
1.2.4.4 (Optional) Configuring a Policy for Preferentially Selecting an SR-

MPLS BE Tunnel
A policy for preferentially selecting an SR-MPLS BE tunnel is configured to allow a
device to select an SR tunnel, not an LDP tunnel.
Context
In a tunnel recursion scenario, an LDP tunnel is preferentially selected to forward
traffic by default. To enable a device to preferentially select an SR-MPLS BE tunnel,
improve the SR-MPLS BE tunnel priority so that the SR-MPLS BE tunnel takes
preference over the LDP tunnel.
Procedure
The SR view is displayed.
Step 3 Run tunnel-prefer segment-routing
SR-MPLS BE tunnels are configured to take precedence over LDP tunnels.
Step 4 Run commit

(2020-10-09)
----End
1.2.4.5 Verifying the OSPF SR-MPLS BE Tunnel Configuration

After successfully configuring SR-MPLS BE, verify SR-MPLS BE configurations.
Prerequisites
The SR-MPLS BE functions have been configured.
Procedure
After completing the configurations, you can run the following commands to
check the configurations.
● Run the display segment-routing prefix mpls forwarding command to view
the information about the label forwarding information base for Segment
Routing.
1.2.5 Configuring Traffic Steering into SR-MPLS BE Tunnels

Traffic steering into SR-MPLS BE tunnels is to recurse routes to SR-MPLS BE
tunnels and forward data using these tunnels.
Usage Scenario
After an SR-MPLS BE tunnel is configured, traffic needs to be steered into the
tunnel for forwarding. This process is called traffic steering. Currently, SR-MPLS BE
tunnels can be used for various routes and services, such as BGP and static routes
as well as BGP4+ 6PE, BGP L3VPN, and EVPN services. The main traffic steering
modes supported by SR-MPLS BE tunnels are as follows:
● Static route: When configuring a static route, set the next hop of the route to
the destination IP address of an SR-MPLS BE tunnel so that traffic transmitted
over the route is steered into the SR-MPLS BE tunnel. For details about how to
configure a static route, see Creating IPv4 Static Routes.
● Tunnel policy: The tunnel policy mode is implemented through tunnel selector
configuration. This mode allows both VPN services and non-labeled public
routes to recurse to SR-MPLS BE tunnels. The configuration varies according
to the service type.
This section describes how to configure routes and services to recurse to SR-MPLS
BE tunnels through tunnel policies.
Before configuring traffic steering into SR-MPLS BE tunnels, complete the
following tasks:
● Configure BGP routes, static routes, BGP4+ 6PE services, BGP L3VPN services,
BGP L3VPNv6 services, and EVPN services correctly.
● Configure a filter, such as an IP prefix list, if you want to restrict the route
recursive to a specified SR-MPLS BE tunnel.

(2020-10-09)
Procedure
Step 1 Configure a tunnel policy.
Select either of the following modes based on the traffic steering mode you select.
Comparatively speaking, the tunnel selection sequence mode applies to all

scenarios, and the tunnel selector mode applies to inter-AS VPN Option B and
inter-AS VPN Option C scenarios.
● Tunnel selection sequence

a. Run system-view
b. Run tunnel-policy policy-name
A tunnel policy is created and the tunnel policy view is displayed.
c. (Optional) Run description description-information
Description information is configured for the tunnel policy.
d. Run tunnel select-seq sr-lsp load-balance-number load-balance-
number [ unmix ]
The tunnel selection sequence and number of tunnels for load balancing
are configured.
e. Run commit
f. Run quit Return to the system view.
● Tunnel selector
a. Run system-view
b. Run tunnel-selector tunnel-selector-name { permit | deny } node node
A tunnel selector is created and the view of the tunnel selector is
displayed.
c. (Optional) Configure if-match clauses.
d. Run apply tunnel-policy tunnel-policy-name
A specified tunnel policy is applied to the tunnel selector.
e. Run commit
f. Run quit
Step 2 Configure routes and services to recurse to SR-MPLS BE tunnels.

● Configure non-labeled public BGP routes and static routes to recurse to SR-
MPLS BE tunnels.
a. Run route recursive-lookup tunnel [ ip-prefix ip-prefix-name ]
[ tunnel-policy policy-name
The function to recurse non-labeled public BGP routes and static routes
to SR-MPLS BE tunnels is enabled.

(2020-10-09)
b. Run commit
● Configure non-labeled public BGP routes to recurse to SR-MPLS BE tunnels.
For details about how to configure a non-labeled public BGP route, see
Configuring Basic BGP Functions.
a. Run bgp { as-number-plain | as-number-dot }
The BGP view is displayed.
b. Run unicast-route recursive-lookup tunnel [ tunnel-selector tunnel-
selector-name ]
The function to recurse non-labeled public BGP routes to SR-MPLS BE
tunnels is enabled.
The unicast-route recursive-lookup tunnel command and route
recursive-lookup tunnel command are mutually exclusive. You can select
either of them for configuration.
c. Run commit
● Configure static routes to recurse to SR-MPLS BE tunnels.
For details about how to configure a static route, see Creating IPv4 Static
Routes.
a. Run ip route-static recursive-lookup tunnel [ ip-prefix ip-prefix-name ]
[ tunnel-policy policy-name ]
The function to recurse static routes to SR-MPLS BE tunnels for MPLS
forwarding is enabled.
The ip route-static recursive-lookup tunnel command and route
b. Run commit
● Configure BGP L3VPN services to recurse to SR-MPLS BE tunnels.
For details about how to configure a BGP L3VPN service, see BGP/MPLS IP
VPN Configuration.
a. Run ip vpn-instance vpn-instance-name
The VPN instance view is displayed.
b. Run ipv4-family
The VPN instance-specific IPv4 address family view is displayed.
c. Run tnl-policy policy-name
A specified tunnel policy is applied to the VPN instance-specific IPv4
address family.
d. Run commit
● Configure BGP L3VPNv6 services to recurse to SR-MPLS BE tunnels.
For details about how to configure a BGP L3VPNv6 service, see BGP/MPLS
IPv6 VPN Configuration.

(2020-10-09)

b. Run ipv6-family
address family.
d. Run commit
● Configure BGP4+ 6PE services to recurse to SR-MPLS BE tunnels.
For details about how to configure a BGP4+ 6PE service, see Configuring
BGP4+ 6PE.
Method 1: Apply a tunnel policy to a specified BGP4+ peer.
b. Run ipv6-family unicast
The BGP IPv6 unicast address family view is displayed.
c. Run peer ipv4-address enable
A specified 6PE peer is enabled.
d. Run peer ipv4-address tnl-policy tnl-policy-name
A specified tunnel policy is applied to the 6PE peer.
e. Run commit
Method 2: Apply a tunnel selector to all the routes of a specified BGP
IPv6 unicast address family.
c. Run unicast-route recursive-lookup tunnel-v4 [ tunnel-selector
tunnel-selector-name ]
The function to recurse non-labeled public BGP routes to SR-MPLS BE
tunnels is enabled.
d. Run commit
● Configure EVPN services to recurse to SR-MPLS BE tunnels.
For details on how to configure EVPN, see 3.2 EVPN Configuration. The
configuration varies according to the service type.
To apply a tunnel policy to an EVPN L3VPN instance, perform the following
steps:

(2020-10-09)

b. Run ipv4-family or ipv6-family
The VPN instance-specific IPv4/IPv6 address family view is displayed.
c. Run tnl-policy policy-name evpn
A specified tunnel policy is applied to the EVPN L3VPN instance.
d. Run commit
To apply a tunnel policy to a BD EVPN instance, perform the following steps:
a. Run evpn vpn-instance vpn-instance-name bd-mode
The BD EVPN instance view is displayed.
b. Run tnl-policy policy-name
A specified tunnel policy is applied to the BD EVPN instance.
c. Run commit
To apply a tunnel policy to an EVPN instance that works in EVPN VPWS mode,
perform the following steps:
a. Run evpn vpn-instance vpn-instance-name vpwsThe view of a specified
EVPN instance that works in EVPN VPWS mode is displayed.
A specified tunnel policy is applied to the EVPN instance that works in
EVPN VPWS mode.
c. Run commit
To apply a tunnel policy to a basic EVPN instance, perform the following
steps:
a. Run evpn vpn-instance vpn-instance-name
The EVPN instance view is displayed.
A specified tunnel policy is applied to the basic EVPN instance.
c. Run commit
----End
1.2.6 Configuring an IS-IS SR-MPLS TE Tunnel (Path

Computation on the Controller)
An SR-MPLS TE tunnel is configured on a forwarder. The forwarder delegates the
tunnel to a controller. The controller generates labels and calculates a path.
Usage Scenario
Among existing TE tunnels, each LSP route is assigned a label on each node, and a
forwarder both generates paths and establishes tunnels, which consumes a large

(2020-10-09)
number of forwarder resources. To reduce the burden on the forwarder, SR-MPLS

TE can be used. It offers the following benefits:
● A controller generates labels, which reduces the burden for the forwarder.
● The controller calculates a path and assigns a label to each route, which
reduces the burden and resource consumption on the forwarder and helps
improve the forwarder performance since the forwarder can focus on core
forwarding tasks.
Before configuring an SR-MPLS TE tunnel, complete the following tasks:
● Configure IS-IS to implement network layer connectivity for LSRs.

● Configure an IS-IS neighbor between the controller and forwarder. See
Creating an IPv4 IS-IS Process and Configuring an IPv4 IS-IS Interface.
NOTE
A controller must be configured to generate labels and calculate an LSP path for an SR-
MPLS TE tunnel to be established.
1.2.6.1 Enabling MPLS TE

Enabling MPLS TE on each node in an SR-MPLS domain is the prerequisites for
configuring an SR-MPLS TE tunnel.
Procedure
The LSR ID is set for the local node.
Note the following issues when setting an LSR ID:

● No default LSR ID is available.
for an LSR.
Step 3 Run mpls
Step 4 Run mpls te
MPLS TE is enabled globally.
Step 5 (Optional) Enabling the MPLS TE capability of the interface
In a scenario where the controller or the headend calculates a tunnel path, the
MPLS TE capability of the interface must be enabled. In a static explicit path
scenario, this step can be ignored.

(2020-10-09)
1. Run quit
2. Run interface interface-type interface-number
The view of the interface on which the MPLS TE tunnel is established is
displayed.
3. Run mpls
MPLS is enabled on an interface.
4. Run mpls te
MPLS TE is enabled on the interface.
Step 6 Run commit
----End
1.2.6.2 Globally Enabling the SR Capability

Globally enabling the SR capability on forwarders is a prerequisite for configuring
an SR-MPLS TE tunnel.
Context
SR must be enabled globally before the SR function becomes available.
Procedure
SR is enabled globally.
Step 3 Run commit
----End
1.2.6.3 Configuring the IS-IS SR-MPLS TE Capability and Topology Report

Function
Before an SR-MPLS TE tunnel is established, the IS-IS SR-MPLS TE capability and
IS-IS topology report function must be enabled.
Context
Before an SR-MPLS TE tunnel is established, a device must assign labels, collect
network topology information, and report the information to the controller so that
the controller uses the information to calculate a path and a label stack for the

(2020-10-09)
path. SR-MPLS TE labels can be assigned by the controller or the extended IS-IS
protocol on forwarders. Network topology information (including labels allocated
by IS-IS) is collected by IS-IS and reported to the controller through BGP-LS.
Procedure
Step 1 Configure the IS-IS SR-MPLS TE capability.
Perform the following steps on each node of an SR-MPLS TE tunnel to be
established:
1. Run system-view
3. Run cost-style { compatible [ relax-spf-limit ] | wide | wide-compatible }
4. Run traffic-eng [ level-1 | level-2 | level-1-2 ]
IS-IS TE is enabled.
If no IS-IS level is specified, the node is a Level-1-2 device that can generate
two TEDBs for communicating with Level-1 and Level-2 devices.
SR-MPLS is enabled for IS-IS.
NOTE
After SR is enabled on a node, an IGP automatically generates an adjacency label. To

disable the dynamic link label capability, run the segment-routing auto-adj-sid disable
command.
6. Run commit
7. Run quit
Step 2 Configure a device to report topology information to the controller.
Perform the following steps on one or more nodes of an SR-MPLS TE tunnel:
NOTE
A forwarder can report network-wide topology information to the controller after they
establish a BGP-LS peer relationship. The following steps can be configured on one or
multiple nodes, depending on the network scale.
2. Run bgp-ls enable [ level-1 | level-2 | level-1-2 ]
IS-IS is enabled to advertise network topology information to BGP-LS.

(2020-10-09)
To configure IS-IS to advertise the topology of a Level-1 area and filter the
route prefixes leaked from Level-2 areas to the Level-1 area, run the bgp-ls
enable level-1 level-2-leaking-route-ignore command.
3. Run quit
4. Configure the BGP-LS route advertisement capability.
BGP is enabled, and the BGP view is displayed.
b. Run peer ipv4-address as-number as-number-plain
A BGP peer group is created.
c. Run link-state-family unicast
BGP-LS is enabled, and the BGP-LS view is displayed.
d. Run peer { group-name | ipv4-address } enable
The device is enabled to exchange BGP-LS routing information with a
specified peer or peer group.
5. Run commit
----End
1.2.6.4 Configuring an SR-MPLS TE Tunnel Interface

A tunnel interface must be configured on an ingress so that the interface is used
to establish and manage an SR-MPLS TE tunnel.
Procedure
Step 2 Run interface tunnel tunnel-number
A tunnel interface is created, and the tunnel interface view is displayed.
Step 3 Run either of the following commands to assign an IP address to the tunnel
interface:
● To configure the IP address of the tunnel interface, run ip address ip-address
{ mask | mask-length } [ sub ]
The secondary IP address of the tunnel interface can be configured only after
the primary IP address is configured.
● To configure the tunnel interface to borrow the IP address of another
interface, run ip address unnumbered interface interface-type interface-
number
NOTE
The MPLS TE tunnel is unidirectional and does not need a peer IP address. A separate IP
address for the tunnel interface is not recommended. Use the LSR ID of the ingress as the
tunnel interface's IP address.

(2020-10-09)
Step 4 Run tunnel-protocol mpls te

MPLS TE is configured as a tunneling protocol.
Step 5 Run destination ip-address
A tunnel destination address is configured, which is usually the LSR ID of the
egress.
Various types of tunnels require specific destination addresses. If a tunnel protocol
is changed from another protocol to MPLS TE, a configured destination address is
deleted automatically and a new destination address needs to be configured.
Step 6 Run mpls te tunnel-id tunnel-id
A tunnel ID is set.
Step 7 Run mpls te signal-protocol segment-routing
Segment Routing is configured as the signaling protocol of the TE tunnel.
Step 8 Run mpls te pce delegate
PCE server delegation is enabled so that the controller can calculate paths.
Step 9 (Optional) Run mpls te path verification enable
Path verification for SR-MPLS TE tunnels is enabled. If a label fails, an LSP using
this label is automatically set to Down.
This function does not need to be configured if the controller or BFD is used.
To enable this function globally, run the mpls te path verification enable
command in the MPLS view.
Step 10 (Optional) Run match dscp { ipv4 | ipv6 } { default | { dscp-value1 [ to dscp-
value2 ] } &<1-32> }
A DSCP value is set for IPv4/IPv6 packets to enter an SR-MPLS TE tunnel.
The DSCP setting and mpls te service-class command configuration are mutually
exclusive for an SR-MPLS TE tunnel.
Step 11 Run commit
----End
1.2.6.5 Configuring the UCMP Function of the SR-MPLS TE Tunnel

When multiple SR-MPLS TE tunnels are directed to the downstream device, the
load balancing weights can be configured to perform the Unequal Cost Multi-Path
Load Balance (UCMP) on the SR-MPLS TE tunnels.
Procedure

(2020-10-09)
Step 2 Run load-balance unequal-cost enable
UCMP is enabled globally.
The SR-MPLS TE tunnel interface view is displayed.
Step 4 Run load-balance unequal-cost weight weight
A weight is set for an SR-MPLS TE tunnel before UCMP is carried out among
tunnels.
Step 5 Run commit
----End
1.2.6.6 (Optional) Configuring SR on a PCC

Configure SR on a PCE client (PCC), so that a controller can deliver path
information to the PCC (forwarder) after path computation.
Context
SR is configured on a PCC (forwarder). Path computation is delegated to the
controller. After the controller computes a path, the controller sends a PCEP
message to deliver path information to the PCC.
NOTE
The path information can also be delivered by a third-party adapter to the forwarder. In this
situation, SR does not need to be configured on the PCC, and the associated step can be
skipped.
Procedure
Step 2 Run pce-client
A PCE client is configured, and the PCE client view is displayed.
Step 3 Run capability segment-routing
SR is enabled for the PCE client.
Step 4 Run connect-server ip-address
A candidate PCE server is specified for the PCE client.
Step 5 Run commit
----End

(2020-10-09)
1.2.6.7 (Optional) Enabling a Device to Simulate an SR-MPLS TE Transit

Node to Perform Adjacency Label-based Forwarding
An SR-MPLS TE-incapable device on an SR-MPLS TE network must be configured
to simulate an SR-MPLS TE transit node to perform adjacency label-based
forwarding.
Context
An SR-MPLS TE-incapable device on an SR-MPLS TE network can be configured to
simulate an SR-MPLS TE transit node to perform adjacency label-based
forwarding. The function resolves the forwarding issue on the SR-MPLS TE-
incapable device.
Procedure
Step 2 Run sr-te-simulate static-cr-lsp transit lsp-name incoming-interface interface-

type interface-number sid segmentid outgoing-interface interface-type interface-
number nexthop next-hop-address out-label implicit-null
A device is enabled to simulate an SR-MPLS TE transit node to perform adjacency
label-based forwarding.
To modify parameters, except for lsp-name, run the sr-te-simulate static-cr-lsp

transit command directly, without the need to run the undo sr-te-simulate
static-cr-lsp transit command. This means that these parameters can be
dynamically updated.
Step 3 Run commit
----End
1.2.6.8 Verifying the IS-IS SR-MPLS TE Tunnel Configuration

After configuring an automatic SR-MPLS TE tunnel, verify information about the
SR-MPLS TE tunnel and its status statistics.
Prerequisites
The SR-MPLS TE tunnel functions have been configured.
Procedure
● Run the following commands to check the IS-IS TE status:
– display isis traffic-eng advertisements [ lspId | local ] [ level-1 | level-2
| level-1-2 ] [ process-id | vpn-instance vpn-instance-name ]
– display isis traffic-eng statistics [ process-id | vpn-instance vpn-
instance-name ]

(2020-10-09)
● Run the display mpls te tunnel [ destination ip-address ] [ lsp-id lsr-id

session-id local-lsp-id | lsr-role { all | egress | ingress | remote | transit } ]
[ name tunnel-name ] [ { incoming-interface | interface | outgoing-
interface } interface-type interface-number ] [ verbose ] command to check
tunnel information.
● Run the display mpls te tunnel statistics or display mpls sr-te-lsp
command to check LSP statistics.
● Run the display mpls te tunnel-interface [ tunnel tunnel-number ]
command to check information about a tunnel interface on the ingress.
● (Optional) If the label stack depth exceeds the upper limit supported by a
forwarder, the controller needs to divide a label stack into multiple stacks for
an entire path. After the controller assigns a stick label to a stick node, run
the display mpls te stitch-label-stack command to check information about
the stick label stack mapped to the stick label.
----End
1.2.7 Configuring an OSPF SR-MPLS TE Tunnel (Path

An SR-MPLS TE tunnel is configured on a forwarder. The forwarder delegates the
tunnel to a controller. The controller generates labels and calculates a path.
Usage Scenario
Among existing TE tunnels, each LSP route is assigned a label on each node, and a
PCC (forwarder) both generates paths and establishes tunnels, which consumes a
large number of forwarder resources. To reduce the burden on the PCC, SR-MPLS
TE can be used. The manual SR-MPLS TE tunnel technique offers the following
benefits:
● A controller generates labels, which reduces the burden for the PCC
(forwarder).
● The controller calculates a path and assigns a label to each route, which
reduces the burden and resource consumption on the forwarder and helps
improve the forwarder performance since the forwarder can focus on core
forwarding tasks.
Before configuring an SR-MPLS TE tunnel, complete the following tasks:
● Configure OSPF to implement LSR connectivity at the network layer.

● Configure an OSPF neighbor relationship between the controller and
forwarder. See Configuring Basic OSPF Functions
NOTE
A controller must be configured to generate labels and calculate an LSP path for an SR-
MPLS TE tunnel to be established.

(2020-10-09)

Procedure

for an LSR.
Step 3 Run mpls
Step 4 Run mpls te
1. Run quit


displayed.
3. Run mpls

4. Run mpls te
Step 6 Run commit
----End

(2020-10-09)

Context
Procedure
Step 3 Run commit
----End
1.2.7.3 Configuring the OSPF SR-MPLS TE Capability and Topology Report

Function
Before an SR-MPLS TE tunnel is established, the OSPF SR-MPLS TE capability and
OSPF topology report function must be enabled.
Context
Before an SR-MPLS TE tunnel is established, a device must assign labels, collect
network topology information, and report the information to the controller so that
the controller uses the information to calculate a path and a label stack for the
path. SR-MPLS TE labels can be assigned by the controller or the extended OSPF
protocol on forwarders. Network topology information (including labels allocated
by OSPF) is collected by OSPF and reported to the controller through BGP-LS.
Procedure
Step 1 Configure the OSPF SR-MPLS TE capability.
Perform the following steps on each node of an SR-MPLS TE tunnel to be
established:
1. Run system-view
The OSPF Opaque capability is enabled.

(2020-10-09)
OSPF SR enabled.
5. Run area area-id
The OSPF area view is displayed.

6. Run mpls-te enable [ standard-complying ]
TE is enabled in the OSPF area.

7. Run commit

8. Run quit
Step 2 Configure a device to report topology information to the controller.
Perform the following steps on one or more nodes of an SR-MPLS TE tunnel:
NOTE
A forwarder can report network-wide topology information to the controller after they
establish a BGP-LS peer relationship. The following steps can be configured on one or
multiple nodes, depending on the network scale.

2. Run bgp-ls enable (OSPF)
OSPF is enabled to advertise network topology information to BGP-LS.

3. Run quit

4. Configure the BGP-LS route advertisement capability.
A BGP peer group is created.
BGP-LS is enabled, and the BGP-LS view is displayed.
The ability to exchange BGP-LS routes with the specified BGP peer is
enabled.
5. Run commit
----End

(2020-10-09)

Procedure
interface:
● To configure the IP address of the tunnel interface, run ip address ip-address
{ mask | mask-length } [ sub ]
interface, run ip address unnumbered interface interface-type interface-
number
NOTE
The MPLS TE tunnel is unidirectional and does not need a peer IP address. A separate IP

egress.
A tunnel ID is set.
PCE server delegation is enabled so that the controller can calculate paths.

(2020-10-09)
value2 ] } &<1-32> }
A DSCP value is set for IPv4/IPv6 packets to enter an SR-MPLS TE tunnel.
The DSCP setting and mpls te service-class command configuration are mutually
exclusive for an SR-MPLS TE tunnel.
Step 11 Run commit
----End

Procedure
tunnels.
Step 5 Run commit
----End

Configure SR on a PCE client (PCC), so that a controller can deliver path
information to the PCC (forwarder) after path computation.
Context
SR is configured on a PCC (forwarder). Path computation is delegated to the
controller. After the controller computes a path, the controller sends a PCEP
message to deliver path information to the PCC.

(2020-10-09)
NOTE
situation, SR does not need to be configured on the PCC, and the associated step can be
skipped.
Procedure
A candidate PCE server is specified for the PCE client.
Step 5 Run commit
----End
1.2.7.7 (Optional) Enabling a Device to Simulate an SR-MPLS TE Transit

Node to Perform Adjacency Label-based Forwarding
An SR-MPLS TE-incapable device on an SR-MPLS TE network must be configured
to simulate an SR-MPLS TE transit node to perform adjacency label-based
forwarding.
Context
An SR-MPLS TE-incapable device on an SR-MPLS TE network can be configured to
simulate an SR-MPLS TE transit node to perform adjacency label-based
forwarding. The function resolves the forwarding issue on the SR-MPLS TE-
incapable device.
Procedure
Step 2 Run sr-te-simulate static-cr-lsp transit lsp-name incoming-interface interface-
type interface-number sid segmentid outgoing-interface interface-type interface-
number nexthop next-hop-address out-label implicit-null
A device is enabled to simulate an SR-MPLS TE transit node to perform adjacency
label-based forwarding.
To modify parameters, except for lsp-name, run the sr-te-simulate static-cr-lsp
transit command directly, without the need to run the undo sr-te-simulate

(2020-10-09)
static-cr-lsp transit command. This means that these parameters can be

dynamically updated.
Step 3 Run commit
----End
1.2.7.8 Verifying the OSPF SR-MPLS TE Tunnel Configuration

Prerequisites
Procedure
Step 1 Run the display ospf [ process-id ] segment-routing routing [ ip-address [ mask
| mask-length ] ] command to check routing table information of OSPF Segment
Routing.
Step 2 Run the display mpls te tunnel [ destination ip-address ] [ lsp-id lsr-id session-
id local-lsp-id | lsr-role { all | egress | ingress | remote | transit } ] [ name
tunnel-name ] [ { incoming-interface | interface | outgoing-interface }
interface-type interface-number ] [ verbose ] command to check tunnel
information.
Step 3 Run the display mpls te tunnel statistics or display mpls sr-te-lsp command to
check LSP statistics.
Step 4 Run the display mpls te tunnel-interface [ tunnel tunnel-number ] command to

check information about a tunnel interface on the ingress.
----End
1.2.8 Configuring an IS-IS SR-MPLS TE Tunnel (Explicit Path

Used)
If no controller is deployed to compute paths, an explicit path can be manually
configured to perform segment routing-traffic engineering (SR-MPLS TE).
Usage Scenario
SR-MPLS TE is a new TE tunnel technology that uses SR as a control protocol. If no
controller is deployed to compute paths, an explicit path can be manually
configured to perform SR-MPLS TE.
Before configuring an IS-IS SR-MPLS TE tunnel, configure IS-IS to implement
network layer connectivity.

(2020-10-09)

Procedure

for an LSR.
Step 3 Run mpls
Step 4 Run mpls te
1. Run quit


displayed.
3. Run mpls

4. Run mpls te
Step 6 Run commit
----End

(2020-10-09)

Context
Procedure
Step 3 Run commit
----End
1.2.8.3 Configuring Basic SR-MPLS TE Functions

This section describes how to configure basic SR-MPLS TE functions.
Context
SR-MPLS TE uses strict and loose explicit paths. Strict explicit paths use adjacency
SIDs, and loose explicit paths use adjacency and node SIDs. Before an SR-MPLS TE
tunnel is configured, the adjacency and node SIDs must be configured.
Procedure
1. Run system-view

(2020-10-09)

An SRGB label range is configured for the current IS-IS instance.
8. Run commit
9. Run quit
Step 2 Configure an SR prefix SID.
An SR prefix SID is configured for the IP address of the interface.
5. Run commit
6. Run quit
Step 3 (Optional) Configure an adjacency SID.
After IS-IS SR is enabled, an adjacency SID is automatically generated. To disable
the automatic generation of adjacency SIDs, run the segment-routing auto-adj-
sid disable command. The automatically generated adjacency SID may change
after a device restart. If an explicit path uses such an adjacency SID and the
associated device is restarted, this adjacency SID must be reconfigured. You can
also manually configure an adjacency SID to facilitate the use of an explicit path.
The Segment Routing view is displayed.
2. Run ipv4 adjacency local-ip-addr local-ip-address remote-ip-addr remote-
ip-address sid sid-value
An adjacency SID is manually set for SR.
3. Run commit
----End
1.2.8.4 Configuring an SR-MPLS TE Explicit Path

An explicit path over which an SR-MPLS TE tunnel is to be established is
configured on the ingress. You can specify node or link labels for the explicit path.

(2020-10-09)
Context
An explicit path is a vector path comprised of a series of nodes that are arranged
in the configuration sequence. The path through which an SR-MPLS TE LSP passes
can be planned by specifying next-hop labels or next-hop IP addresses on an
explicit path. The IP addresses involved in an explicit path are set to interfaces' IP
addresses. An explicit path in use can be dynamically updated.
Procedure
Step 2 Run explicit-path path-name
An explicit path is created, and the explicit path view is displayed.
Step 3 Perform either of the following operations:

● To specify a next-hop label for the explicit path, run the next sid label label-
value type { adjacency | prefix | binding-sid } command.
● Specify a next-hop address for the explicit path:
a. Run the next hop ipv4 [ include [ [ strict | loose ] | [ incoming |
outgoing ] ] * | exclude ] command to specify a next-hop node for the
explicit path.
The include parameter indicates that an LSP must pass through a
specified node. The exclude parameter indicates that an LSP cannot pass
through a specified node.
b. (Optional) Run the add hop ipv4 [ include [ [ strict | loose ] |
[ incoming | outgoing ] ] * | exclude ] { after | before } contrastIpv4
command to add a node to the explicit path.
c. (Optional) Run the modify hop contrastIpv4 ipv4 [ include [ [ strict |
loose ] | [ incoming | outgoing ] ] * | exclude ] command to change the
address of a node to allow another specified node to be used by the
explicit path.
d. (Optional) Run the delete hop ipv4 command to remove a node from
the explicit path.
● To configure an explicit path where the next hop label and IP address are
mixed, perform the following operations:
a. Run the command next sid label label-value type { adjacency | prefix |
binding-sid } or the command next hop ip-address [ include [ [ strict |
loose ] | [ incoming | outgoing ] ] * | exclude ] to specify the next label
or node of the explicit path.
b. (Optional) Run the command add sid label label-value type { adjacency
| prefix | binding-sid } { after | before } { hop contrastIpv4 | index
indexValue | sid label contrastLabel index indexValue } or the command
add hop ipv4 [ include [ [ strict | loose ] | [ incoming | outgoing ] ] * |
exclude ] { after | before } { hop contrastIpv4 | index indexValue | sid
label contrastLabel index indexValue }, add a label or node to the
specified explicit path.

(2020-10-09)
c. (Optional) Run the command modify hop contrastIpv4 to { hop ipv4

[ exclude | include [ [ strict | loose ] | [ incoming | outgoing ] ] * ] | sid
label label-value type { adjacency | prefix | binding-sid } }, or the
command modify index indexValue to { hop ipv4 [ exclude | include
[ [ strict | loose ] | [ incoming | outgoing ] ] * ] | sid label label-value
type { adjacency | prefix | binding-sid } }, or the command modify sid
label contrastLabel index indexValue to { hop ipv4 [ exclude | include
type { adjacency | prefix | binding-sid } }, modify the label or node in
the specified explicit path.
d. (Optional) Run the command delete { sid label labelValue index
indexValue | index indexValue } or the command delete hop ip-address,
remove a label or node from the specified explicit path.
Step 4 Run commit
----End

Procedure
interface:
● To configure the IP address of the tunnel interface, run the ip address ip-
address { mask | mask-length } [ sub ] command.
interface, run the ip address unnumbered interface interface-type interface-
number command.
NOTE
The SR-MPLS TE tunnel is unidirectional and does not need a peer IP address. A separate IP
address for the tunnel interface is not recommended. The LSR ID of the ingress is generally
used as the tunnel interface's IP address.


(2020-10-09)

egress.
A tunnel ID is set.
Step 8 Run mpls te path explicit-path path-name [ secondary ]
An explicit path is configured for the tunnel.
The path-name value must be the same as that specified in the explicit-path
path-name command.
value2 ] } &<1-32> }
A DSCP value is set for IPv4/IPv6 packets to enter the SR-MPLS TE tunnel.
The DSCP setting and mpls te service-class command configuration of an SR-
MPLS TE tunnel are mutually exclusive.
Step 11 Run commit
----End

Procedure

(2020-10-09)

tunnels.
Step 5 Run commit
----End

Prerequisites
Procedure
instance-name ]
tunnel information.
----End
1.2.9 Configuring an OSPF SR-MPLS TE Tunnel (Explicit Path

Used)
If no controller is deployed to compute paths, an explicit path can be manually

(2020-10-09)
Usage Scenario
controller is deployed to compute paths, an explicit path can be manually
Before configuring an OSPF SR-MPLS TE tunnel, configure OSPF to implement
connectivity at the network layer.

Procedure
for an LSR.
Step 3 Run mpls
Step 4 Run mpls te
1. Run quit
displayed.
3. Run mpls

(2020-10-09)
4. Run mpls te
Step 6 Run commit
----End

Context
Procedure
Step 3 Run commit
----End

Context
Procedure
1. Run system-view

(2020-10-09)
The OSPF Segment Routing function is enabled.

An SRGB label range is set for OSPF.

6. Run area area-id


8. Run commit

9. Run quit
Return to the OSPF view.

10. Run quit




disable ]

5. Run commit

6. Run quit
Step 3 (Optional) Configure an adjacency SID.
After OSPF SR is enabled, an adjacency SID is automatically generated. To disable

the automatic generation of adjacency SIDs, run the segment-routing auto-adj-
sid disable command. The automatically generated adjacency SID may change
after a device restart. If an explicit path uses such an adjacency SID and the
associated device is restarted, this adjacency SID must be reconfigured. You can
also manually configure an adjacency SID to facilitate the use of an explicit path.

(2020-10-09)
2. Run ipv4 adjacency local-ip-addr local-ip-address remote-ip-addr remote-

ip-address sid sid-value
An adjacency SID is manually set for SR.
3. Run commit
----End

Context
An explicit path is a vector path comprised of a series of nodes that are arranged
in the configuration sequence. The path through which an SR-MPLS TE LSP passes
can be planned by specifying next-hop labels or next-hop IP addresses on an
explicit path. The IP addresses involved in an explicit path are set to interfaces' IP
addresses. An explicit path in use can be dynamically updated.
Procedure
An explicit path is created, and the explicit path view is displayed.
Step 3 Perform either of the following operations:
● To specify a next-hop label for the explicit path, run the next sid label label-
value type { adjacency | prefix | binding-sid } command.
● Specify a next-hop address for the explicit path:
a. Run the next hop ipv4 [ include [ [ strict | loose ] | [ incoming |
outgoing ] ] * | exclude ] command to specify a next-hop node for the
explicit path.
The include parameter indicates that an LSP must pass through a
specified node. The exclude parameter indicates that an LSP cannot pass
through a specified node.
b. (Optional) Run the add hop ipv4 [ include [ [ strict | loose ] |
[ incoming | outgoing ] ] * | exclude ] { after | before } contrastIpv4
command to add a node to the explicit path.
c. (Optional) Run the modify hop contrastIpv4 ipv4 [ include [ [ strict |
loose ] | [ incoming | outgoing ] ] * | exclude ] command to change the
address of a node to allow another specified node to be used by the
explicit path.
d. (Optional) Run the delete hop ipv4 command to remove a node from
the explicit path.

(2020-10-09)
● To configure an explicit path where the next hop label and IP address are
mixed, perform the following operations:
a. Run the command next sid label label-value type { adjacency | prefix |
binding-sid } or the command next hop ip-address [ include [ [ strict |
loose ] | [ incoming | outgoing ] ] * | exclude ] to specify the next label
or node of the explicit path.
b. (Optional) Run the command add sid label label-value type { adjacency
| prefix | binding-sid } { after | before } { hop contrastIpv4 | index
indexValue | sid label contrastLabel index indexValue } or the command
add hop ipv4 [ include [ [ strict | loose ] | [ incoming | outgoing ] ] * |
exclude ] { after | before } { hop contrastIpv4 | index indexValue | sid
label contrastLabel index indexValue }, add a label or node to the
specified explicit path.
c. (Optional) Run the command modify hop contrastIpv4 to { hop ipv4
[ exclude | include [ [ strict | loose ] | [ incoming | outgoing ] ] * ] | sid
label label-value type { adjacency | prefix | binding-sid } }, or the
command modify index indexValue to { hop ipv4 [ exclude | include
type { adjacency | prefix | binding-sid } }, or the command modify sid
label contrastLabel index indexValue to { hop ipv4 [ exclude | include
type { adjacency | prefix | binding-sid } }, modify the label or node in
the specified explicit path.
d. (Optional) Run the command delete { sid label labelValue index
indexValue | index indexValue } or the command delete hop ip-address,
remove a label or node from the specified explicit path.
Step 4 Run commit
----End

Procedure
interface:

(2020-10-09)

number command.
NOTE

egress.

A tunnel ID is set.
path-name command.
value2 ] } &<1-32> }

Step 11 Run commit
----End

(2020-10-09)

Procedure
tunnels.
Step 5 Run commit
----End

Prerequisites
Procedure
Routing.
information.

(2020-10-09)

----End
1.2.10 Configuring an IS-IS SR-MPLS TE Tunnel (Path

Computation on a Forwarder)
If no controller is deployed to compute paths, CSPF can be configured on the
ingress to perform SR-MPLS TE.
Usage Scenario
controller is deployed to compute paths, CSPF can be configured on the ingress to
perform SR-MPLS TE.
Before configuring an IS-IS SR-MPLS TE tunnel, configure IS-IS to implement
network layer connectivity.

Procedure
for an LSR.
Step 3 Run mpls
Step 4 Run mpls te

(2020-10-09)
1. Run quit


displayed.
3. Run mpls

4. Run mpls te
Step 6 Run commit
----End

Context
Procedure
Step 3 Run commit
----End

Context

(2020-10-09)
Procedure
1. Run system-view





An SRGB label range is configured for the current IS-IS instance.

8. Run commit

9. Run quit





5. Run commit
----End
1.2.10.4 Enabling the Ingress to Compute a Path

CSPF is configured on the ingress to compute a path for an SR-MPLS TE tunnel.

(2020-10-09)
Procedure
Step 2 Run mpls
Step 3 Run mpls te
MPLS TE is enabled.
Step 4 Run mpls te cspf
CSPF is enabled on the ingress to compute paths.
Step 5 Run commit
----End

Procedure
interface:
number command.
NOTE


(2020-10-09)

egress.

A tunnel ID is set.
Step 8 (Optional) Run mpls te cspf path-selection adjacency-sid
By default, this function is disabled.
If the mpls te cspf path-selection adjacency-sid command is not run, both node
and adjacency SIDs are used in CSPF path computation for an LSP in an SR-MPLS
TE tunnel.
By default, path verification is disabled for SR-MPLS TE tunnels.
value2 ] } &<1-32> }

Step 11 Run commit
----End

Procedure

(2020-10-09)
tunnels.
Step 5 Run commit
----End

Prerequisites
Procedure
instance-name ]
tunnel information.
----End

(2020-10-09)
1.2.11 Configuring an OSPF SR-MPLS TE Tunnel (Path

Computation on a Forwarder)
If no controller is deployed to compute paths, CSPF can be configured on the
ingress to perform SR-MPLS TE.
Usage Scenario
controller is deployed to compute paths, CSPF can be configured on the ingress to
perform SR-MPLS TE.
Before configuring an OSPF SR-MPLS TE tunnel, configure OSPF to implement
connectivity at the network layer.

Procedure
for an LSR.
Step 3 Run mpls
Step 4 Run mpls te
1. Run quit

(2020-10-09)

displayed.
3. Run mpls
4. Run mpls te
Step 6 Run commit
----End

Context
Procedure
Step 3 Run commit
----End

Context
Procedure
1. Run system-view

(2020-10-09)

The OSPF Segment Routing function is enabled.
An SRGB label range is set for OSPF.
6. Run area area-id
8. Run commit
9. Run quit
disable ]
5. Run commit
----End
1.2.11.4 Enabling the Ingress to Compute a Path

CSPF is configured on the ingress to compute a path for an SR-MPLS TE tunnel.
Procedure

(2020-10-09)
Step 2 Run mpls
Step 3 Run mpls te
MPLS TE is enabled.
Step 4 Run mpls te cspf
CSPF is enabled on the ingress to compute paths.
Step 5 Run commit
----End

Procedure
interface:
number command.
NOTE

egress.

(2020-10-09)

A tunnel ID is set.
Step 8 (Optional) Run mpls te cspf path-selection adjacency-sid
By default, this function is disabled.
If the mpls te cspf path-selection adjacency-sid command is not run, both node
and adjacency SIDs are used in CSPF path computation for an LSP in an SR-MPLS
TE tunnel.
By default, path verification is disabled for SR-MPLS TE tunnels.
value2 ] } &<1-32> }
Step 11 Run commit
----End

Procedure

(2020-10-09)
tunnels.
Step 5 Run commit
----End

Prerequisites
Procedure
Routing.
information.

----End
1.2.12 Configuring BGP SR

A controller orchestrates IGP SIDs and BGP SR-allocated BGP peer SIDs to
implement inter-AS forwarding over the optimal path.
Context
BGP is a dynamic routing protocol used between ASs. BGP SR is a BGP extension
for SR and is used for inter-AS source routing.
BGP SR uses BGP egress peer engineering (EPE) to allocate Peer-Node and Peer-
Adj SIDs to peers or Peer-Set SIDs to peer groups. These SIDs can be reported to
the controller through BGP-LS for orchestrating E2E SR-MPLS TE tunnels.

(2020-10-09)
Procedure
● Configure BGP EPE.
a. Run system-view

b. Run segment-routing
SR is enabled.
c. Run quit

d. Run bgp { as-number-plain | as-number-dot }

e. Run peer ipv4-address as-number { as-number-plain | as-number-dot }
A BGP peer is created.

f. Run peer ipv4-address egress-engineering [ label static-label ]
BGP EPE is enabled.

g. Run peer ipv4-address egress-engineering link-down { relate-bfd-state
| label-pop }
BGP EPE fault association is enabled.
The relate-bfd-state and label-pop parameters are mutually exclusive.

Therefore, you can configure only one of them.
▪ With the relate-bfd-state parameter configured, if the inter-AS link

corresponding to a BGP EPE label fails, BGP EPE triggers SBFD for SR-
MPLS TE tunnel in the local AS to go down. This enables the ingress
of the involved SR-MPLS TE tunnel to rapidly detect the failure and
switch traffic to another normal tunnel.
▪ With the label-pop parameter configured, if the inter-AS link

corresponding to a BGP EPE label fails, the ASBR in the local AS pops
the BGP EPE label from the received data packet and searches the IP
routing table based on the destination address of the packet.
h. (Optional) Configure a peer set.
i. Run egress-engineering peer-set peer-set-name [ label static-
label ]
A BGP peer set is created.
ii. Run peer ipv4-address peer-set name peer-set-name
A specified peer is added to the BGP peer set.
iii. Run egress-engineering peer-set peer-set-name link-down
{ relate-bfd-state | label-pop }
Link fault association is configured for the BGP peer set.
i. Run commit

(2020-10-09)
j. Run quit
Return to the system view
● Configure BGP-LS.
BGP-LS provides a simple and efficient method of collecting topology
information. You must configure a BGP-LS peer relationship between the
controller and forwarder, so that topology information can be properly
reported from the forwarder to the controller. This example provides the
procedure for configuring a BGP-LS peer relationship on the forwarder. The
procedure on the controller is similar to that on the forwarder.
BGP-LS is enabled, and the BGP-LS address family view is displayed.
The device is enabled to exchange BGP-LS routing information with a
specified peer or peer group.
e. Run commit
----End
Verifying the Configuration

After configuring BGP SR, verify the configuration:
Run the display bgp egress-engineering command to check BGP EPE
information.
1.2.13 Configuring an Inter-AS E2E SR-MPLS TE Tunnel (Path

An inter-AS E2E SR-MPLS TE tunnel can connect SR-MPLS TE tunnels in multiple
AS domains to build a large-scale TE network.
Usage Scenario
SR-MPLS TE, a new MPLS TE tunneling technology, has unique advantages in label
distribution, protocol simplification, large-scale expansion, and fast path
adjustment. SR-MPLS TE can better cooperate with SDN.
The SR that is extended through an IGP can implement SR-MPLS TE only within an
AS domain. To implement inter-AS E2E SR-MPLS TE tunnels, BGP EPE needs to be
used to allocate peer SIDs to the adjacencies and nodes between AS domains.
Peer SIDs can be advertised to the network controller using BGP-LS. The controller
uses the explicit paths to orchestrate IGP SIDs and BGP peer SIDs to implement
inter-AS optimal path forwarding on the network shown in Figure 1-114.

(2020-10-09)
In addition, the label depth supported by an ordinary forwarder is limited, whereas

the depth of the label stack of an inter-AS SR-MPLS TE tunnel may exceed the
maximum depth supported by a forwarder. To reduce the number of label stack
layers encapsulated by the forwarder, use binding SIDs. When configuring an
intra-AS SR-MPLS TE tunnel, set a binding SID for the tunnel. The binding SID
identifies an SR-MPLS TE tunnel and replaces the label stack of an SR-MPLS TE
tunnel.
Figure 1-114 Inter-AS E2E SR-MPLS TE tunnel networking
Before configuring an inter-AS E2E SR-MPLS TE tunnel, complete the following
tasks:
● Configure an intra-AS SR-MPLS TE tunnel.

● Configure BGP SR between ASBRs.
1.2.13.1 Setting a Binding SID

Using binding SIDs reduces the number of labels in a label stack on an NE, which
helps build a large-scale network.

(2020-10-09)
Context
To reduce the number of label stack layers encapsulated by an NE, a binding SID
needs to be used. A binding SID can represent the label stack of an intra-AS SR-
MPLS TE tunnel. After binding SIDs and BGP peer SIDs are orchestrated properly,
E2E SR-MPLS TE LSPs can be established.
An SR-MPLS TE tunnel is unidirectional. In the following operations, the binding
SID is set for the unidirectional SR-MPLS TE tunnel only within an AS domain.
● To set a binding SID of a reverse SR-MPLS TE tunnel, perform the
configuration on the ingress of the reverse tunnel.
● To set a binding SID of an SR-MPLS TE tunnel in another AS domain, perform
the configuration on the ingress of the specific AS domain.
Procedure
The intra-AS SR-MPLS TE tunnel interface view is displayed.
Step 3 Run mpls te binding-sid label label-value
A binding SID is specified for the intra-AS SR-MPLS TE tunnel.
Step 4 Run commit
----End
1.2.13.2 Configuring an E2E SR-MPLS TE Tunnel Interface

to establish and manage an E2E SR-MPLS TE tunnel.
Context
An SR-MPLS TE tunnel is unidirectional. To configure a reverse tunnel, perform the
Procedure
An inter-AS E2E tunnel interface is created, and the tunnel interface view is
displayed.
interface:

(2020-10-09)
● To configure an IP address for the tunnel interface, run the ip address ip-
number command.
NOTE
A tunnel destination address, which is usually the LSR ID of the egress, is

configured.

A tunnel ID is set.
PCE server delegation is enabled so that the controller can compute paths.
value2 ] } &<1-32> }

Step 10 Run commit
----End

The SR capability is configured on a PCC. After a controller calculates a path and
delivers path information to a forwarder (PCC), the SR-enabled PCC can establish

(2020-10-09)
Context
SR can be configured on a PCC (forwarder). Path computation is then delegated
to the controller. After the controller calculates a path, the controller sends a PCEP
message to deliver path information to the PCC (forwarder).
NOTE
situation, SR does not need to be configured on the PCC, and the following operation can
be skipped.
Procedure
A candidate PCE server is configured for the PCE client.
Step 5 Run commit
----End
1.2.13.4 Verifying the Configuration of an Inter-AS E2E SR-MPLS TE Tunnel

After configuring an inter-AS E2E SR-MPLS TE tunnel, verify information about the
Prerequisites
The inter-AS E2E SR-MPLS TE tunnel has been configured.
Procedure
information.


(2020-10-09)
Step 3 Run the display mpls te binding-sid [ label label-value ] command to check the
mapping between binding SIDs and tunnels.
----End
1.2.14 Configuring an Inter-AS E2E SR-MPLS TE Tunnel

(Explicit Path Used)
An inter-AS E2E SR-MPLS TE tunnel can connect SR-MPLS TE tunnels in multiple
AS domains to build a large-scale TE network.
Usage Scenario
SR-MPLS TE, a new MPLS TE tunneling technology, has unique advantages in label
distribution, protocol simplification, large-scale expansion, and fast path
adjustment. SR-MPLS TE can better cooperate with SDN.
The SR that is extended through an IGP can implement SR-MPLS TE only within an
AS domain. To implement inter-AS E2E SR-MPLS TE tunnels, BGP EPE needs to be
used to allocate peer SIDs to the adjacencies and nodes between AS domains. The
controller uses the explicit paths to orchestrate IGP SIDs and BGP peer SIDs to
implement inter-AS optimal path forwarding on the network shown in Figure
1-115.
In addition, the label depth supported by an ordinary forwarder is limited, whereas
the depth of the label stack of an inter-AS SR-MPLS TE tunnel may exceed the
maximum depth supported by a forwarder. To reduce the number of label stack
layers encapsulated by the forwarder, use binding SIDs. When configuring an
intra-AS SR-MPLS TE tunnel, set a binding SID for the tunnel. The binding SID
identifies an SR-MPLS TE tunnel and replaces the label stack of an SR-MPLS TE
tunnel.
Figure 1-115 Inter-AS E2E SR-MPLS TE tunnel networking

(2020-10-09)
Before configuring an inter-AS E2E SR-MPLS TE tunnel, complete the following
tasks:
● Configure an intra-AS SR-MPLS TE tunnel.
● Configure BGP EPE between ASBRs. For details, see Configuring BGP SR.
1.2.14.1 Setting a Binding SID

Using binding SIDs reduces the number of labels in a label stack on an NE, which
helps build a large-scale network.
Context
To reduce the number of label stack layers encapsulated by an NE, a binding SID
needs to be used. A binding SID can represent the label stack of an intra-AS SR-
MPLS TE tunnel. After binding SIDs and BGP peer SIDs are orchestrated properly,
E2E SR-MPLS TE LSPs can be established.
An SR-MPLS TE tunnel is unidirectional. In the following operations, the binding
SID is set for the unidirectional SR-MPLS TE tunnel only within an AS domain.
● To set a binding SID of a reverse SR-MPLS TE tunnel, perform the
● To set a binding SID of an SR-MPLS TE tunnel in another AS domain, perform
the configuration on the ingress of the specific AS domain.
Procedure
The intra-AS SR-MPLS TE tunnel interface view is displayed.
Step 3 Run mpls te binding-sid label label-value
A binding SID is specified for the intra-AS SR-MPLS TE tunnel.
Step 4 Run commit
----End

Context
An explicit path refers to a vector path on which a series of nodes are arranged in
a configuration sequence. To plan a path over which an SR-MPLS TE LSP is

(2020-10-09)
established, you can specify either next-hop labels or next-hop IP addresses for an
explicit path. An IP address specified on an explicit path is the IP address of an
interface. An explicit path in use can be dynamically updated.
Procedure
An explicit path is created and the explicit path view is displayed.
Step 3 Configure an explicit path.
In the following example, two AS domains are connected. If there are multiple AS
domains, add configurations based on the network topology.
1. Run next sid label label-value type binding-sid

A binding SID is specified for the first AS domain on an explicit path.
NOTE
When the first hop of an explicit path is assigned a binding SID, the explicit path supports
a maximum of three hops.
2. Run next sid label label-value type adjacency
An inter-AS adjacency label is specified.
3. Run next sid label label-value type binding-sid
A binding SID is specified for the second AS domain on an explicit path.
In the case of multiple AS domains, this binding SID can be the binding SID of
a new E2E SR-MPLS TE tunnel.
Step 4 Run commit
----End
1.2.14.3 Configuring an E2E SR-MPLS TE Tunnel Interface

to establish and manage an E2E SR-MPLS TE tunnel.
Context
An SR-MPLS TE tunnel is unidirectional. To configure a reverse tunnel, perform the
Procedure

(2020-10-09)
An inter-AS E2E tunnel interface is created, and the tunnel interface view is
displayed.
interface:
● To configure an IP address for the tunnel interface, run the ip address ip-
number command.
NOTE
A tunnel destination address, which is usually the LSR ID of the egress, is

configured.

A tunnel ID is set.
path-name command.
value2 ] } &<1-32> }

Step 10 Run commit

(2020-10-09)
----End
1.2.14.4 Verifying the Configuration of an Inter-AS E2E SR-MPLS TE Tunnel

After configuring an inter-AS E2E SR-MPLS TE tunnel, verify information about the
Prerequisites
The inter-AS E2E SR-MPLS TE tunnel has been configured.
Procedure
information.
Step 3 Run the display mpls te binding-sid [ label label-value ] command to check the
mapping between binding SIDs and tunnels.
----End
1.2.15 Configuring Traffic Steering into SR-MPLS TE Tunnels

Traffic steering into SR-MPLS TE tunnels is to recurse routes to SR-MPLS TE
tunnels and forward data using these tunnels.
Usage Scenario
After an SR-MPLS TE tunnel is configured, traffic needs to be steered into the
tunnel for forwarding. This process is called traffic steering. Currently, SR-MPLS TE
tunnels can be used for various routes and services, such as BGP and static routes
as well as BGP4+ 6PE, BGP L3VPN, and EVPN services. The main traffic steering
modes supported by SR-MPLS TE tunnels are as follows:
● Static route: When configuring a static route, set the outbound interface of
the route to an SR-MPLS TE tunnel interface so that traffic transmitted over
the route is steered into the SR-MPLS TE tunnel. For details about how to
configure a static route, see Creating IPv4 Static Routes.
● Auto route: An IGP uses an auto route related to an SR-MPLS TE tunnel that
functions as a logical link to compute a path. The tunnel interface is used as
an outbound interface in the auto route. Auto routes support both IGP
shortcut and forwarding adjacency functions. For details about how to
configure the functions, see Configuring the IGP Shortcut and Configuring
Forwarding Adjacency.
● Policy-based routing (PBR): SR-MPLS TE PBR has the same definition as IP
unicast PBR. PBR is implemented by defining a series of matching rules and

(2020-10-09)
behavior. An outbound interface in an apply clause is set to an interface on an

SR-MPLS TE tunnel. If packets do not match PBR rules, they are properly
forwarded using IP; if they match PBR rules, they are forwarded over specific
tunnels. For details about how to configure PBR, see Routing Policy
Configuration.
● Tunnel policy: The tunnel policy mode is implemented through tunnel selector
or tunnel binding configuration. This mode allows both VPN services and non-
labeled public routes to recurse to SR-MPLS TE tunnels. The configuration
varies according to the service type.
Before configuring traffic steering into SR-MPLS TE tunnels, complete the
following tasks:
● Configure BGP routes, static routes, BGP4+ 6PE services, BGP L3VPN services,
BGP L3VPNv6 services, and EVPN services correctly.
● Configure a filter, such as an IP prefix list, if you want to restrict the route
recursive to a specified SR-MPLS TE tunnel.
Procedure
The tunnel binding mode rather than the tunnel selection sequence mode allows
you to specify the SR-MPLS TE tunnel to be used, facilitating QoS deployment. The
tunnel selector mode applies to inter-AS VPN Option B and inter-AS VPN Option C
scenarios.
● Tunnel selection sequence
a. Run system-view
d. Run tunnel select-seq sr-te load-balance-number load-balance-number
[ unmix ]
are configured.
e. Run commit
f. Run quit
● Tunnel binding
a. Run system-view

(2020-10-09)

d. Run tunnel binding destination dest-ip-address te { tunnel-name }
&<1-32> [ ignore-destination-check ] [ down-switch ]
A tunnel binding policy is configured to bind the specified destination IP
address and SR-MPLS TE tunnel.
e. Run commit
f. Run quit
● Tunnel selector
a. Run system-view
b. Run tunnel-selector tunnel-selector-name { permit | deny } node node
A tunnel selector is created and the view of the tunnel selector is
displayed.
c. (Optional) Configure if-match clauses.
d. Run apply tunnel-policy tunnel-policy-name
A specified tunnel policy is applied to the tunnel selector.
e. Run commit
f. Run quit
Step 2 Configure routes and services to recurse to SR-MPLS TE tunnels.
● Configure non-labeled public BGP routes and static routes to recurse to SR-
MPLS TE tunnels.
a. Run route recursive-lookup tunnel [ ip-prefix ip-prefix-name ]
The function to recurse non-labeled public BGP routes and static routes
to SR-MPLS TE tunnels is enabled.
b. Run commit
● Configure non-labeled public BGP routes to recurse to SR-MPLS TE tunnels.
b. Run unicast-route recursive-lookup tunnel [ tunnel-selector tunnel-
selector-name ]
The function to recurse non-labeled public BGP routes to SR-MPLS TE
tunnels is enabled.

(2020-10-09)

c. Run commit
● Configure static routes to recurse to SR-MPLS TE tunnels.
For details about how to configure a static route, see Creating IPv4 Static
Routes.
a. Run ip route-static recursive-lookup tunnel [ ip-prefix ip-prefix-name ]
The function to recurse static routes to SR-MPLS TE tunnels for MPLS
The ip route-static recursive-lookup tunnel command and route
b. Run commit
● Configure BGP L3VPN services to recurse to SR-MPLS TE tunnels.
For details about how to configure a BGP L3VPN service, see BGP/MPLS IP
VPN Configuration.
b. Run ipv4-family
address family.
d. Run commit
● Configure BGP L3VPNv6 services to recurse to SR-MPLS TE tunnels.
For details about how to configure a BGP L3VPNv6 service, see BGP/MPLS
IPv6 VPN Configuration.
b. Run ipv6-family
address family.
d. Run commit
● Configure BGP4+ 6PE services to recurse to SR-MPLS TE tunnels.
BGP4+ 6PE.

(2020-10-09)
Method 1: Apply a tunnel policy to a specified BGP4+ peer.

A specified 6PE peer is enabled.
d. Run peer ipv4-address tnl-policy tnl-policy-name
A specified tunnel policy is applied to the 6PE peer.
e. Run commit
Method 2: Apply a tunnel selector to all the routes of a specified BGP
IPv6 unicast address family.
c. Run unicast-route recursive-lookup tunnel-v4 [ tunnel-selector
tunnel-selector-name ]
The function to recurse non-labeled public BGP routes to SR-MPLS TE
tunnels is enabled.
d. Run commit
● Configure EVPN services to recurse to SR-MPLS TE tunnels.
For details on how to configure EVPN, see 3.2 EVPN Configuration. The
configuration varies according to the service type.
steps:
b. Run ipv4-family or ipv6-family
The VPN instance IPv4/IPv6 address family view is displayed.
c. Run tnl-policy policy-name evpn
A specified tunnel policy is applied to the EVPN L3VPN instance.
d. Run commit
a. Run evpn vpn-instance vpn-instance-name bd-mode

(2020-10-09)

A specified tunnel policy is applied to the BD EVPN instance.
c. Run commit
a. Run evpn vpn-instance vpn-instance-name vpws
The view of a specified EVPN instance that works in EVPN VPWS mode is
displayed.
A specified tunnel policy is applied to the EVPN instance that works in
EVPN VPWS mode.
c. Run commit
steps:
a. Run evpn vpn-instance vpn-instance-name
A specified tunnel policy is applied to the basic EVPN instance.
c. Run commit
----End
1.2.16 Configuring IS-IS SR to Communicate with LDP

This section describes how to configure IS-IS SR to communicate with LDP.
Usage Scenario
The SR and LDP interworking technique allows both segment routing and LDP to
work within the same network. This technique connects an SR network to an LDP
network to implement MPLS forwarding.
On the network shown in Figure 1-116, an SR domain is created between PE1
that functions as a mapping client and the P device that functions as a mapping
server. Mappings between prefixes and SIDs need to be configured on the P device
and advertised to PE1, which receives the mappings. An LDP domain lies between
the P device and PE2, which supports only LDP. To enable PE1 and PE2 to
communicate with each other, you need to establish an SR LSP and an LDP LSP,
and establish the mapping between the SR LSP and LDP LSP on the P device.
Figure 1-116 Communication between SR and LDP

(2020-10-09)
Before you configure IS-IS SR to communicate with LDP, complete the following
tasks:
● Configure an SR LSP from PE1 to the P. See Configuring an IS-IS SR-MPLS BE

Tunnel.
● Configure an LDP LSP from the P to PE2. See Configuring an LDP LSP.
Procedure
● Configure the mapping server.
a. Run system-view

Segment routing is globally enabled, and the Segment Routing view is

displayed.
c. Run mapping-server prefix-sid-mapping ip-address mask-length begin-
value [ range range-value ] [ attached ]
Mapping between the prefix and SID is configured.
d. Run quit
Exist the SR view.

e. Run isis [ process-id ]

f. Run segment-routing mapping-server send
The local node is enabled to advertise the local SID label mapping.
g. (Optional) Run segment-routing mapping-server receive
The local node is enabled to receive SID label mapping messages.

h. Run commit

● (Optional) Configure the mapping client.
A device that is not configured as a mapping server functions as a mapping

client by default.
a. Run system-view

b. Run isis [ process-id ]

c. Run segment-routing mapping-server receive

(2020-10-09)
d. Run commit

● Configure the device connecting the LDP domain and the SR domain.
a. Run system-view

b. Run mpls

c. Run lsp-trigger segment-routing-interworking best-effort host
A policy for triggering backup LDP LSP establishment is configured.

d. Run commit
----End
Checking the Configurations

After completing the configurations, run the display segment-routing prefix
mpls forwarding command to check the label forwarding information base of
Segment Routing.
1.2.17 Configuring OSPF SR to Communicate with LDP

This section describes how to configure OSPF SR to communicate with LDP.
Usage Scenario
The SR and LDP interworking technique allows both segment routing and LDP to
work within the same network. This technique connects an SR network to an LDP
network to implement MPLS forwarding.
On the network shown in Figure 1-117, an SR domain is created between PE1

that functions as a mapping client and the P device that functions as a mapping
server. Mappings between prefixes and SIDs need to be configured on the P device
and advertised to PE1, which receives the mappings. An LDP domain lies between
the P device and PE2, which supports only LDP. To enable PE1 and PE2 to
communicate with each other, you need to establish an SR LSP and an LDP LSP,
and establish the mapping between the SR LSP and LDP LSP on the P device.

(2020-10-09)
Before you configure OSPF SR to communicate with LDP, complete the following
tasks:
● Configure an SR LSP from PE1 to the P. See Configuring an OSPF SR-MPLS
BE Tunnel.
● Configure an LDP LSP from the P to PE2. See Configuring an LDP LSP.
Procedure
● Configure the mapping server.
a. Run system-view
Segment routing is globally enabled, and the Segment Routing view is
displayed.
c. Run mapping-server prefix-sid-mapping ip-address mask-length begin-
value [ range range-value ] [ attached ]
Mapping between the prefix and SID is configured.
d. Run quit
Exist the SR view.
e. Run ospf [ process-id ]
f. Run segment-routing mapping-server send
The local node is enabled to advertise the local SID label mapping.
g. (Optional) Run segment-routing mapping-server receive
h. Run commit
● (Optional) Configure the mapping client.
A device that is not configured as a mapping server functions as a mapping
client by default.
a. Run system-view
b. Run ospf [ process-id ]
c. Run segment-routing mapping-server receive
d. Run commit

(2020-10-09)
● Configure the device connecting the LDP domain and the SR domain.
a. Run system-view

b. Run mpls

A policy for triggering backup LDP LSP establishment is configured.

d. Run commit
----End

After completing the configurations, run the display segment-routing prefix
mpls forwarding command to check the label forwarding information base of
Segment Routing.
1.2.18 Configuring IS-IS TI-LFA FRR

This section describes how to configure IS-IS TI-LFA FRR.
Usage Scenario
With the development of networks, VoIP and on-line video services require high-
quality real-time transmission. Nevertheless, if an IS-IS fault occurs, multiple
processes, including fault detection, LSP update, LSP flooding, route calculation,
and FIB entry delivery, must be performed to switch traffic to a new link. As a
result, the traffic interruption time is longer than 50 ms, leading to a failure to
satisfy real-time requirements.
TI-LFA fast reroute (FRR) protects links and nodes on segment routing tunnels. If a
link or node fails, traffic is rapidly switched to a backup path, which minimizes
traffic loss.
In some LFA or RLFA scenarios, the P space and Q space do not share nodes or
have direct neighbors. If a link or node fails, no backup path can be calculated,
causing traffic loss and resulting in a failure to meet reliability requirements. In
this situation, TI-LFA can be used.
Before configuring IS-IS TI-LFA FRR, complete the following tasks:
● Configure IP addresses for interfaces to implement connectivity at the

network layer.
● Configure basic IPv4 IS-IS functions.
● Globally enable the Segment Routing capability.
● Enable the Segment Routing capability in an IS-IS process.

(2020-10-09)
Procedure
An IS-IS process is created, and the IS-IS view is displayed.
Step 3 Run frr
The IS-IS FRR view is displayed.
Step 4 Run loop-free-alternate [ level-1 | level-2 | level-1-2 ]
IS-IS LFA is enabled, and LFA links can be generated.
Step 5 Run ti-lfa [ level-1 | level-2 | level-1-2 ]
IS-IS TI-LFA is enabled.
Step 6 (Optional) Run tiebreaker { node-protecting | lowest-cost | non-ecmp | srlg-
disjoint | hold-max-cost } preference preference [ level-1 | level-2 | level-1-2 ]
The solution of selecting a backup path for IS-IS TI-LFA FRR is set.
The larger the value, the higher the priority.
Before configuring the srlg-disjoint parameter, you need to run the isis srlg srlg-
value command in the IS-IS interface view to configure the IS-IS SRLG function.
Step 7 (Optional) After completing the preceding configuration, IS-IS TI-LFA is enabled
on all IS-IS interfaces. If you do not want to enable IS-IS TI-LFA on some
interfaces, perform the following operations:
1. Run quit
Quit the IS-IS FRR view.
2. Run quit
Quit the IS-IS view.
The interface view is displayed.
4. Run isis [ process-id process-id ] ti-lfa disable [ level-1 | level-2 | level-1-2 ]
IS-IS TI-LFA is disabled on the interface.
Step 8 If a network fault occurs or is rectified, an IGP performs route convergence. A
transient forwarding status inconsistency between nodes results in different
convergence rates on devices, posing the risk of microloops. To prevent
microloops, perform the following steps:
1. Run quit
Quit the interface view.
The IS-IS process is created, and the IS-IS view is displayed.
3. Run avoid-microloop frr-protected
The IS-IS local anti-microloop is enabled.

(2020-10-09)
4. (Optional) Run avoid-microloop frr-protected rib-update-delay rib-update-

delay
The delay after which IS-IS delivers routes is configured.
5. Run avoid-microloop segment-routing
The IS-IS remote anti-micro-loop function is enabled.
6. (Optional) Run avoid-microloop segment-routing rib-update-delay rib-
update-delay
The delay in delivering IS-IS route in a segment routing scenario is set.
Step 9 Run commit
----End

After configuring IS-IS TI-LFA FRR, run the display isis route [ process-id ]
[ level-1 | level-2 ] [ verbose ] command to check information about the primary
and backup links.
1.2.19 Configuring OSPF TI-LFA FRR

This section describes how to configure OSPF TI-LFA FRR.
Usage Scenario
In some LFA or RLFA scenarios, the P space and Q space do not share nodes or
have direct neighbors. If a link or node fails, no backup path can be calculated,
causing traffic loss and resulting in a failure to meet reliability requirements. In
this situation, TI-LFA can be used.
TI-LFA fast reroute (FRR) protects links and nodes on segment routing tunnels. If a
link or node fails, traffic is rapidly switched to a backup path, which minimizes
traffic loss.
Before configuring OSPF TI-LFA FRR, complete the following tasks:
● Configure IP addresses for interfaces to implement connectivity at the

network layer.
● Configure basic OSPF functions
● Globally enable the Segment Routing capability.
● Enable the Segment Routing capability in an OSPF process.
Procedure

(2020-10-09)
Step 2 Run ospf [ process-id ]
The OSPF process is enabled, and the OSPF view is displayed.
Step 3 Run frr
The OSPF FRR view is displayed.
Step 4 Run loop-free-alternate
OSPF LFA is enabled, and LFA links can be generated.
Step 5 Run ti-lfa enable
OSPF TI-LFA is enabled.
Step 6 (Optional) After completing the preceding configuration, OSPF TI-LFA is enabled
on all OSPF interfaces. If you do not want to enable OSPF TI-LFA on some
interfaces, perform the following operations:
1. Run quit
Quit the OSPF FRR view.

2. Run quit
Quit the OSPF view.


4. To disable the OSPF TI-LFA on a specified interface, run either of the following
commands:
– For a common interface, run the ospf ti-lfa disable command.
– For a multi-area interface, run the ospf ti-lfa disable multi-area area-id
command.

1. Run quit
Quit the interface view.
The OSPF process is created, and the OSPF view is displayed.
The OSPF local anti-microloop is enabled.
4. Run avoid-microloop frr-protected rib-update-delay rib-update-delay
The delay after which OSPF delivers routes is configured.
5. Run avoid-microloop segment-routing
The OSPF remote anti-micro-loop function is enabled.
6. (Optional) Run avoid-microloop segment-routing rib-update-delay rib-
update-delay
The delay in delivering OSPF route in a segment routing scenario is set.

(2020-10-09)
Step 8 Run commit

----End
All OSPF TI-LFA FRR configurations are complete.

After completing all OSPF TI-LFA FRR configurations, run the display ospf
[ process-id ] segment-routing routing [ ip-address [ mask | mask-length ] ]
command to check the routing table information of OSPF Segment Routing.
1.2.20 Configuring SBFD for SR-MPLS BE Tunnel

SBFD for SR-MPLS BE tunnel can be configured to monitor SR-MPLS TE tunnels.
Usage Scenario
If SBFD for SR-MPLS BE detects a fault on the primary tunnel, VPN FRR rapidly
switches traffic, which minimizes the impact on traffic.
Before configuring SBFD for SR-MPLS BE tunnel, complete the following tasks:
● Configure an SR-MPLS BE tunnel.
● Run the mpls lsr-id lsr-id command to set the LSR ID, and ensure the peer to
local end lsr-id address is reachable.
Procedure
● Configuring the SBFD Initiator
a. Run system-view
b. Run bfd
BFD is globally enabled.
You can set BFD parameters only after running the bfd command to
enable global BFD.
c. Run quit
d. Run sbfd
SBFD is globally enabled.
e. (Optional) Run destination ipv4 ip-address remote-discriminator
discriminator-value
The mapping between the IP address and discriminator of the SBFD
reflector is configured.
f. Run quit

(2020-10-09)
g. Run segment-routing
h. Run seamless-bfd enable mode tunnel [ filter-policy ip-prefix ip-
prefix-name | effect-sr-lsp ] *
SBFD for SR-MPLS BE tunnel is enabled.
i. (Optional) Run seamless-bfd tunnel { min-rx-interval receive-interval |
min-tx-interval transmit-interval | detect-multiplier multiplier-value } *
SBFD parameters are set.
j. Run commit
● Configuring an SBFD Reflector
a. Run system-view
b. Run bfd
BFD is globally enabled.
enable global BFD.
c. Run quit
d. Run sbfd
SBFD is globally enabled.
e. Run reflector discriminator { unsigned-integer-value | ip-address-value }
A discriminator is configured for the SBFD reflector.
f. Run commit
----End

After successfully configuring SBFD for SR-MPLS BE tunnel, run the display
segment-routing seamless-bfd tunnel session [ prefix ip-address [ mask | mask-
length ] ] command to check information about the SBFD session that monitors
the SR-MPLS BE tunnel.
1.2.21 Configuring SBFD for SR-MPLS TE LSP

This section describes how to configure SBFD to detect SR-MPLS TE LSP faults.
Usage Scenario
If SBFD for SR-MPLS TE LSP detects a fault on the primary LSP, traffic is rapidly
switched to the backup LSP, which minimizes the impact on traffic.

(2020-10-09)
Before configuring SBFD for SR-MPLS TE LSP, complete the following task:
● Configure an SR-MPLS TE tunnel.
● Set each LSR ID using the mpls lsr-id lsr-id command. Ensure that the route
to the local lsr-id is reachable.
Procedure
● Configure an SBFD initiator.
a. Run system-view
b. Run bfd
BFD is enabled globally.
enable global BFD.
c. Run quit
d. Run sbfd
SBFD is enabled globally.
e. Run quit
f. Run interface tunnel tunnel-number
g. Run mpls te bfd enable seamless
SBFD for SR-MPLS TE LSP is enabled.
After the configuration is complete, the SBFD initiator automatically
establishes an SBFD session destined for the destination IP address of an
SR-MPLS TE tunnel.
h. Run commit
● Configure the SBFD reflector.
a. Run system-view
b. Run bfd
enable global BFD.
c. Run quit

(2020-10-09)
d. Run sbfd
The discriminator of an SBFD reflector is configured.
f. Run commit
----End

After you configure SBFD for SR-MPLS TE LSP, run the display bfd session { all |
discriminator discr-value } [ verbose ] command to check information about the
SBFD session that monitors an SR-MPLS TE tunnel.
1.2.22 Configuring SBFD for SR-MPLS TE Tunnel

This section describes how to configure SBFD to detect SR-MPLS TE tunnel faults.
Usage Scenario
If SBFD for SR-MPLS TE tunnel detects a fault on the primary tunnel, traffic is
rapidly switched to the backup tunnel, which minimizes the impact on traffic.
Before configuring SBFD for SR-MPLS TE tunnel, complete the following task:
● Configure an SR-MPLS TE tunnel.
Procedure
a. Run system-view
b. Run bfd
enable global BFD.
c. Run quit
d. Run sbfd
e. Run quit

(2020-10-09)

f. Run interface tunnel tunnel-number
g. Run mpls te bfd tunnel enable seamless
SBFD for SR-MPLS TE tunnel is enabled.
After the configuration is complete, the SBFD initiator automatically
establishes an SBFD session destined for the destination IP address of an
SR-MPLS TE tunnel.
h. Run commit
● Configure the SBFD reflector.
a. Run system-view
b. Run bfd
enable global BFD.
c. Run quit
d. Run sbfd
The discriminator of an SBFD reflector is configured.
f. Run commit
----End

After you configure SBFD for SR-MPLS TE tunnel, run the display bfd session { all
| discriminator discr-value } [ verbose ] command to check information about the
SBFD session that monitors an SR-MPLS TE tunnel.
1.2.23 Configuring BFD for SR-MPLS BE

BFD for SR LSP can be configured to detect faults of SR LSPs.
Usage Scenario
Segment Routing-MPLS Best Effort (SR-MPLS BE) refers to the use of an IGP to
compute an optimal SR LSP based on the shortest path first algorithm. An SR LSP
is a label forwarding path that is established using SR and guides data packet
forwarding through a prefix or node SID.

(2020-10-09)
BFD for SR-MPLS BE is used to detect SR LSP connectivity. If BFD for SR-MPLS BE
detects a fault on the primary SR LSP, an application such as VPN FRR rapidly
switches traffic, which minimizes the impact on services.
Before configuring BFD for SR-MPLS BE, complete the following tasks:
● Configure an IS-IS SR-MPLS BE tunnel or configure an OSPF SR-MPLS BE

tunnel.
Procedure
Step 2 Run bfd
The BFD view is displayed.
Step 3 Run mpls-passive
The egress is enabled to create a BFD session passively.
The egress has to receive an LSP ping request carrying a BFD TLV before creating a
BFD session.
Step 4 Run quit
Step 6 Run bfd enable mode tunnel [ filter-policy ip-prefix ip-prefix-name | effect-sr-
lsp ] *
BFD is enabled for SR LSPs.
If effect-sr-lsp is specified and BFD goes down, the SR LSPs are withdrawn.
Step 7 (Optional) Run bfd tunnel { min-rx-interval receive-interval | min-tx-interval

transmit-interval | detect-multiplier multiplier-value } *
BFD parameters are set for SR LSPs.
Step 8 Run commit
----End

(2020-10-09)

After successfully configuring BFD for SR-MPLS BE, run the display segment-
routing bfd tunnel session [ prefix ip-address { mask | mask-length } ] command
to check information about the BFD session that monitors SR LSPs.
1.2.24 Configuring BFD for SR-MPLS BE (SR and LDP

Interworking Scenario)
This section describes how to use BFD to detect an LSP fault in an SR+LDP
interworking scenario.
Usage Scenario
SR and LDP interworking enables SR and LDP to work together on the same
network. SR-MPLS BE and LDP networks can be connected through this
technology to implement MPLS forwarding.
If BFD for SR-MPLS BE detects a fault on the primary tunnel when SR

communicates with LDP, an application, such as VPN FRR, rapidly switches traffic
to minimize the impact on traffic.
Before configuring BFD for SR-MPLS BE (in the SR and LDP interworking scenario),
complete the following tasks:
● Configure IS-IS SR to communicate with LDP or OSPF SR to communicate

with LDP.
Procedure
● Create a BFD session on the SR side.
a. Run system-view

b. Run bfd

c. Run mpls-passive
The egress has to receive an LSP ping request carrying a BFD TLV before
creating a BFD session.
d. Run quit

e. Run segment-routing

(2020-10-09)
f. Run bfd enable mode tunnel [ filter-policy ip-prefix ip-prefix-name |

effect-sr-lsp | nil-fec ] *BFD is enabled for SR LSPs.
If effect-sr-lsp is specified and BFD goes down, the SR LSPs are
withdrawn.
In an SR and LDP interworking scenario, the ingress node cannot detect
whether LDP LSPs are stitched to SR LSPs in the LDP to SR direction. In
the LSP ping packet triggered by BFD, the encapsulated FEC type is LDP.
When the packet arrives at the egress node (SR node), the FEC type fails
to be verified, preventing BFD from going Up. To resolve this issue,
configure the nil-fec parameter.
g. (Optional) Run bfd tunnel { min-rx-interval receive-interval | min-tx-
interval transmit-interval | detect-multiplier multiplier-value } *
BFD parameters are set for SR tunnels.
h. Run commit
● Create a BFD session on the LDP side.
a. Run system-view
b. Run bfd
c. Run mpls-passive
d. Run quit
e. Run mpls
f. Run mpls bfd enable
An MPLS device to dynamically establish a BFD session.
g. Run mpls bfd-trigger host
Host IP routes are used as the policy for triggering LDP BFD sessions.
h. Run commit
● Configure a device that connects the LDP area to the SR area.
a. Run system-view
b. Run mpls

(2020-10-09)

A device is enabled to stitch SR LSPs to the proxy egress LSPs and transit
LSPs that are established over non-local host routes with a 32-bit mask.
d. Run commit
----End

After successfully configuring BFD for SR-MPLS BE, run the display segment-
routing bfd tunnel session [ prefix ip-address { mask | mask-length } ] command
to check information about the BFD session that monitors SR LSPs.
1.2.25 Configuring Static BFD for SR-MPLS TE Tunnel

This section describes how to configure static BFD for SR-MPLS TE to detect SR-
MPLS TE tunnel faults.
Usage Scenario
BFD can be used to monitor to SR-MPLS TE tunnels. If the primary tunnel fails,
BFD instructs applications such as VPN FRR to quickly switch traffic, minimizing
the impact on services.
Before configuring static BFD for SR-MPLS TE, configure SR-MPLS TE tunnels.
Procedure
Step 1 Enable BFD globally.
1. Run system-view
2. Run bfd
BFD is enabled globally, and the BFD view is displayed.
You can set BFD parameters only after running the bfd command to enable
BFD globally.
3. Run commit
Step 2 Set ingress BFD parameters.
1. Run system-view
2. Run bfd sessname-value bind mpls-te interface tunnel-name
BFD is configured to monitor an SR-MPLS TE tunnel.

(2020-10-09)
3. Run discriminator local discr-value
A local discriminator is configured for the BFD session.

4. Run discriminator remote discr-value
A remote discriminator is configured for the BFD session.
This command does not need to be run if a one-arm BFD session is

established.
5. (Optional) Run min-tx-interval tx-interval The minimum interval at which
the local device sends BFD packets is changed.
This command cannot be run for a one-arm BFD session.
Actual local interval at which BFD packets are sent = MAX { Locally
configured interval at which BFD packets are sent, Remotely configured
interval at which BFD packets are received }
Actual local interval at which BFD packets are received = MAX { Remotely
configured interval at which BFD packets are sent, Locally configured interval
at which BFD packets are received }
Local BFD detection period = Actual local interval at which BFD packets are
received x Remotely configured BFD detection multiplier
For example: If on the local device, the intervals at which BFD packets are
sent and received are 200 ms and 300 ms, respectively, and the detection
multiplier is 4; on the remote device, the intervals at which BFD packets are
multiplier is 5, then:
– On the local device, the actual interval for sending BFD packets is 600 ms
calculated using the formula MAX {200 ms, 600 ms}, the actual interval
for receiving BFD packets is 300 ms calculated using the formula MAX
{100 ms, 300 ms}, and the actual detection period is 1500 ms (300 ms ×
5).
– On the remote device, the actual interval between sending BFD packets is
300 ms calculated using the formula MAX {100 ms, 300 ms}, the actual
interval between receiving BFD packets is 600 ms calculated using the
formula MAX {200 ms, 600 ms}, and the actual detection period is 2400
ms (600 ms × 4).
6. (Optional) Run min-rx-interval rx-interval
The minimum interval at which the local device receives BFD packets is
changed.
If a one-arm BFD session is to be established, run the min-echo-rx-interval

command to set the minimum interval at which BFD packets are received
locally.
7. (Optional) Run detect-multiplier multiplier
The local BFD detection multiplier is changed.

8. Run commit

(2020-10-09)
Step 3 Set egress BFD parameters.

1. Run system-view

2. Run bfd sessname-value bind mpls-te interface tunnel-name
BFD is configured to monitor an SR-MPLS TE tunnel.

A local discriminator is configured for the BFD session.

A remote discriminator is configured for the BFD session.
This command does not need to be run for a one-arm BFD session.
5. (Optional) Run min-tx-interval tx-interval
The minimum interval at which the local device sends BFD packets is
changed.
This command cannot be run for a one-arm BFD session.
If the reverse link is an IP link, you cannot run this command.
5).
ms (600 ms × 4).
The minimum interval at which the local device receives BFD packets is
changed.

(2020-10-09)

locally.
The local BFD detection multiplier is changed.

8. Run commit
----End

After configuring static BFD for SR-MPLS TE, check the configurations.
● Run the display bfd session mpls-te interface interface-type interface-
number [ verbose ] command to check BFD session information on the
tunnel ingress.
● Check BFD session information on the tunnel egress.
– To check all BFD sessions' information, run the display bfd session all
[ for-te ] [ verbose ] command.
– To check static BFD sessions' information, run the display bfd session
static [ for-te ] [ verbose ] command.
● Check BFD statistics.
– To check statistics about all BFD sessions, run the display bfd statistics
session all [ for-te ] command.
– To check statistics about static BFD sessions, run the display bfd
statistics session static [ for-te ] command.
– To check statistics about BFD sessions, run the display bfd statistics
session mpls-te interface interface-type interface-number command.
1.2.26 Configuring Static BFD for SR-MPLS TE LSP

Static BFD for SR-MPLS TE LSP can be configured to detect faults on SR-MPLS TE
LSPs.
Usage Scenario
BFD detects the connectivity of SR-MPLS TE LSPs. If a BFD session fails to go up
through negotiation, an SR-MPLS TE LSP cannot go up. Static BFD for SR-MPLS TE
LSP is configured to rapidly switch traffic from a primary LSP to a backup LSP if
the primary LSP fails.
Before configuring static BFD for SR-MPLS TE LSP, configure an SR-MPLS TE
tunnel.

(2020-10-09)
Procedure
1. Run system-view
2. Run bfd
BFD globally.
3. Run commit
Step 2 Configure BFD parameters on the ingress.
1. Run system-view
2. Run bfd sessname-value bind mpls-te interface tunnel-name te-lsp
[ backup ] [ one-arm-echo ]
BFD is configured to monitor the primary or backup LSP that is bound to an
SR-MPLS TE tunnel.
If one-arm-echo is configured, a one-arm BFD session is established to
monitor an LSP bound to the SR-MPLS TE tunnel. A Huawei device at the
ingress cannot use BFD for SR-MPLS TE LSP to communicate with a non-
Huawei device at the egress. In this situation, no BFD session can be
established. To establish a BFD session to monitor an LSP bound to the SR-
MPLS TE tunnel, configure a one-arm BFD session.
A local discriminator of a BFD session is set.
A remote discriminator of a BFD session is set.
established.
The minimum interval at which BFD packets are sent locally is set.
This parameter cannot be set if a one-arm BFD session is established.

(2020-10-09)
5).
ms (600 ms × 4).
The minimum interval at which BFD packets are received locally is set.
locally.
A local BFD detection multiplier is set.
8. (Optional) Run bit-error-detection
Bit-error-triggered SR-MPLS TE LSP switching is enabled.
SR-MPLS TE LSP establishment does not require protocols. Therefore, an SR-
MPLS TE LSP can be established as long as a label stack is delivered. If an SR-
MPLS TE LSP encounters bit errors, upper-layer services may be affected. With
the bit-error-detection command being executed, if BFD detects bit errors on
the primary LSP bound to the SR-MPLS TE tunnel, it instructs the SR-MPLS TE
tunnel to switch traffic to the backup LSP, minimizing the impact on services.
9. Run commit
Step 3 Configure BFD parameters on the egress.
1. Run system-view
2. Run bfd sessname-value bind mpls-te interface tunnel-name te-lsp
[ backup ] [ one-arm-echo ]
BFD is configured to monitor the primary or backup LSP that is bound to an
SR-MPLS TE tunnel.
monitor an LSP bound to the SR-MPLS TE tunnel. A Huawei device at the
ingress cannot use BFD for SR-MPLS TE LSP to communicate with a non-
Huawei device at the egress. In this situation, no BFD session can be
established. To establish a BFD session to monitor an LSP bound to the SR-
MPLS TE tunnel, configure a one-arm BFD echo session.

(2020-10-09)

A local discriminator of a BFD session is set.
A remote discriminator of a BFD session is set.
established.
The minimum interval at which BFD packets are sent locally is set.
This parameter cannot be set if a one-arm BFD session is established.
5).
ms (600 ms × 4).
The minimum interval at which BFD packets are received locally is set.
locally.
A BFD detection multiplier is set locally.
8. (Optional) Run bit-error-detection
Bit-error-triggered SR-MPLS TE LSP switching is enabled.
SR-MPLS TE LSP establishment does not require protocols. Therefore, an SR-
MPLS TE LSP can be established as long as a label stack is delivered. If an SR-

(2020-10-09)
MPLS TE LSP encounters bit errors, upper-layer services may be affected. With
the bit-error-detection command being executed, if BFD detects bit errors on
the primary LSP bound to the SR-MPLS TE tunnel, it instructs the SR-MPLS TE
tunnel to switch traffic to the backup LSP, minimizing the impact on services.
9. Run commit
----End

After successfully configuring BFD for SR-MPLS TE LSP, verify the configuration.
For example, check whether the BFD session is up.
● Run the display bfd session mpls-te interface interface-type interface-
number te-lsp [ verbose ] command to check information about BFD
sessions on the ingress.
● Run the following commands to check BFD session information about the
egress:
– Run the display bfd session all [ for-lsp ] [ verbose ] command to check
the configurations of all BFD sessions.
– Run the display bfd session static [ for-lsp ] [ verbose ] command to
check the configurations of static BFD sessions.
● Run the following commands to check BFD statistics:
– Run the display bfd statistics session all [ for-lsp ] command to check
statistics about all BFD sessions.
– Run the display bfd statistics session static [ for-lsp ] command to
check statistics about static BFD sessions.
– Run the display bfd statistics session mpls-te interface interface-type
interface-number te-lsp command to check statistics about BFD sessions
that monitor LSPs.
1.2.27 Configuring Dynamic BFD for SR-MPLS TE LSP

Dynamic BFD for SR-MPLS TE LSP rapidly detects faults of SR-MPLS TE LSPs,
which protects traffic transmitted on SR-MPLS TE LSPs.
Usage Scenario
BFD detects the connectivity of SR-MPLS TE LSPs. Dynamic BFD for SR-MPLS TE
LSP is configured to rapidly switch traffic from a primary LSP to a backup LSP if
the primary LSP fails. Unlike static BFD for SR-MPLS TE LSP, dynamic BFD for SR-
MPLS TE LSP simplifies the configuration and minimizes manual configuration
errors.
Dynamic BFD can only monitor a part of an SR-MPLS TE tunnel.
Before configuring dynamic BFD for SR-MPLS TE LSP, you should configure an SR-
MPLS TE Tunnel.

(2020-10-09)
Procedure
Step 1 Enabling BFD Globally
1. Run system-view
2. Run bfd
BFD globally.
3. Run commit
Step 2 Enabling the Ingress to Dynamically Create a BFD Session to Monitor SR-MPLS TE
LSPs
Perform either of the following operations to enable the ingress to dynamically
create a BFD Session to monitor SR-MPLS TE LSPs:
● Globally enable the capability if BFD sessions need to be automatically
created for most SR-MPLS TE tunnels on the ingress.
● Enable the capability on a specific tunnel interface if a BFD session needs to
be automatically created for a specific or some SR-MPLS TE tunnels on the
ingress.
Please select the appropriate configuration according to your actual needs.
● Globally enable the capability.
a. Run system-view
b. Run mpls
c. Run mpls te bfd enable [ one-arm-echo ]
The ingress is configured to automatically create a BFD session for each
SR-MPLS TE tunnel.
After this command is run in the MPLS view, BFD for SR-MPLS TE LSP is
enabled on all tunnel interfaces, except the tunnel interfaces on which
BFD for SR-MPLS TE LSP is blocked.
monitor an SR-MPLS TE LSP. A Huawei device at the ingress cannot use
BFD for SR-MPLS TE LSP to communicate with a non-Huawei device at
the egress. In this situation, no BFD session can be established. To address
this issue, configure a one-arm BFD session.
d. (Optional) If some SR-MPLS TE tunnels do not need to be monitored
using BFD for SR-MPLS TE LSP, block BFD for SR-MPLS TE LSP on each
tunnel interface:
i. Run quit

(2020-10-09)
ii. Run interface tunnel interface-number

iii. Run the mpls te bfd block
The tunnel interface is disabled from automatically creating a BFD
session to monitor an SR-MPLS TE tunnel.
e. Run commit
● Enable the capability on a tunnel interface.
– Run system-view
– Run interface tunnel interface-number
The view of the SR-MPLS TE tunnel interface is displayed.
– Run mpls te bfd enable [ one-arm-echo ]
The ingress is configured to automatically create a BFD session for the
tunnel.
This command run in the tunnel interface view takes effect only on the
tunnel interface.
If one-arm-echo is configured, a one-arm BFD echo session is established
to monitor an SR-MPLS TE LSP. A Huawei device at the ingress cannot
use BFD for SR-MPLS TE LSP to communicate with a non-Huawei device
at the egress. In this situation, no BFD session can be established. To
address this issue, configure a one-arm BFD session.
– Run commit
Step 3 Enabling the Egress to Passively Create a BFD Session

1. Run system-view

2. Run bfd

3. Run mpls-passive
4. Run commit
Step 4 (Optional) Adjusting BFD Parameters on the Ingress
Adjust BFD parameters on the ingress in either of the following modes:
● Adjust BFD parameters globally. This method is used when BFD parameters
for most SR-MPLS TE tunnels need to be adjusted on the ingress.

(2020-10-09)
● Adjust BFD parameters on a specific tunnel interface. If an SR-MPLS TE tunnel

interface needs BFD parameters different from the globally configured ones,
adjust BFD parameters on the specific tunnel interface.
NOTE
● Effective local interval at which BFD packets are sent = MAX { Locally configured
interval at which BFD packets are sent, Remotely configured interval at which BFD
packets are received }
● Effective local interval at which BFD packets are received = MAX { Remotely
configured interval at which BFD packets are sent, Locally configured interval at which
BFD packets are received }
● Effective local BFD detection period = Effective local interval at which BFD packets are
On the egress that passively creates a BFD session, the BFD parameters cannot be adjusted,
because the default values are the smallest values that can be set on the ingress. Therefore,
if BFD for TE is used, the effective BFD detection period on both ends of an SR-MPLS TE
tunnel is as follows:
● Effective detection period on the ingress = Configured interval at which BFD packets are
received on the ingress x 3
● Effective detection period on the egress = Configured interval at which BFD packets are
sent on the ingress x Configured detection multiplier on the ingress
Please select the appropriate configuration according to your actual needs.
● Adjust BFD parameters globally.

– Run system-view
– Run mpls
– Run mpls te bfd { min-tx-interval tx-interval | min-rx-interval rx-
interval | detect-multiplier multiplier }*
The BFD parameters are set.
– Run commit
● Adjust BFD parameters on a specific tunnel interface.
– Run system-view
The tunnel interface view is displayed.
– Run mpls te bfd { min-tx-interval tx-interval | min-rx-interval rx-
interval | detect-multiplier multiplier }*
The BFD parameters are set.
– Run commit
----End

(2020-10-09)

After the configuration of dynamic BFD for SR-MPLS TE LSP is complete, verify the
configurations.
● Run the display bfd session dynamic [ verbose ] command to check
information about BFD sessions on the ingress.
● Run the display bfd session passive-dynamic [ peer-ip peer-ip remote-
discriminator discriminator ] [ verbose ] command to check information
about BFD sessions that are passively created on the egress.
– Run the display bfd statistics command to check all BFD statistics.
– Run the display bfd statistics session dynamic command to check
statistics about dynamic BFD sessions.
● Run the display mpls bfd session { protocol rsvp-te | outgoing-interface
interface-type interface-number } [ verbose ] command to check information
about BFD sessions for MPLS.
1.2.28 Configuring One-Arm BFD for E2E SR-MPLS TE Tunnel

One-arm BFD for E2E SR-MPLS TE tunnel quickly detects faults on inter-AS E2E
SR-MPLS TE tunnels and protects traffic on the E2E SR-MPLS TE tunnels.
Usage Scenario
If one-arm BFD for inter-AS E2E SR-MPLS TE tunnel detects a fault on the primary
tunnel, a protection application, for example, VPN FRR, rapidly switches traffic,
which minimizes the impact on traffic.
With one-arm BFD for E2E SR-MPLS TE tunnel enabled, if the reflector can
successfully iterate packets to the E2E SR-MPLS TE tunnel using the IP address of
the initiator, the reflector forwards the packets through the E2E SR-MPLS TE
tunnel. Otherwise, the reflector forwards the packets over IP routes.
Before configuring one-arm BFD for E2E SR-MPLS TE tunnel, configure an inter-AS
E2E SR-MPLS TE tunnel.
Procedure
1. Run system-view
2. Run bfd
BFD is enabled.
3. Run commit
Step 2 Enable the ingress to dynamically create a BFD session to monitor E2E SR-MPLS
TE tunnels.

(2020-10-09)
Perform either of the following operations:
● Globally enable the capability if BFD sessions need to be automatically

created for most E2E SR-MPLS TE tunnels on the ingress.
● Enable the capability on a specific tunnel interface if a BFD session needs to
be automatically created for some E2E SR-MPLS TE tunnels on the ingress.
Run the following commands as needed.
● Enable the capability globally.

a. Run system-view
b. Run mpls
c. Run mpls te bfd tunnel enable one-arm-echo
One-arm BFD for E2E SR-MPLS TE tunnel is enabled.
d. Run quit
e. Run interface tunnel interface-number
The view of the E2E SR-MPLS TE tunnel interface is displayed.
f. Run mpls te reverse-lsp binding-sid label label-value
A binding SID is set for a reverse LSP in the E2E SR-MPLS TE tunnel.
Ensure that the mpls te binding-sid label label-value command has
been run on the ingress of the reverse LSP.
g. (Optional) Run mpls te bfd block
The capability of automatically creating BFD sessions for the E2E SR-
MPLS TE tunnel is blocked.
If some SR-MPLS TE tunnels do not need to be monitored using BFD for
E2E SR-MPLS TE tunnel, block this capability on each tunnel interface:
h. Run commit
● Enable the capability on a tunnel interface.
– Run system-view
– Run mpls te bfd tunnel enable one-arm-echo
One-arm BFD for E2E SR-MPLS TE tunnel is enabled.
This command run in the tunnel interface view takes effect only on the
tunnel interface.
– Run mpls te reverse-lsp binding-sid label label-value
A binding SID is set for a reverse LSP in the E2E SR-MPLS TE tunnel.
Ensure that the mpls te binding-sid label label-value command has
been run on the ingress of the reverse LSP.

(2020-10-09)
– Run commit
Step 3 (Optional) Adjust BFD parameters on the ingress.
for most E2E SR-MPLS TE tunnels need to be adjusted on the ingress.
● Adjust BFD parameters on a specific tunnel interface. If an E2E SR-MPLS TE
tunnel interface needs BFD parameters different from the globally configured
ones, adjust BFD parameters on the specific tunnel interface.
NOTE
In one-arm BFD for E2E SR-MPLS TE mode, BFD does not need to be enabled on the peer,
and the min-tx-interval tx-interval parameter of the local end does not take effect.
Therefore, the actual detection period of the ingress equals the configured interval at which
BFD packets are received on the ingress multiplied by the detection multiplier configured
on the ingress.

– Run system-view
– Run mpls
– Run mpls te bfd tunnel { min-rx-interval rx-interval | detect-multiplier
multiplier } *
BFD parameters are set.
– Run commit
– Run system-view
– Run mpls te bfd tunnel { min-rx-interval rx-interval | detect-multiplier
multiplier } *
– Run commit
----End
Verifying the Configuration of One-Arm BFD for E2E SR-MPLS TE Tunnel

After successfully configuring one-arm BFD for E2E SR-MPLS TE tunnel, verify the
configurations.

(2020-10-09)

1.2.29 Configuring One-Arm BFD for E2E SR-MPLS TE LSP

One-arm BFD for E2E SR-MPLS TE LSP quickly detects faults on inter-AS E2E SR-
MPLS TE LSPs and protects traffic on E2E SR-MPLS TE LSPs.
Usage Scenario
One-arm BFD monitors inter-AS E2E SR-MPLS TE LSPs. If a specified transit node
on a tunnel fails, traffic is switched to the hot-standby LSP, which reduces the
impact on services.
With one-arm BFD for E2E SR-MPLS TE LSP enabled, if the reflector can
successfully iterate packets to the E2E SR-MPLS TE LSP using the IP address of the
initiator, the reflector forwards the packets through the E2E SR-MPLS TESR-MPLS
TE Otherwise, the reflector forwards the packets over IP routes.
Before configuring one-arm BFD for E2E SR-MPLS TE LSP, configure an inter-AS
E2E SR-MPLS TE tunnel.
Procedure
Step 1 Enable global BFD.
1. Run system-view
2. Run bfd
BFD is enabled.
3. Run commit
Step 2 Enable the ingress to dynamically create a one-arm BFD session to monitor E2E
SR-MPLS TE LSPs.
1. Run system-view
2. Run interface tunnel interface-number
3. Run mpls te bfd enable one-arm-echo [ primary ]
Automatic creation of a one-arm BFD session to monitor E2E SR-MPLS TE
LSPs is triggered.

(2020-10-09)
4. Run mpls te reverse-lsp binding-sid label label-value

A binding SID is specified for a reverse LSP in the E2E SR-MPLS TE tunnel.
Ensure that the mpls te binding-sid label label-value command has been run
on the ingress of the reverse LSP.
5. Run commit
Step 3 (Optional) Adjust BFD parameters on the ingress.
for most E2E SR-MPLS TE tunnels need to be adjusted on the ingress.
● Adjust BFD parameters on a specific tunnel interface. If an E2E SR-MPLS TE
tunnel interface needs BFD parameters different from the globally configured
ones, adjust BFD parameters on the specific tunnel interface.
NOTE
In one-arm BFD for E2E SR-MPLS TE mode, BFD does not need to be enabled on the peer,
and the min-tx-interval tx-interval parameter of the local end does not take effect.
Therefore, the actual detection period of the ingress equals the configured interval at which
BFD packets are received on the ingress multiplied by the detection multiplier configured
on the ingress.

– Run system-view
– Run mpls
– Run mpls te bfd { min-rx-interval rx-interval | detect-multiplier
multiplier } *
– Run commit
– Run system-view
– Run mpls te bfd { min-rx-interval rx-interval | detect-multiplier
multiplier } *
– Run commit
----End

(2020-10-09)
Verifying the Configuration of One-arm BFD for E2E SR-MPLS TE LSP

After successfully configuring one-arm BFD for E2E SR-MPLS TE LSP, verify the
configurations.
1.2.30 Configuring a Device as the Egress of an MPLS-in-UDP

Tunnel
This section describes how to configure a device as the egress of an MPLS-in-UDP
tunnel.
Usage Scenario
MPLS in UDP is a DCN overlay technology that encapsulates MPLS packets (or SR-
MPLS packets) into UDP packets to traverse through some networks that do not
support MPLS or SR-MPLS.
A device can be configured only as the egress of an MPLS-in-UDP tunnel to

properly process MPLS-in-UDP packets. Running the mpls-in-udp command does
not trigger the establishment of an MPLS-in-UDP tunnel.
Before configuring a device as the egress of an MPLS-in-UDP tunnel, configure an
SR-MPLS tunnel.
Procedure
Step 2 Run mpls-in-udp
The MPLS-in-UDP capability is enabled, and the MPLS-in-UDP view is displayed.
Step 3 Run source-ip-validate list destination-ip ip-addr
A destination IP address is specified for an IP address verification list.
Step 4 Run source-ip (MPLS-in-UDP-List view) ip-addr
A source IP address is specified for an IP address verification list.
Step 5 Run validate-list enable
The device is enabled to verify the source IP address mapped to the specified
destination IP address.

(2020-10-09)
Source address verification secures MPLS-in-UDP tunnels. After the validate-list

enable command is run and the device receives an MPLS-in-UDP packet, the
device verifies the source IP address. The device discards the packet if the
verification fails.
Step 6 Run commit
----End
1.2.31 Configuring SR-MPLS BE Traffic Statistics Collection

This section describes how to configure SR LSP (that is, SR-MPLS BE tunnel) traffic
statistics collection.
Context
This function is used to collect statistics about traffic forwarded over an SR-MPLS
BE.
Perform the following steps on the router:
Procedure
Step 3 Run traffic-statistics enable host [ ip-prefix ip-prefix-name ]
The function to collect SR-MPLS BE traffic statistics is enabled.
Step 4 Run commit
----End
Verifying the Configuration of SR-MPLS BE Traffic Statistics Collection

After configuring SR-MPLS BE traffic statistics collection, verify the configuration.
● Run the display segment-routing traffic-statistics [ ip-address mask-
length ] [ verbose ] command to query SR-MPLS BE traffic statistics.
Follow-up Procedure
To clear SR-MPLS BE traffic statistics before re-collection, run the reset segment-
routing traffic-statistics [ ip-address mask-length ] command.

(2020-10-09)
1.2.32 Configuring an SR-MPLS TE Policy (Manual

Configuration)
SR-MPLS TE Policy is a tunneling technology developed based on SR.
Usage Scenario
An SR-MPLS TE Policy is a set of candidate paths consisting of one or more
segment lists, that is, segment ID (SID) lists. Each SID list identifies an end-to-end
path from the source to the destination, instructing a device to forward traffic
through the path rather than the shortest path computed by an IGP. The header of
a packet steered into an SR-MPLS TE Policy is augmented with an ordered list of
segments associated with that SR-MPLS TE Policy, so that other devices on the
network can execute the instructions encapsulated into the list.
You can configure an SR-MPLS TE Policy through CLI or NETCONF. For a manually
configured SR-MPLS TE Policy, information, such as the endpoint and color
attributes, the preference values of candidate paths, and segment lists, must be
configured. Moreover, the preference values must be unique. The first-hop label of
a segment list can be a node, adjacency, BGP EPE, parallel, or anycast SID, but
cannot be any binding SID. Ensure that the first-hop label is a local incoming
label, so that the forwarding plane can use this label to search the local
forwarding table for the corresponding forwarding entry.
Before configuring an SR-MPLS TE Policy, configure an IGP to ensure that all
nodes can communicate with each other at the network layer.
1.2.32.1 Configuring IGP SR

This section describes how to configure IGP SR.
Context
An SR-MPLS TE Policy may contain multiple candidate paths that are defined
using segment lists. Because adjacency and node SIDs are required for SR-MPLS TE
Policy configuration, you need to configure the IGP SR function. Node SIDs need
to be configured manually, whereas adjacency SIDs can either be generated
dynamically by an IGP or be configured manually.
● In scenarios where SR-MPLS TE Policies are configured manually, if dynamic
adjacency SIDs are used, the adjacency SIDs may change after an IGP restart.
To keep the SR-MPLS TE Policies up, you must adjust them manually. The
adjustment workload is heavy if a large number of SR-MPLS TE Policies are
configured manually. Therefore, you are advised to configure adjacency SIDs
manually and not to use adjacency SIDs generated dynamically.
● In scenarios where SR-MPLS TE Policies are delivered by a controller
dynamically, you are also advised to configure adjacency SIDs manually.
Although the controller can use BGP-LS to detect adjacency SID changes, the
adjacency SIDs dynamically generated by an IGP change randomly, causing
inconvenience in routine maintenance and troubleshooting.

(2020-10-09)
Procedure
Step 1 Enable MPLS.
1. Run system-view
2. Run mpls lsr-id lsr-id
– LSR IDs must be set before other MPLS commands are run.
– No default LSR ID is available.
– Using the IP address of a loopback interface as the LSR ID is
recommended for an LSR.
3. (Optional) Run mpls
MPLS is enabled, and the MPLS view is displayed.
SR-MPLS uses the MPLS forwarding plane, so MPLS needs to be enabled.
However, the MPLS capability on the interface is automatically enabled when
one of the following conditions is met, and there is no need to configure this
step.
– MPLS is enabled on the interface.
– Segment Routing is enabled for IGP, and IGP is enabled on the interface.
– The static adjacency label of the corresponding interface is configured in
the Segment Routing view.
4. Run commit
5. Run quit
Step 2 Enable SR globally.
2. (Optional) Run local-block begin-value end-value [ ignore-conflict ]
An SRLB label range is configured.
If the system displays a message indicating that the SRLB is used, run the
display segment-routing local-block command to view the SRLB ranges that
can be set. Alternatively, delete unwanted configurations related to the used
label to release the label space.
When the ignore-conflict parameter is specified in the local-block command,
if a label conflict occurs, the configuration is forcibly delivered but does not
occupy label resources. This function is mainly used for pre-deployment, and
the configuration takes effect after the device is restarted.
3. Run commit

(2020-10-09)
4. Run quit
Step 3 Configure IGP SR.
In scenarios where SR-MPLS TE Policies need to be manually configured, you are

advised to use manually configured adjacency SIDs. In scenarios where a controller
dynamically delivers SR-MPLS TE Policies, you are advised to preferentially use
manually configured adjacency SIDs. However, you can also use IGP to
dynamically generate adjacency SIDs.
● If the IGP is IS-IS, configure IGP SR by referring to 1.2.8.3 Configuring Basic

SR-MPLS TE Functions.
● If the IGP is OSPF, configure IGP SR by referring to 1.2.9.3 Configuring Basic
----End
1.2.32.2 Configuring an SR-MPLS TE Policy

Context
SR-MPLS TE Policies are used to direct traffic to traverse an SR-MPLS TE network.
Each SR-MPLS TE Policy can have multiple candidate paths with different
preferences. The valid candidate path with the highest preference is selected as
the primary path of the SR-MPLS TE Policy, and the valid candidate path with the
second highest preference as the hot-standby path.
Procedure
● Configure a segment list.
a. Run system-view

SR is enabled globally and the Segment Routing view is displayed.

c. Run segment-list (Segment Routing view) list-name
A segment list is created for SR-MPLS TE candidate paths and the

segment list view is displayed.
d. Run index index sid label label
A SID (next-hop label) is configured for the segment list.

e. Run commit

● Configure an SR-MPLS TE Policy.
a. Run system-view

(2020-10-09)

c. (Optional) Run sr-te-policy bgp-ls enable
The SR-MPLS TE Policy is enabled to report information to BGP-LS.
After the sr-te-policy bgp-ls enable command is run, the system sends
the path information to BGP-LS with the candidate paths of the SR-MPLS
TE Policy as the granularity.
d. Run sr-te policy policy-name [ endpoint ipv4-address color color-value ]
An SR-MPLS TE Policy is created, the endpoint and color value are

configured for the SR-MPLS TE Policy, and the SR-MPLS TE Policy view is
displayed.
e. (Optional) Run binding-sid label-value
A binding SID is configured for the SR-MPLS TE Policy.
The value of label-value needs to be within the scope defined by the

local-block begin-value end-value command.
f. (Optional) Run mtu mtu
An MTU is configured for the SR-MPLS TE Policy.

g. (Optional) Run diffserv-mode { pipe service-class service-color |
uniform }
A DiffServ mode is configured for the SR-MPLS TE Policy to implement

end-to-end QoS guarantee.
h. Run candidate-path preference preference
A candidate path and its preference are configured for the SR-MPLS TE
Policy.
Each SR-MPLS TE Policy supports multiple candidate paths. A larger

preference value indicates a higher preference. The candidate path with
the highest preference takes effect.
i. Run segment-list (candidate path view) list-name
The segment list of the candidate path is referenced.
The segment list must have been created using the segment-list
(Segment Routing view) command.
j. Run commit
----End
1.2.32.3 Configuring a BGP Extended Community

This section describes how to add a BGP extended community, that is, the Color
Extended Community, to a route through a route-policy, enabling the route to be
recursed to an SR-MPLS TE Policy based on the color value and next-hop address
in the route.

(2020-10-09)
Context
policy.
Procedure
Step 1 Configure a route-policy.
1. Run system-view
2. Run route-policy route-policy-name { deny | permit } node node
A route-policy node is created and the route-policy view is displayed.
3. (Optional) Configure an if-match clause as a route-policy filter criterion. You
can add or modify the Color Extended Community only for a route-policy that
meets the filter criterion.
For details about the configuration, see (Optional) Configuring an if-match
Clause.
4. Run apply extcommunity color color
The Color extended community is configured.
5. Run commit
Step 2 Apply the route-policy.
● Apply the route-policy to a BGP IPv4 unicast peer.
a. Run system-view
b. Run bgp as-number
c. Run peer { ipv4-address | group-name } as-number { as-number-plain |
as-number-dot }
d. Run ipv4-family unicast
The IPv4 unicast address family view is displayed.
e. Run peer { ipv4-address | group-name } route-policy route-policy-name
{ import | export }
A BGP import or export route-policy is configured.
f. Run commit
● Apply the route-policy to a BGP4+ 6PE peer.
a. Run system-view

(2020-10-09)

as-number-dot }
A BGP4+ 6PE peer is created.
{ import | export }
A BGP4+ 6PE import or export route-policy is configured.
f. Run commit
● Apply the route-policy to a BGP VPNv4 peer.
a. Run system-view
as-number-dot }
d. Run ipv4-family vpnv4
The BGP VPNv4 address family view is displayed.
e. Run peer { ipv4-address | group-name } enable
The BGP VPNv4 peer relationship is enabled.
f. Run peer { ipv4-address | group-name } route-policy route-policy-name
{ import | export }
g. Run commit
a. Run system-view
as-number-dot }

(2020-10-09)

{ import | export }
g. Run commit
● Apply the route-policy to a BGP EVPN peer.
a. Run system-view
c. Run l2vpn-family evpn
The BGP EVPN address family view is displayed.
d. Run peer { ipv4-address | group-name } enable
The BGP EVPN peer relationship is enabled.
{ import | export }
A BGP EVPN import or export route-policy is configured.
f. Run commit
● Apply the route-policy to a VPN instance IPv4 address family.
a. Run system-view
b. Run ip vpn-instance vpn-instance-name
c. Run ipv4-family
The VPN instance IPv4 address family view is displayed.
d. Run import route-policy policy-name
An import route-policy is configured for the VPN instance IPv4 address
family.
e. Run export route-policy policy-name
An export route-policy is configured for the VPN instance IPv4 address
family.
f. Run commit
a. Run system-view
c. Run ipv6-family

(2020-10-09)

family.
family.
f. Run commit
----End
1.2.32.4 Configuring Traffic Steering

This section describes how to configure traffic steering to recurse a route to an SR-
MPLS TE Policy so that traffic can be forwarded through the path specified by the
SR-MPLS TE Policy.
Usage Scenario
After an SR-MPLS TE Policy is configured, traffic needs to be steered into the
policy for forwarding. This process is called traffic steering. Currently, SR-MPLS TE
Policies can be used for various routes and services, such as BGP and static routes
as well as BGP4+ 6PE, BGP L3VPN, and EVPN services. This section describes how
to use tunnel policies to recurse services to SR-MPLS TE Policies.
Before configuring traffic steering, complete the following tasks:
● Configure a BGP route, static route, BGP4+ 6PE service, BGP L3VPN service,
BGP L3VPNv6 service, or EVPN service correctly.
● Configure an IP prefix list and a tunnel policy if you want to restrict the route
to be recursed to the specified SR-MPLS TE Policy.
Procedure
Use either of the following procedures based on the traffic steering mode you
select:
● Color-based traffic steering
a. Run system-view
d. Run tunnel select-seq sr-te-policy load-balance-number load-balance-
number unmix

(2020-10-09)
are configured.
e. Run commit
● DSCP-based traffic steering
a. Run system-view
c. Run sr-te-policy group group-value
An SR-MPLS TE Policy group is created and the SR-MPLS TE Policy group
view is displayed.
d. Run endpoint ipv4-address
An endpoint is configured for the SR-MPLS TE Policy group.
e. Run color color-value match dscp { ipv4 | ipv6 } { { dscp-value1 [ to
dscp-value2 ] } &<1-10> | default }
Mappings between the color values of SR-MPLS TE Policies in an SR-
MPLS TE Policy group and the DSCP values of packets to be steered into
the SR-MPLS TE Policies are configured.
Each SR-MPLS TE Policy in the SR-MPLS TE Policy group has its own color
attribute. To configure mappings between the color values of SR-MPLS TE
Policies in an SR-MPLS TE Policy group and the DSCP values of packets to
be steered into the SR-MPLS TE Policies, run the color match dscp
command. In this way, DSCP values, color values, and SR-MPLS TE
Policies are associated within the SR-MPLS TE Policy group. Based on the
association, packets with the specified DSCP values can be steered into
SR-MPLS TE Policies with the mapping color values.
When using the color match dscp command, pay attention to the
following points:
i. The mappings between color and DSCP values can be separately
configured for an IPv4 or IPv6 address family. However, in the same
IPv4 or IPv6 address family, each DSCP value can be associated with
only one SR-MPLS TE Policy. Only up SR-MPLS TE Policies can be
associated with DSCP values.
ii. You can run the color color-value match dscp { ipv4 | ipv6 } default
command to specify a default SR-MPLS TE Policy for an IPv4 or IPv6
address family. When a DSCP value is not associated with any SR-
MPLS TE Policy in an SR-MPLS TE Policy group, the packets with this
DSCP value are forwarded through the default SR-MPLS TE Policy. In
an SR-MPLS TE Policy group, only one default SR-MPLS TE Policy can
be specified for an IPv4 or IPv6 address family.
iii. In scenarios where no default SR-MPLS TE Policy is specified for an
IPv4 or IPv6 address family in an SR-MPLS TE Policy group:
1) If the mappings between color and DSCP values are configured
in the group and only some of the DSCP values are associated
with SR-MPLS TE Policies, the packets with DSCP values that are
not associated with SR-MPLS TE Policies are forwarded through

(2020-10-09)
the SR-MPLS TE Policy associated with the smallest DSCP value

in the address family.
2) If no DSCP value is associated with an SR-MPLS TE Policy in the
group, for example, the mappings between color and DSCP
values are not configured or DSCP values are not successfully
associated with SR-MPLS TE Policies, the default SR-MPLS TE
Policy specified for the other type of address family (IPv4 or
IPv6) is used to forward packets. If no default SR-MPLS TE Policy
is specified for the other type of address family, packets are
forwarded through the SR-MPLS TE Policy associated with the
smallest DSCP value in the local address family.
f. Run quit
Return to the SR view.
g. Run quit
h. Run tunnel-policy policy-name
i. (Optional) Run description description-information
j. Run tunnel binding destination dest-ip-address sr-te-policy group sr-
te-policy-group-id [ ignore-destination-check ] [ down-switch ]
A tunnel binding policy is configured to bind the destination IP address
and SR-MPLS TE Policy group.
The ignore-destination-check keyword is used to disable the function to
check the consistency between the destination IP address specified using
destination dest-ip-address and the endpoint of the corresponding SR-
MPLS TE Policy.
k. Run commit
Step 2 Configure a route or service to be recursed to an SR-MPLS TE Policy.
● Configure a non-labeled public BGP route to be recursed to an SR-MPLS TE
Policy.
a. Run system-view
b. Run route recursive-lookup tunnel [ ip-prefix ip-prefix-name ]
The function to recurse a non-labeled public BGP route to an SR-MPLS TE
Policy is enabled.
c. Run commit
● Configure a static route to be recursed to an SR-MPLS TE Policy.
For details about how to configure a static route, see Configuring IPv4 Static
Routes.

(2020-10-09)
a. Run system-view
b. Run ip route-static recursive-lookup tunnel [ ip-prefix ip-prefix-name ]
The function to recurse a static route to an SR-MPLS TE Policy for MPLS
c. Run commit
● Configure a BGP L3VPN service to be recursed to an SR-MPLS TE Policy.
For details about how to configure a BGP L3VPN service, see Configuring a
Basic BGP/MPLS IP VPN.
a. Run system-view
c. Run ipv4-family
d. Run tnl-policy policy-name
A tunnel policy is applied to the VPN instance IPv4 address family.
e. (Optional) Run default-color color-value
The default color used by the L3VPN service to recurse to the SR-MPLS TE
Policy tunnel is set.
After a remote VPN route is leaked to the local VPN instance, if the route
does not carry the color extended community attribute, the default color
value is used for SR-MPLS TE Policy recursion.
f. Run commit
● Configure a BGP L3VPNv6 service to be recursed to an SR-MPLS TE Policy.
For details about how to configure a BGP L3VPNv6 service, see Configuring a
Basic BGP/MPLS IPv6 VPN.
a. Run system-view
c. Run ipv6-family
The default color used by the L3VPNv6 service to recurse to the SR-MPLS
TE Policy tunnel is set.

(2020-10-09)
value is used for SR-MPLS TE Policy recursion
f. Run commit
● Configure a BGP4+ 6PE service to be recursed to an SR-MPLS TE Policy.
BGP4+ 6PE.
a. Run system-view
b. Run bgp { as-number-plain | as-number-dot }
c. Run ipv6-family unicast
d. Run peer ipv4-address enable
A 6PE peer is enabled.
e. Run peer ipv4-address tnl-policy tnl-policy-name
A tunnel policy is applied to the 6PE peer.
f. Run commit
● Configure an EVPN service to be recursed to an SR-MPLS TE Policy.
For details about how to configure an EVPN service, see 3.2.5 Configuring
BD-EVPN Functions.
steps:
a. Run system-view
c. Run ipv4-family or ipv6-family
The VPN instance IPv4 or IPv6 address family view is displayed.
d. Run tnl-policy policy-name evpn
A tunnel policy is applied to the EVPN L3VPN instance.
e. (Optional) Run default-color color-value evpn
The default color used by the EVPN L3VPN service to recurse to the SR-
MPLS TE Policy tunnel is set.
After a remote EVPN route is leaked to the local VPN instance, if the
route does not carry the color extended community attribute, the default
color value is used for SR-MPLS TE Policy recursion.
f. Run commit

(2020-10-09)
a. Run system-view
b. Run evpn vpn-instance vpn-instance-name bd-mode
A tunnel policy is applied to the BD EVPN instance.
d. (Optional) Run default-color color-value
The default color used by the EVPN service to recurse to the SR-MPLS TE
After a remote EVPN route is leaked to the local EVPN instance, if the
e. Run commit
a. Run system-view
b. Run evpn vpn-instance vpn-instance-name vpws
The view of the EVPN instance that works in EVPN VPWS mode is
displayed.
A tunnel policy is applied to the EVPN instance that works in EVPN VPWS
mode.
Policy is set.
e. Run commit
steps:
a. Run system-view
b. Run evpn vpn-instance vpn-instance-name
A tunnel policy is applied to the basic EVPN instance.
d. Run commit
----End

(2020-10-09)
1.2.32.5 Verifying the SR-MPLS TE Policy Configuration

After configuring SR-MPLS TE Policies, verify the configuration.
Prerequisites
SR-MPLS TE Policies have been configured.
Procedure
Step 1 Run the display sr-te policy [ endpoint ipv4-address color color-value | policy-
name name-value ] command to check SR-MPLS TE Policy details.
Step 2 Run the display sr-te policy statistics command to check SR-MPLS TE Policy
statistics.
Step 3 Run the display sr-te policy status { endpoint ipv4-address color color-value |
policy-name name-value } command to check SR-MPLS TE Policy status to
determine the reason why a specified SR-MPLS TE Policy cannot go up.
Step 4 Run the display sr-te policy last-down-reason [ endpoint ipv4-address color
color-value | policy-name name-value ] command to check records about events
where SR-MPLS TE Policies or segment lists in SR-MPLS TE Policies go down.
Step 5 Run the display ip vpn-instance vpn-instance-name tunnel-info nexthop
nexthopIpv4Addr command to display information about the iterations of the
routes that match the nexthop under each address family in the current VPN
instance.
Step 6 Run the display evpn vpn-instance [ name vpn-instance-name ] tunnel-info
command to displays information about the tunnel associated with the EVPN
instance.
Step 7 Run the display evpn vpn-instance name vpn-instance-name tunnel-info
nexthop nexthopIpv4Addr command to display information about a tunnel
associated with an EVPN with a specified next-hop address.
----End
1.2.33 Configuring an SR-MPLS TE Policy (Dynamic Delivery

by a Controller)
Usage Scenario
An SR-MPLS TE Policy can either be manually configured on a forwarder through
CLI or NETCONF, or be delivered to a forwarder after being dynamically generated
by a protocol, such as BGP, on a controller. The dynamic mode facilitates network
deployment.
The candidate paths in an SR-MPLS TE Policy are identified using <Protocol-Origin,
originator, discriminator>. If SR-MPLS TE Policies generated in both modes exist,
the forwarder selects an SR-MPLS TE Policy based on the following rules in
descending order:

(2020-10-09)
● Protocol-Origin: The default value of Protocol-Origin is 20 for a BGP-delivered

SR-MPLS TE Policy and is 30 for a manually configured SR-MPLS TE Policy. A
larger value indicates a higher preference.
● <ASN, node-address> tuple: originator of an SR-MPLS TE Policy's primary
path. ASN indicates an AS number, and node-address indicates the address of
the node where the SR-MPLS TE Policy is generated.
– The ASN and node-address values of a manually configured SR-MPLS TE
Policy are fixed at 0 and 0.0.0.0, respectively.
– For an SR-MPLS TE Policy delivered by a controller through BGP, the ASN
and node-address values are as follows:
i. If a BGP SR-MPLS TE Policy peer relationship is established between
the headend and controller, the ASN and node-address values are
the AS number of the controller and the BGP router ID, respectively.
ii. If the headend receives an SR-MPLS TE Policy through a multi-
segment EBGP peer relationship, the ASN and node-address values
are the AS number and BGP router ID of the original EBGP peer,
respectively.
iii. If the controller sends an SR-MPLS TE Policy to a reflector and the
headend receives the SR-MPLS TE Policy from the reflector through
the IBGP peer relationship, the ASN and node-address values are the
AS number and BGP originator ID of the controller, respectively.
For both ASN and node-address, a smaller value indicates a higher preference.
● Distinguisher: A larger value indicates a higher preference. For a manually
configured SR-MPLS TE Policy, the value of Distinguisher is the same as the
preference value.
The process for a controller to dynamically generate and deliver an SR-MPLS TE

Policy to a forwarder is as follows:

2. The controller and headend forwarder establish an IPv4 SR-MPLS TE Policy
address family-specific BGP peer relationship.
Before configuring an SR-MPLS TE Policy, complete the following tasks:
● Configure an IGP to ensure that all nodes can communicate with each other
at the network layer.
● Configure a routing protocol between the controller and forwarder to ensure
that they can communicate with each other.
1.2.33.1 Configuring IGP SR

This section describes how to configure IGP SR.

(2020-10-09)
Context
An SR-MPLS TE Policy may contain multiple candidate paths that are defined
using segment lists. Because adjacency and node SIDs are required for SR-MPLS TE
Policy configuration, you need to configure the IGP SR function. Node SIDs need
to be configured manually, whereas adjacency SIDs can either be generated
dynamically by an IGP or be configured manually.
● In scenarios where SR-MPLS TE Policies are configured manually, if dynamic
adjacency SIDs are used, the adjacency SIDs may change after an IGP restart.
To keep the SR-MPLS TE Policies up, you must adjust them manually. The
adjustment workload is heavy if a large number of SR-MPLS TE Policies are
configured manually. Therefore, you are advised to configure adjacency SIDs
manually and not to use adjacency SIDs generated dynamically.
● In scenarios where SR-MPLS TE Policies are delivered by a controller
dynamically, you are also advised to configure adjacency SIDs manually.
Although the controller can use BGP-LS to detect adjacency SID changes, the
adjacency SIDs dynamically generated by an IGP change randomly, causing
inconvenience in routine maintenance and troubleshooting.
Procedure
Step 1 Enable MPLS.
1. Run system-view
2. Run mpls lsr-id lsr-id
– LSR IDs must be set before other MPLS commands are run.
– No default LSR ID is available.
– Using the IP address of a loopback interface as the LSR ID is
recommended for an LSR.
3. (Optional) Run mpls
MPLS is enabled, and the MPLS view is displayed.
SR-MPLS uses the MPLS forwarding plane, so MPLS needs to be enabled.
However, the MPLS capability on the interface is automatically enabled when
one of the following conditions is met, and there is no need to configure this
step.
– MPLS is enabled on the interface.
– Segment Routing is enabled for IGP, and IGP is enabled on the interface.
– The static adjacency label of the corresponding interface is configured in
the Segment Routing view.
4. Run commit
5. Run quit

(2020-10-09)
Step 2 Enable SR globally.

2. (Optional) Run local-block begin-value end-value [ ignore-conflict ]
An SRLB label range is configured.
If the system displays a message indicating that the SRLB is used, run the
display segment-routing local-block command to view the SRLB ranges that
can be set. Alternatively, delete unwanted configurations related to the used
label to release the label space.
When the ignore-conflict parameter is specified in the local-block command,
if a label conflict occurs, the configuration is forcibly delivered but does not
occupy label resources. This function is mainly used for pre-deployment, and
the configuration takes effect after the device is restarted.
3. Run commit
4. Run quit
Step 3 Configure IGP SR.
In scenarios where SR-MPLS TE Policies need to be manually configured, you are
advised to use manually configured adjacency SIDs. In scenarios where a controller
dynamically delivers SR-MPLS TE Policies, you are advised to preferentially use
manually configured adjacency SIDs. However, you can also use IGP to
dynamically generate adjacency SIDs.
● If the IGP is IS-IS, configure IGP SR by referring to 1.2.8.3 Configuring Basic
● If the IGP is OSPF, configure IGP SR by referring to 1.2.9.3 Configuring Basic
----End
1.2.33.2 Configuring BGP Peer Relationships Between the Controller and

Forwarder
This section describes how to configure BGP peer relationships between a
controller and a forwarder, so that the controller can deliver SR-MPLS TE Policies
to the forwarder. This improves SR-MPLS TE Policy deployment efficiency.
Context
The process for a controller to dynamically generate and deliver an SR-MPLS TE
Policy to a forwarder is as follows:
2. The controller and headend forwarder establish a BGP peer relationship of the
IPv4 SR-MPLS TE Policy address family.

(2020-10-09)

To implement the preceding operations, you need to establish a BGP-LS peer
relationship and a BGP IPv4 SR-MPLS TE Policy peer relationship between the
controller and the specified forwarder.
Procedure
● Configure a BGP-LS peer relationship.
BGP-LS is used to collect network topology information, making topology
information collection simple and efficient. You must configure a BGP-LS peer
relationship between the controller and forwarder, so that topology
information can be properly reported from the forwarder to the controller.
This example provides the procedure for configuring BGP-LS on the forwarder.
The procedure on the controller is similar to that on the forwarder.
a. Run system-view
c. Run peer { group-name | ipv4-address } as-number { as-number-plain |
as-number-dot }
d. Run link-state-family unicast
BGP-LS is enabled and the BGP-LS address family view is displayed.
e. Run peer { group-name | ipv4-address } enable
A specified BGP-LS peer is enabled.
f. Run commit
● Configure a BGP IPv4 SR-MPLS TE Policy peer relationship.
This example provides the procedure for configuring a BGP IPv4 SR-MPLS TE
Policy peer relationship on the forwarder. The procedure on the controller is
similar to that on the forwarder.
a. Run system-view
c. Run peer { group-name | ipv4-address } as-number { as-number-plain |
as-number-dot }
d. Run ipv4-family sr-policy
The BGP IPv4 SR-MPLS TE Policy address family view is displayed.

(2020-10-09)
e. Run peer { group-name | ipv4-address } enable
The specified BGP IPv4 SR-MPLS TE Policy peer is enabled.

f. Run commit

● (Optional) Enable the SR-MPLS TE policy to report BGP-LS.
a. Run system-view


c. Run sr-te-policy bgp-ls enable
The SR-MPLS TE policy is enabled to report BGP-LS.
After the sr-te-policy bgp-ls enable command is run, the system sends
the path information to the BGP-LS with the granularity of candidate
path of the SR-MPLS TE policy.
----End

Extended Community, to a route through a route-policy, enabling the route to be
recursed to an SR-MPLS TE Policy based on the color value and next-hop address
in the route.
Context
policy.
Procedure
1. Run system-view

A route-policy node is created and the route-policy view is displayed.


Clause.

(2020-10-09)
The Color extended community is configured.

5. Run commit

● Apply the route-policy to a BGP IPv4 unicast peer.
a. Run system-view
as-number-dot }
{ import | export }
f. Run commit
● Apply the route-policy to a BGP4+ 6PE peer.
a. Run system-view
as-number-dot }
A BGP4+ 6PE peer is created.
{ import | export }
A BGP4+ 6PE import or export route-policy is configured.
f. Run commit
a. Run system-view

(2020-10-09)

as-number-dot }
{ import | export }
g. Run commit
a. Run system-view
as-number-dot }
{ import | export }
g. Run commit
a. Run system-view
c. Run l2vpn-family evpn
d. Run peer { ipv4-address | group-name } enable
{ import | export }

(2020-10-09)
f. Run commit
a. Run system-view
c. Run ipv4-family
family.
family.
f. Run commit
a. Run system-view
c. Run ipv6-family
family.
family.
f. Run commit
----End

This section describes how to configure traffic steering to recurse a route to an SR-
MPLS TE Policy so that traffic can be forwarded through the path specified by the
SR-MPLS TE Policy.
Usage Scenario
After an SR-MPLS TE Policy is configured, traffic needs to be steered into the
policy for forwarding. This process is called traffic steering. Currently, SR-MPLS TE

(2020-10-09)
Policies can be used for various routes and services, such as BGP and static routes
as well as BGP4+ 6PE, BGP L3VPN, and EVPN services. This section describes how
to use tunnel policies to recurse services to SR-MPLS TE Policies.
Before configuring traffic steering, complete the following tasks:
● Configure a BGP route, static route, BGP4+ 6PE service, BGP L3VPN service,
BGP L3VPNv6 service, or EVPN service correctly.
● Configure an IP prefix list and a tunnel policy if you want to restrict the route
to be recursed to the specified SR-MPLS TE Policy.
Procedure
Use either of the following procedures based on the traffic steering mode you
select:

a. Run system-view
d. Run tunnel select-seq sr-te-policy load-balance-number load-balance-
number unmix
are configured.
e. Run commit
a. Run system-view
c. Run sr-te-policy group group-value
An SR-MPLS TE Policy group is created and the SR-MPLS TE Policy group
view is displayed.
d. Run endpoint ipv4-address
An endpoint is configured for the SR-MPLS TE Policy group.
e. Run color color-value match dscp { ipv4 | ipv6 } { { dscp-value1 [ to
dscp-value2 ] } &<1-10> | default }

(2020-10-09)
Mappings between the color values of SR-MPLS TE Policies in an SR-

MPLS TE Policy group and the DSCP values of packets to be steered into
the SR-MPLS TE Policies are configured.
Each SR-MPLS TE Policy in the SR-MPLS TE Policy group has its own color
attribute. To configure mappings between the color values of SR-MPLS TE
Policies in an SR-MPLS TE Policy group and the DSCP values of packets to
be steered into the SR-MPLS TE Policies, run the color match dscp
command. In this way, DSCP values, color values, and SR-MPLS TE
Policies are associated within the SR-MPLS TE Policy group. Based on the
association, packets with the specified DSCP values can be steered into
SR-MPLS TE Policies with the mapping color values.
When using the color match dscp command, pay attention to the
following points:
i. The mappings between color and DSCP values can be separately
configured for an IPv4 or IPv6 address family. However, in the same
IPv4 or IPv6 address family, each DSCP value can be associated with
only one SR-MPLS TE Policy. Only up SR-MPLS TE Policies can be
associated with DSCP values.
ii. You can run the color color-value match dscp { ipv4 | ipv6 } default
command to specify a default SR-MPLS TE Policy for an IPv4 or IPv6
address family. When a DSCP value is not associated with any SR-
MPLS TE Policy in an SR-MPLS TE Policy group, the packets with this
DSCP value are forwarded through the default SR-MPLS TE Policy. In
an SR-MPLS TE Policy group, only one default SR-MPLS TE Policy can
be specified for an IPv4 or IPv6 address family.
iii. In scenarios where no default SR-MPLS TE Policy is specified for an
IPv4 or IPv6 address family in an SR-MPLS TE Policy group:
1) If the mappings between color and DSCP values are configured
in the group and only some of the DSCP values are associated
with SR-MPLS TE Policies, the packets with DSCP values that are
not associated with SR-MPLS TE Policies are forwarded through
the SR-MPLS TE Policy associated with the smallest DSCP value
in the address family.
2) If no DSCP value is associated with an SR-MPLS TE Policy in the
group, for example, the mappings between color and DSCP
values are not configured or DSCP values are not successfully
associated with SR-MPLS TE Policies, the default SR-MPLS TE
Policy specified for the other type of address family (IPv4 or
IPv6) is used to forward packets. If no default SR-MPLS TE Policy
is specified for the other type of address family, packets are
forwarded through the SR-MPLS TE Policy associated with the
smallest DSCP value in the local address family.
f. Run quit
g. Run quit
h. Run tunnel-policy policy-name

(2020-10-09)
i. (Optional) Run description description-information

j. Run tunnel binding destination dest-ip-address sr-te-policy group sr-
te-policy-group-id [ ignore-destination-check ] [ down-switch ]
A tunnel binding policy is configured to bind the destination IP address
and SR-MPLS TE Policy group.
The ignore-destination-check keyword is used to disable the function to
check the consistency between the destination IP address specified using
destination dest-ip-address and the endpoint of the corresponding SR-
MPLS TE Policy.
k. Run commit
Step 2 Configure a route or service to be recursed to an SR-MPLS TE Policy.
● Configure a non-labeled public BGP route to be recursed to an SR-MPLS TE
Policy.
a. Run system-view
b. Run route recursive-lookup tunnel [ ip-prefix ip-prefix-name ]
The function to recurse a non-labeled public BGP route to an SR-MPLS TE
Policy is enabled.
c. Run commit
● Configure a static route to be recursed to an SR-MPLS TE Policy.
For details about how to configure a static route, see Configuring IPv4 Static
Routes.
a. Run system-view
b. Run ip route-static recursive-lookup tunnel [ ip-prefix ip-prefix-name ]
The function to recurse a static route to an SR-MPLS TE Policy for MPLS
c. Run commit
● Configure a BGP L3VPN service to be recursed to an SR-MPLS TE Policy.
a. Run system-view

(2020-10-09)
c. Run ipv4-family
The default color used by the L3VPN service to recurse to the SR-MPLS TE
value is used for SR-MPLS TE Policy recursion.
f. Run commit
● Configure a BGP L3VPNv6 service to be recursed to an SR-MPLS TE Policy.
For details about how to configure a BGP L3VPNv6 service, see Configuring a
Basic BGP/MPLS IPv6 VPN.
a. Run system-view
c. Run ipv6-family
The default color used by the L3VPNv6 service to recurse to the SR-MPLS
TE Policy tunnel is set.
value is used for SR-MPLS TE Policy recursion
f. Run commit
● Configure a BGP4+ 6PE service to be recursed to an SR-MPLS TE Policy.
BGP4+ 6PE.
a. Run system-view
c. Run ipv6-family unicast
A 6PE peer is enabled.

(2020-10-09)
e. Run peer ipv4-address tnl-policy tnl-policy-name

A tunnel policy is applied to the 6PE peer.
f. Run commit
● Configure an EVPN service to be recursed to an SR-MPLS TE Policy.
BD-EVPN Functions.
steps:
a. Run system-view
e. (Optional) Run default-color color-value evpn
The default color used by the EVPN L3VPN service to recurse to the SR-
MPLS TE Policy tunnel is set.
After a remote EVPN route is leaked to the local VPN instance, if the
f. Run commit
a. Run system-view
e. Run commit

(2020-10-09)
a. Run system-view
displayed.
mode.
Policy is set.
e. Run commit
steps:
a. Run system-view
d. Run commit
----End
1.2.33.5 Verifying the SR-MPLS TE Policy Configuration

After configuring SR-MPLS TE Policies, verify the configuration.
Prerequisites
SR-MPLS TE Policies have been configured.
Procedure
Step 1 Run the display sr-te policy [ endpoint ipv4-address color color-value | policy-
name name-value ] command to check SR-MPLS TE Policy details.
Step 2 Run the display sr-te policy statistics command to check SR-MPLS TE Policy
statistics.
Step 3 Run the display sr-te policy status { endpoint ipv4-address color color-value |
policy-name name-value } command to check SR-MPLS TE Policy status to
determine the reason why a specified SR-MPLS TE Policy cannot go up.

(2020-10-09)
Step 4 Run the display sr-te policy last-down-reason [ endpoint ipv4-address color
color-value | policy-name name-value ] command to check records about events
where SR-MPLS TE Policies or segment lists in SR-MPLS TE Policies go down.
Step 5 Run the display ip vpn-instance vpn-instance-name tunnel-info nexthop
nexthopIpv4Addr command to display information about the iterations of the
routes that match the nexthop under each address family in the current VPN
instance.
Step 6 Run the display evpn vpn-instance [ name vpn-instance-name ] tunnel-info
command to displays information about the tunnel associated with the EVPN
instance.
Step 7 Run the display evpn vpn-instance name vpn-instance-name tunnel-info
nexthop nexthopIpv4Addr command to display information about a tunnel
associated with an EVPN with a specified next-hop address.
----End
1.2.34 Configuring SBFD for SR-MPLS TE Policy

This section describes how to configure seamless bidirectional forwarding
detection (SBFD) for SR-MPLS TE Policy.
Usage Scenario
SBFD for SR-MPLS TE Policy can quickly detect segment list faults. If all the
segment lists of a candidate path are faulty, SBFD triggers a candidate path
switchover to reduce impacts on services.
Before configuring SBFD for SR-MPLS TE Policy, complete the following tasks:
● Configure an SR-MPLS TE Policy.
● Run the mpls lsr-id lsr-id command to configure an LSR ID and ensure that
the route from the peer end to the local address specified using lsr-id is
reachable.
Procedure
a. Run system-view
b. Run bfd
BFD can be configured only after this function is enabled globally using
the bfd command.
c. Run quit
d. Run sbfd

(2020-10-09)

e. Run quit
f. Run segment-routing
g. Configure SBFD for SR-MPLS TE Policy.
SBFD for SR-MPLS TE Policy supports both global configuration and
single-policy configuration. You can select either of the two modes.
▪ Global configuration
1) Run sr-te-policy seamless-bfd enable
SBFD is enabled for all SR-MPLS TE Policies.
2) (Optional) Run sr-te-policy seamless-bfd { min-rx-interval
receive-interval | min-tx-interval transmit-interval | detect-
multiplier multiplier-value } *
SBFD parameters are set for the SR-MPLS TE Policies.
NOTE
In the SBFD scenario, the min-rx-interval receive-interval parameter

will not take effect.
▪ Single-policy configuration
1) Run sr-te policy policy-name
The SR-MPLS TE Policy view is displayed.
2) Run seamless-bfd { enable | disable }
SBFD is enabled or disabled for the SR-MPLS TE Policy.
3) Run quit
If an SR-MPLS TE Policy has both global configuration and single-policy
configuration, the single-policy configuration takes effect.
h. (Optional) Run sr-te-policy delete-delay delete-delay-value
i. Run commit
● Configure an SBFD reflector.
a. Run system-view
b. Run bfd
the bfd command.
c. Run quit

(2020-10-09)
d. Run sbfd
f. Run commit
----End

After SBFD for SR-MPLS TE Policy is configured, run the display sr-te policy
[ endpoint ipv4-address color color-value | policy-name name-value ] command
to check SBFD status.
1.2.35 Configuring Hot Standby for SR-MPLS TE Policy

This section describes how to configure hot standby (HSB) for SR-MPLS TE Policy.
Usage Scenario
SBFD for SR-MPLS TE Policy can quickly detect segment list faults. If all the
segment lists of the primary path are faulty, SBFD triggers a candidate path HSB
switchover to reduce impacts on services.
Before configuring HSB for SR-MPLS TE Policy, configure one or more SR-MPLS TE
Policies.
Procedure
Step 3 Enable HSB for SR-MPLS TE Policy.
HSB for SR-MPLS TE Policy supports both global configuration and individual
configuration. Select either of the following configuration modes as needed:
● Global configuration
a. Run sr-te-policy backup hot-standby enable
HSB is enabled for all SR-MPLS TE Policies.
● Individual configuration
a. Run sr-te policy policy-name

(2020-10-09)
b. Run backup hot-standby { enable | disable }

HSB is enabled or disabled for a single SR-MPLS TE Policy.
If an SR-MPLS TE Policy has both global configuration and individual

configuration, the individual configuration takes effect.
Step 4 Run commit
----End
1.2.36 Configuring SR-MPLS TE Policy-related Alarm

Thresholds
You can configure SR-MPLS TE Policy-related alarm thresholds, enabling the
device to generate an alarm when the number of SR-MPLS TE Policies or segment
lists reaches the specified threshold. This facilitates O&M.
Context
If the number of SR-MPLS TE Policies or segment lists exceeds the upper limit,
adding new SR-MPLS TE Policies or segment lists may affect existing services. To
prevent this, you can configure alarm thresholds for the number of SR-MPLS TE
Policies and the number of segment lists. In this way, when the number of SR-
MPLS TE Policies or segment lists reaches the specified threshold, an alarm is
generated to notify users to handle the problem.
Procedure
Segment Routing is enabled, and the Segment Routing view is displayed.
Step 3 Run sr-te-policy segment-list-number threshold-alarm upper-limit

upperLimitValue lower-limit lowerLimitValue
An alarm threshold is configured for the number of segment lists.
Step 4 Run sr-te-policy policy-number threshold-alarm upper-limit upperLimitValue

lower-limit lowerLimitValue
An alarm threshold is configured for the number of SR-MPLS TE Policies.
Step 5 Run commit
----End

(2020-10-09)
1.2.37 Configuring SR-MPLS TE Policy Traffic Statistics

Collection
This section describes how to configure SR-MPLS TE Policy traffic statistics
collection.
Context
Traffic statistics collection for an SR-MPLS TE Policy helps you collect statistics
about traffic forwarded through the SR-MPLS TE Policy.
This function supports both global configuration and individual configuration. If
global configuration and individual configuration both exist, the individual
configuration takes effect.
Perform the following steps on the router:
Procedure
a. Run system-view
c. Run sr-te-policy traffic-statistics enable
Traffic statistics collection is enabled for all SR-MPLS TE Policies.
d. Run commit
a. Run system-view
c. Run sr-te policy policy-name
d. Run traffic-statistics (SR-MPLS TE Policy view) { enable | disable }
Traffic statistics collection is enabled for a specified SR-MPLS TE Policy.
e. Run commit
----End

After configuring SR-MPLS TE Policy traffic statistics collection, run the display sr-
te policy traffic-statistics [ endpoint ipv4-address color color-value | policy-

(2020-10-09)
name name-value | binding-sid binding-sid ] command to check collected SR-

MPLS TE Policy traffic statistics.
Follow-up Procedure
To clear existing SR Policy traffic statistics, run the reset sr-te policy traffic-
statistics [ endpoint ipv4-address color color-value | policy-name name-value |
binding-sid binding-sid ] command.
1.2.38 Redirecting a Public IPv4 BGP FlowSpec Route to an SR-

MPLS TE Policy
Redirecting a public IPv4 BGP FlowSpec route to an SR-MPLS TE Policy helps
implement more accurate traffic filtering.
Context
In traditional BGP FlowSpec-based traffic optimization, traffic transmitted over
paths with the same source and destination nodes can be redirected to only one
path, which does not achieve accurate traffic steering. With the function to
redirect a public IPv4 BGP FlowSpec route to an SR-MPLS TE Policy, a device can
redirect traffic transmitted over paths with the same source and destination nodes
to different SR-MPLS TE Policies.
1.2.38.1 Redirecting a Public IPv4 BGP FlowSpec Route to an SR-MPLS TE

Policy (Manual Configuration)
Manually generate a BGP FlowSpec route and configure redirection rules to
redirect the route to an SR-MPLS TE Policy.
Usage Scenario
If no controller is deployed, perform the following operations to manually redirect
a public IPv4 BGP Flow Specification route to an SR-MPLS TE Policy:
1. Manually configure an SR-MPLS TE Policy.

2. Manually configure a BGP FlowSpec route and define redirection rules. BGP
FlowSpec route redirection is based on <Redirection IP address, Color>. If the
redirection IP address and color attributes of a BGP FlowSpec route match the
endpoint and color attributes of an SR-MPLS TE Policy, the route can be
successfully redirected to the SR-MPLS TE Policy.
3. To enable the device to advertise the BGP FlowSpec route to another device,
configure a BGP peer relationship in the BGP-Flow address family.
Prerequisites
Before redirecting a public IPv4 BGP FlowSpec route to an SR-MPLS TE Policy,
● Configuring a BGP Peer

● 1.2.32 Configuring an SR-MPLS TE Policy (Manual Configuration)

(2020-10-09)
Procedure
● Configure a BGP FlowSpec route.
a. Run system-view
b. Run flow-route flowroute-name
A static BGP FlowSpec route is created, and the Flow-Route view is
displayed.
c. (Optional) Configure if-match clauses. For details, see Configuring Static
BGP FlowSpec.
d. Run apply redirect ip redirect-ip-rt color colorvalue
The device is enabled to precisely redirect the traffic that matches the if-
match clauses to the SR-MPLS TE Policy.
NOTE
To enable the device to process the redirection next hop attribute that is received
from a peer and configured using the apply redirect ip redirect-ip-rt color
colorvalue command, run the peer redirect ip command.
e. Run commit
● (Optional) Configure a BGP peer relationship in the BGP-Flow address family.
Establish a BGP FlowSpec peer relationship between the ingress of the SR-
MPLS TE Policy and the device on which the BGP FlowSpec route is manually
generated. If the BGP FlowSpec route is manually generated on the ingress of
the SR-MPLS TE Policy, skip this step.
a. Run system-view


c. Run ipv4-family flow
The BGP-Flow address family view is displayed.

The BGP FlowSpec peer relationship is enabled.
After the BGP FlowSpec peer relationship is established in the BGP-Flow

address family view, the manually generated BGP FlowSpec route is
automatically imported to the BGP-Flow routing table and then sent to
each peer.
e. Run peer ipv4-address redirect ip
The device is enabled to process the BGP FlowSpec route's redirection

next hop attribute that is received from a peer and configured using the
apply redirect ip command.
f. Run commit

(2020-10-09)
----End

After configuring the redirection, verify the configuration.
● Run the display bgp flow peer [ [ ipv4-address ] verbose ] command to

check information about BGP FlowSpec peers.
● Run the display bgp flow routing-table command to check BGP FlowSpec
routing information.
● Run the display flowspec statistics reindex command to check statistics
about traffic transmitted over BGP FlowSpec routes.
1.2.38.2 Redirecting a Public IPv4 BGP FlowSpec Route to an SR-MPLS TE

Policy (Dynamic Delivery by a Controller)
After a controller dynamically delivers a BGP FlowSpec route and an SR-MPLS TE
Policy to a forwarder, the forwarder needs to redirect the BGP FlowSpec route to
the SR-MPLS TE Policy.
Usage Scenario
If a controller is deployed, the controller can be used to deliver a public IPv4 BGP
FlowSpec route and an SR-MPLS TE Policy. The procedure involved in redirecting
the public IPv4 BGP FlowSpec route to the SR-MPLS TE Policy is as follows:
1. Establish a BGP-LS peer relationship between the controller and forwarder,

enabling the controller to collect network information, such as topology and
label information, through BGP-LS.
2. Establish a BGP IPv4 SR-MPLS TE Policy peer relationship between the
controller and forwarder, enabling the controller to deliver a dynamically
computed SR-MPLS TE Policy path to the ingress through the peer
relationship. After receiving the SR-MPLS TE Policy, the ingress generates
corresponding entries.
3. Establish a BGP-Flow address family peer relationship between the controller
and forwarder, enabling the controller to dynamically deliver a BGP FlowSpec
route.
The following procedure focuses on forwarder configurations.
Prerequisites
Before redirecting a public IPv4 BGP FlowSpec route to an SR-MPLS TE Policy,
● Configuring a BGP Peer

● 1.2.33 Configuring an SR-MPLS TE Policy (Dynamic Delivery by a
Controller)

(2020-10-09)
Procedure
Step 1 Establish BGP-LS and BGP IPv4 SR-MPLS TE Policy peer relationships. For details,
see 1.2.33.2 Configuring BGP Peer Relationships Between the Controller and
Forwarder.
Step 2 Establish a BGP-Flow address family peer relationship.
1. Run system-view
2. Run bgp as-number
3. Run ipv4-family flow
4. Run peer ipv4-address enable
address family view, the manually created BGP FlowSpec route is
automatically imported to the BGP-Flow routing table and then sent to each
BGP FlowSpec peer.
5. Run peer ipv4-address redirect ip
The device is enabled to process the BGP FlowSpec route's redirection next
hop attribute that is received from a peer and configured using the apply
redirect ip command.
6. Run redirect ip recursive-lookup tunnel [ tunnel-selector tunnel-selector-
name ]
The device is enabled to recurse the received routes that carry the redirection
next hop attribute to tunnels.
7. Run commit
----End

1.2.39 Configuring Examples for SR-MPLS BE

This section provides several configuration examples of SR-MPLS BE.

(2020-10-09)
1.2.39.1 Example for Configuring L3VPN over IS-IS SR-MPLS BE

L3VPN services are configured to allow users within the same VPN to securely
access each other.
Networking Requirements
On the network shown in Figure 1-118:
● CE1 and CE2 belong to vpna.
● The VPN-target attribute of vpna is 111:1.
L3VPN services recurse to an IS-IS SR-MPLS BE tunnel to allow users within the
same VPN to securely access each other. Since multiple links exist between PEs on
a public network, traffic needs to be balanced on the public network.
Figure 1-118 L3VPN recursive to an IS-IS SR-MPLS BE tunnel

NOTE
Interfaces 1 through 3 in this example represent GE 1/0/0, GE 2/0/0, and GE 3/0/0, respectively.
Precautions
When configuring L3VPN recursion to an IS-IS SR-MPLS BE tunnel, note the
following:
After an interface that connects a PE to a CE is bound to a VPN instance, Layer 3

features on this interface such as the IP address and routing protocol must be
deleted and then reconfigured if required.
Configuration Roadmap
The configuration roadmap is as follows:

(2020-10-09)
1. Enable IS-IS on the backbone network to ensure that PEs interwork with each
other.
2. Configure MPLS and Segment Routing on the backbone network and
establish SR LSPs. Enable TI-LFA FRR.
3. Configure IPv4 address family VPN instances on the PEs and bind each
interface that connects a PE to a CE to a VPN instance.
4. Enable Multi-protocol Extensions for Interior Border Gateway Protocol (MP-
IBGP) on PEs to exchange VPN routing information.
5. Configure External Border Gateway Protocol (EBGP) on the CEs and PEs to
exchange VPN routing information.
Data Preparation
To complete the configuration, you need the following data:
● MPLS LSR IDs of the PEs and P
● vpna's VPN-target and RD
● SRGB ranges on the PEs and P
Procedure
Step 1 Configure IP addresses for interfaces.
# Configure PE1.
<HUAWEI> system-view
[~HUAWEI] sysname PE1
[*HUAWEI] commit
[~PE1] interface loopback 1
[*PE1-LoopBack1] ip address 1.1.1.9 32
[*PE1-LoopBack1] quit
[*PE1] interface gigabitethernet1/0/0
[*PE1-GigabitEthernet1/0/0] ip address 172.18.1.1 24
[*PE1-GigabitEthernet1/0/0] quit
[*PE1] commit
# Configure P1.
[~HUAWEI] sysname P1
[*HUAWEI] commit
[~P1] interface loopback 1
[*P1-LoopBack1] ip address 2.2.2.9 32
[*P1-LoopBack1] quit
[*P1] interface gigabitethernet1/0/0
[*P1-GigabitEthernet1/0/0] ip address 172.16.1.2 24
[*P1-GigabitEthernet1/0/0] quit
[*P1] commit
# Configure PE2.
[*HUAWEI] commit

(2020-10-09)

[*PE2] commit
# Configure P2.
[*HUAWEI] commit
[*P2] commit
Step 2 Configure an IGP protocol on the MPLS backbone network to implement

connectivity between the PEs and P. IS-IS is used as an IGP protocol in this
example.
# Configure PE1.
[~PE1] isis 1
[*PE1-isis-1] is-level level-1
[*PE1-isis-1] network-entity 10.0000.0000.0001.00
[*PE1-isis-1] quit
[*PE1] interface loopback 1
[*PE1-LoopBack1] isis enable 1
[*PE1-GigabitEthernet1/0/0] isis enable 1
[*PE1] commit
# Configure P1.
[~P1] isis 1
[*P1-isis-1] is-level level-1
[*P1-isis-1] network-entity 10.0000.0000.0002.00
[*P1-isis-1] quit
[*P1] interface loopback 1
[*P1-LoopBack1] isis enable 1
[*P1-GigabitEthernet1/0/0] isis enable 1
[*P1] commit
# Configure PE2.
[~PE2] isis 1

(2020-10-09)
[*PE2-isis-1] quit
[*PE2] commit
# Configure P2.
[~P2] isis 1
[*P2-isis-1] quit
[*P2] commit
Step 3 Configure the basic MPLS functions on the backbone network.
# Configure PE1.
[~PE1] mpls lsr-id 1.1.1.9
[*PE1] mpls
[*PE1-mpls] commit
[~PE1-mpls] quit
# Configure P1.
[~P1] mpls lsr-id 2.2.2.9
[*P1] mpls
[*P1-mpls] commit
[~P1-mpls] quit
# Configure PE2.
[*PE2] mpls
[*PE2-mpls] commit
[~PE2-mpls] quit
# Configure P2.
[*P2] mpls
[*P2-mpls] commit
[~P2-mpls] quit
Step 4 Configure Segment Routing on the backbone network and enable TI-LFA FRR.
# Configure PE1.
[~PE1] segment-routing
[*PE1-segment-routing] quit
[*PE1] isis 1
[*PE1-isis-1] cost-style wide
[*PE1-isis-1] segment-routing mpls
[*PE1-isis-1] segment-routing global-block 16000 23999

(2020-10-09)
NOTE
The value range of SRGB changes dynamically, depending on the actual situation of the
equipment. Here is an example only.
[*PE1-isis-1] frr
[*PE1-isis-1-frr] loop-free-alternate level-1
[*PE1-isis-1-frr] ti-lfa level-1
[*PE1-isis-1-frr] quit
[*PE1-isis-1] quit
[*PE1-LoopBack1] isis prefix-sid index 10
[*PE1] commit
# Configure P1.
[~P1] segment-routing
[*P1-segment-routing] quit
[*P1] isis 1
[*P1-isis-1] cost-style wide
[*P1-isis-1] segment-routing mpls
[*P1-isis-1] segment-routing global-block 16000 23999
NOTE
[*P1-isis-1] frr
[*P1-isis-1-frr] loop-free-alternate level-1
[*P1-isis-1-frr] ti-lfa level-1
[*P1-isis-1-frr] quit
[*P1-isis-1] quit
[*P1-LoopBack1] isis prefix-sid index 20
[*P1] commit
# Configure PE2.
[*PE2] isis 1
NOTE
[*PE2-isis-1] frr
[*PE2-isis-1] quit
[*PE2] commit
# Configure P2.
[*P2] isis 1

(2020-10-09)
NOTE
[*P2-isis-1] frr
[*P2-isis-1] quit
[*P2] commit
# After the configuration is complete, run the display tunnel-info all command
on each PE. The command output shows that the SR LSPs have been established.
The following example uses the command output on PE1.
[~PE1] display tunnel-info all
Tunnel ID Type Destination Status
----------------------------------------------------------------------------------------
0x000000002900000003 srbe-lsp 4.4.4.9 UP
0x000000002900000004 srbe-lsp 2.2.2.9 UP
0x000000002900000005 srbe-lsp 3.3.3.9 UP
# Use Ping to detect SR LSP connectivity on PE1, for example:

[~PE1] ping lsp segment-routing ip 3.3.3.9 32 version draft2
LSP PING FEC: SEGMENT ROUTING IPV4 PREFIX 3.3.3.9/32 : 100 data bytes, press CTRL_C to break
Reply from 3.3.3.9: bytes=100 Sequence=1 time=12 ms
--- FEC: SEGMENT ROUTING IPV4 PREFIX 3.3.3.9/32 ping statistics ---
5 packet(s) transmitted
5 packet(s) received
0.00% packet loss
round-trip min/avg/max = 5/6/12 ms
Step 5 Set up an MP-IBGP peer relationship between PEs.

# Configure PE1.
[~PE1] bgp 100
[~PE1-bgp] peer 3.3.3.9 as-number 100
[*PE1-bgp] peer 3.3.3.9 connect-interface loopback 1
[*PE1-bgp] ipv4-family vpnv4
[*PE1-bgp-af-vpnv4] peer 3.3.3.9 enable
[*PE1-bgp-af-vpnv4] commit
[~PE1-bgp-af-vpnv4] quit
[~PE1-bgp] quit
# Configure PE2.
[~PE2] bgp 100
[~PE2-bgp] quit
After the configuration is complete, run the display bgp peer or display bgp
vpnv4 all peer command on each PE to check whether a BGP peer relationship

(2020-10-09)
has been established between the PEs. If the Established state is displayed in the
command output, the BGP peer relationship has been established successfully. The
following example uses the command output on PE1.
[~PE1] display bgp peer
BGP local router ID : 1.1.1.9

Local AS number : 100
Total number of peers : 1 Peers in established state : 1
Peer V AS MsgRcvd MsgSent OutQ Up/Down State PrefRcv

3.3.3.9 4 100 2 6 0 00:00:12 Established 0
[~PE1] display bgp vpnv4 all peer


3.3.3.9 4 100 12 18 0 00:09:38 Established 0
Step 6 Configure VPN instances in the IPv4 address family on each PE and connect each
PE to a CE.
# Configure PE1.
[~PE1] ip vpn-instance vpna
[*PE1-vpn-instance-vpna] ipv4-family
[*PE1-vpn-instance-vpna-af-ipv4] route-distinguisher 100:1
[*PE1-vpn-instance-vpna-af-ipv4] vpn-target 111:1 both
[*PE1-vpn-instance-vpna-af-ipv4] quit
[*PE1-vpn-instance-vpna] quit
[*PE1-GigabitEthernet2/0/0] ip binding vpn-instance vpna
[*PE1] commit
# Configure PE2.
[*PE2] commit
# Assign an IP address to each interface on CEs as shown in Figure 1-118. The

detailed configuration procedure is not provided here. For details, see
Configuration Files.
After the configuration is complete, run the display ip vpn-instance verbose
command on the PEs to check VPN instance configurations. Check that each PE
can successfully ping its connected CE.
NOTE
If a PE has multiple interfaces bound to the same VPN instance, you must specify a source
IP addresses by specifying -a source-ip-address in the ping -vpn-instance vpn-instance-
name -a source-ip-address dest-ip-address command to ping the CE connected to the
remote PE. Otherwise, the ping fails.

(2020-10-09)
Step 7 Configure a tunnel policy on each PE to preferentially select an SR LSP.

# Configure PE1.
[~PE1] tunnel-policy p1
[*PE1-tunnel-policy-p1] tunnel select-seq sr-lsp load-balance-number 2
[*PE1-tunnel-policy-p1] quit
[*PE1] commit
[*PE1-vpn-instance-vpna-af-ipv4] tnl-policy p1
[*PE1] commit
# Configure PE2.
[*PE2] commit
[*PE2] commit
Step 8 Set up EBGP peer relationships between PEs and CEs.

# Configure CE1.
[~HUAWEI] sysname CE1
[*HUAWEI] commit
[~CE1] interface loopback 1
[*CE1-LoopBack1] ip address 10.11.1.1 32
[*CE1-LoopBack1] quit
[*CE1] interface gigabitethernet1/0/0
[*CE1-GigabitEthernet1/0/0] ip address 10.1.1.1 24
[*CE1-GigabitEthernet1/0/0] quit
[*CE1] bgp 65410
[*CE1-bgp] peer 10.1.1.2 as-number 100
[*CE1-bgp] network 10.11.1.1 32
[*CE1-bgp] quit
[*CE1] commit
NOTE
The configuration of CE2 is similar to the configuration of CE1, and are not provided here.
For details, see "Configuration Files".
# Configure PE1.
[~PE1] bgp 100
[~PE1-bgp] ipv4-family vpn-instance vpna
[*PE1-bgp-vpna] peer 10.1.1.1 as-number 65410
[*PE1-bgp-vpna] commit
[~PE1-bgp-vpna] quit
[~PE1-bgp] quit
NOTE
The procedure for configuring PE2 is similar to the procedure for configuring PE1, and the
detailed configuration is not provided here. For details, see "Configuration Files".
After the configuration, run the display bgp vpnv4 vpn-instance peer command
on the PEs, and you can view that BGP peer relationships between PEs and CEs
have been established and are in the Established state.

(2020-10-09)
In the following example, the peer relationship between PE1 and CE1 is used.
[~PE1] display bgp vpnv4 vpn-instance vpna peer

VPN-Instance vpna, Router ID 1.1.1.9:


10.1.1.1 4 65410 11 9 0 00:06:37 Established 1
Step 9 Verify the configuration.

# Run the display ip routing-table vpn-instance command on each PE to view
the routes to CEs' loopback interfaces.
In the following, the command output on PE1 is used.
[~PE1] display ip routing-table vpn-instance vpna
Route Flags: R - relay, D - download to fib, T - to vpn-instance, B - black hole route
------------------------------------------------------------------------------
Routing Table: vpna
Destinations : 7 Routes : 7
Destination/Mask Proto Pre Cost Flags NextHop Interface
10.1.1.0/24 Direct 0 0 D 10.1.1.2 GigabitEthernet1/0/0
10.11.1.1/32 EBGP 255 0 RD 10.1.1.1 GigabitEthernet1/0/0
10.22.2.2/32 IBGP 255 0 RD 3.3.3.9 GigabitEthernet1/0/0
IBGP 255 0 RD 3.3.3.9 GigabitEthernet3/0/0
255.255.255.255/32 Direct 0 0 D 127.0.0.1 InLoopBack0
CEs within the same VPN can ping each other. For example, CE1 successfully pings
CE2 at 10.22.2.2.
[~CE1] ping -a 10.11.1.1 10.22.2.2
PING 10.22.2.2: 56 data bytes, press CTRL_C to break
Reply from 10.22.2.2: bytes=56 Sequence=1 ttl=251 time=72 ms
--- 10.22.2.2 ping statistics ---
0.00% packet loss
----End
Configuration Files
● PE1 configuration file
#
sysname PE1
#
ip vpn-instance vpna
ipv4-family
route-distinguisher 100:1
tnl-policy p1
vpn-target 111:1 export-extcommunity
vpn-target 111:1 import-extcommunity
#
mpls lsr-id 1.1.1.9
#

(2020-10-09)
mpls
#
segment-routing
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0001.00
segment-routing mpls
segment-routing global-block 16000 23999
frr
loop-free-alternate level-1
ti-lfa level-1
#
interface GigabitEthernet1/0/0
undo shutdown
ip address 172.18.1.1 255.255.255.0
isis enable 1
#
undo shutdown
ip binding vpn-instance vpna
ip address 10.1.1.2 255.255.255.0
#
undo shutdown
ip address 172.16.1.1 255.255.255.0
isis enable 1
#
interface LoopBack1
ip address 1.1.1.9 255.255.255.255
isis enable 1
isis prefix-sid index 10
#
bgp 100
peer 3.3.3.9 as-number 100
peer 3.3.3.9 connect-interface LoopBack1
#
ipv4-family unicast
undo synchronization
peer 3.3.3.9 enable
#
ipv4-family vpnv4
policy vpn-target
peer 3.3.3.9 enable
#
ipv4-family vpn-instance vpna
#
tunnel-policy p1
tunnel select-seq sr-lsp load-balance-number 2
#
return
● P1 configuration file
#
sysname P1
#
mpls lsr-id 2.2.2.9
#
mpls
#
segment-routing
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0002.00

(2020-10-09)
frr
ti-lfa level-1
#
undo shutdown
ip address 172.16.1.2 255.255.255.0
isis enable 1
#
undo shutdown
ip address 172.17.1.1 255.255.255.0
isis enable 1
#
interface LoopBack1
ip address 2.2.2.9 255.255.255.255
isis enable 1
#
return
#
sysname PE2
#
ipv4-family
tnl-policy p1
#
mpls lsr-id 3.3.3.9
#
mpls
#
segment-routing
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0003.00
frr
ti-lfa level-1
#
undo shutdown
ip address 172.19.1.2 255.255.255.0
isis enable 1
#
undo shutdown
ip address 10.2.1.2 255.255.255.0
#
undo shutdown
ip address 172.17.1.2 255.255.255.0
isis enable 1
#
interface LoopBack1
ip address 3.3.3.9 255.255.255.255
isis enable 1
#
bgp 100

(2020-10-09)

#
ipv4-family unicast
peer 1.1.1.9 enable
#
ipv4-family vpnv4
policy vpn-target
peer 1.1.1.9 enable
#
#
tunnel-policy p1
#
return
#
sysname P2
#
mpls lsr-id 4.4.4.9
#
mpls
#
segment-routing
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0004.00
frr
ti-lfa level-1
#
undo shutdown
ip address 172.18.1.2 255.255.255.0
isis enable 1
#
undo shutdown
ip address 172.19.1.1 255.255.255.0
isis enable 1
#
interface LoopBack1
ip address 4.4.4.9 255.255.255.255
isis enable 1
#
return
● CE1 configuration file
#
sysname CE1
#
undo shutdown
ip address 10.1.1.1 255.255.255.0
#
interface LoopBack1
ip address 10.11.1.1 255.255.255.255
#
bgp 65410
network 10.11.1.1 255.255.255.255
#

(2020-10-09)
ipv4-family unicast
peer 10.1.1.2 enable
#
return

#
sysname CE2
#
undo shutdown
ip address 10.2.1.1 255.255.255.0
#
interface LoopBack1
ip address 10.22.2.2 255.255.255.255
#
bgp 65420
network 10.22.2.2 255.255.255.255
#
ipv4-family unicast
#
return
1.2.39.2 Example for Configuring L3VPN over OSPF SR-MPLS BE

L3VPN services are configured to allow users within the same VPN to securely
access each other.
In Figure 1-119:
● The VPN-target attribute of vpna is 111:1.
L3VPN services recurse to an OSPF SR-MPLS BE tunnel to allow users within the
same VPN to securely access each other. Since multiple links exist between PEs on
a public network, traffic needs to be balanced on the public network.
Figure 1-119 L3VPN recursive to an OSPF SR-MPLS BE tunnel

NOTE

(2020-10-09)
Precautions
When configuring L3VPN recursion to an OSPF SR-MPLS BE tunnel, note the
following:
1. Enable OSPF on the backbone network to ensure that PEs interwork with
each other.
2. Configure MPLS and segment routing on the backbone network and establish
SR LSPs. Enable TI-LFA FRR.
3. Configure IPv4 address family VPN instances on the PEs and bind each
interface that connects a PE to a CE to a VPN instance.
4. Enable Multi-protocol Extensions for Interior Border Gateway Protocol (MP-
IBGP) on PEs to exchange VPN routing information.
5. Configure External Border Gateway Protocol (EBGP) on the CEs and PEs to
exchange VPN routing information.
Data Preparation
● vpna's VPN-target and RD

(2020-10-09)
Procedure
# Configure PE1.
[*HUAWEI] commit
[*PE1] commit
# Configure P1.
[*HUAWEI] commit
[*P1] commit
# Configure PE2.
[*HUAWEI] commit
[*PE2] commit
# Configure P2.
[*HUAWEI] commit
[*P2] commit

(2020-10-09)

connectivity between the PEs and P. OSPF is used as an IGP protocol in this
example.
# Configure PE1.
[~PE1] ospf 1
[*PE1-ospf-1] opaque-capability enable
[*PE1-ospf-1] area 0
[*PE1-ospf-1-area-0.0.0.0] quit
[*PE1-ospf-1] quit
[*PE1-LoopBack1] ospf enable 1 area 0
[*PE1-GigabitEthernet1/0/0] ospf enable 1 area 0
[*PE1] commit
# Configure P1.
[~P1] ospf 1
[*P1-ospf-1] opaque-capability enable
[*P1-ospf-1] area 0
[*P1-ospf-1-area-0.0.0.0] quit
[*P1-ospf-1] quit
[*P1-LoopBack1] ospf enable 1 area 0
[*P1-GigabitEthernet1/0/0] ospf enable 1 area 0
[*P1] commit
# Configure PE2.
[~PE2] ospf 1
[*PE2-ospf-1] quit
[*PE2-LoopBack1] ospf enable 1 area 0
[*PE2] commit
# Configure P2.
[~P2] ospf 1
[*P2-ospf-1] opaque-capability enable
[*P2-ospf-1] area 0
[*P2-ospf-1-area-0.0.0.0] quit
[*P2-ospf-1] quit
[*P2-LoopBack1] ospf enable 1 area 0

(2020-10-09)

[*P2] commit
# Configure PE1.
[*PE1] mpls
[*PE1-mpls] commit
[~PE1-mpls] quit
# Configure P1.
[*P1] mpls
[*P1-mpls] commit
[~P1-mpls] quit
# Configure PE2.
[*PE2] mpls
[*PE2-mpls] commit
[~PE2-mpls] quit
# Configure P2.
[*P2] mpls
[*P2-mpls] commit
[~P2-mpls] quit
Step 4 Configure segment routing on the backbone network and enable TI-LFA FRR.
# Configure PE1.
[*PE1] ospf 1
[*PE1-ospf-1] segment-routing mpls
[*PE1-ospf-1] segment-routing global-block 16000 23999
NOTE
[*PE1-ospf-1] frr
[*PE1-ospf-1-frr] loop-free-alternate
[*PE1-ospf-1-frr] ti-lfa enable
[*PE1-ospf-1-frr] quit
[*PE1-ospf-1] quit
[*PE1-LoopBack1] ospf prefix-sid index 10
[*PE1] commit
# Configure P1.
[*P1] ospf 1
[*P1-ospf-1] segment-routing mpls
[*P1-ospf-1] segment-routing global-block 16000 23999

(2020-10-09)
NOTE
[*P1-ospf-1] frr
[*P1-ospf-1-frr] loop-free-alternate
[*P1-ospf-1-frr] ti-lfa enable
[*P1-ospf-1-frr] quit
[*P1-ospf-1] quit
[*P1-LoopBack1] ospf prefix-sid index 20
[*P1] commit
# Configure PE2.
[*PE2] ospf 1
NOTE
[*PE2-ospf-1] frr
[*PE2-ospf-1-frr] loop-free-alternate
[*PE2-ospf-1-frr] ti-lfa enable
[*PE2-ospf-1-frr] quit
[*PE2-ospf-1] quit
[*PE2-LoopBack1] ospf prefix-sid index 30
[*PE2] commit
# Configure P2.
[*P2] ospf 1
[*P2-ospf-1] segment-routing mpls
[*P2-ospf-1] segment-routing global-block 16000 23999
NOTE
[*P2-ospf-1] frr
[*P2-ospf-1-frr] loop-free-alternate
[*P2-ospf-1-frr] ti-lfa enable
[*P2-ospf-1-frr] quit
[*P2-ospf-1] quit
[*P2-LoopBack1] ospf prefix-sid index 40
[*P2] commit
on each PE. The command output shows that the SR LSPs have been established.
----------------------------------------------------------------------------------------
0x000000002900000003 srbe-lsp 4.4.4.9 UP

(2020-10-09)
0x000000002900000004 srbe-lsp 2.2.2.9 UP

0x000000002900000005 srbe-lsp 3.3.3.9 UP
# Using Ping to detect SR LSP connectivity on PE1, for example:

0.00% packet loss
Step 5 Set up an MP-IBGP peer relationship between PEs.

# Configure PE1.
[~PE1] bgp 100
[~PE1-bgp] quit
# Configure PE2.
[~PE2] bgp 100
[~PE2-bgp] quit


3.3.3.9 4 100 5 5 0 00:00:12 Established 0


3.3.3.9 4 100 12 18 0 00:09:38 Established 1
Step 6 Configure VPN instances in the IPv4 address family on each PE and connect each
PE to a CE.

(2020-10-09)
# Configure PE1.
[*PE1] commit
# Configure PE2.
[*PE2] commit
# Assign an IP address to each interface on CEs as shown in Figure 1-119. The

detailed configuration procedure is not provided here. For details, see
"Configuration Files".
NOTE
If a PE has multiple interfaces bound to the same VPN instance, you must specify a source
IP addresses by specifying -a source-ip-address in the ping -vpn-instance vpn-instance-
name -a source-ip-address dest-ip-address command to ping the CE connected to the
remote PE. Otherwise, the ping fails.
Step 7 Configure a tunnel policy on each PE to preferentially select an SR LSP.

# Configure PE1.
[*PE1] commit
[*PE1] commit
# Configure PE2.
[*PE2] commit

(2020-10-09)
[*PE2] commit
Step 8 Set up EBGP peer relationships between PEs and CEs.
# Configure CE1.
[*HUAWEI] commit
[*CE1] bgp 65410
[*CE1-bgp] network 10.11.1.1 32
[*CE1-bgp] quit
[*CE1] commit
NOTE
The configuration of CE2 is similar to the configuration of CE1, and are not provided here.
For details, see "Configuration Files".
# Configure PE1.
[~PE1] bgp 100
[~PE1-bgp] quit
NOTE
The procedure for configuring PE2 is similar to the procedure for configuring PE1, and the
detailed configuration is not provided here. For details, see "Configuration Files".
After the configuration, run the display bgp vpnv4 vpn-instance peer command
on the PEs, and you can view that BGP peer relationships between PEs and CEs
have been established and are in the Established state.
In the following example, the peer relationship between PE1 and CE1 is used.



10.1.1.1 4 65410 19 18 0 00:12:39 Established 1
# Run the display ip routing-table vpn-instance command on each PE to view

the routes to CEs' loopback interfaces.
In the following, the command output on PE1 is used.


(2020-10-09)

------------------------------------------------------------------------------
Routing Table: vpna
IBGP 255 0 RD 3.3.3.9 GigabitEthernet3/0/0
CEs within the same VPN can ping each other. For example, CE1 successfully pings
CE2 at 10.22.2.2.
[~CE1] ping -a 10.11.1.1 10.22.2.2

0.00% packet loss
----End
Configuration Files
#
sysname PE1
#
ipv4-family
tnl-policy p1
#
mpls lsr-id 1.1.1.9
#
mpls
#
segment-routing
#
undo shutdown
ip address 172.18.1.1 255.255.255.0
ospf enable 1 area 0.0.0.0
#
undo shutdown
ip address 10.1.1.2 255.255.255.0
#
undo shutdown
ip address 172.16.1.1 255.255.255.0
#
interface LoopBack1
ip address 1.1.1.9 255.255.255.255

(2020-10-09)

ospf prefix-sid index 10
#
bgp 100
#
ipv4-family unicast
peer 3.3.3.9 enable
#
ipv4-family vpnv4
policy vpn-target
peer 3.3.3.9 enable
#
#
ospf 1
opaque-capability enable
frr
loop-free-alternate
ti-lfa enable
area 0.0.0.0
#
tunnel-policy p1
#
return
#
sysname P1
#
mpls lsr-id 2.2.2.9
#
mpls
#
segment-routing
#
undo shutdown
ip address 172.16.1.2 255.255.255.0
#
undo shutdown
ip address 172.17.1.1 255.255.255.0
#
interface LoopBack1
ip address 2.2.2.9 255.255.255.255
#
ospf 1
frr
loop-free-alternate
ti-lfa enable
area 0.0.0.0
#
return

(2020-10-09)
#
sysname PE2
#
ipv4-family
tnl-policy p1
#
mpls lsr-id 3.3.3.9
#
mpls
#
segment-routing
#
undo shutdown
ip address 172.19.1.2 255.255.255.0
#
undo shutdown
ip address 10.2.1.2 255.255.255.0
#
undo shutdown
ip address 172.17.1.2 255.255.255.0
#
interface LoopBack1
ip address 3.3.3.9 255.255.255.255
#
bgp 100
#
ipv4-family unicast
peer 1.1.1.9 enable
#
ipv4-family vpnv4
policy vpn-target
peer 1.1.1.9 enable
#
#
ospf 1
frr
loop-free-alternate
ti-lfa enable
area 0.0.0.0
#
tunnel-policy p1
#
return
#
sysname P2
#
mpls lsr-id 4.4.4.9

(2020-10-09)
#
mpls
#
segment-routing
#
undo shutdown
ip address 172.18.1.2 255.255.255.0
#
undo shutdown
ip address 172.19.1.1 255.255.255.0
#
interface LoopBack1
ip address 4.4.4.9 255.255.255.255
#
ospf 1
frr
loop-free-alternate
ti-lfa enable
area 0.0.0.0
#
return
#
sysname CE1
#
undo shutdown
ip address 10.1.1.1 255.255.255.0
#
interface LoopBack1
ip address 10.11.1.1 255.255.255.255
#
bgp 65410
network 10.11.1.1 255.255.255.255
#
ipv4-family unicast
#
return
#
sysname CE2
#
undo shutdown
ip address 10.2.1.1 255.255.255.0
#
interface LoopBack1
ip address 10.22.2.2 255.255.255.255
#
bgp 65420
network 10.22.2.2 255.255.255.255
#
ipv4-family unicast
#
return

(2020-10-09)
1.2.39.3 Example for Configuring Non-Labeled Public BGP Routes to Recurse

to an SR-MPLS BE tunnel
Non-labeled public BGP routes are configured to recurse to an SR-MPLS BE tunnel,
so that public network BGP traffic can be transmitted along the SR-MPLS BE
tunnel.
If an Internet user sends packets to a carrier network that performs IP forwarding
to access the Internet, core carrier devices on a forwarding path must learn many
Internet routes. This imposes a heavy load on the core carrier devices and affects
the performance of these devices. To tackle the problems, a user access device can
be configured to recurse non-labeled public network BGP or static routes to a
segment routing (SR) tunnel. User packets travel through the SR tunnel to access
the Internet. The recursion to the SR tunnel prevents the problems induced by
insufficient performance, heavy burdens, and service transmission on the core
devices on the carrier network.
In Figure 1-120, non-labeled public BGP routes are configured to recurse to an
SR-MPLS BE tunnel.
Figure 1-120 Non-labeled public BGP route recursion to an SR-MPLS BE tunnel

NOTE
Interfaces 1 and 2 in this example represent GE 1/0/0 and GE 2/0/0, respectively.
Precautions
When configuring non-labeled public BGP route recursion to an SR-MPLS BE
tunnel, note the following:
When establishing a peer, if the specified IP address of the peer is a loopback
interface address or a sub-interface address, you need to run the peer connect-
interface command on the two ends of the peer to ensure that the two ends are
correctly connected.
other.

(2020-10-09)
2. MPLS and segment routing are configured on the backbone network and SR
LSPs are established.
3. Enable IBGP on PEs to exchange VPN routing information.
4. Enable PEs to recurse non-labeled public BGP routes to the SR-MPLS BE
tunnel.
Data Preparation
Procedure
# Configure PE1.
[*HUAWEI] commit
[*PE1] commit
# Configure the P.
[~HUAWEI] sysname P
[*HUAWEI] commit
[~P] interface loopback 1
[*P-LoopBack1] ip address 2.2.2.9 32
[*P-LoopBack1] quit
[*P] interface gigabitethernet1/0/0
[*P-GigabitEthernet1/0/0] ip address 172.16.1.2 24
[*P-GigabitEthernet1/0/0] quit
[*P] commit
# Configure PE2.
[*HUAWEI] commit
[*PE2] commit
Step 2 Configure an IGP protocol on the backbone network to implement connectivity

between the PEs. IS-IS is used as an IGP protocol in this example.
# Configure PE1.

(2020-10-09)
[~PE1] isis 1
[*PE1-isis-1] quit
[*PE1] commit
# Configure the P.
[~P] isis 1
[*P-isis-1] is-level level-1
[*P-isis-1] network-entity 10.0000.0000.0002.00
[*P-isis-1] quit
[*P] interface loopback 1
[*P-LoopBack1] isis enable 1
[*P-LoopBack1] quit
[*P-GigabitEthernet1/0/0] isis enable 1
[*P] commit
# Configure PE2.
[~PE2] isis 1
[*PE2-isis-1] quit
[*PE2] commit
# Configure PE1.
[*PE1] mpls
[*PE1-mpls] commit
[~PE1-mpls] quit
# Configure the P.
[~P] mpls lsr-id 2.2.2.9
[*P] mpls
[*P-mpls] commit
[~P-mpls] quit
# Configure PE2.
[*PE2] mpls
[*PE2-mpls] commit
[~PE2-mpls] quit
Step 4 Configure segment routing on the backbone network.
# Configure PE1.

(2020-10-09)
[*PE1-segment-routing] tunnel-prefer segment-routing
[*PE1] isis 1
NOTE
[*PE1-isis-1] quit
[*PE1] commit
# Configure the P.
[~P] segment-routing
[*P-segment-routing] tunnel-prefer segment-routing
[*P-segment-routing] quit
[*P] isis 1
[*P-isis-1] cost-style wide
[*P-isis-1] segment-routing mpls
[*P-isis-1] segment-routing global-block 160000 161000
NOTE
[*P-isis-1] quit
[*P-LoopBack1] isis prefix-sid index 20
[*P-LoopBack1] quit
[*P] commit
# Configure PE2.
[*PE2] isis 1
NOTE
[*PE2-isis-1] quit
[*PE2] commit
Step 5 Establish an IBGP peer relationship between PEs.
# Configure PE1.
[~PE1] bgp 100
[*PE1-bgp] peer 3.3.3.9 as-number 100
[*PE1-bgp] commit
[~PE1-bgp] quit

(2020-10-09)
# Configure PE2.
[~PE2] bgp 100
[*PE2-bgp] commit
[~PE2-bgp] quit
After the configuration is complete, run the display bgp peer command on the
PEs to check whether the BGP peer relationship has been established. If the
Established state is displayed in the command output, the BGP peer relationship
has been established successfully. The following example uses the command
output on PE1.
3.3.3.9 4 100 2 6 0 00:00:12 Established 0
Step 6 Enable PEs to recurse non-labeled public BGP routes to the SR-MPLS BE tunnel.
# Configure PE1.
[*PE1] tunnel-selector s1 permit node 10
[*PE1-tunnel-selector] apply tunnel-policy p1
[*PE1-tunnel-selector] quit
[*PE1] bgp 100
[*PE1-bgp] unicast-route recursive-lookup tunnel tunnel-selector s1
[*PE1-bgp] commit
[~PE1-bgp] quit
# Configure PE2.
[*PE2] tunnel-selector s1 permit node 10
[*PE2-tunnel-selector] apply tunnel-policy p1
[*PE2-tunnel-selector] quit
[*PE2] bgp 100
[*PE2-bgp] unicast-route recursive-lookup tunnel tunnel-selector s1
[*PE2-bgp] commit
[~PE2-bgp] quit
----End
Configuration Files
#
sysname PE1
#
tunnel-selector s1 permit node 10
apply tunnel-policy p1
#
mpls lsr-id 1.1.1.9
#
mpls
#
segment-routing
tunnel-prefer segment-routing
#

(2020-10-09)
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0001.00
#
undo shutdown
ip address 172.16.1.1 255.255.255.0
isis enable 1
#
interface LoopBack1
ip address 1.1.1.9 255.255.255.255
isis enable 1
#
bgp 100
#
ipv4-family unicast
unicast-route recursive-lookup tunnel tunnel-selector s1
peer 3.3.3.9 enable
#
tunnel-policy p1
#
return
● P configuration file
#
sysname P
#
mpls lsr-id 2.2.2.9
#
mpls
#
segment-routing
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0002.00
#
undo shutdown
ip address 172.16.1.2 255.255.255.0
isis enable 1
#
undo shutdown
ip address 172.17.1.2 255.255.255.0
isis enable 1
#
interface LoopBack1
ip address 2.2.2.9 255.255.255.255
isis enable 1
#
return
#
sysname PE2
#

(2020-10-09)
tunnel-selector s1 permit node 10

apply tunnel-policy p1
#
mpls lsr-id 3.3.3.9
#
mpls
#
segment-routing
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0003.00
#
undo shutdown
ip address 172.17.1.1 255.255.255.0
isis enable 1
#
interface LoopBack1
ip address 3.3.3.9 255.255.255.255
isis enable 1
#
bgp 100
#
ipv4-family unicast
unicast-route recursive-lookup tunnel tunnel-selector s1
peer 1.1.1.9 enable
#
tunnel-policy p1
#
return
1.2.39.4 Example for Configuring IS-IS SR to Communicate with LDP

This section provides an example for configuring IS-IS SR to communicate with
LDP so that devices in the SR domain can communicate with devices in the LDP
domain using MPLS forwarding techniques.
As shown in Figure 1-121, an SR domain is created between PE1 and P, and an
LDP domain lies between P and PE2. PE1 and PE2 need to communicate with each
other.

NOTE

(2020-10-09)
Precautions
When configuring IS-IS SR to communicate with LDP, note that a device in the SR
domain must be able to map LDP prefix information to SR SIDs.
other.
2. Enable MPLS on the backbone network. Configure segment routing to
establish an SR LSP from PE1 to the P. Configure LDP to establish an LDP LSP
from the P to PE2.
3. Configure the mapping server function on the P to map LDP prefix
information to SR SIDs.
Data Preparation
● SRGB ranges on the PE1 and P
Procedure
# Configure PE1.
[*HUAWEI] commit
[*PE1] commit
# Configure the P.
[~HUAWEI] sysname P
[*HUAWEI] commit

(2020-10-09)

[*P-LoopBack1] quit
[*P] commit
# Configure PE2.
[*HUAWEI] commit
[*PE2] commit

connectivity between the PEs.
IS-IS is used as an IGP protocol in this example.
# Configure PE1.
[~PE1] isis 1
[*PE1-isis-1] quit
[*PE1] commit
# Configure the P.
[~P] isis 1
[*P-isis-1] quit
[*P-LoopBack1] quit
[*P] commit
# Configure PE2.
[~PE2] isis 1
[*PE2-isis-1] quit

(2020-10-09)

[*PE2] commit
Step 3 Configure the basic MPLS functions on the MPLS backbone network.
# Configure PE1.
[*PE1] mpls
[*PE1-mpls] commit
[~PE1-mpls] quit
# Configure the P.
[*P] mpls
[*P-mpls] quit
[*P-GigabitEthernet2/0/0] mpls
[*P] commit
# Configure PE2.
[*PE2] mpls
[*PE2-mpls] quit
[*PE2-GigabitEthernet1/0/0] mpls
[*PE2] commit
Step 4 Configure segment routing between PE1 and the P on the backbone network.
# Configure PE1.
[*PE1] isis 1
NOTE
[*PE1-isis-1] quit
[*PE1] commit
# Configure the P.
[*P-segment-routing] tunnel-prefer segment-routing
[*P] isis 1

(2020-10-09)
NOTE
[*P-isis-1] quit
[*P-LoopBack1] isis prefix-sid index 20
[*P-LoopBack1] quit
[*P] commit
Step 5 Establish an LDP LSP between PE2 and the P.

# Configure the P.
[~P] mpls ldp
[*P-mpls-ldp] quit
[*P-GigabitEthernet2/0/0] mpls ldp
[*P] commit
# Configure PE2.
[~PE2] mpls ldp
[*PE2-mpls-ldp] quit
[*PE2-GigabitEthernet1/0/0] mpls ldp
[*PE2] commit
Step 6 Configure the mapping server function on the P, and configure the P to allow SR
and LDP to communicate with each other.
# Configure the P.
[~P-segment-routing] mapping-server prefix-sid-mapping 3.3.3.9 32 22
[*P] isis 1
[*P-isis-1] segment-routing mapping-server send
[*P-isis-1] quit
[*P] mpls
[*P-mpls] lsp-trigger segment-routing-interworking best-effort host
[*P-mpls] commit
[~P-mpls] quit

Run the display segment-routing prefix mpls forwarding command on an SR
device to check information about the label forwarding table for segment routing.
# In the following, the command output on the P is used.
[~P] display segment-routing prefix mpls forwarding
Segment Routing Prefix MPLS Forwarding Information
--------------------------------------------------------------
Role : I-Ingress, T-Transit, E-Egress, I&T-Ingress And Transit
Prefix Label OutLabel Interface NextHop Role MPLSMtu Mtu State

-----------------------------------------------------------------------------------------------------
3.3.3.9/32 160022 NULL Mapping LDP --- E --- --- Active
Total information(s): 1
The command output shows that the forwarding entry for the route to 3.3.3.9/32
exists and has its outbound interface is the mapping LDP, which indicates that the
P has successfully stitched the SR LSP to the MPLS LDP LSP.

(2020-10-09)
# Configure the PEs to ping each other. For example, PE1 pings PE2 at 3.3.3.9.
[~PE1] ping lsp segment-routing ip 3.3.3.9 32 version draft2 remote 3.3.3.9
LSP PING FEC: Nil FEC : 100 data bytes, press CTRL_C to break
--- FEC: Nil FEC ping statistics ---
0.00% packet loss
----End
Configuration Files
#
sysname PE1
#
mpls lsr-id 1.1.1.9
#
mpls
#
segment-routing
#
isis 1
cost-style wide
network-entity 10.0000.0000.0001.00
#
undo shutdown
ip address 172.16.1.1 255.255.255.0
isis enable 1
#
interface LoopBack1
ip address 1.1.1.9 255.255.255.255
isis enable 1
#
return
#
sysname P
#
mpls lsr-id 2.2.2.9
#
mpls
lsp-trigger segment-routing-interworking best-effort host
#
mpls ldp
#
segment-routing
mapping-server prefix-sid-mapping 3.3.3.9 32 22
#
isis 1
cost-style wide
network-entity 10.0000.0000.0002.00

(2020-10-09)
segment-routing mapping-server send

#
undo shutdown
ip address 172.16.1.2 255.255.255.0
isis enable 1
#
undo shutdown
ip address 172.17.1.1 255.255.255.0
isis enable 1
mpls
mpls ldp
#
interface LoopBack1
ip address 2.2.2.9 255.255.255.255
isis enable 1
#
return

#
sysname PE2
#
mpls lsr-id 3.3.3.9
#
mpls
#
mpls ldp
#
isis 1
cost-style wide
network-entity 10.0000.0000.0003.00
#
undo shutdown
ip address 172.17.1.2 255.255.255.0
isis enable 1
mpls
mpls ldp
#
interface LoopBack1
ip address 3.3.3.9 255.255.255.255
isis enable 1
#
return
1.2.39.5 Example for Configuring IS-IS Anycast FRR

IS-IS anycast FRR can be configured to enhance the reliability of a segment
routing network.
As shown in Figure 1-122, CE1 can be reached through either PE2 and PE3. To
enable PE2 and PE3 to protect each other, configure IS-IS anycast FRR. This
improves network reliability.
Figure 1-122 IS-IS anycast FRR protection networking

NOTE

(2020-10-09)
other.
2. MPLS and segment routing are configured on the backbone network and SR
LSPs are established.
3. Enable TI-LFA FRR on PE1 and configure the delayed switchback function.
Data Preparation
● SRGB ranges on the PEs
Procedure
Step 1 Assign an IP address to each interface.
# Configure PE1.
[*HUAWEI] commit
[*PE1] commit
# Configure PE2.

(2020-10-09)
[*HUAWEI] commit
[*PE2] commit
# Configure PE3.
[*HUAWEI] commit
[*PE3] commit
Step 2 Configure an IGP protocol on the backbone network to implement connectivity

between the PEs. IS-IS is used as an IGP protocol in this example.
# Configure PE1.
[~PE1] isis 1
[*PE1-isis-1] quit
[*PE1] commit
# Configure PE2.
[~PE2] isis 1
[*PE2-isis-1] quit
[*PE2] commit
# Configure PE3.
[~PE3] isis 1
[*PE3-isis-1] quit

(2020-10-09)
[*PE3] commit
# Configure PE1.
[*PE1] mpls
[*PE1-mpls] commit
[~PE1-mpls] quit
# Configure PE2.
[*PE2] mpls
[*PE2-mpls] commit
[~PE2-mpls] quit
# Configure PE3.
[*PE3] mpls
[*PE3-mpls] commit
[~PE3-mpls] quit
Step 4 Configure segment routing on the backbone network and enable TI-LFA FRR the
anti-micro-loop function for a switchback.
# Configure PE1.
[*PE1] isis 1
NOTE
The SRGB range various according to a live network. Set the range as needed. The SRGB
setting here is an example.
[*PE1-isis-1] frr
[*PE1-isis-1] avoid-microloop segment-routing
[*PE1-isis-1] avoid-microloop segment-routing rib-update-delay 6000
[*PE1-isis-1] quit
[*PE1] commit
# Configure PE2.
[*PE2] isis 1
NOTE
The SRGB range varies according to the device. The configuration in this example is for
reference only.

(2020-10-09)
[*PE2-isis-1] quit
[*PE2] commit
# Configure PE3.
[*PE3] isis 1
NOTE
reference only.
[*PE3-isis-1] quit
[*PE3] commit
Step 5 Checking the Configurations

Run the display segment-routing prefix mpls forwarding verbose command on
PE1 to check information about the label forwarding table for segment routing.
The command output contains FRR backup entry information.
[~PE1] display segment-routing prefix mpls forwarding ip-prefix 2.2.2.9 32 verbose

--------------------------------------------------------------

-----------------------------------------------------------------------------------------------------------------
2.2.2.9/32 160020 3 GE1/0/0 172.16.1.2 I&T --- 1500 Active
Protocol : ISIS SubProtocol : Level-1 Process ID : 1
Cost : 10 Weight :0 UpdateTime : 2018-12-11 06:46:33.920
BFD State: -- Favor :Y
Label Stack (Top -> Bottom): { 3 }

-----------------------------------------------------------------------------------------------------------------
2.2.2.9/32 160020 3 GE2/0/0 172.18.1.2 I&T --- 1500 Active
Protocol : ISIS SubProtocol : Level-1 Process ID : 1
Cost : 10 Weight :0 UpdateTime : 2018-12-11 06:47:21.478
BFD State: -- Favor :Y
Label Stack (Top -> Bottom): { 3 }
----End
Configuration Files
#
sysname PE1
#
mpls lsr-id 1.1.1.9
#
mpls
#

(2020-10-09)
segment-routing
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0001.00
avoid-microloop segment-routing
avoid-microloop segment-routing rib-update-delay 6000
frr
ti-lfa level-1
#
undo shutdown
ip address 172.18.1.1 255.255.255.0
isis enable 1
#
undo shutdown
ip address 172.16.1.1 255.255.255.0
isis enable 1
#
interface LoopBack1
ip address 1.1.1.9 255.255.255.255
isis enable 1
#
return
#
sysname PE2
#
mpls lsr-id 2.2.2.9
#
mpls
#
segment-routing
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0002.00
#
undo shutdown
ip address 172.16.1.2 255.255.255.0
isis enable 1
#
interface LoopBack1
ip address 2.2.2.9 255.255.255.255
isis enable 1
#
return
#
sysname PE3
#
mpls lsr-id 4.4.4.9
#
mpls
#

(2020-10-09)
segment-routing
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0004.00
#
undo shutdown
ip address 172.18.1.2 255.255.255.0
isis enable 1
#
interface LoopBack0
ip address 4.4.4.9 255.255.255.255
#
interface LoopBack1
ip address 2.2.2.9 255.255.255.255
isis enable 1
#
return
1.2.39.6 Example for Configuring SBFD to Monitor SR-MPLS BE Tunnels

This section provides an example for configuring SBFD to monitor SR-MPLS BE
tunnels, which improves network reliability.
As shown in Figure 1-123, SR-MPLS BE tunnels are established between PEs on
the public network. To improve network reliability, configure SBFD. SBFD can be
used to monitor the SR-MPLS BE tunnels. If the primary tunnel fails, applications
such as VPN FRR are instructed to quickly switch traffic, minimizing the impact on
services.
Figure 1-123 SBFD for SR-MPLS BE tunnel

NOTE

(2020-10-09)
other.
2. Configure MPLS and Segment Routing on the backbone network to establish
SR LSPs. Enable topology independent-loop free alternate (TI-LFA) FRR.
3. Configure SBFD to establish sessions between PEs to monitor SR-MPLS BE
tunnels.
Data Preparation
Procedure
Step 1 Assign an IP address to each interface.
# Configure PE1.
[*HUAWEI] commit
[*PE1] commit
# Configure P1.
[*HUAWEI] commit
[*P1] commit
# Configure PE2.
[*HUAWEI] commit

(2020-10-09)

[*PE2] commit
# Configure P2.
[*HUAWEI] commit
[*P2] commit

connectivity between the PEs. IS-IS is used as an IGP protocol in this example.
# Configure PE1.
[~PE1] isis 1
[*PE1-isis-1] quit
[*PE1] commit
# Configure P1.
[~P1] isis 1
[*P1-isis-1] quit
[*P1] commit
# Configure PE2.
[~PE2] isis 1
[*PE2-isis-1] quit

(2020-10-09)

[*PE2] commit
# Configure P2.
[~P2] isis 1
[*P2-isis-1] quit
[*P2] commit
# Configure PE1.
[*PE1] mpls
[*PE1-mpls] commit
[~PE1-mpls] quit
# Configure P1.
[*P1] mpls
[*P1-mpls] commit
[~P1-mpls] quit
# Configure PE2.
[*PE2] mpls
[*PE2-mpls] commit
[~PE2-mpls] quit
# Configure P2.
[*P2] mpls
[*P2-mpls] commit
[~P2-mpls] quit
Step 4 Configure SR on the backbone network and enable TI-LFA FRR.

# Configure PE1.
[*PE1] isis 1
NOTE
The SRGB range various according to a live network. Set a range as needed. The SRGB

(2020-10-09)
[*PE1-isis-1] frr
[*PE1-isis-1] quit
[*PE1] commit
# Configure P1.
[*P1] isis 1
NOTE
[*P1-isis-1] frr
[*P1-isis-1] quit
[*P1] commit
# Configure PE2.
[*PE2] isis 1
NOTE
[*PE2-isis-1] frr
[*PE2-isis-1] quit
[*PE2] commit
# Configure P2.
[*P2] isis 1
NOTE

(2020-10-09)
[*P2-isis-1] frr
[*P2-isis-1] quit
[*P2] commit
# After completing the configuration, run the display tunnel-info all command
on a PE. The SR LSP has been established. In the following example, the command
output on PE1 is used.
----------------------------------------------------------------------------------------
0x000000002900000003 srbe-lsp 4.4.4.9 UP
0x000000002900000004 srbe-lsp 2.2.2.9 UP
0x000000002900000005 srbe-lsp 3.3.3.9 UP
# Use ping to monitor SR LSP connectivity on PE1.

0.00% packet loss
Step 5 Configure SBFD on PEs.

# Configure PE1.
[~PE1] bfd
[*PE1-bfd] quit
[*PE1] sbfd
[*PE1-sbfd] quit
[*PE1] segment-routing
[*PE1-segment-routing] seamless-bfd enable mode tunnel
[*PE1-segment-routing] commit
[~PE1-segment-routing] quit
# Configure PE2.
[~PE2] bfd
[*PE2-bfd] quit
[*PE2] sbfd
[*PE2-sbfd] reflector discriminator 3.3.3.9
[*PE2-sbfd] commit
[~PE2-sbfd] quit

Run the display segment-routing seamless-bfd tunnel session prefix ip-address
command on a PE. The command output shows information about SBFD sessions
that monitor SR tunnels.
In the following example, the command output on PE1 is used.
[~PE1] display segment-routing seamless-bfd tunnel session prefix 3.3.3.9 32

(2020-10-09)
Seamless BFD Information for SR Tunnel

Total Tunnel Number: 1
-------------------------------------------------------------------
Prefix Discriminator State
-------------------------------------------------------------------
3.3.3.9/32 16385 Up
-------------------------------------------------------------------
----End
Configuration Files
#
sysname PE1
#
bfd
#
sbfd
#
mpls lsr-id 1.1.1.9
#
mpls
#
segment-routing
seamless-bfd enable mode tunnel
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0001.00
frr
ti-lfa level-1
#
undo shutdown
ip address 172.18.1.1 255.255.255.0
isis enable 1
#
undo shutdown
ip address 172.16.1.1 255.255.255.0
isis enable 1
#
interface LoopBack1
ip address 1.1.1.9 255.255.255.255
isis enable 1
#
return
#
sysname P1
#
mpls lsr-id 2.2.2.9
#
mpls
#
segment-routing
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0002.00

(2020-10-09)
frr
ti-lfa level-1
#
undo shutdown
ip address 172.16.1.2 255.255.255.0
isis enable 1
#
undo shutdown
ip address 172.17.1.1 255.255.255.0
isis enable 1
#
interface LoopBack1
ip address 2.2.2.9 255.255.255.255
isis enable 1
#
return
#
sysname PE2
#
bfd
#
sbfd
reflector discriminator 3.3.3.9
#
mpls lsr-id 3.3.3.9
#
mpls
#
segment-routing
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0003.00
frr
ti-lfa level-1
#
undo shutdown
ip address 172.19.1.2 255.255.255.0
isis enable 1
#
undo shutdown
ip address 172.17.1.2 255.255.255.0
isis enable 1
#
interface LoopBack1
ip address 3.3.3.9 255.255.255.255
isis enable 1
#
return
#
sysname P2
#
mpls lsr-id 4.4.4.9

(2020-10-09)
#
mpls
#
segment-routing
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0004.00
frr
ti-lfa level-1
#
undo shutdown
ip address 172.18.1.2 255.255.255.0
isis enable 1
#
undo shutdown
ip address 172.19.1.1 255.255.255.0
isis enable 1
#
interface LoopBack1
ip address 4.4.4.9 255.255.255.255
isis enable 1
#
return
1.2.39.7 Example for Configuring TI-LFA FRR for an SR-MPLS BE Tunnel

Topology-Independent Loop-Free Alternate (TI-LFA) FRR can be configured to
enhance the reliability of a segment routing (SR) network.
On the network shown in Figure 1-124, IS-IS is enabled, and the SR-MPLS BE
function is configured. The cost of the link between Device C and Device D is 100,
and the cost of other links is 10. The optimal path from Device A to Device F is
Device A -> Device B -> Device E -> Device F. TI-LFA FRR can be configured on
Device B to provide local protection, enabling traffic to be quickly switched to the
backup path (Device A -> Device B -> Device C -> Device D -> Device E -> Device
F) when the link between Device B and Device E fails.
Figure 1-124 TI-LFA FRR for an SR-MPLS BE tunnel

NOTE

(2020-10-09)
Precautions
In this example, TI-LFA FRR is configured on DeviceB to protect the link between
DeviceB and EDevice. On a live network, you are advised to configure TI-LFA FRR
on all nodes in the SR domain.
1. Configure IS-IS on the entire network to implement interworking between
devices.
2. Enable MPLS on the entire network, configure SR, and establish an SR-MPLS
BE tunnel.
3. Enable TI-LFA FRR and anti-microloop on Device B.
Data Preparation
● MPLS LSR ID of each device
● SRGB range of each device
Procedure
Step 1 Configure interface IP addresses.
# Configure Device A.
[~HUAWEI] sysname DeviceA
[*HUAWEI] commit
[~DeviceA] interface loopback 1
[*DeviceA-LoopBack1] ip address 1.1.1.9 32
[*DeviceA-LoopBack1] quit
[*DeviceA] interface gigabitethernet1/0/0
[*DeviceA-GigabitEthernet1/0/0] ip address 10.1.1.1 24
[*DeviceA-GigabitEthernet1/0/0] quit
[*DeviceA] commit

(2020-10-09)
Repeat this step for the other devices. For configuration details, see Configuration
Files in this section.
Step 2 Configure an IGP to implement interworking. IS-IS is used as an example.
[~DeviceA] isis 1
[*DeviceA-isis-1] is-level level-1
[*DeviceA-isis-1] network-entity 10.0000.0000.0001.00
[*DeviceA-isis-1] cost-style wide
[*DeviceA-isis-1] quit
[*DeviceA] interface loopback 1
[*DeviceA-LoopBack1] isis enable 1
[*DeviceA-GigabitEthernet1/0/0] isis enable 1
[*DeviceA] commit
Set the cost of the link between DeviceC and DeviceD to 100 to simulate a special
network scenario.
# Configure DeviceC.
[~DeviceC] interface gigabitethernet2/0/0
[~DeviceC-GigabitEthernet2/0/0] isis cost 100
[*DeviceC-GigabitEthernet2/0/0] quit
[*DeviceC] commit
# Configure DeviceD.
[~DeviceD] interface gigabitethernet1/0/0
[~DeviceD-GigabitEthernet1/0/0] isis cost 100
[*DeviceD-GigabitEthernet1/0/0] quit
[*DeviceD] commit
Step 3 Configure basic MPLS capabilities on the backbone network.

[~DeviceA] mpls lsr-id 1.1.1.9
[*DeviceA] mpls
[*DeviceA-mpls] commit
[~DeviceA-mpls] quit
# Configure Device B.
[~DeviceB] mpls lsr-id 2.2.2.9
[*DeviceB] mpls
[*DeviceB-mpls] commit
[~DeviceB-mpls] quit
# Configure Device C.
[~DeviceC] mpls lsr-id 3.3.3.9
[*DeviceC] mpls
[*DeviceC-mpls] commit
[~DeviceC-mpls] quit
# Configure Device D.
[~DeviceD] mpls lsr-id 4.4.4.9
[*DeviceD] mpls
[*DeviceD-mpls] commit

(2020-10-09)
[~DeviceD-mpls] quit
# Configure Device E.
[~DeviceE] mpls lsr-id 5.5.5.9
[*DeviceE] mpls
[*DeviceE-mpls] commit
[~DeviceE-mpls] quit
# Configure Device F.
[~DeviceF] mpls lsr-id 6.6.6.9
[*DeviceF] mpls
[*DeviceF-mpls] commit
[~DeviceF-mpls] quit
Step 4 Configure SR on the backbone network and establish an SR-MPLS BE tunnel.

[~DeviceA] segment-routing
[*DeviceA-segment-routing] quit
[*DeviceA] isis 1
[*DeviceA-isis-1] segment-routing mpls
[*DeviceA-isis-1] segment-routing global-block 16000 23999
NOTE
reference only.
[*DeviceA-LoopBack1] isis prefix-sid index 10
[*DeviceA] commit
[~DeviceB] segment-routing
[*DeviceB-segment-routing] quit
[*DeviceB] isis 1
[*DeviceB-isis-1] segment-routing mpls
[*DeviceB-isis-1] segment-routing global-block 16000 23999
NOTE
reference only.
[*DeviceB-isis-1] quit
[*DeviceB] interface loopback 1
[*DeviceB-LoopBack1] isis prefix-sid index 20
[*DeviceB-LoopBack1] quit
[*DeviceB] commit
[~DeviceC] segment-routing
[*DeviceC-segment-routing] quit
[*DeviceC] isis 1
[*DeviceC-isis-1] segment-routing mpls
[*DeviceC-isis-1] segment-routing global-block 16000 23999
NOTE
reference only.
[*DeviceC-isis-1] quit
[*DeviceC] interface loopback 1

(2020-10-09)
[*DeviceC-LoopBack1] isis prefix-sid index 30

[*DeviceC-LoopBack1] quit
[*DeviceC] commit
[~DeviceD] segment-routing
[*DeviceD-segment-routing] quit
[*DeviceD] isis 1
[*DeviceD-isis-1] segment-routing mpls
[*DeviceD-isis-1] segment-routing global-block 16000 23999
NOTE
reference only.
[*DeviceD-isis-1] quit
[*DeviceD] interface loopback 1
[*DeviceD-LoopBack1] isis prefix-sid index 40
[*DeviceD-LoopBack1] quit
[*DeviceD] commit
[~DeviceE] segment-routing
[*DeviceE-segment-routing] quit
[*DeviceE] isis 1
[*DeviceE-isis-1] segment-routing mpls
[*DeviceE-isis-1] segment-routing global-block 16000 23999
NOTE
reference only.
[*DeviceE-isis-1] quit
[*DeviceE] interface loopback 1
[*DeviceE-LoopBack1] isis prefix-sid index 50
[*DeviceE-LoopBack1] quit
[*DeviceE] commit
[~DeviceF] segment-routing
[*DeviceF-segment-routing] quit
[*DeviceF] isis 1
[*DeviceF-isis-1] segment-routing mpls
[*DeviceF-isis-1] segment-routing global-block 16000 23999
NOTE
reference only.
[*DeviceF-isis-1] quit
[*DeviceF] interface loopback 1
[*DeviceF-LoopBack1] isis prefix-sid index 60
[*DeviceF-LoopBack1] quit
[*DeviceF] commit
# After completing the configurations, run the display segment-routing prefix

mpls forwarding command on each device. The command output shows that SR-
MPLS BE label forwarding paths have been established. The following example
uses the command output on Device A.
[~DeviceA] display segment-routing prefix mpls forwarding
--------------------------------------------------------------

(2020-10-09)

-----------------------------------------------------------------------------------------------------------------
1.1.1.9/32 16010 NULL Loop1 127.0.0.1 E --- 1500 Active
2.2.2.9/32 16020 3 GE1/0/0 10.1.1.2 I&T --- 1500 Active
3.3.3.9/32 16030 16030 GE1/0/0 10.1.1.2 I&T --- 1500 Active
4.4.4.9/32 16040 16040 GE1/0/0 10.1.1.2 I&T --- 1500 Active
5.5.5.9/32 16050 16050 GE1/0/0 10.1.1.2 I&T --- 1500 Active
6.6.6.9/32 16060 16060 GE1/0/0 10.1.1.2 I&T --- 1500 Active
Step 5 Configure TI-LFA FRR.
[~DeviceB] isis 1
[~DeviceB-isis-1] avoid-microloop frr-protected
[*DeviceB-isis-1] avoid-microloop frr-protected rib-update-delay 5000
[*DeviceB-isis-1] avoid-microloop segment-routing
[*DeviceB-isis-1] avoid-microloop segment-routing rib-update-delay 10000
[*DeviceB-isis-1] frr
[*DeviceB-isis-1-frr] loop-free-alternate level-1
[*DeviceB-isis-1-frr] ti-lfa level-1
[*DeviceB-isis-1-frr] quit
[*DeviceB] commit
After completing the configurations, run the display isis route [ level-1 | level-2 ]
[ process-id ] [ verbose ] command on Device B. The command output shows IS-
IS TI-LFA FRR backup entries.
[~DeviceB] display isis route level-1 verbose
Route information for ISIS(1)
-----------------------------
ISIS(1) Level-1 Forwarding Table

--------------------------------
IPV4 Dest : 1.1.1.9/32 Int. Cost : 10 Ext. Cost : NULL

Admin Tag : - Src Count : 1 Flags : A/-/-/-
Priority : Medium Age : 04:35:30
NextHop : Interface : ExitIndex :
10.1.1.1 GE1/0/0 0x0000000e
Prefix-sid : 16010 Weight : 0 Flags : -/N/-/-/-/-/A/-
SR NextHop : Interface : OutLabel :
10.1.1.1 GE1/0/0 3

Admin Tag : - Src Count : 1 Flags : D/-/L/-
Priority : - Age : 04:35:30
Direct Loop1 0x00000000
Prefix-sid : 16020 Weight : 0 Flags : -/N/-/-/-/-/A/L
Direct Loop1 -

10.2.1.2 GE2/0/0 0x0000000a
TI-LFA:
Interface : GE3/0/0
NextHop : 10.5.1.2 LsIndex : 0x00000002 ProtectType: L
Backup Label Stack (Top -> Bottom): {16040, 48141}

(2020-10-09)
10.2.1.2 GE2/0/0 3
TI-LFA:
Interface : GE3/0/0

10.5.1.2 GE3/0/0 0x00000007
TI-LFA:
Interface : GE2/0/0
NextHop : 10.2.1.2 LsIndex : 0x00000003 ProtectType: N
Backup Label Stack (Top -> Bottom): {48142}
10.5.1.2 GE3/0/0 16040
TI-LFA:
Interface : GE2/0/0

10.5.1.2 GE3/0/0 0x00000007
TI-LFA:
Interface : GE2/0/0
10.5.1.2 GE3/0/0 3
TI-LFA:
Interface : GE2/0/0

10.5.1.2 GE3/0/0 0x00000007
TI-LFA:
Interface : GE2/0/0
10.5.1.2 GE3/0/0 16060
TI-LFA:
Interface : GE2/0/0

Direct GE1/0/0 0x00000000

Direct GE2/0/0 0x00000000

(2020-10-09)

Priority : Low Age : 04:09:15
10.2.1.2 GE2/0/0 0x0000000a
TI-LFA:
Interface : GE3/0/0
Backup Label Stack (Top -> Bottom): {}

10.5.1.2 GE3/0/0 0x00000007
TI-LFA:
Interface : GE2/0/0

Direct GE3/0/0 0x00000000

10.5.1.2 GE3/0/0 0x00000007
TI-LFA:
Interface : GE2/0/0
Flags: D-Direct, A-Added to URT, L-Advertised in LSPs, S-IGP Shortcut,
U-Up/Down Bit Set, LP-Local Prefix-Sid
Protect Type: L-Link Protect, N-Node Protect

# Run a tracert command on Device A to check the connectivity of the SR-MPLS
BE tunnel to Device F. For example:
[~DeviceA] tracert lsp segment-routing ip 6.6.6.9 32 version draft2
LSP Trace Route FEC: SEGMENT ROUTING IPV4 PREFIX 6.6.6.9/32 , press CTRL_C to break.
TTL Replier Time Type Downstream
0 Ingress 10.1.1.2/[16060 ]
1 10.1.1.2 291 ms Transit 10.5.1.2/[16060 ]
2 10.5.1.2 10 ms Transit 10.6.1.2/[3 ]
3 6.6.6.9 11 ms Egress
# Run the shutdown command on GE 3/0/0 of Device B to simulate a link fault

between Device B and Device E.
[~DeviceB] interface gigabitethernet3/0/0
[~DeviceB-GigabitEthernet3/0/0] shutdown
[*DeviceB-GigabitEthernet3/0/0] quit
[*DeviceB] commit
# Run the tracert command on Device A again to check the connectivity of the SR-
MPLS BE tunnel. For example:
[~DeviceA] tracert lsp segment-routing ip 6.6.6.9 32 version draft2
LSP Trace Route FEC: SEGMENT ROUTING IPV4 PREFIX 6.6.6.9/32 , press CTRL_C to break.
0 Ingress 10.1.1.2/[16060 ]
1 10.1.1.2 3 ms Transit 10.2.1.2/[16060 ]
2 10.2.1.2 46 ms Transit 10.3.1.2/[16060 ]

(2020-10-09)
3 10.3.1.2 33 ms Transit 10.4.1.2/[16060 ]

4 10.4.1.2 48 ms Transit 10.6.1.2/[3 ]
5 6.6.6.9 4 ms Egress
The preceding command output shows that the SR-MPLS BE tunnel has been
switched to the TI-LFA FRR backup path.
----End
Configuration Files
● Device A configuration file
#
sysname DeviceA
#
mpls lsr-id 1.1.1.9
#
mpls
#
segment-routing
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0001.00
#
undo shutdown
ip address 10.1.1.1 255.255.255.0
isis enable 1
#
interface LoopBack1
ip address 1.1.1.9 255.255.255.255
isis enable 1
#
return
● Device B configuration file
#
sysname DeviceB
#
mpls lsr-id 2.2.2.9
#
mpls
#
segment-routing
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0002.00
avoid-microloop frr-protected
avoid-microloop frr-protected rib-update-delay 5000
frr
ti-lfa level-1
#
undo shutdown
ip address 10.1.1.2 255.255.255.0
isis enable 1

(2020-10-09)
#
undo shutdown
ip address 10.2.1.1 255.255.255.0
isis enable 1
#
undo shutdown
ip address 10.5.1.1 255.255.255.0
isis enable 1
#
interface LoopBack1
ip address 2.2.2.9 255.255.255.255
isis enable 1
#
return
● Device C configuration file
#
sysname DeviceC
#
mpls lsr-id 3.3.3.9
#
mpls
#
segment-routing
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0003.00
#
undo shutdown
ip address 10.2.1.2 255.255.255.0
isis enable 1
#
undo shutdown
ip address 10.3.1.1 255.255.255.0
isis enable 1
isis cost 100
#
interface LoopBack1
ip address 3.3.3.9 255.255.255.255
isis enable 1
#
return
● Device D configuration file
#
sysname DeviceD
#
mpls lsr-id 4.4.4.9
#
mpls
#
segment-routing
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0004.00
#

(2020-10-09)
undo shutdown
ip address 10.3.1.2 255.255.255.0
isis enable 1
isis cost 100
#
undo shutdown
ip address 10.4.1.1 255.255.255.0
isis enable 1
#
interface LoopBack1
ip address 4.4.4.9 255.255.255.255
isis enable 1
#
return
● Device E configuration file
#
sysname DeviceE
#
mpls lsr-id 5.5.5.9
#
mpls
#
segment-routing
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0005.00
#
undo shutdown
ip address 10.6.1.1 255.255.255.0
isis enable 1
#
undo shutdown
ip address 10.4.1.2 255.255.255.0
isis enable 1
#
undo shutdown
ip address 10.5.1.2 255.255.255.0
isis enable 1
#
interface LoopBack1
ip address 5.5.5.9 255.255.255.255
isis enable 1
#
return
● Device F configuration file
#
sysname DeviceF
#
mpls lsr-id 6.6.6.9
#
mpls
#
segment-routing
#
isis 1
is-level level-1
cost-style wide

(2020-10-09)
network-entity 10.0000.0000.0006.00
#
undo shutdown
ip address 10.6.1.2 255.255.255.0
isis enable 1
#
interface LoopBack1
ip address 6.6.6.9 255.255.255.255
isis enable 1
#
return
1.2.40 Configuring Examples for SR-MPLS TE

This section provides several configuration examples of SR-MPLS TE.
1.2.40.1 Example for Configuring L3VPN over SR-MPLS TE

This section provides an example for configuring L3VPN over an SR-MPLS TE
tunnel to ensure secure communication between users of the same VPN.
● The VPN target used by vpna is 111:1.
To ensure secure communication between CE1 and CE2, configure L3VPN over an
SR-MPLS TE tunnel.
Figure 1-125 Configuring L3VPN over an SR-MPLS TE tunnel

NOTE

(2020-10-09)
Precautions
When you configure L3VPN over an SR-MPLS TE tunnel, note the following:
After a PE interface connected to a CE is bound to a VPN instance, Layer 3
features, such as the IP address and routing protocol, on this interface are
automatically deleted. These features can be reconfigured if required.
1. Configure IS-IS on the backbone network to ensure PE communication.
2. On the backbone network, enable MPLS, configure segment routing (SR),
establish an SR-MPLS TE tunnel, specify the tunnel IP address, tunnel
protocol, and destination IP address, and use explicit paths for path
computation.
3. On each PE, configure a VPN instance, enable the IPv4 address family, and
bind each PE interface that connects to a CE to the corresponding VPN
instance.
4. Configure MP-IBGP between PEs to exchange VPN routing information.
5. Configure EBGP between CEs and PEs to exchange VPN routing information.
Data Preparation
● MPLS LSR IDs on the PEs and P1
● VPN target and RD of vpna
● SRGB range on the PEs and P1
Procedure
Step 1 Configure an IP address for each interface.
# Configure PE1.
[*HUAWEI] commit
[*PE1] commit
# Configure P1.
[*HUAWEI] commit

(2020-10-09)
[*P1] commit
# Configure PE2.
[*HUAWEI] commit
[*PE2] commit
Step 2 Configure an IGP on the MPLS backbone network to ensure communication

between the PEs and P1. IS-IS is used in this example.
# Configure PE1.
[~PE1] isis 1
[*PE1-isis-1] quit
[*PE1] commit
# Configure P1.
[~P1] isis 1
[*P1-isis-1] quit
[*P1] commit
# Configure PE2.
[~PE2] isis 1
[*PE2-isis-1] quit
[*PE2] commit
Step 3 Configure basic MPLS functions and enable MPLS TE on the backbone network.
# Configure PE1.

(2020-10-09)

[*PE1] mpls
[*PE1-mpls] mpls te
[*PE1-mpls] quit
[*PE1] commit
# Configure P1.
[*P1] mpls
[*P1-mpls] mpls te
[*P1-mpls] quit
[*P1] commit
# Configure PE2.
[*PE2] mpls
[*PE2-mpls] mpls te
[*PE2-mpls] quit
[*PE2] commit
Step 4 On the backbone network, configure SR, establish an SR-MPLS TE tunnel, specify
the tunnel IP address, tunnel protocol, and destination IP address, and use explicit
paths for path computation.
# Configure PE1.
[*PE1] isis 1
[*PE1-isis-1] traffic-eng level-2
[*PE1-isis-1] quit
NOTE
The SRGB value range varies according to a live network. The following example is for
reference only.
[*PE1-LoopBack1] isis prefix-sid absolute 16100
[*PE1] commit
[~PE1] explicit-path pe2
[*PE1-explicit-path-pe2] next sid label 16200 type prefix
[*PE1-explicit-path-pe2] quit
[*PE1] interface tunnel1
[*PE1-Tunnel1] ip address unnumbered interface LoopBack1
[*PE1-Tunnel1] tunnel-protocol mpls te
[*PE1-Tunnel1] destination 3.3.3.9
[*PE1-Tunnel1] mpls te tunnel-id 1
[*PE1-Tunnel1] mpls te signal-protocol segment-routing
[*PE1-Tunnel1] mpls te path explicit-path pe2
[*PE1-Tunnel1] commit
[~PE1-Tunnel1] quit
# Configure P1.
[*P1] isis 1
[*P1-isis-1] traffic-eng level-2
[*P1-isis-1] quit

(2020-10-09)
NOTE
reference only.
[*P1-LoopBack1] isis prefix-sid absolute 16200
[*P1] commit
# Configure PE2.
[*PE2] isis 1
[*PE2-isis-1] quit
NOTE
reference only.
[*PE2] commit
[~PE2] explicit-path pe1
[*PE2-explicit-path-pe1] quit
[*PE2-Tunnel1] mpls te path explicit-path pe1
[~PE2-Tunnel1] quit
on each PE. The command output shows that the SR-MPLS TE tunnel has been
established. The command output on PE1 is used as an example.
----------------------------------------------------------------------------------------
0x000000000300004001 sr-te 3.3.3.9 UP
# Run the ping command on PE1 to check the connectivity of the SR-MPLS TE
tunnel. For example:
[~PE1] ping lsp segment-routing te Tunnel 1
LSP PING FEC: SEGMENT ROUTING TE TUNNEL IPV4 SESSION QUERY Tunnel1 : 100 data bytes, press
CTRL_C to break
--- FEC: SEGMENT ROUTING TE TUNNEL IPV4 SESSION QUERY Tunnel1 ping statistics ---

(2020-10-09)
0.00% packet loss

Step 5 Establish an MP-IBGP peer relationship between PEs.

# Configure PE1.
[~PE1] bgp 100
[~PE1-bgp] quit
# Configure PE2.
[~PE2] bgp 100
[~PE2-bgp] quit
vpnv4 all peer command on each PE. The command output shows that the MP-
IBGP peer relationship has been set up and is in the Established state. The
command output on PE1 is used as an example.


3.3.3.9 4 100 2 6 0 00:00:12 Established 0


3.3.3.9 4 100 12 18 0 00:09:38 Established 0
Step 6 On each PE, create a VPN instance, enable the IPv4 address family in the VPN
instance, and bind the PE interface connected to a CE to the VPN instance.
# Configure PE1.
[*PE1] commit
# Configure PE2.

(2020-10-09)
[*PE2] commit
# Assign an IP address to each CE interface as shown in Figure 1-125. For details,

see "Configuration Files" in this section.
command on each PE. The command output shows the configurations of VPN
instances. Each PE can successfully ping its connected CE.
NOTE
If a PE has multiple interfaces bound to the same VPN instance, specify a source IP address
using the -a source-ip-address parameter in the ping -vpn-instance vpn-instance-name -a
source-ip-address dest-ip-address command to ping the CE that is connected to the remote
PE. If the source IP address is not specified, the ping operation fails.
Step 7 Configure a tunnel policy on each PE, and specify SR-MPLS TE as the preferred
tunnel.
# Configure PE1.
[*PE1-tunnel-policy-p1] tunnel select-seq sr-te load-balance-number 1
[*PE1] commit
[*PE1] commit
# Configure PE2.
[*PE2-tunnel-policy-p1] tunnel select-seq sr-te load-balance-number 1
[*PE2] commit
[*PE2] commit
Step 8 Set up EBGP peer relationships between the PEs and CEs.
# Configure CE1.
[*CE1] bgp 65410
[*CE1-bgp] network 10.11.1.1 32

(2020-10-09)
[*CE1-bgp] quit
[*CE1] commit
NOTE
Repeat this step on CE2. For configuration details, see "Configuration Files" in this section.
# Configure PE1.
[~PE1] bgp 100
[*PE1-bgp] ipv4-family vpn-instance vpna
[*PE1-bgp-vpna] quit
NOTE
Repeat this step on PE2. For configuration details, see "Configuration Files" in this section.
After the configuration is complete, run the display bgp vpnv4 vpn-instance peer
command on each PE. The command output shows that the BGP peer
relationships have been established and are in the Established state.
The BGP peer relationship between PE1 and CE1 is used as an example.



10.1.1.1 4 65410 11 9 0 00:06:37 Established 1

Run the display ip routing-table vpn-instance command on each PE. The
command output shows the routes to CE loopback interfaces.
The command output on PE1 is used as an example.
------------------------------------------------------------------------------
Routing Table: vpna
10.1.1.0/24 Direct 0 0 D 10.1.1.2 GigabitEthernet 1/0/0
10.11.1.1/32 EBGP 255 0 RD 10.1.1.1 GigabitEthernet 1/0/0
10.22.2.2/32 IBGP 255 0 RD 3.3.3.9 Tunnel1
The CEs can ping each other. For example, CE1 can ping CE2 (10.22.2.2).
[~CE1] ping -a 10.11.1.1 10.22.2.2

(2020-10-09)
0.00% packet loss
----End
Configuration Files
#
sysname PE1
#
ipv4-family
tnl-policy p1
apply-label per-instance
#
mpls lsr-id 1.1.1.9
#
mpls
mpls te
#
explicit-path pe2
next sid label 16200 type prefix
#
segment-routing
#
isis 1
is-level level-2
cost-style wide
network-entity 10.0000.0000.0001.00
traffic-eng level-2
#
undo shutdown
ip address 10.1.1.2 255.255.255.0
#
undo shutdown
ip address 172.16.1.1 255.255.255.0
isis enable 1
#
interface LoopBack1
ip address 1.1.1.9 255.255.255.255
isis enable 1
isis prefix-sid absolute 16100
#
interface Tunnel1
ip address unnumbered interface LoopBack1
tunnel-protocol mpls te
destination 3.3.3.9
mpls te signal-protocol segment-routing
mpls te tunnel-id 1
mpls te path explicit-path pe2
#
bgp 100
#
ipv4-family unicast

(2020-10-09)
peer 3.3.3.9 enable

#
ipv4-family vpnv4
policy vpn-target
peer 3.3.3.9 enable
#
#
tunnel-policy p1
tunnel select-seq sr-te load-balance-number 1
#
return
#
sysname P1
#
mpls lsr-id 2.2.2.9
#
mpls
mpls te
#
segment-routing
#
isis 1
is-level level-2
cost-style wide
network-entity 10.0000.0000.0002.00
traffic-eng level-2
#
undo shutdown
ip address 172.16.1.2 255.255.255.0
isis enable 1
#
undo shutdown
ip address 172.17.1.1 255.255.255.0
isis enable 1
#
interface LoopBack1
ip address 2.2.2.9 255.255.255.255
isis enable 1
#
return
#
sysname PE2
#
ipv4-family
tnl-policy p1
#
mpls lsr-id 3.3.3.9
#
mpls
mpls te
#
explicit-path pe1

(2020-10-09)
#
segment-routing
#
isis 1
is-level level-2
cost-style wide
network-entity 10.0000.0000.0003.00
traffic-eng level-2
#
undo shutdown
ip address 10.2.1.2 255.255.255.0
#
undo shutdown
ip address 172.17.1.2 255.255.255.0
isis enable 1
#
interface LoopBack1
ip address 3.3.3.9 255.255.255.255
isis enable 1
#
interface Tunnel1
destination 1.1.1.9
mpls te tunnel-id 1
mpls te path explicit-path pe1
#
bgp 100
#
ipv4-family unicast
peer 1.1.1.9 enable
#
ipv4-family vpnv4
policy vpn-target
peer 1.1.1.9 enable
#
#
tunnel-policy p1
#
return
#
sysname CE1
#
interface GigabitEthernet 1/0/0
undo shutdown
ip address 10.1.1.1 255.255.255.0
#
interface LoopBack1
ip address 10.11.1.1 255.255.255.255
#
bgp 65410
#
ipv4-family unicast
network 10.11.1.1 255.255.255.255

(2020-10-09)

#
return

#
sysname CE2
#
undo shutdown
ip address 10.2.1.1 255.255.255.0
#
interface LoopBack1
ip address 10.22.2.2 255.255.255.255
#
bgp 65420
#
ipv4-family unicast
network 10.22.2.2 255.255.255.255
#
return
1.2.40.2 Example for Configuring VPLS over SR-MPLS TE

The public network tunnel for an LDP VPLS network can be an SR-MPLS TE
tunnel.
On the network shown in Figure 1-126, CE1 and CE2 are on the same VPLS
network. They access the MPLS core network through PE1 and PE2 respectively.
OSPF is used as the IGP on the MPLS backbone network.
LDP VPLS and an SR-MPLS TE tunnel must be deployed between PE1 and PE2 to
transmit VPLS services.
Figure 1-126 Configuring LDP VPLS over SR-MPLS TE

NOTE
Interface 1, sub-interface 1.1, interface 2, and Sub-interface 2.1 in this example represent
GE 1/0/0, GE 1/0/0.1, GE 2/0/0, and GE 2/0/0.1, respectively.

(2020-10-09)
Configuration Notes
When configuring LDP VPLS over SR-MPLS TE, note that PEs on the same L2VPN
must be configured with the same VSI ID.
1. Configure a routing protocol on the backbone devices (PEs and the P) to
achieve connectivity and enable MPLS.
2. Set up an SR-MPLS TE tunnel and configure the tunnel policy. For
configuration details, see the NE40EConfiguration Guide - Segment Routing.
3. Enable MPLS L2VPN on PEs.
4. Create VSIs on PEs, set the signaling protocol to LDP, and bind VSIs to AC
interfaces.
5. Configure VSIs to use the SR-MPLS TE tunnel.
Data Preparation
● OSPF areas enabled with SR-MPLS TE
● Names and IDs of VSIs
● IP addresses of peers and the tunnel policy
● AC interfaces to which VSIs are bound
Procedure
Step 1 Assign IP addresses to interfaces.
# Configure PE1.
[*HUAWEI] commit
[*PE1] commit
# Configure P.
[~HUAWEI] sysname P
[*HUAWEI] commit
[*P-LoopBack1] quit
[*P] commit

(2020-10-09)
# Configure PE2.
[*HUAWEI] commit
[*PE2] commit
Step 2 Configure MPLS and MPLS TE.

On the nodes along the MPLS TE tunnel, configure MPLS and MPLS TE globally.
# Configure PE1.
[*PE1] mpls
[*PE1-mpls] mpls te
[*PE1-mpls] quit
[*PE1] commit
# Configure the P.
[*P] mpls
[*P-mpls] mpls te
[*P-mpls] quit
[*P] commit
# Configure PE2.
[*PE2] mpls
[*PE2-mpls] mpls te
[*PE2-mpls] quit
[*PE2] commit
Step 3 Configure OSPF TE on the backbone network.

# Configure PE1.
[~PE1] ospf 1
[*PE1-ospf-1] area 0.0.0.0
[*PE1-ospf-1-area-0.0.0.0] network 1.1.1.9 0.0.0.0
[*PE1-ospf-1-area-0.0.0.0] mpls-te enable
[*PE1-ospf-1] quit
[*PE1] commit
# Configure the P.
[~P] ospf 1
[*P-ospf-1] opaque-capability enable
[*P-ospf-1] area 0.0.0.0
[*P-ospf-1-area-0.0.0.0] network 2.2.2.9 0.0.0.0
[*P-ospf-1-area-0.0.0.0] mpls-te enable
[*P-ospf-1-area-0.0.0.0] quit
[*P-ospf-1] quit
[*P] commit
# Configure PE2.

(2020-10-09)
[~PE2] ospf 1
[*PE2-ospf-1] area 0.0.0.0
[*PE2-ospf-1-area-0.0.0.0] mpls-te enable
[*PE2-ospf-1] quit
[*PE2] commit
Step 4 Configure Segment Routing on the backbone network.

# Configure PE1.
[*PE1] ospf 1
NOTE
[*PE1-ospf-1] quit
[*PE1-LoopBack1] ospf prefix-sid absolute 16100
[*PE1] commit
# Configure the P.
[*P] ospf 1
[*P-ospf-1] segment-routing mpls
[*P-ospf-1] segment-routing global-block 16000 47999
NOTE
[*P-ospf-1] quit
[*P-LoopBack1] ospf prefix-sid absolute 16300
[*P-LoopBack1] quit
[*P] commit
# Configure PE2.
[*PE2] ospf 1
NOTE
[*PE2-ospf-1] quit
[*PE2-LoopBack1] ospf prefix-sid absolute 16200
[*PE2] commit
Step 5 Configure explicit paths.

# Configure PE1.

(2020-10-09)
[~PE1] explicit-path path2pe2

[*PE1-explicit-path-path2pe2] next sid label 16300 type prefix
[*PE1-explicit-path-path2pe2] quit
[*PE1] commit
# Configure PE2.
[*PE2] commit
Step 6 Configure tunnel interfaces.

# Create tunnel interfaces on PEs. Specify MPLS TE as the tunneling protocol and
Segment Routing as the signaling protocol.
# Configure PE1.
[~PE1] interface Tunnel 10
[*PE1-Tunnel10] ip address unnumbered interface loopback1
[*PE1-Tunnel10] mpls te path explicit-path path2pe2
[*PE1-Tunnel10] mpls te reserved-for-binding
[*PE1-Tunnel10] quit
[*PE1] commit
# Configure PE2.
[~PE2] interface Tunnel 10
[*PE2-Tunnel10] ip address unnumbered interface loopback1
[*PE2-Tunnel10] quit
[*PE2] commit
Run the display tunnel-info all command in the system view. The command
output shows that the TE tunnel with the destination address being the peer MPLS
LSR ID exists between PEs. The following example uses the command output on
PE1.
-----------------------------------------------------------------------------
0x000000000300000001 sr-te 3.3.3.9 UP
Step 7 Configure remote LDP sessions.

Set up remote peer sessions between PE1 and PE2.
# Configure PE1.
[~PE1] mpls ldp
[*PE1] mpls ldp remote-peer 3.3.3.9
[*PE1-mpls-ldp-remote-3.3.3.9] remote-ip 3.3.3.9
[*PE1-mpls-ldp-remote-3.3.3.9] quit
[*PE1] commit
# Configure PE2.

(2020-10-09)
[~PE2] mpls ldp

[*PE2] mpls ldp remote-peer 1.1.1.9
[*PE2-mpls-ldp-remote-1.1.1.9] remote-ip 1.1.1.9
[*PE2-mpls-ldp-remote-1.1.1.9] quit
[*PE2] commit
Step 8 Configure the tunnel policy.

# Configure PE1.
[~PE1] tunnel-policy policy1
[*PE1-tunnel-policy-policy1] tunnel binding destination 3.3.3.9 te Tunnel10
[*PE1-tunnel-policy-policy1] quit
[*PE1] commit
# Configure PE2.
[*PE2-tunnel-policy-policy1] tunnel binding destination 1.1.1.9 te Tunnel10
[*PE2-tunnel-policy-policy1] quit
[*PE2] commit
Step 9 Enable MPLS L2VPN on PEs.

# Configure PE1.
[~PE1] mpls l2vpn
[*PE1-l2vpn] quit
[*PE1] commit
# Configure PE2.
[~PE2] mpls l2vpn
[*PE2-l2vpn] quit
[*PE2] commit
Step 10 Create VSIs on PEs and bind the tunnel policy to the VSIs.
# Configure PE1.
[~PE1] vsi a2
[*PE1-vsi-a2] pwsignal ldp
[*PE1-vsi-a2-ldp] vsi-id 2
[*PE1-vsi-a2-ldp] peer 3.3.3.9 tnl-policy policy1
[*PE1-vsi-a2-ldp] quit
[*PE1-vsi-a2] quit
[*PE1] commit
# Configure PE2.
[~PE2] vsi a2
[*PE2-vsi-a2] pwsignal ldp
[*PE2-vsi-a2-ldp] vsi-id 2
[*PE2-vsi-a2-ldp] peer 1.1.1.9 tnl-policy policy1
[*PE2-vsi-a2-ldp] quit
[*PE2-vsi-a2] quit
[*PE2] commit
Step 11 Bind VSIs to AC interfaces on PEs.

# Configure PE1.
[~PE1] interface gigabitethernet2/0/0.1
[*PE1-GigabitEthernet2/0/0.1] vlan-type dot1q 10
[*PE1-GigabitEthernet2/0/0.1] l2 binding vsi a2
[*PE1-GigabitEthernet2/0/0.1] quit
[*PE1] commit
# Configure PE2.

(2020-10-09)
[~PE2] interface gigabitethernet2/0/0.1

[*PE2-GigabitEthernet2/0/0.1] vlan-type dot1q 10
[*PE2-GigabitEthernet2/0/0.1] l2 binding vsi a2
[*PE2] commit
# Configure CE1.
[~CE1] interface gigabitethernet1/0/0.1
[*CE1-GigabitEthernet1/0/0.1] vlan-type dot1q 10
[*CE1-GigabitEthernet1/0/0.1] ip address 10.1.1.1 255.255.255.0
[*CE1-GigabitEthernet1/0/0.1] quit
[*CE1] commit
# Configure CE2.
[~CE2] interface gigabitethernet1/0/0.1
[*CE2] commit

After completing the configurations, run the display vsi name a2 verbose
command on PE1. The command output shows that the VSI named a2 has
established a PW to PE2, and the status of the VSI is up.
[~PE1] display vsi name a2 verbose
***VSI Name : a2
Work Mode : noarmal
Administrator VSI : no
Isolate Spoken : disable
VSI Index :1
PW Signaling : ldp
Member Discovery Style : --
Bridge-domain Mode : disable
PW MAC Learn Style : unqualify
Encapsulation Type : vlan
MTU : 1500
Diffserv Mode : uniform
Service Class : --
Color : --
DomainId : 255
Domain Name :
Ignore AcState : disable
P2P VSI : disable
Multicast Fast Switch : disable
Create Time : 1 days, 8 hours, 46 minutes, 34 seconds
VSI State : up
Resource Status : --
VSI ID :2
*Peer Router ID : 3.3.3.9
Negotiation-vc-id :2
primary or secondary : primary
ignore-standby-state : no
VC Label : 18
Peer Type : dynamic
Session : up
Tunnel ID : 0x000000000300000001
Broadcast Tunnel ID : --
Broad BackupTunnel ID : --
Tunnel Policy Name : policy1
CKey : 33
NKey : 1610612843
Stp Enable :0
PwIndex :0

(2020-10-09)
Control Word : disable

BFD for PW : unavailable
Interface Name : GigabitEthernet2/0/0.1

State : up
Ac Block State : unblocked
Access Port : false
Last Up Time : 2012/09/10 10:14:46
Total Up Time : 1 days, 8 hours, 41 minutes, 37 seconds
**PW Information:
*Peer Ip Address : 3.3.3.9

PW State : up
Local VC Label : 18
Remote VC Label : 18
Remote Control Word : disable
PW Type : label
Local VCCV : alert lsp-ping bfd
Remote VCCV : alert lsp-ping bfd
Tunnel ID : 0x000000000300000001
Ckey : 33
Nkey : 1610612843
Main PW Token : 0x0
Slave PW Token : 0x0
Tnl Type : te
OutInterface : Tunnel10
Backup OutInterface : --
Stp Enable :0
Mac Flapping :0
Monitor Group Name : --
PW Last Up Time : 2012/09/11 09:19:12
PW Total Up Time : 1 days, 6 hours, 52 minutes, 3 seconds
Run the display vsi pw out-interface vsi a2 command on PE2. The command
output shows that the outbound interface of the MPLS TE tunnel between 1.1.1.9
and 3.3.3.9 is Tunnel 10.
[~PE1] display vsi pw out-interface vsi a2
Total: 1
--------------------------------------------------------------------------------
Vsi Name peer vcid interface
--------------------------------------------------------------------------------
a2 3.3.3.9 2 Tunnel10
CE1 and CE2 can ping each other.

[~CE1] ping 10.1.1.2
0.00% packet loss
----End
Configuration Files
#
sysname CE1

(2020-10-09)
#
undo shutdown
#
interface GigabitEthernet1/0/0.1
vlan-type dot1q 10
ip address 10.1.1.1 255.255.255.0
#
return
#
sysname PE1
#
mpls lsr-id 1.1.1.9
#
mpls
mpls te
#
mpls l2vpn
#
vsi a2
pwsignal ldp
vsi-id 2
peer 3.3.3.9 tnl-policy policy1
#
explicit-path path2pe2
#
mpls ldp
#
ipv4-family
#
mpls ldp remote-peer 3.3.3.9
remote-ip 3.3.3.9
#
segment-routing
#
undo shutdown
ip address 10.10.1.1 255.255.255.0
#
undo shutdown
#
vlan-type dot1q 10
l2 binding vsi a2
#
interface LoopBack1
ip address 1.1.1.9 255.255.255.255
ospf prefix-sid absolute 16100
#
interface Tunnel10
destination 3.3.3.9
mpls te reserved-for-binding
mpls te tunnel-id 100
mpls te path explicit-path path2pe2
#
ospf 1
area 0.0.0.0
network 1.1.1.9 0.0.0.0
network 10.10.1.0 0.0.0.255

(2020-10-09)
mpls-te enable
#
tunnel-policy policy1
tunnel binding destination 3.3.3.9 te Tunnel10
#
return
#
sysname P
#
mpls lsr-id 2.2.2.9
#
mpls
mpls te
#
segment-routing
#
undo shutdown
ip address 10.10.1.2 255.255.255.0
#
undo shutdown
ip address 10.20.1.1 255.255.255.0
#
interface LoopBack1
ip address 2.2.2.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 2.2.2.9 0.0.0.0
network 10.10.1.0 0.0.0.255
network 10.20.1.0 0.0.0.255
mpls-te enable
#
return
#
sysname PE2
#
mpls lsr-id 3.3.3.9
#
mpls
mpls te
#
mpls l2vpn
#
vsi a2
pwsignal ldp
vsi-id 2
peer 1.1.1.9 tnl-policy policy1
#
#
segment-routing
#
undo shutdown
ip address 10.20.1.2 255.255.255.0
#
undo shutdown

(2020-10-09)
#
vlan-type dot1q 10
l2 binding vsi a2
#
interface LoopBack1
ip address 3.3.3.9 255.255.255.255
#
interface Tunnel10
destination 1.1.1.9
#
ospf 1
area 0.0.0.0
network 3.3.3.9 0.0.0.0
network 10.20.1.0 0.0.0.255
mpls-te enable
#
#
return

#
sysname CE2
#
undo shutdown
#
vlan-type dot1q 10
ip address 10.1.1.2 255.255.255.0
#
return
1.2.40.3 Example for Configuring BD EVPN IRB over SR-MPLS TE

This section provides an example for configuring BD EVPN IRB over SR-MPLS TE.
On the network shown in Figure 1-127, the EVPN and VPN functions are
configured to transmit Layer 2 and Layer 3 traffic to allow communication
between different sites on the backbone network. If Site 1 and Site 2 are
connected through the same subnet, create an EVPN instance on each PE to store
EVPN routes. Layer 2 forwarding is based on an EVPN route that matches a MAC
address. If Site 1 and Site 2 are connected through different subnets, create a VPN
instance on each PE to store VPN routes. In this situation, Layer 2 traffic is
terminated, and Layer 3 traffic is forwarded through a Layer 3 gateway. In this
example, PEs transmit service traffic over SR-MPLS TE tunnels.

(2020-10-09)
Figure 1-127 Networking of BD EVPN IRB over SR-MPLS TE

NOTE
Interface 1, interface 2, and sub-interface 1.1 in this example represent GE 1/0/0, GE 2/0/0, and
GE 1/0/0.1, respectively.
Configuration Notes
When configuring BD EVPN IRB over SR-MPLS TE, note the following:
● On the same EVPN instance, the export VPN target list of a site shares VPN
targets with the import VPN target lists of the other sites, and the import VPN
target list of a site shares VPN targets with the export VPN target lists of the
other sites.
● Using the local loopback interface address of a PE as the EVPN source address
is recommended.
1. Configure an IGP to allow communication between PE1, PE2, and P.
2. Configure an SR-MPLS TE tunnel on the backbone network.
3. Configure an EVPN instance and a VPN instance on each PE.
4. Configure an EVPN source address on each PE.
5. Configure the Layer 2 Ethernet sub-interfaces connecting PEs and CEs.
6. Configure a vBDIF interface on each PE and bind the vBDIF interface to a VPN
instance.
7. Configure and apply a tunnel policy so that EVPN can recurse to SR-MPLS TE
tunnels.

(2020-10-09)
8. Establish BGP EVPN peer relationships between PEs.

9. Configure CEs to communicate with PEs.
Data Preparation
● EVPN instance name (evrf1) and VPN instance name (vpn1)

● EVPN instance evrf1's RD (100:1) and RT (1:1) on PE1, EVPN instance evrf1's
RD (200:1) and RT (1:1) on PE2, VPN instance vpn1's RD (100:2) and RT (2:2)
on PE1, and VPN instance vpn1's RD (200:2) and RT (2:2) on PE2
Procedure
Step 1 Configure IP addresses for the interfaces connecting PEs and P2 according to
Figure 1-127.
# Configure PE1.
[*HUAWEI] commit
[*PE1] commit
# Configure P.
[~HUAWEI] sysname P
[*HUAWEI] commit
[*P-LoopBack1] quit
[*P] commit
# Configure PE2.
[*HUAWEI] commit
[*PE2] commit
Step 2 Configure an IGP to allow communication between PE1, PE2, and P. IS-IS is used
as an IGP protocol in this example.
# Configure PE1.

(2020-10-09)
[~PE1] isis 1
[*PE1-isis-1] quit
[*PE1] interface GigabitEthernet 2/0/0
[*PE1] commit
# Configure the P.
[~P] isis 1
[*P-isis-1] quit
[*P-LoopBack1] quit
[*P] interface GigabitEthernet 1/0/0
[*P] commit
# Configure PE2.
[~PE2] isis 1
[*PE2-isis-1] quit
[*PE2] commit
After completing the configuration, run the display isis peer command to check
that the status of the IS-IS neighbor relationship between PE1, PE2, and P is Up.
Run the display ip routing-table command to view that the PEs have learned the
routes to Loopback1 of each other.
[~PE1] display isis peer
Peer information for ISIS(1)
System Id Interface Circuit Id State HoldTime Type PRI

--------------------------------------------------------------------------------
1111.1111.2222 GE2/0/0 1111.1111.2222.01 Up 8s L2 64
Total Peer(s): 1
[~PE1] display ip routing-table
------------------------------------------------------------------------------
Routing Table : _public_
1.1.1.1/32 Direct 0 0 D 127.0.0.1 LoopBack1

2.2.2.2/32 ISIS-L2 15 10 D 10.1.1.2 GigabitEthernet2/0/0

(2020-10-09)

Step 3 Configure an SR-MPLS TE tunnel on the backbone network.
# Configure PE1.
[*PE1] mpls
[*PE1-mpls] mpls te
[*PE1-mpls] quit
[*PE1] isis 1
NOTE
The value range of SRGB varies according to the actual situation. This is only an example.
[*PE1-isis-1] quit
[*PE1] explicit-path pe1tope2
[*PE1-explicit-path-pe1tope2] next sid label 48121 type adjacency
[*PE1-explicit-path-pe1tope2] quit
[*PE1-Tunnel1] ip address unnumbered interface loopback 1
[*PE1-Tunnel1] mpls te path explicit-path pe1tope2
[*PE1-Tunnel1] quit
[*PE1] commit
NOTE
The next sid label command uses the adjacency label from PE1 to P which is dynamically
generated using IS-IS. This adjacency label can be obtained using the display segment-routing
adjacency mpls forwarding command.
[~PE1] display segment-routing adjacency mpls forwarding
Segment Routing Adjacency MPLS Forwarding Information
Label Interface NextHop Type MPLSMtu Mtu

-----------------------------------------------------------------------------
48121 GE2/0/0 10.1.1.2 ISIS-V4 --- 1500
# Configure the P.
[*P] mpls
[*P-mpls] mpls te
[*P-mpls] quit
[*P] segment-routing
[*P] isis 1

(2020-10-09)

[*P-isis-1] traffic-eng level-2
NOTE
[*P-isis-1] quit
[*P-LoopBack1] isis prefix-sid absolute 153710
[*P-LoopBack1] quit
[*P] commit
NOTE
After the configuration is complete, yan can view the adjacency labels by using the display
segment-routing adjacency mpls forwarding command.
[~P] display segment-routing adjacency mpls forwarding

-----------------------------------------------------------------------------
48221 GE1/0/0 10.1.1.1 ISIS-V4 --- 1500
48120 GE2/0/0 10.2.1.2 ISIS-V4 --- 1500
# Configure PE2.
[*PE2] mpls
[*PE2-mpls] mpls te
[*PE2-mpls] quit
[*PE2] isis 1
NOTE
[*PE2-isis-1] quit
[*PE2-Tunnel1] quit
[*PE2] commit

(2020-10-09)
NOTE

-----------------------------------------------------------------------------
48220 GE2/0/0 10.2.1.1 ISIS-V4 --- 1500
After completing the configuration, run the display mpls te tunnel-interface

command to check that the tunnel interface is Up.
[~PE1] display mpls te tunnel-interface
Tunnel Name : Tunnel1
Signalled Tunnel Name: -
Tunnel State Desc : CR-LSP is Up
Tunnel Attributes :
Active LSP : Primary LSP
Traffic Switch :-
Session ID :1
Ingress LSR ID : 1.1.1.1 Egress LSR ID: 3.3.3.3
Admin State : UP Oper State : UP
Signaling Protocol : Segment-Routing
FTid :1
Tie-Breaking Policy : None Metric Type : None
Bfd Cap : None
Reopt : Disabled Reopt Freq : -
Auto BW : Disabled Threshold : -
Current Collected BW: - Auto BW Freq : -
Min BW :- Max BW :-
Offload : Disabled Offload Freq : -
Low Value :- High Value : -
Readjust Value :-
Offload Explicit Path Name: -
Tunnel Group : Primary
Interfaces Protected: -
Excluded IP Address : -
Referred LSP Count : 0
Primary Tunnel :- Pri Tunn Sum : -
Backup Tunnel :-
Group Status : Up Oam Status : None
IPTN InLabel :- Tunnel BFD Status : -
BackUp LSP Type : None BestEffort : -
Secondary HopLimit : -
BestEffort HopLimit : -
Secondary Explicit Path Name: -
Secondary Affinity Prop/Mask: 0x0/0x0
BestEffort Affinity Prop/Mask: -
IsConfigLspConstraint: -
Hot-Standby Revertive Mode: Revertive
Hot-Standby Overlap-path: Disabled
Hot-Standby Switch State: CLEAR
Bit Error Detection: Disabled
Bit Error Detection Switch Threshold: -
Bit Error Detection Resume Threshold: -
Ip-Prefix Name : -
P2p-Template Name : -
PCE Delegate : No LSP Control Status : Local control
Path Verification : No
Entropy Label :-
Associated Tunnel Group ID: - Associated Tunnel Group Type: -
Auto BW Remain Time : - Reopt Remain Time :-
Segment-Routing Remote Label : -

(2020-10-09)
Binding Sid :- Reverse Binding Sid : -

FRR Attr Source : - Is FRR degrade down : No
Primary LSP ID : 1.1.1.1:2
LSP State : UP LSP Type : Primary
Setup Priority :7 Hold Priority: 7
IncludeAll : 0x0
IncludeAny : 0x0
ExcludeAny : 0x0
Affinity Prop/Mask : 0x0/0x0 Resv Style : SE
Configured Bandwidth Information:
CT0 Bandwidth(Kbit/sec): 0 CT1 Bandwidth(Kbit/sec): 0
Actual Bandwidth Information:
Explicit Path Name : pe1tope2 Hop Limit: -
Record Route :- Record Label : -
Route Pinning :-
FRR Flag :-
IdleTime Remain :-
BFD Status :-
Soft Preemption :-
Reroute Flag :-
Pce Flag : Normal
Path Setup Type : EXPLICIT
Create Modify LSP Reason: -
Step 4 Configure an EVPN instance and a VPN instance on each PE.
# Configure PE1.
[~PE1] evpn vpn-instance evrf1 bd-mode
[*PE1-evpn-instance-evrf1] route-distinguisher 100:1
[*PE1-evpn-instance-evrf1] vpn-target 1:1
[*PE1-evpn-instance-evrf1] quit
[*PE1] ip vpn-instance vpn1
[*PE1-vpn-instance-vpn1] ipv4-family
[*PE1-vpn-instance-vpn1-af-ipv4] route-distinguisher 100:2
[*PE1-vpn-instance-vpn1-af-ipv4] vpn-target 2:2 evpn
[*PE1-vpn-instance-vpn1-af-ipv4] quit
[*PE1-vpn-instance-vpn1] evpn mpls routing-enable
[*PE1-vpn-instance-vpn1] quit
[*PE1] bridge-domain 10
[*PE1-bd10] evpn binding vpn-instance evrf1
[*PE1-bd10] quit
[*PE1] commit
# Configure PE2.
[*PE2-bd10] quit
[*PE2] commit

(2020-10-09)
Step 5 Configure an EVPN source address on each PE.

# Configure PE1.
[~PE1] evpn source-address 1.1.1.1
[*PE1] commit
# Configure PE2.
[*PE2] commit
Step 6 Configure the Layer 2 Ethernet sub-interfaces connecting PEs and CEs.
# Configure PE1.
[~PE1] interface GigabitEthernet 1/0/0
[*PE1-Gigabitethernet1/0/0] esi 0011.1111.1111.1111.1111
[*PE1-Gigabitethernet1/0/0] quit
[*PE1] interface GigabitEthernet 1/0/0.1 mode l2
[*PE1-GigabitEthernet 1/0/0.1] encapsulation dot1q vid 10
[*PE1-GigabitEthernet 1/0/0.1] rewrite pop single
[*PE1-GigabitEthernet 1/0/0.1] bridge-domain 10
[*PE1-GigabitEthernet 1/0/0.1] quit
[*PE1] commit
# Configure PE2.
[~PE2] interface GigabitEthernet 1/0/0
[*PE2-Gigabitethernet1/0/0] esi 0011.1111.1111.1111.2222
[*PE2-Gigabitethernet1/0/0] quit
[*PE2] interface GigabitEthernet 1/0/0.1 mode l2
[*PE2] commit
Step 7 Configure a vBDIF interface on each PE and bind the vBDIF interface to a VPN
instance.
# Configure PE1.
[~PE1] interface Vbdif10
[*PE1-Vbdif10] ip binding vpn-instance vpn1
[*PE1-Vbdif10] ip address 192.168.1.1 255.255.255.0
[*PE1-Vbdif10] quit
[*PE1] commit
# Configure PE2.
[~PE2] interface Vbdif10
[*PE2-Vbdif10] quit
[*PE2] commit
Step 8 Configure and apply a tunnel policy so that EVPN can recurse to SR-MPLS TE
tunnels.
# Configure PE1.
[~PE1] tunnel-policy srte
[*PE1-tunnel-policy-srte] tunnel binding destination 3.3.3.3 te Tunnel1
[*PE1-tunnel-policy-srte] quit
[*PE1] evpn vpn-instance evrf1 bd-mode
[*PE1-evpn-instance-evrf1] tnl-policy srte

(2020-10-09)
[*PE1-vpn-instance-vpn1] tnl-policy srte evpn

[*PE1] commit
# Configure PE2.
[*PE2-evpn-instance-evrf1] tnl-policy srte
[*PE2-vpn-instance-vpn1] tnl-policy srte evpn
[*PE2] commit
Step 9 Establish BGP EVPN peer relationships between PEs.

# Configure PE1.
[~PE1] bgp 100
[*PE1-bgp] l2vpn-family evpn
[*PE1-bgp-af-evpn] peer 3.3.3.3 enable
[*PE1-bgp-af-evpn] peer 3.3.3.3 advertise irb
[*PE1-bgp-af-evpn] quit
[*PE1-bgp] ipv4-family vpn-instance vpn1
[*PE1-bgp-vpn1] import-route direct
[*PE1-bgp-vpn1] advertise l2vpn evpn
[*PE1-bgp-vpn1] quit
[*PE1-bgp] quit
[*PE1] commit
# Configure PE2.
[~PE2] bgp 100
[*PE2-bgp] quit
[*PE2] commit
After completing the configuration, run the display bgp evpn peer command to
check that BGP peer relationships have been established between PEs and are in
the Established state. The following example uses the command output on PE1.
[~PE1] display bgp evpn peer


3.3.3.3 4 100 9 9 0 00:00:02 Established 5
Step 10 Configure CEs to communicate with PEs.

# Configure CE1.
[~CE1] interface GigabitEthernet 1/0/0.1 mode l2

(2020-10-09)
[*CE1-GigabitEthernet1/0/0.1] encapsulation dot1q vid 10

[*CE1-GigabitEthernet1/0/0.1] rewrite pop single
[*CE1] commit
# Configure CE2.
[~CE2] interface GigabitEthernet 1/0/0.1 mode l2
[*CE2] commit
After completing the configurations, run the display bgp evpn all routing-table
command on PEs to view the EVPN routes sent from the peer PEs. The following
example uses the command output on PE1.
[~PE1] display bgp evpn all routing-table
BGP Local router ID is 1.1.1.1

Status codes: * - valid, > - best, d - damped, x - best external, a - add path,
h - history, i - internal, s - suppressed, S - Stale
Origin : i - IGP, e - EGP, ? - incomplete
EVPN address family:

Number of A-D Routes: 4
Route Distinguisher: 100:1
Network(ESI/EthTagId) NextHop
*> 0011.1111.1111.1111.1111:0 127.0.0.1
*>i 0011.1111.1111.1111.2222:0 3.3.3.3
Route Distinguisher: 1.1.1.1:0
*> 0011.1111.1111.1111.1111:4294967295 127.0.0.1
*>i 0011.1111.1111.1111.2222:4294967295 3.3.3.3
EVPN-Instance evrf1:
*> 0011.1111.1111.1111.1111:0 127.0.0.1
*>i 0011.1111.1111.1111.2222:0 3.3.3.3
*>i 0011.1111.1111.1111.2222:4294967295 3.3.3.3

Number of Mac Routes: 2
Network(EthTagId/MacAddrLen/MacAddr/IpAddrLen/IpAddr) NextHop
*> 0:48:00e0-fc12-7890:32:192.168.1.1 0.0.0.0
*>i 0:48:00e0-fc12-3456:32:192.168.2.1 3.3.3.3
*>i 0:48:00e0-fc12-3456:32:192.168.2.1 3.3.3.3
*> 0:48:00e0-fc12-7890:32:192.168.1.1 0.0.0.0

Number of Inclusive Multicast Routes: 2

(2020-10-09)

Network(EthTagId/IpAddrLen/OriginalIp) NextHop
*> 0:32:1.1.1.1 127.0.0.1
*>i 0:32:3.3.3.3 3.3.3.3
*> 0:32:1.1.1.1 127.0.0.1
*>i 0:32:3.3.3.3 3.3.3.3

Number of ES Routes: 2
Network(ESI) NextHop
*> 0011.1111.1111.1111.1111 127.0.0.1
*>i 0011.1111.1111.1111.2222 3.3.3.3
*> 0011.1111.1111.1111.1111 127.0.0.1
*>i 0011.1111.1111.1111.2222 3.3.3.3

Number of Ip Prefix Routes: 2
Network(EthTagId/IpPrefix/IpPrefixLen) NextHop
*> 0:192.168.1.0:24 0.0.0.0
*>i 0:192.168.2.0:24 3.3.3.3
The display bgp evpn all routing-table mac-route 0:48:00e0-

fc12-3456:32:192.168.2.1 or display bgp evpn all routing-table prefix-route
0:192.168.2.0:24 command output shows that the detailed information about
MAC routes or IP prefix routes contains the tunnel interface name of the recursive
routes.
[~PE1] display bgp evpn all routing-table mac-route 0:48:00e0-fc12-3456:32:192.168.2.1
Total routes of Route Distinguisher(200:1): 1
BGP routing table entry information of 0:48:00e0-fc12-3456:32:192.168.2.1:
Label information (Received/Applied): 54011 48182/NULL
From: 3.3.3.3 (3.3.3.3)
Route Duration: 0d20h42m36s
Relay IP Nexthop: 10.1.1.2
Relay IP Out-Interface: GigabitEthernet2/0/0
Relay Tunnel Out-Interface: GigabitEthernet2/0/0
Original nexthop: 3.3.3.3
Qos information : 0x0
Ext-Community: RT <1 : 1>, Mac Mobility <flag:1 seq:0 res:0>
AS-path Nil, origin incomplete, localpref 100, pref-val 0, valid, internal, best, select, pre 255, IGP cost 20
Route Type: 2 (MAC Advertisement Route)
Ethernet Tag ID: 0, MAC Address/Len: 00e0-fc12-3456/48, IP Address/Len: 0.0.0.0/0, ESI:
0000.0000.0000.0000.0000
Not advertised to any peer yet

(2020-10-09)

Remote-Cross route
Label information (Received/Applied): 54011 48182/NULL
From: 3.3.3.3 (3.3.3.3)
Relay Tunnel Out-Interface: Tunnel1
Ext-Community: RT <1 : 1>, Mac Mobility <flag:1 seq:0 res:0>
AS-path Nil, origin incomplete, localpref 100, pref-val 0, valid, internal, best, select, pre 255
0000.0000.0000.0000.0000
[~PE1] display bgp evpn all routing-table prefix-route 0:192.168.2.0:24
BGP routing table entry information of 0:192.168.2.0:24:
Label information (Received/Applied): 48185/NULL
From: 3.3.3.3 (3.3.3.3)
Ext-Community: RT <2 : 2>
AS-path Nil, origin incomplete, MED 0, localpref 100, pref-val 0, valid, internal, best, select, pre 255, IGP
cost 20
Route Type: 5 (Ip Prefix Route)
Ethernet Tag ID: 0, IP Prefix/Len: 192.168.2.0/24, ESI: 0000.0000.0000.0000.0000, GW IP Address: 0.0.0.0
----End
Configuration Files
#
sysname PE1
#
evpn vpn-instance evrf1 bd-mode
tnl-policy srte
#
ip vpn-instance vpn1
ipv4-family
vpn-target 2:2 export-extcommunity evpn
vpn-target 2:2 import-extcommunity evpn
tnl-policy srte evpn
evpn mpls routing-enable
#
mpls lsr-id 1.1.1.1
#
mpls
mpls te
#
bridge-domain 10
evpn binding vpn-instance evrf1
#
explicit-path pe1tope2
next sid label 48121 type adjacency

(2020-10-09)

#
segment-routing
#
isis 1
is-level level-2
cost-style wide
network-entity 00.1111.1111.1111.00
traffic-eng level-2
#
interface Vbdif10
ip binding vpn-instance vpn1
ip address 192.168.1.1 255.255.255.0
#
undo shutdown
esi 0011.1111.1111.1111.1111
#
interface GigabitEthernet1/0/0.1 mode l2
encapsulation dot1q vid 10
rewrite pop single
bridge-domain 10
#
undo shutdown
ip address 10.1.1.1 255.255.255.0
isis enable 1
#
interface LoopBack1
ip address 1.1.1.1 255.255.255.255
isis enable 1
#
interface Tunnel1
destination 3.3.3.3
mpls te tunnel-id 1
mpls te path explicit-path pe1tope2
#
bgp 100
#
ipv4-family unicast
peer 3.3.3.3 enable
#
ipv4-family vpn-instance vpn1
import-route direct
advertise l2vpn evpn
#
l2vpn-family evpn
policy vpn-target
peer 3.3.3.3 enable
peer 3.3.3.3 advertise irb
#
tunnel-policy srte
#
evpn source-address 1.1.1.1
#
return

(2020-10-09)
#
sysname P
#
mpls lsr-id 2.2.2.2
#
mpls
mpls te
#
segment-routing
#
isis 1
is-level level-2
cost-style wide
network-entity 00.1111.1111.2222.00
traffic-eng level-2
#
undo shutdown
ip address 10.1.1.2 255.255.255.0
isis enable 1
#
undo shutdown
ip address 10.2.1.1 255.255.255.0
isis enable 1
#
interface LoopBack1
ip address 2.2.2.2 255.255.255.255
isis enable 1
#
return
#
sysname PE2
#
tnl-policy srte
#
ipv4-family
#
mpls lsr-id 3.3.3.3
#
mpls
mpls te
#
bridge-domain 10
#
#
segment-routing
#
isis 1
is-level level-2

(2020-10-09)
cost-style wide
network-entity 00.1111.1111.3333.00
traffic-eng level-2
#
interface Vbdif10
ip address 192.168.2.1 255.255.255.0
#
undo shutdown
esi 0011.1111.1111.1111.2222
#
rewrite pop single
bridge-domain 10
#
undo shutdown
ip address 10.2.1.2 255.255.255.0
isis enable 1
#
interface LoopBack1
ip address 3.3.3.3 255.255.255.255
isis enable 1
#
interface Tunnel1
destination 1.1.1.1
mpls te tunnel-id 1
#
bgp 100
#
ipv4-family unicast
peer 1.1.1.1 enable
#
import-route direct
#
l2vpn-family evpn
policy vpn-target
peer 1.1.1.1 enable
#
tunnel-policy srte
#
#
return
#
sysname CE1
#
undo shutdown
#

(2020-10-09)

rewrite pop single
#
return
#
sysname CE2
#
undo shutdown
#
rewrite pop single
#
return
1.2.40.4 Example for Configuring EVPN L3VPNv6 over SR-MPLS TE

This section provides an example for configuring EVPN L3VPNv6 to iterate traffic
over an SR-MPLS TE tunnel.
On the network shown in Figure 1-128, EVPN L3VPNv6 is configured on the
backbone network to allow IPv6 interworking at Layer 3 between CEs. In this
Figure 1-128 Networking of configuring EVPN L3VPNv6 over SR-MPLS TE

NOTE

(2020-10-09)
Configuration Notes
When configuring EVPN L3VPNv6 over SR-MPLS TE, note the following:
● For the same VPN instance, the export VPN target list of a site shares VPN
other sites.
is recommended.
3. Configure an IPv6 VPN instance on each PE and bind the IPv6 VPN instance to
an interface.
5. Configure and apply a tunnel policy so that EVPN routes can be iterated over
SR-MPLS TE tunnels.
6. Establish VPN BGP peer relationships between PEs and CEs.
Data Preparation
● Name of the IPv6 VPN instance: vpn1
● RD (100:1) and RT (1:1) of the IPv6 VPN instance
Procedure
Step 1 Configure interface IP addresses of each device.
# Configure PE1.
[*HUAWEI] commit
[*PE1] commit
# Configure P.
[~HUAWEI] sysname P
[*HUAWEI] commit
[*P-LoopBack1] quit

(2020-10-09)
[*P] commit
# Configure PE2.
[*HUAWEI] commit
[*PE2] commit
Step 2 Configure an IGP to allow communication between PE1, PE2, and P. IS-IS is used
as an IGP protocol in this example.
# Configure PE1.
[~PE1] isis 1
[*PE1-isis-1] quit
[*PE1] commit
# Configure the P.
[~P] isis 1
[*P-isis-1] quit
[*P-LoopBack1] quit
[*P] commit
# Configure PE2.
[~PE2] isis 1
[*PE2-isis-1] quit
[*PE2] commit
After completing the configurations, run the display isis peer command to check
that the status of the IS-IS neighbor relationship between PE1, PE2, and the P is

(2020-10-09)
Up. Run the display ip routing-table command to view that the PEs have learned
the routes to Loopback1 of each other.

--------------------------------------------------------------------------------
1111.1111.2222 GE2/0/0 1111.1111.2222.02 Up 7s L2 64
Total Peer(s): 1
------------------------------------------------------------------------------

Step 3 Configure an SR-MPLS TE tunnel on the backbone network.

# Configure PE1.
[*PE1] mpls
[*PE1-mpls] mpls te
[*PE1-mpls] quit
[*PE1] isis 1
NOTE
The value range of SRGB varies according to the actual situation. This is only an example.
[*PE1-isis-1] quit
[*PE1-Tunnel1] quit

(2020-10-09)
[*PE1] commit
NOTE

-----------------------------------------------------------------------------
48140 GE2/0/0 10.1.1.2 ISIS-V4 --- 1500
# Configure the P.
[*P] mpls
[*P-mpls] mpls te
[*P-mpls] quit
[*P] segment-routing
[*P] isis 1
[*P-isis-1] traffic-eng level-2
NOTE
[*P-isis-1] quit
[*P-LoopBack1] isis prefix-sid absolute 153710
[*P-LoopBack1] quit
[*P] commit
NOTE
After the configuration is complete, yan can view the adjacency labels by using the display
segment-routing adjacency mpls forwarding command.
[~P] display segment-routing adjacency mpls forwarding

-----------------------------------------------------------------------------
48241 GE1/0/0 10.1.1.1 ISIS-V4 --- 1500
48140 GE2/0/0 10.2.1.2 ISIS-V4 --- 1500
# Configure PE2.
[*PE2] mpls
[*PE2-mpls] mpls te
[*PE2-mpls] quit
[*PE2] isis 1
NOTE

(2020-10-09)
[*PE2-isis-1] quit
[*PE2-Tunnel1] quit
[*PE2] commit
NOTE

-----------------------------------------------------------------------------
48240 GE2/0/0 10.2.1.1 ISIS-V4 --- 1500
After completing the configurations, run the display mpls te tunnel-interface

command to check that the tunnel interface is Up.
[~PE1] display mpls te tunnel-interface
Tunnel Attributes :
Traffic Switch :-
Session ID :1
FTid :1
Bfd Cap : None
Min BW :- Max BW :-
Readjust Value :-
Backup Tunnel :-

(2020-10-09)

Ip-Prefix Name : -
Entropy Label :-

IncludeAll : 0x0
IncludeAny : 0x0
ExcludeAny : 0x0
Explicit Path Name : pe1tope2 Hop Limit: -
Route Pinning :-
FRR Flag :-
IdleTime Remain :-
BFD Status :-
Soft Preemption :-
Reroute Flag :-
Pce Flag : Normal
Step 4 Configure an IPv6 VPN instance on each PE and bind the IPv6 VPN instance to an
interface.
# Configure PE1.
[~PE1] ip vpn-instance vpn1
[*PE1-vpn-instance-vpn1-af-ipv6] evpn mpls routing-enable
[*PE1-GigabitEthernet1/0/0] ip binding vpn-instance vpn1
[*PE1-GigabitEthernet1/0/0] ipv6 enable
[*PE1-GigabitEthernet1/0/0] ipv6 address 2001:DB8:1::1 64
[*PE1] commit

(2020-10-09)
# Configure PE2.
[*PE2] commit
Step 5 Configure and apply a tunnel policy so that EVPN can iterate SR-MPLS TE tunnels.
# Configure PE1.
[*PE1-vpn-instance-vpn1-af-ipv6] tnl-policy srte evpn
[*PE1] commit
# Configure PE2.
[*PE2-vpn-instance-vpn1-af-ipv6] tnl-policy srte evpn
[*PE2] commit
Step 6 Establish BGP EVPN peer relationships between PEs.

# Configure PE1.
[~PE1] bgp 100
[*PE1-bgp-6-vpn1] import-route direct
[*PE1-bgp-6-vpn1] advertise l2vpn evpn
[*PE1-bgp-6-vpn1] quit
[*PE1-bgp] quit
[*PE1] commit
# Configure PE2.
[~PE2] bgp 100

(2020-10-09)
[*PE2-bgp] quit
[*PE2] commit
After completing the configurations, run the display bgp evpn peer command to
check that BGP peer relationships have been established between PEs and are in
the Established state. The following example uses the command output on PE1.


3.3.3.3 4 100 9 9 0 00:00:02 Established 5
Step 7 Establish VPN BGP peer relationships between PEs and CEs.
# Configure EBGP on PE1.
[~PE1] bgp 100
[*PE1-bgp-6-vpn1] peer 2001:DB8:1::2 as-number 65410
[*PE1-bgp] quit
[*PE1] commit
# Configure EBGP on CE1.

[*CE1-LoopBack1] ipv6 enable
[*CE1-LoopBack1] ipv6 address 2001:DB8:4::4 128
[*CE1] interface GigabitEthernet 1/0/0
[*CE1-GigabitEthernet1/0/0] ipv6 enable
[*CE1-GigabitEthernet1/0/0] ipv6 address 2001:DB8:1::2 64
[*CE1] bgp 65410
[*CE1-bgp] router-id 4.4.4.4
[*CE1-bgp] peer 2001:db8:1::1 as-number 100
[*CE1-bgp] ipv6-family unicast
[*CE1-bgp-af-ipv6] peer 2001:db8:1::1 enable
[*CE1-bgp-af-ipv6] import-route direct
[*CE1-bgp-af-ipv6] quit
[*CE1-bgp] quit
[*CE1] commit
The configurations of establishing a VPN BGP peer relationship between PE2 and
CE2 is similar to those of establishing a VPN BGP peer relationship between PE1
and CE1. For configuration details, see configuration file in this section.
command on PEs to view the EVPN routes sent from the peer PEs. The following


(2020-10-09)

*> 0:[2001:DB8:1::]:64 ::
* ::2001:DB8:1::2
*>i 0:[2001:DB8:2::]:64 ::FFFF:3.3.3.3
*> 0:[2001:DB8:4::4]:128 ::2001:DB8:1::2
*>i 0:[2001:DB8:5::5]:128 ::FFFF:3.3.3.3
[~PE1] display bgp evpn all routing-table prefix-route 0:[2001:DB8:5::5]:128

BGP routing table entry information of 0:[2001:DB8:5::5]:
128:
From: 3.3.3.3 (3.3.3.3)
Relay IP Out-Interface:
GigabitEthernet2/0/0
Relay Tunnel Out-Interface:
GigabitEthernet2/0/0
Original nexthop: ::FFFF:3.3.3.3
AS-path 65420, origin incomplete, MED 0, localpref 100, pref-val 0, valid, internal, best, select, pre 255, IGP
cost 20
Ethernet Tag ID: 0, IPv6 Prefix/Len: 2001:DB8:5::5/128, ESI: 0000.0000.0000.0000.0000, GW IPv6
Address: ::
Run the display ipv6 routing-table vpn-instance vpn1 command on the PEs to
view the VPN instance routing table information. The following example uses the
command output on PE1.
[~PE1] display ipv6 routing-table vpn-instance vpn1
Routing Table : vpn1
Destination : 2001:DB8:1:: PrefixLength : 64

NextHop : 2001:DB8:1::1 Preference : 0
Cost :0 Protocol : Direct
RelayNextHop : :: TunnelID : 0x0
Interface : GigabitEthernet1/0/0 Flags :D
Destination : 2001:DB8:1::1 PrefixLength : 128

NextHop : ::1 Preference : 0

NextHop : ::FFFF:3.3.3.3 Preference : 255
Cost :0 Protocol : IBGP
RelayNextHop : ::FFFF:0.0.0.0 TunnelID :
0x000000000300000001
Interface : Tunnel1 Flags : RD

Cost :0 Protocol : EBGP
RelayNextHop : 2001:DB8:1::2 TunnelID : 0x0
Interface : GigabitEthernet1/0/0 Flags : RD


(2020-10-09)
RelayNextHop : ::FFFF:0.0.0.0 TunnelID :

0x000000000300000001
Interface : Tunnel1 Flags : RD
Destination : FE80:: PrefixLength : 10

NextHop : :: Preference : 0
Interface : NULL0 Flags : DB
Run the display ipv6 routing-table brief command on the CEs to view the IPv6
routing table information. The following example uses the command output on
CE1.
[~CE1] display ipv6 routing-table brief
Route Flags: R - relay, D - download to fib, T - to vpn-instance, B - black hole
route
------------------------------------------------------------------------------
Format :
Destination/Mask Protocol
Nexthop Interface
------------------------------------------------------------------------------
::1/128 Direct
::1 InLoopBack0
::FFFF:127.0.0.0/104 Direct
::FFFF:127.0.0.1 InLoopBack0
::FFFF:127.0.0.1/128 Direct
::1 InLoopBack0
2001:DB8:1::/64 Direct
2001:DB8:1::2 GigabitEthernet1/0/0
2001:DB8:1::2/128 Direct
::1 GigabitEthernet1/0/0
2001:DB8:2::/64 EBGP
2001:DB8:4::4/128 Direct
::1 LoopBack1
2001:DB8:5::5/128 EBGP
FE80::/10 Direct
:: NULL0
The CEs can ping each other. For example, CE1 can ping CE2 (2001:DB8:5::5).
[~CE1] ping ipv6 2001:DB8:5::5
PING 2001:DB8:5::5 : 56 data bytes, press CTRL_C to
break
Reply from 2001:DB8:5::5
bytes=56 Sequence=1 hop limit=61 time=385
ms
bytes=56 Sequence=2 hop limit=61 time=24 ms
--- 2001:DB8:5::5 ping statistics---

0.00% packet loss
round-trip min/avg/max=18/95/385 ms
----End

(2020-10-09)
Configuration Files
#
sysname PE1
#
ipv6-family
#
mpls lsr-id 1.1.1.1
#
mpls
mpls te
#
#
segment-routing
#
isis 1
is-level level-2
cost-style wide
network-entity 00.1111.1111.1111.00
traffic-eng level-2
#
undo shutdown
ipv6 enable
ipv6 address 2001:DB8:1::1/64
#
undo shutdown
ip address 10.1.1.1 255.255.255.0
isis enable 1
#
interface LoopBack1
ip address 1.1.1.1 255.255.255.255
isis enable 1
#
interface Tunnel1
destination 3.3.3.3
mpls te tunnel-id 1
#
bgp 100
#
ipv4-family unicast
peer 3.3.3.3 enable
#
import-route direct

(2020-10-09)

peer 2001:DB8:1::2 as-number 65410
#
l2vpn-family evpn
policy vpn-target
peer 3.3.3.3 enable
#
tunnel-policy srte
#
return
#
sysname P
#
mpls lsr-id 2.2.2.2
#
mpls
mpls te
#
segment-routing
#
isis 1
is-level level-2
cost-style wide
network-entity 00.1111.1111.2222.00
traffic-eng level-2
#
undo shutdown
ip address 10.1.1.2 255.255.255.0
isis enable 1
#
undo shutdown
ip address 10.2.1.1 255.255.255.0
isis enable 1
#
interface LoopBack1
ip address 2.2.2.2 255.255.255.255
isis enable 1
#
return
#
sysname PE2
#
ipv6-family
#
mpls lsr-id 3.3.3.3
#
mpls
mpls te
#
#

(2020-10-09)
segment-routing
#
isis 1
is-level level-2
cost-style wide
network-entity 00.1111.1111.3333.00
traffic-eng level-2
#
undo shutdown
ipv6 enable
#
undo shutdown
ip address 10.2.1.2 255.255.255.0
isis enable 1
#
interface LoopBack1
ip address 3.3.3.3 255.255.255.255
isis enable 1
#
interface Tunnel1
destination 1.1.1.1
mpls te tunnel-id 1
#
bgp 100
#
ipv4-family unicast
peer 1.1.1.1 enable
#
import-route direct
#
l2vpn-family evpn
policy vpn-target
peer 1.1.1.1 enable
#
tunnel-policy srte
#
return
#
sysname CE1
#
undo shutdown
ipv6 enable
#
interface LoopBack1
ipv6 enable
#

(2020-10-09)
bgp 65410
router-id 4.4.4.4
#
ipv4-family unicast
#
ipv6-family unicast
import-route direct
peer 2001:DB8:1::1 enable
#
return

#
sysname CE2
#
undo shutdown
ipv6 enable
#
interface LoopBack1
ipv6 enable
#
bgp 65420
router-id 5.5.5.5
#
ipv4-family unicast
#
ipv6-family unicast
import-route direct
#
return
1.2.40.5 Example for Configuring the Controller to Run NETCONF to Deliver

Configurations to Create an SR-MPLS TE Tunnel
This section provides an example for configuring the controller to run NETCONF to
deliver configurations to create an SR-MPLS TE tunnel.
On the network shown in Figure 1-129, a customer wants to establish a tunnel
and an LSP from PE1 to PE2. The SR protocol is used for path generation and data
forwarding, with PE1 functioning as the ingress, and PE2 the egress. IS-IS neighbor
relationships need to be established between PEs and Ps.
● IS-IS assigns labels to each neighbor and collects network topology
information. P1 runs BGP-LS to collect topology information and reports the
information to the controller.
● The controller uses the information to calculate a path and runs PCEP to
deliver path information to ingress PE1.
● The controller sends the tunnel configuration information to the ingress node
PE1 through NETCONF.

(2020-10-09)
● The ingress node PE1 uses the delivered tunnel configurations and label
stacks to establish an SR-MPLS TE tunnel. PE1 delegates the tunnel to the
controller through PCE.
Figure 1-129 Example for configuring the controller to run NETCONF to deliver
configurations to create an SR-MPLS TE tunnel
NOTE
Interfaces 1 through 3 in this example represent GE 1/0/0, GE 2/0/0, and GE 3/0/0,

respectively.
1. Assign an IP address and its mask to every interface and configure a loopback
interface address as an MPLS LSR-ID on every node.
2. Configure LSR IDs and enable MPLS TE globally and on interfaces on each
LSR.
3. Enable SR globally on each node.
4. Configure a label allocation mode and a topology information collection
mode. In this example, the forwarders assign labels.
5. Configure the PCC and segment routing on each forwarder.
6. Configure the PCE server on the controller.
Data Preparation
● IP addresses of interfaces as shown in Figure 1-129

● IS-IS process ID (1), IS-IS system ID of each node (converted from a
loopback0 IP address), and IS-IS level (level-2)
● BGP-LS peer relationship between the controller and P1, as shown in Figure
1-129.

(2020-10-09)
Procedure
Step 1 Assign an IP address and a mask to each interface.
# Configure PE1.
[*HUAWEI] commit
[*PE1] commit
# Configure P1.
[*HUAWEI] commit
[*P1] commit
# Configure PE2.
[*HUAWEI] commit
[*PE2] commit
Step 2 Configure IS-IS to advertise the route to each network segment to which each
interface is connected and to advertise the host route to each loopback address
that is used as an LSR ID.
# Configure PE1.
[~PE1] isis 1
[*PE1-isis-1] quit
[*PE1] commit
# Configure P1.

(2020-10-09)
[~P1] isis 1
[*P1-isis-1] quit
[*P1] commit
# Configure PE2.
[~PE2] isis 1
[*PE2-isis-1] quit
[*PE2] commit
Step 3 Configure PCE on the forwarders and controller. For configuration details, see
Configuration Files in this section.
Step 4 Configure basic MPLS functions and enable MPLS TE.
# Configure PE1.
[*PE1] mpls
[*PE1-mpls] mpls te
[*PE1-mpls] quit
[*PE1] interface gigabitethernet 1/0/0
[*PE1-GigabitEthernet1/0/0] mpls te
[*PE1-GigabitEthernet1/0/0] commit
[~PE1-GigabitEthernet1/0/0] quit
The configurations on P1 and PE2 are the same as the configuration on PE1. The
configuration details are not provided.
Step 5 Enable SR globally on each node.
# Configure PE1.
[*PE1] commit
Step 6 Configure a label allocation mode and a topology information collection mode. In
this example, the forwarders assign labels.
● Enable IS-IS SR-MPLS TE.
[~PE1] isis 1

(2020-10-09)
[~PE1-isis-1] cost-style wide

[*PE1-isis-1] bgp-ls enable level-2
[*PE1-isis-1] commit
[~PE1-isis-1] quit
The configurations on P1 and PE2 are the same as the configuration on PE1.
The configuration details are not provided.
● Configure the BGP-LS route advertisement capability on P1.
# Enable BGP-LS on P1 and establish a BGP-LS peer relationship with the
controller.
[~P1] bgp 100
[*P1-bgp] peer 10.2.1.2 as-number 100
[*P1-bgp] link-state-family unicast
[*P1-bgp-af-ls] peer 10.2.1.2 enable
[*P1-bgp-af-ls] commit
[~P1-bgp-af-ls] quit
[~P1-bgp] quit
# Enable BGP-LS on the controller and establish a BGP-LS peer relationship
with P1.
[~Controller] bgp 100
[*Controller-bgp] peer 10.2.1.1 as-number 100
[*Controller-bgp] link-state-family unicast
[*Controller-bgp-af-ls] peer 10.2.1.1 enable
[*Controller-bgp-af-ls] commit
[~Controller-bgp-af-ls] quit
[~Controller-bgp] quit
Step 7 The controller sends the tunnel configuration information to PE1 through
NETCONF.
The detailed tunnel configuration delivered by the controller through NETCONF is
as follows:
[~PE1] interface tunnel1
[*PE1-Tunnel1] mpls te pce delegate
[*PE1-Tunnel1] quit
[*PE1] commit

Run the display mpls te tunnel command on PE1 to view SR-MPLS TE tunnel
information.
[~PE1] display mpls te tunnel
-------------------------------------------------------------------------------
Ingress LsrId Destination LSPID In/OutLabel R Tunnel-name
-------------------------------------------------------------------------------
1.1.1.1 3.3.3.3 21 -/330000 I Tunnel1
-------------------------------------------------------------------------------
R: Role, I: Ingress, T: Transit, E: Egress
Run the display mpls te tunnel path command on PE1 to view path information
on the SR-MPLS TE tunnel.
[~PE1] display mpls te tunnel path
Tunnel Interface Name : Tunnel1
Lsp ID : 1.1.1.1 :1 :21
Hop Information

(2020-10-09)
Hop 0 Label 330002 NAI 10.1.2.2

Hop 1 Label 330002 NAI 10.1.3.1
----End
Configuration Files
#
sysname PE1
#
mpls lsr-id 1.1.1.1
#
mpls
mpls te
#
pce-client
capability segment-routing
connect-server 10.2.1.2
#
segment-routing
#
isis 1
is-level level-2
cost-style wide
bgp-ls enable level-2
network-entity 10.0000.0000.0002.00
traffic-eng level-2
#
undo shutdown
ip address 10.1.2.1 255.255.255.0
isis enable 1
mpls
mpls te
#
interface LoopBack0
ip address 1.1.1.1 255.255.255.255
isis enable 1
#
interface Tunnel1
destination 3.3.3.3
mpls te tunnel-id 1
mpls te pce delegate
#
return
#
sysname P1
#
mpls lsr-id 2.2.2.2
#
mpls
mpls te
#
segment-routing
#
isis 1
is-level level-2
cost-style wide
network-entity 10.0000.0000.0003.00
traffic-eng level-2

(2020-10-09)
#
undo shutdown
ip address 10.1.2.2 255.255.255.0
isis enable 1
mpls
mpls te
#
undo shutdown
ip address 10.1.3.2 255.255.255.0
isis enable 1
mpls
mpls te
#
undo shutdown
ip address 10.2.1.1 255.255.255.0
isis enable 1
#
interface LoopBack0
ip address 2.2.2.2 255.255.255.255
isis enable 1
#
bgp 100
#
ipv4-family unicast
#
link-state-family unicast
#
return

#
sysname PE2
#
mpls lsr-id 3.3.3.3
#
mpls
mpls te
#
segment-routing
#
isis 1
is-level level-2
cost-style wide
network-entity 10.0000.0000.0004.00
traffic-eng level-2
#
undo shutdown
ip address 10.1.3.1 255.255.255.0
isis enable 1
mpls
mpls te
#
interface LoopBack0
ip address 3.3.3.3 255.255.255.255
isis enable 1
#
return
● Controller configuration file

(2020-10-09)
#
sysname Controller
#
pce-server
source-address 10.2.1.2
#
isis 1
is-level level-2
cost-style wide
network-entity 10.0000.0000.0005.00
traffic-eng level-2
#
undo shutdown
ip address 10.2.1.2 255.255.255.0
isis enable 1
#
bgp 100
#
ipv4-family unicast
#
#
return
1.2.40.6 Example for Configuring Static BFD for SR-MPLS TE

This section provides an example for configuring static BFD for SR-MPLS TE to
implement rapid traffic switching if a tunnel fault occurs.
On the network shown in Figure 1-130, a customer wants to establish a tunnel
and an LSP from PE1 to PE2. The SR protocol is used for path generation and data
forwarding. PE1 and PE2 are the path's ingress and egress, respectively. P1 collects
the network topology and reports it to the controller over IS-IS. The controller
calculates an LSP based on the collected topology information and delivers the
path information to the third-party adapter. The third-party adapter then sends
the path information to PE1.
NOTE
You do not need to configure a PCE client (PCC) because the third-party adapter delivers
the path information.
If a Huawei device connects to a non-Huawei device but the non-Huawei device does not
support BFD, configure one-arm BFD to monitor the link.
Figure 1-130 Configuring static BFD for SR-MPLS TE

NOTE

respectively.

(2020-10-09)
1. Assign an IP address and a mask to each interface, and configure a loopback
address as an MPLS LSR ID on each node.
LSR.
4. Configure IS-IS TE on each node.
5. Configure an IS-IS neighbor relationship between P1 and the controller so
that P1 reports the network topology to the controller over IS-IS.
6. Configure a tunnel interface on PE1, and specify an IP address, tunnel
protocol, destination IP address, and tunnel bandwidth.
7. Configure a BFD session on PE1 to monitor the primary SR-MPLS TE tunnel.
Data Preparation
● IP address of each interface, as shown in Figure 1-130
● IS-IS process ID: 1; system ID of each node: converted from a loopback0
address; IS-IS level: level-2
● IS-IS neighbor relationship between P1 and the controller, as shown in Figure
1-130
● Name of a BFD session
● Local and remote discriminators of a BFD session
Procedure
# Configure PE1.

(2020-10-09)
[*HUAWEI] commit
[*PE1] commit
# Configure P1.
[*HUAWEI] commit
[*P1] commit
# Configure PE2.
[*HUAWEI] commit
[*PE2] commit
Step 2 Configure IS-IS to advertise the route to each network segment of each interface
and to advertise the host route to each loopback address (used as an LSR ID).
# Configure PE1.
[~PE1] isis 1
[*PE1-isis-1] quit
[*PE1] commit
# Configure P1.
[~P1] isis 1
[*P1-isis-1] quit

(2020-10-09)

[*P1] commit
# Configure PE2.
[~PE2] isis 1
[*PE2-isis-1] quit
[*PE2] commit
Step 3 Configure an IS-IS neighbor relationship between P1 and the controller.

Configure an IS-IS neighbor relationship between P1 and the controller so that P1
reports the network topology to the controller over IS-IS. For configuration details,
see Configuration Files in this section.
[~P1] interface gigabitethernet1/0/1
[~P1-GigabitEthernet1/0/1] isis enable 1
[*P1] commit

# Configure PE1.
[~PE1] mpls lsr-id 10.21.2.9
[*PE1] mpls
[*PE1-mpls] mpls te
[*PE1-mpls] quit
The configurations except the LSR ID configuration on P1 and PE2 are the same as
those on PE1.
# Configure PE1.
[*PE1] commit
The configuration on P1 and PE2 is the same as that on PE1.

Step 6 Configure IS-IS TE on each node.
# Configure PE1.
[~PE1] isis 1

(2020-10-09)
[~PE1-isis-1] quit
The configuration on P1 and PE2 is the same as that on PE1.

Step 7 Configure a tunnel interface on PEs.
# Configure PE1.
[~PE1] interface Tunnel10
[~PE1-Tunnel10] quit
# Configure PE2.
[~PE2-Tunnel10] quit

After completing the configuration, run the display interface tunnel command
on PE1. You can check that the tunnel interface is Up.
Run the display mpls te tunnel command on each node to check MPLS TE tunnel
establishment.
------------------------------------------------------------------------------
Ingress LsrId Destination LSPID In/Out Label R Tunnel-name
------------------------------------------------------------------------------
10.21.2.9 10.41.2.9 1 --/20 I Tunnel10
-------------------------------------------------------------------------------
------------------------------------------------------------------------------
Ingress LsrId Destination LSPID In/Out Label R Tunnel-name
------------------------------------------------------------------------------
10.41.2.9 10.21.2.9 1 --/120 I Tunnel10
-------------------------------------------------------------------------------
Step 9 Configure BFD for SR-MPLS TE.

# Configure a BFD session on PE1 to detect the SR-MPLS TE tunnel, and set the
minimum intervals at which BFD packets are sent and received.
[~PE1] bfd
[*PE1-bfd] quit
[*PE1] bfd pe1tope2 bind mpls-te interface Tunnel10
[*PE1-bfd-lsp-session-pe1tope2] discriminator local 12
[*PE1-bfd-lsp-session-pe1tope2] discriminator remote 21
[*PE1-bfd-lsp-session-pe1tope2] min-tx-interval 100
[*PE1-bfd-lsp-session-pe1tope2] min-rx-interval 100
[*PE1-bfd-lsp-session-pe1tope2] commit
[~PE1-bfd-lsp-session-pe1tope2] quit
# Configure a BFD session on PE2 to detect the reverse SR-MPLS TE tunnel, and
set the minimum intervals at which BFD packets are sent and received.

(2020-10-09)
[~PE2] bfd
[*PE2-bfd] quit
[*PE2] bfd pe2tope1 bind mpls-te interface Tunnel10
[*PE2-bfd-lsp-session-pe2tope1] discriminator local 21
[*PE1-bfd-lsp-session-pe1tope2] discriminator remote 12
[*PE2-bfd-lsp-session-pe2tope1] min-tx-interval 100
[*PE2-bfd-lsp-session-pe2tope1] min-rx-interval 100
[*PE2-bfd-lsp-session-pe2tope1] commit
[~PE2-bfd-lsp-session-pe2tope1] quit
# After completing the configuration, run the display bfd session { all |
discriminator discr-value | mpls-te interface interface-type interface-number }
[ verbose ] command on PE1 and PE2. You can check that the BFD session is Up.
----End
Configuration Files
#
sysname PE1
#
bfd
#
mpls lsr-id 10.21.2.9
#
mpls
mpls te
#
segment-routing
#
isis 1
is-level level-2
cost-style wide
network-entity 11.1111.1111.1111.00
traffic-eng level-2
#
undo shutdown
ip address 10.1.23.2 255.255.255.0
isis enable 1
mpls
mpls te
#
interface LoopBack0
ip address 10.21.2.9 255.255.255.255
isis enable 1
#
interface Tunnel10
destination 10.41.2.9
mpls te tunnel-id 1
#
bfd pe1tope2 bind mpls-te interface Tunnel10
discriminator local 12
discriminator remote 21
min-tx-interval 100
min-rx-interval 100
#
return
#
sysname P1

(2020-10-09)
#
#
mpls
mpls te
#
segment-routing
#
isis 1
is-level level-2
cost-style wide
network-entity 11.2222.2222.2222.00
traffic-eng level-2
#
undo shutdown
ip address 10.1.23.3 255.255.255.0
isis enable 1
mpls
mpls te
#
undo shutdown
ip address 10.7.2.10 255.255.255.0
isis enable 1
#
undo shutdown
ip address 10.20.34.3 255.255.255.0
isis enable 1
mpls
mpls te
#
interface LoopBack0
ip address 10.31.2.9 255.255.255.255
isis enable 1
#
return
#
sysname PE2
#
bfd
#
#
mpls
mpls te
#
segment-routing
#
isis 1
is-level level-2
cost-style wide
network-entity 11.3333.3333.3333.00
traffic-eng level-2
#
undo shutdown
ip address 10.20.34.4 255.255.255.0
isis enable 1
mpls
mpls te
#
interface LoopBack0
ip address 10.41.2.9 255.255.255.255
isis enable 1

(2020-10-09)
#
interface Tunnel10
destination 10.21.2.9
mpls te tunnel-id 2
#
bfd pe2tope1 bind mpls-te interface Tunnel10
min-tx-interval 100
min-rx-interval 100
#
return
1.2.40.7 Example for Configuring Dynamic BFD for SR-MPLS TE LSP

This section provides an example for configuring dynamic BFD for SR-MPLS TE
LSP. Dynamic BFD for SR-MPLS TE LSP rapidly detects faults of SR-MPLS TE LSPs,
which protects traffic transmitted on SR-MPLS TE LSPs.
On the network shown in Figure 1-131, a tunnel as well as primary and backup
LSPs for the tunnel need to be established from PE1 to PE2. The SR protocol is
used for path generation and data forwarding. PE2 collects network topology
information and runs IS-IS to flood the information to the controller. The
controller uses the information to calculate the primary and backup LSPs and
delivers LSP information to a third-party adapter, and the third-party adapter
forwards the LSP information to the ingress PE1.
Hot standby is enabled for the tunnel. If the primary LSP fails, traffic is switched to
the backup LSP. After the primary LSP recovers, traffic is switched back.
NOTE
There is no need to configure a PCE client (PCC) because the third-party adapter is used to
deliver paths.
If a Huawei device connects to a BFD-incapable non-Huawei device, one-arm BFD can be
configured to monitor links.
Figure 1-131 Networking diagram for configuring dynamic BFD for SR-MPLS TE
LSP
NOTE
Interfaces 1 to 3 in this example represent GE 1/0/0, GE 2/0/0, and GE 3/0/0, respectively.

(2020-10-09)
1. Assign an IP address and a mask to each interface, and configure a loopback

address as an MPLS LSR ID on each node.
LSR.
4. Configure a label allocation mode and a topology information collection
mode. In this example, the controller collects assigns labels to forwarders.
5. Establish an IS-IS neighbor relationship between PE2 and the controller so
that PE2 can flood network topology information to the controller.
6. Configure a tunnel interface on the ingress PE1 and set a tunnel IP address, a
tunneling protocol, a destination IP address, and the tunnel bandwidth.
7. Configure CR-LSP hot standby.
8. Enable BFD on the ingress PE1, configure BFD for MPLS TE, and set the
minimum intervals at which BFD packets are sent and received and the local
detection multiplier
9. Enable the egress to passively create a BFD session.
Data Preparation

(2020-10-09)

● IS-IS process ID (1), IS-IS system ID of each node (converted from a
loopback0 IP address), and IS-IS level (level-2)
● IS-IS neighbor relationship between the controller and PE2, as shown in
Figure 1-131
● Name of the BFD session
● Local and remote discriminators of the BFD session
Procedure
# Configure PE1.
[*HUAWEI] commit
[*PE1] commit
# Configure P1.
[*HUAWEI] commit
[*P1] commit
# Configure PE2.
[*HUAWEI] commit
[*PE2] commit

(2020-10-09)
Step 2 Configure IS-IS to advertise the route to each network segment to which each
interface is connected and to advertise the host route to each loopback address
that is used as an LSR ID.
# Configure PE1.
[~PE1] isis 1
[*PE1-isis-1] quit
[*PE1] commit
# Configure P1.
[~P1] isis 1
[*P1-isis-1] quit
[*P1] commit
# Configure PE2.
[~PE2] isis 1
[*PE2-isis-1] quit
[*PE2] commit
Step 3 Configure an IS-IS neighbor relationship between the controller and PE2.
Running IS-IS between the controller and PE2 allows the two devices to
communicate with each other so that PE2 can flood network topology information
to the controller. For configuration details, see Configuration Files in this section.
[~PE2] interface gigabitethernet2/0/0
[~PE2-GigabitEthernet2/0/0] isis enable 1
[*PE2] commit

# Configure PE1.

(2020-10-09)

[*PE1] mpls
[*PE1-mpls] mpls te
[*PE1-mpls] quit
The configurations on P1 and PE2 are similar to the configuration on PE1. For
configuration details, see Configuration Files in this section.
# Configure PE1.
[*PE1] commit
Step 6 Configure a label allocation mode and a topology information collection mode. In
this example, the controller collects assigns labels to forwarders.
# Configure PE1.
[~PE1] isis 1
[~PE1-isis-1] quit
Step 7 Configure a tunnel interface and hot standby on the ingress PE1.
# Configure PE1.
[*PE1-Tunnel1] mpls te pce delegate
[*PE1-Tunnel1] mpls te backup hot-standby
[~PE1-Tunnel1] quit

command on PE1. The tunnel interface is Up.
[~PE1] display mpls te tunnel-interface tunnel1

(2020-10-09)
Tunnel Attributes :
Traffic Switch :-
Session ID :1
FTid :1
Bfd Cap : None
Inter-area Reopt : Disabled
Auto BW : Disabled Threshold : 0 percent
Current Collected BW: 0 kbps Auto BW Freq : 0
Min BW : 0 kbps Max BW : 0 kbps
Readjust Value :-
Backup Tunnel :-
BackUp LSP Type : Hot-Standby BestEffort : -
Ip-Prefix Name : -
PCE Delegate : Active LSP Control Status : Local control
Path Verificaiton : No
Entropy Label :None
Auto BW Remain Time : - Reopt Remain Time : -
Metric Inherit IGP : None
IncludeAll : 0x0
IncludeAny : 0x0
ExcludeAny : 0x0
Explicit Path Name : - Hop Limit: -

(2020-10-09)

Route Pinning :-
FRR Flag :-
IdleTime Remain :-
BFD Status :-
Soft Preemption :-
Reroute Flag :-
Pce Flag : Normal
Path Setup Type : PCE
Backup LSP ID : 1.1.1.1:46945

IsBestEffortPath : No
LSP State : UP LSP Type : Hot-Standby
IncludeAll : 0x0
IncludeAny : 0x0
ExcludeAny : 0x0
Explicit Path Name : - Hop Limit: -
Route Pinning :-
FRR Flag :-
IdleTime Remain :-
BFD Status :-
Soft Preemption :-
Reroute Flag :-
Pce Flag : Normal
Path Setup Type : PCE
Run the display mpls te tunnel command on PE1 to view SR-MPLS TE tunnel
information.
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
- - - 101/101 T lsp
1.1.1.1 3.3.3.3 21 -/330000 I Tunnel1
1.1.1.1 3.3.3.3 26 -/330002 I Tunnel1
-------------------------------------------------------------------------------
Run the display mpls te tunnel path command on PE1 to view path information
on the SR-MPLS TE tunnel.
[~PE1] display mpls te tunnel path
Lsp ID : 1.1.1.1 :1 :21
Hop Information
Hop 0 Label 330000 NAI 10.1.1.2

Lsp ID : 1.1.1.1 :1 :26
Hop Information
Hop 0 Label 330002 NAI 10.1.2.2
Hop 1 Label 330002 NAI 10.1.3.1

(2020-10-09)
Step 9 Enable BFD and configure BFD for MPLS TE on the ingress PE1.
# Enable BFD for MPLS TE on the tunnel interface of PE1. Set the minimum
intervals at which BFD packets are sent and received to 100 ms and the local
detection multiplier to 3.
[~PE1] bfd
[*PE1-bfd] quit
[*PE1] interface tunnel 1
[*PE1-Tunnel1] mpls te bfd enable
[*PE1-Tunenl1] mpls te bfd min-tx-interval 100 min-rx-interval 100 detect-multiplier 3
[*PE1-Tunenl1] commit
[~PE1-Tunenl1] quit
Step 10 Enable the egress to passively create a BFD session.

[~PE2] bfd
[*PE2-bfd] mpls-passive
[*PE2-bfd] commit
[~PE2-bfd] quit
# After completing the configuration, run the display bfd session mpls-te
interface Tunnel command on PE1. The BFD session status is Up.
[~PE1] display bfd session mpls-te interface Tunnel 1 te-lsp
(w): State in WTR
(*): State is invalid
--------------------------------------------------------------------------------
Local Remote PeerIpAddr State Type InterfaceName
--------------------------------------------------------------------------------
16399 16386 3.3.3.3 Up D_TE_LSP Tunnel1
--------------------------------------------------------------------------------
----End
Configuration Files
#
sysname PE1
#
bfd
#
mpls lsr-id 1.1.1.1
#
mpls
mpls te
#
segment-routing
#
isis 1
is-level level-2
cost-style wide
network-entity 10.0000.0000.0002.00
traffic-eng level-2
#
undo shutdown
ip address 10.1.1.1 255.255.255.0
isis enable 1
mpls
mpls te
#
undo shutdown
ip address 10.1.2.1 255.255.255.0
isis enable 1

(2020-10-09)
mpls
mpls te
#
interface LoopBack0
ip address 1.1.1.1 255.255.255.255
isis enable 1
#
interface Tunnel1
destination 3.3.3.3
mpls te backup hot-standby
mpls te tunnel-id 1
mpls te pce delegate
mpls te bfd enable
mpls te bfd min-tx-interval 100 min-rx-interval 100
#
return
#
sysname P1
#
mpls lsr-id 2.2.2.2
#
mpls
mpls te
#
segment-routing
#
isis 1
is-level level-2
cost-style wide
network-entity 10.0000.0000.0003.00
traffic-eng level-2
#
undo shutdown
ip address 10.1.2.2 255.255.255.0
isis enable 1
mpls
mpls te
#
undo shutdown
ip address 10.1.3.2 255.255.255.0
isis enable 1
mpls
mpls te
#
interface LoopBack0
ip address 2.2.2.2 255.255.255.255
isis enable 1
#
return
#
sysname PE2
#
bfd
mpls-passive
#
mpls lsr-id 3.3.3.3
#
mpls
mpls te
#

(2020-10-09)
segment-routing
#
isis 1
is-level level-2
cost-style wide
network-entity 10.0000.0000.0004.00
traffic-eng level-2
#
undo shutdown
ip address 10.1.1.2 255.255.255.0
isis enable 1
mpls
mpls te
#
undo shutdown
ip address 10.2.1.1 255.255.255.0
isis enable 1
#
undo shutdown
ip address 10.1.3.1 255.255.255.0
isis enable 1
mpls
mpls te
#
interface LoopBack0
ip address 3.3.3.3 255.255.255.255
isis enable 1
#
return
#
sysname Controller
#
isis 1
is-level level-2
cost-style wide
network-entity 10.0000.0000.0005.00
traffic-eng level-2
#
undo shutdown
ip address 10.2.1.2 255.255.255.0
isis enable 1
#
return
1.2.40.8 Example for Configuring TI-LFA FRR for a Loose SR-MPLS TE Tunnel
Topology-Independent Loop-Free Alternate (TI-LFA) FRR can be configured to
enhance the reliability of a segment routing (SR) network.
On the network shown in Figure 1-132, IS-IS is enabled. The cost of the link
between Device C and Device D is 100, and the cost of other links is 10. Based on
node SIDs, an SR-MPLS TE tunnel (Device A -> Device B -> Device E -> Device F) is
established from Device A to Device F through static explicit paths.
The SR-MPLS TE tunnel established based on node SIDs is a loose one that
supports TI-LFA FRR. TI-LFA FRR can be configured on Device B to provide local

(2020-10-09)
protection, enabling traffic to be quickly switched to the backup path (Device A ->
Device B -> Device C -> Device D -> Device E -> Device F) when the link between
Device B and Device E fails.
Figure 1-132 TI-LFA FRR for a loose SR-MPLS TE tunnel

NOTE
Precautions
In this example, TI-LFA FRR is configured on DeviceB to protect the link between
DeviceB and DeviceE. On a live network, you are advised to configure TI-LFA FRR
on all nodes in the SR domain.
1. Configure IS-IS on the entire network to implement interworking between
devices.
2. Enable MPLS on the entire network and configure SR.
3. Configure an explicit path on Device A and establish an SR-MPLS TE tunnel.
4. Enable TI-LFA FRR and anti-microloop on Device B.
Data Preparation
● MPLS LSR ID of each device
● SRGB range of each device
Procedure

(2020-10-09)
[~HUAWEI] sysname DeviceA
[*HUAWEI] commit
[~DeviceA] interface loopback 1
[*DeviceA-LoopBack1] ip address 1.1.1.9 32
[*DeviceA-GigabitEthernet1/0/0] ip address 10.1.1.1 24
[*DeviceA] commit
Step 2 Configure an IGP to implement interworking. IS-IS is used as an example.
[~DeviceA] isis 1
[*DeviceA-isis-1] is-level level-1
[*DeviceA-isis-1] network-entity 10.0000.0000.0001.00
[*DeviceA-isis-1] cost-style wide
[*DeviceA-LoopBack1] isis enable 1
[*DeviceA-GigabitEthernet1/0/0] isis enable 1
[*DeviceA] commit
Set the cost of the link between DeviceC and DeviceD to 100 to simulate a special
network scenario.
# Configure DeviceC.
[~DeviceC] interface gigabitethernet2/0/0
[~DeviceC-GigabitEthernet2/0/0] isis cost 100
[*DeviceC-GigabitEthernet2/0/0] quit
[*DeviceC] commit
# Configure DeviceD.
[~DeviceD] interface gigabitethernet1/0/0
[~DeviceD-GigabitEthernet1/0/0] isis cost 100
[*DeviceD-GigabitEthernet1/0/0] quit
[*DeviceD] commit
Step 3 Configure basic MPLS capabilities on the backbone network.

[~DeviceA] mpls lsr-id 1.1.1.9
[*DeviceA] mpls
[*DeviceA-mpls] mpls te
[*DeviceA-mpls] commit
[~DeviceA-mpls] quit
[~DeviceB] mpls lsr-id 2.2.2.9
[*DeviceB] mpls
[*DeviceB-mpls] mpls te
[*DeviceB-mpls] commit
[~DeviceB-mpls] quit

(2020-10-09)
[~DeviceC] mpls lsr-id 3.3.3.9
[*DeviceC] mpls
[*DeviceC-mpls] mpls te
[*DeviceC-mpls] commit
[~DeviceC-mpls] quit
[~DeviceD] mpls lsr-id 4.4.4.9
[*DeviceD] mpls
[*DeviceD-mpls] mpls te
[*DeviceD-mpls] commit
[~DeviceD-mpls] quit
[~DeviceE] mpls lsr-id 5.5.5.9
[*DeviceE] mpls
[*DeviceE-mpls] mpls te
[*DeviceE-mpls] commit
[~DeviceE-mpls] quit
[~DeviceF] mpls lsr-id 6.6.6.9
[*DeviceF] mpls
[*DeviceF-mpls] mpls te
[*DeviceF-mpls] commit
[~DeviceF-mpls] quit
Step 4 Configure basic SR functions on the backbone network.

[~DeviceA] segment-routing
[*DeviceA-segment-routing] quit
[*DeviceA] isis 1
[*DeviceA-isis-1] segment-routing mpls
[*DeviceA-isis-1] segment-routing global-block 16000 23999
NOTE
reference only.
[*DeviceA-LoopBack1] isis prefix-sid index 10
[*DeviceA] commit
[~DeviceB] segment-routing
[*DeviceB-segment-routing] quit
[*DeviceB] isis 1
[*DeviceB-isis-1] segment-routing mpls
[*DeviceB-isis-1] segment-routing global-block 16000 23999
NOTE
reference only.
[*DeviceB] interface loopback 1
[*DeviceB-LoopBack1] isis prefix-sid index 20
[*DeviceB-LoopBack1] quit

(2020-10-09)
[*DeviceB] commit
[~DeviceC] segment-routing
[*DeviceC-segment-routing] quit
[*DeviceC] isis 1
[*DeviceC-isis-1] segment-routing mpls
[*DeviceC-isis-1] segment-routing global-block 16000 23999
NOTE
reference only.
[*DeviceC-isis-1] quit
[*DeviceC] interface loopback 1
[*DeviceC-LoopBack1] isis prefix-sid index 30
[*DeviceC-LoopBack1] quit
[*DeviceC] commit
[~DeviceD] segment-routing
[*DeviceD-segment-routing] quit
[*DeviceD] isis 1
[*DeviceD-isis-1] segment-routing mpls
[*DeviceD-isis-1] segment-routing global-block 16000 23999
NOTE
reference only.
[*DeviceD-isis-1] quit
[*DeviceD] interface loopback 1
[*DeviceD-LoopBack1] isis prefix-sid index 40
[*DeviceD-LoopBack1] quit
[*DeviceD] commit
[~DeviceE] segment-routing
[*DeviceE-segment-routing] quit
[*DeviceE] isis 1
[*DeviceE-isis-1] segment-routing mpls
[*DeviceE-isis-1] segment-routing global-block 16000 23999
NOTE
reference only.
[*DeviceE-isis-1] quit
[*DeviceE] interface loopback 1
[*DeviceE-LoopBack1] isis prefix-sid index 50
[*DeviceE-LoopBack1] quit
[*DeviceE] commit
[~DeviceF] segment-routing
[*DeviceF-segment-routing] quit
[*DeviceF] isis 1
[*DeviceF-isis-1] segment-routing mpls
[*DeviceF-isis-1] segment-routing global-block 16000 23999
NOTE
reference only.

(2020-10-09)
[*DeviceF-isis-1] quit
[*DeviceF] interface loopback 1
[*DeviceF-LoopBack1] isis prefix-sid index 60
[*DeviceF-LoopBack1] quit
[*DeviceF] commit
# After completing the configurations, run the display segment-routing prefix

mpls forwarding command on each device. The command output shows that SR-
MPLS BE LSPs have been established. The command output on DeviceA is used as
an example.
[~DeviceA] display segment-routing prefix mpls forwarding
--------------------------------------------------------------

-----------------------------------------------------------------------------------------------------------------
2.2.2.9/32 16020 3 GE1/0/0 10.1.1.2 I&T --- 1500 Active
3.3.3.9/32 16030 16030 GE1/0/0 10.1.1.2 I&T --- 1500 Active
4.4.4.9/32 16040 16040 GE1/0/0 10.1.1.2 I&T --- 1500 Active
5.5.5.9/32 16050 16050 GE1/0/0 10.1.1.2 I&T --- 1500 Active
6.6.6.9/32 16060 16060 GE1/0/0 10.1.1.2 I&T --- 1500 Active
Step 5 Configure an SR-MPLS TE tunnel.

[~DeviceA] explicit-path p1
[*DeviceA-explicit-path-p1] next sid label 16020 type prefix
[*DeviceA-explicit-path-p1] quit
[*DeviceA] interface tunnel1
[*DeviceA-Tunnel1] ip address unnumbered interface LoopBack1
[*DeviceA-Tunnel1] tunnel-protocol mpls te
[*DeviceA-Tunnel1] destination 6.6.6.9
[*DeviceA-Tunnel1] mpls te tunnel-id 1
[*DeviceA-Tunnel1] mpls te signal-protocol segment-routing
[*DeviceA-Tunnel1] mpls te path explicit-path p1
[*DeviceA-Tunnel1] commit
[~DeviceA-Tunnel1] quit
# After completing the configurations, run the display mpls te tunnel

destination command on Device A. The command output shows that the SR-
MPLS TE tunnel has been established.
[~DeviceA] display mpls te tunnel destination 6.6.6.9
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
1.1.1.9 6.6.6.9 5 -/16020 I Tunnel1
-------------------------------------------------------------------------------
# Run the display mpls te tunnel-interface command on Device A. The

command output shows information about the SR-MPLS TE tunnel.
[~DeviceA] display mpls te tunnel-interface Tunnel 1
Tunnel Attributes :
Traffic Switch :-

(2020-10-09)
Session ID :1
FTid : 8193
Bfd Cap : None
Min BW :- Max BW :-
Readjust Value :-
Backup Tunnel :-
Ip-Prefix Name : -
Entropy Label :-
FRR Attr Source : - Is FRR degrade down : -

IncludeAll : 0x0
IncludeAny : 0x0
ExcludeAny : 0x0
Explicit Path Name : p1 Hop Limit: -
Route Pinning :-
FRR Flag :-

(2020-10-09)
IdleTime Remain :-
BFD Status :-
Soft Preemption :-
Reroute Flag :-
Pce Flag : Normal
Step 6 Configure TI-LFA FRR.
[~DeviceB] isis 1
[~DeviceB-isis-1] avoid-microloop frr-protected
[*DeviceB-isis-1] avoid-microloop frr-protected rib-update-delay 5000
[*DeviceB-isis-1] avoid-microloop segment-routing
[*DeviceB-isis-1] avoid-microloop segment-routing rib-update-delay 10000
[*DeviceB-isis-1] frr
[*DeviceB-isis-1-frr] loop-free-alternate level-1
[*DeviceB-isis-1-frr] ti-lfa level-1
[*DeviceB-isis-1-frr] quit
[*DeviceB] commit
After completing the configurations, run the display isis route [ level-1 | level-2 ]
[ process-id ] [ verbose ] command on Device B. The command output shows IS-
IS TI-LFA FRR backup entries.
[~DeviceB] display isis route level-1 verbose
-----------------------------

--------------------------------

10.1.1.1 GE1/0/0 0x0000000e
10.1.1.1 GE1/0/0 3

Direct Loop1 0x00000000
Prefix-sid : 16020 Weight : 0 Flags : -/N/-/-/-/-/A/L
Direct Loop1 -

10.2.1.2 GE2/0/0 0x0000000a
TI-LFA:
Interface : GE3/0/0
10.2.1.2 GE2/0/0 3
TI-LFA:
Interface : GE3/0/0

(2020-10-09)

10.5.1.2 GE3/0/0 0x00000007
TI-LFA:
Interface : GE2/0/0
10.5.1.2 GE3/0/0 16040
TI-LFA:
Interface : GE2/0/0

10.5.1.2 GE3/0/0 0x00000007
TI-LFA:
Interface : GE2/0/0
10.5.1.2 GE3/0/0 3
TI-LFA:
Interface : GE2/0/0

10.5.1.2 GE3/0/0 0x00000007
TI-LFA:
Interface : GE2/0/0
10.5.1.2 GE3/0/0 16060
TI-LFA:
Interface : GE2/0/0

Direct GE1/0/0 0x00000000

Direct GE2/0/0 0x00000000


(2020-10-09)
10.2.1.2 GE2/0/0 0x0000000a

TI-LFA:
Interface : GE3/0/0
Backup Label Stack (Top -> Bottom): {}

10.5.1.2 GE3/0/0 0x00000007
TI-LFA:
Interface : GE2/0/0

Direct GE3/0/0 0x00000000

10.5.1.2 GE3/0/0 0x00000007
TI-LFA:
Interface : GE2/0/0
# Run a tracert command on Device A to check the connectivity of the SR-MPLS

TE tunnel to Device F. For example:
[~DeviceA] tracert lsp segment-routing te Tunnel 1
LSP Trace Route FEC: SEGMENT ROUTING TE TUNNEL IPV4 SESSION QUERY Tunnel1 , press CTRL_C to
break.
0 Ingress 10.1.1.2/[16050 16060 ]
1 10.1.1.2 2 ms Transit 10.5.1.2/[3 ]
2 10.5.1.2 3 ms Transit 10.6.1.2/[3 ]
3 6.6.6.9 3 ms Egress
# Run the shutdown command on GE 3/0/0 of Device B to simulate a link fault

between Device B and Device E.
[~DeviceB] interface gigabitethernet3/0/0
[~DeviceB-GigabitEthernet3/0/0] shutdown
[*DeviceB] commit
# Run the tracert command on Device A again to check the connectivity of the SR-
MPLS TE tunnel. For example:
[~DeviceA] tracert lsp segment-routing te Tunnel 1
LSP Trace Route FEC: SEGMENT ROUTING TE TUNNEL IPV4 SESSION QUERY Tunnel1 , press CTRL_C to
break.
0 Ingress 10.1.1.2/[16050 16060 ]
1 10.1.1.2 3 ms Transit 10.2.1.2/[16050 ]
2 10.2.1.2 4 ms Transit 10.3.1.2/[16050 ]
3 10.3.1.2 4 ms Transit 10.4.1.2/[3 ]

(2020-10-09)
4 10.4.1.2 3 ms Transit 10.6.1.2/[3 ]

5 6.6.6.9 5 ms Egress
The preceding command output shows that the SR-MPLS TE tunnel has been
switched to the TI-LFA FRR backup path.
----End
Configuration Files
● Device A configuration file
#
sysname DeviceA
#
mpls lsr-id 1.1.1.9
#
mpls
mpls te
#
explicit-path p1
#
segment-routing
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0001.00
#
undo shutdown
ip address 10.1.1.1 255.255.255.0
isis enable 1
#
interface LoopBack1
ip address 1.1.1.9 255.255.255.255
isis enable 1
#
interface Tunnel1
destination 6.6.6.9
mpls te tunnel-id 1
mpls te path explicit-path p1
#
return
● Device B configuration file
#
sysname DeviceB
#
mpls lsr-id 2.2.2.9
#
mpls
mpls te
#
segment-routing
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0002.00

(2020-10-09)
avoid-microloop frr-protected rib-update-delay 5000
frr
ti-lfa level-1
#
undo shutdown
ip address 10.1.1.2 255.255.255.0
isis enable 1
#
undo shutdown
ip address 10.2.1.1 255.255.255.0
isis enable 1
#
undo shutdown
ip address 10.5.1.1 255.255.255.0
isis enable 1
#
interface LoopBack1
ip address 2.2.2.9 255.255.255.255
isis enable 1
#
return
● Device C configuration file

#
sysname DeviceC
#
mpls lsr-id 3.3.3.9
#
mpls
mpls te
#
segment-routing
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0003.00
#
undo shutdown
ip address 10.2.1.2 255.255.255.0
isis enable 1
#
undo shutdown
ip address 10.3.1.1 255.255.255.0
isis enable 1
isis cost 100
#
interface LoopBack1
ip address 3.3.3.9 255.255.255.255
isis enable 1
#
return
● Device D configuration file

(2020-10-09)
#
sysname DeviceD
#
mpls lsr-id 4.4.4.9
#
mpls
mpls te
#
segment-routing
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0004.00
#
undo shutdown
ip address 10.3.1.2 255.255.255.0
isis enable 1
isis cost 100
#
undo shutdown
ip address 10.4.1.1 255.255.255.0
isis enable 1
#
interface LoopBack1
ip address 4.4.4.9 255.255.255.255
isis enable 1
#
return
● Device E configuration file
#
sysname DeviceE
#
mpls lsr-id 5.5.5.9
#
mpls
mpls te
#
segment-routing
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0005.00
#
undo shutdown
ip address 10.6.1.1 255.255.255.0
isis enable 1
#
undo shutdown
ip address 10.4.1.2 255.255.255.0
isis enable 1
#
undo shutdown
ip address 10.5.1.2 255.255.255.0
isis enable 1
#
interface LoopBack1
ip address 5.5.5.9 255.255.255.255

(2020-10-09)
isis enable 1
#
return
● Device F configuration file

#
sysname DeviceF
#
mpls lsr-id 6.6.6.9
#
mpls
mpls te
#
segment-routing
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0006.00
#
undo shutdown
ip address 10.6.1.2 255.255.255.0
isis enable 1
#
interface LoopBack1
ip address 6.6.6.9 255.255.255.255
isis enable 1
#
return
1.2.40.9 Example for Configuring an E2E SR-MPLS TE Tunnel (Explicit Path

Used)
An inter-AS E2E SR-MPLS TE tunnel can be configured to provide a secure data
channel for services, for example, inter-AS VPN services.
On the network shown inFigure 1-133, PE1 and ASBR1 reside in AS 100, PE2 and
ASBR2 reside in AS 200, and ASBR1 and ASBR2 are directly connected through two
physical links. A bidirectional E2E tunnel needs to be established between PE1 and
PE2. SR is used to for path generation and data forwarding. In the PE1-to-PE2
direction, PE1 and PE2 are the ingress and egress of the path, respectively. In the
PE2-to-PE1 direction, PE2 and PE1 are the ingress and egress of the path,
respectively.
Figure 1-133 E2E SR-MPLS TE tunnel networking

NOTE

(2020-10-09)
1. Configure intra-AS SR-MPLS TE tunnels in AS 100 and AS 200. Set binding
SIDs for the SR-MPLS TE tunnels.
2. Configure an EBGP peer relationship between ASBR1 and ASBR2, enable BGP
EPE and BGP-LS, and enable the devices to generate BGP peer SIDs.
3. Create an E2E SR-MPLS TE tunnel interface on PE1 and PE2. Specify the IP
address, tunneling protocol, and destination address of each tunnel. Explicit
paths are used for path calculation.
Data Preparation
● IS-IS process ID (1), IS-IS level (Level-2), and IS-IS system IDs
(10.0000.0000.0001.00, 10.0000.0000.0002.00, 10.0000.0000.0003.00, and
10.0000.0000.0004.00)
● AS number (100) of PE1 and ASBR1 and that (200) of PE2 and ASBR2
● SR-MPLS TE tunnel interface names in AS 100 (Ttunnel1) and AS 200
(Tunnel2); tunnel interface name of the PE1-to-PE2 E2E SR-MPLS TE tunnel
(Tunnel3) and that of the PE2-to-PE1 E2E SR-MPLS TE tunnel (Tunnel 3)
Procedure
# Configure PE1.
[*HUAWEI] commit
[*PE1] commit
# Configure ASBR1.

(2020-10-09)
[~HUAWEI] sysname ASBR1
[*HUAWEI] commit
[~ASBR1] interface loopback 1
[*ASBR1-LoopBack1] ip address 2.2.2.2 32
[*ASBR1-LoopBack1] quit
[*ASBR1] interface gigabitethernet1/0/0
[*ASBR1-GigabitEthernet1/0/0] ip address 10.1.1.1 24
[*ASBR1-GigabitEthernet1/0/0] quit
[*ASBR1] commit
# Configure ASBR2.
[~HUAWEI] sysname ASBR2
[*HUAWEI] commit
[~ASBR2] interface loopback 1
[*ASBR2-LoopBack1] ip address 3.3.3.3 32
[*ASBR2] commit
# Configure PE2.
[*HUAWEI] commit
[*PE2] commit
Step 2 Configure an intra-AS SR-MPLS TE tunnel in AS 100.

# Configure PE1.
[*PE1] mpls
[*PE1-mpls] mpls te
[*PE1-mpls] quit
[*PE1] isis 1
[*PE1-isis-1] quit

(2020-10-09)

[*PE1] explicit-path path2asbr1
[*PE1-explicit-path-path2asbr1] next sid label 330102 type adjacency
[*PE1-explicit-path-path2asbr1] quit
[*PE1-Tunnel1] mpls te path explicit-path path2asbr1
[~PE1-Tunnel1] quit
NOTE
In the preceding steps, the next sid label command uses the adjacency label from PE1 to
ASBR1, which is dynamically generated by IS-IS. Before the configuration, you can run the
display segment-routing adjacency mpls forwarding command to query the label value. For
example:

-----------------------------------------------------------------------------
330102 GE1/0/0 10.0.1.2 ISIS-V4 --- 1500
# Configure ASBR1.
[~ASBR1] mpls lsr-id 2.2.2.2
[*ASBR1] mpls
[*ASBR1-mpls] mpls te
[*ASBR1-mpls] quit
[*ASBR1] segment-routing
[*ASBR1-segment-routing] quit
[*ASBR1] isis 1
[*ASBR1-isis-1] is-level level-2
[*ASBR1-isis-1] network-entity 10.0000.0000.0002.00
[*ASBR1-isis-1] cost-style wide
[*ASBR1-isis-1] traffic-eng level-2
[*ASBR1-isis-1] segment-routing mpls
[*ASBR1-isis-1] quit
[*ASBR1] interface loopback 1
[*ASBR1-LoopBack1] isis enable 1
[*ASBR1-LoopBack1] isis prefix-sid absolute 16200
[*ASBR1-GigabitEthernet3/0/0] isis enable 1
[*ASBR1-GigabitEthernet3/0/0] mpls
[*ASBR1-GigabitEthernet3/0/0] mpls te
[*ASBR1] explicit-path path2pe1
[*ASBR1-explicit-path-path2pe1] next sid label 330201 type adjacency
[*ASBR1-explicit-path-path2pe1] quit
[*ASBR1] interface tunnel1
[*ASBR1-Tunnel1] ip address unnumbered interface loopback 1
[*ASBR1-Tunnel1] tunnel-protocol mpls te
[*ASBR1-Tunnel1] destination 1.1.1.1
[*ASBR1-Tunnel1] mpls te tunnel-id 1
[*ASBR1-Tunnel1] mpls te signal-protocol segment-routing
[*ASBR1-Tunnel1] mpls te path explicit-path path2pe1
[*ASBR1-Tunnel1] commit
[~ASBR1-Tunnel1] quit

(2020-10-09)
NOTE
In the preceding step, an ASBR1-to-PE1 adjacency label is used in the next sid label command
and is dynamically generated using IS-IS. To obtain the label value, run the display segment-
routing adjacency mpls forwarding command. For example:
[~ASBR1] display segment-routing adjacency mpls forwarding

-----------------------------------------------------------------------------
330201 GE3/0/0 10.0.1.1 ISIS-V4 --- 1500
Step 3 Configure an intra-AS SR-MPLS TE tunnel in AS 200.

# Configure ASBR2.
[~ASBR2] mpls lsr-id 3.3.3.3
[*ASBR2] mpls
[*ASBR2-mpls] mpls te
[*ASBR2-mpls] quit
[*ASBR2] segment-routing
[*ASBR2-segment-routing] quit
[*ASBR2] isis 1
[*ASBR2-isis-1] traffic-eng level-2
[*ASBR2-isis-1] segment-routing mpls
[*ASBR2] interface loopback 1
[*ASBR2-LoopBack1] isis enable 1
[*ASBR2-LoopBack1] isis prefix-sid absolute 16300
[*ASBR2-GigabitEthernet3/0/0] isis enable 1
[*ASBR2] explicit-path path2pe2
[*ASBR2-explicit-path-path2pe2] next sid label 330304 type adjacency
[*ASBR2-explicit-path-path2pe2] quit
[*ASBR2] interface tunnel2
[*ASBR2-Tunnel2] ip address unnumbered interface loopback 1
[*ASBR2-Tunnel2] tunnel-protocol mpls te
[*ASBR2-Tunnel2] destination 4.4.4.4
[*ASBR2-Tunnel2] mpls te tunnel-id 1
[*ASBR2-Tunnel2] mpls te signal-protocol segment-routing
[*ASBR2-Tunnel2] mpls te path explicit-path path2pe2
NOTE
In the preceding step, an ASBR2-to-PE2 adjacency label is used in the next sid label command
[~ASBR2] display segment-routing adjacency mpls forwarding

-----------------------------------------------------------------------------
330304 GE3/0/0 10.9.1.2 ISIS-V4 --- 1500
# Configure PE2.

(2020-10-09)

[*PE2] mpls
[*PE2-mpls] mpls te
[*PE2-mpls] quit
[*PE2] isis 1
[*PE2-isis-1] quit
[*PE2] explicit-path path2asbr2
[*PE2-explicit-path-path2asbr2] next sid label 330403 type adjacency
[*PE2-explicit-path-path2asbr2] quit
[*PE2-Tunnel2] mpls te path explicit-path path2asbr2
[~PE2-Tunnel2] quit
NOTE
In the preceding step, a PE2-to-ASBR2 adjacency label is used in the next sid label command

-----------------------------------------------------------------------------
330403 GE1/0/0 10.9.1.1 ISIS-V4 --- 1500
Step 4 Configure the MPLS TE capability on ASBRs.

# Configure ASBR1.
[~ASBR1] interface gigabitethernet1/0/0
[~ASBR1-GigabitEthernet1/0/0] mpls
[*ASBR1] commit
# Configure ASBR2.
[~ASBR2] interface gigabitethernet1/0/0
[~ASBR2-GigabitEthernet1/0/0] mpls

(2020-10-09)

[*ASBR2] commit
Step 5 Establish an EBGP peer relationship between ASBRs and enable BGP EPE and BGP-
LS.
In this example, a loopback interface is used to establish a multi-hop EBGP peer
relationship. Before the configuration, ensure that the loopback interfaces of
ASBR1 and ASBR2 are routable to each other.
BGP EPE supports only EBGP peer relationships. Multi-hop EBGP peers must be
directly connected using physical links. If intermediate nodes exist, no BGP peer
SID is set on them, which causes forwarding failures.
# Configure ASBR1.
[~ASBR1] ip route-static 3.3.3.3 32 gigabitethernet1/0/0 10.1.1.2 description asbr1toasbr2
[*ASBR1] ip route-static 3.3.3.3 32 gigabitethernet2/0/0 10.2.1.2 description asbr1toasbr2
[*ASBR1] bgp 100
[*ASBR1-bgp] peer 3.3.3.3 as-number 200
[*ASBR1-bgp] peer 3.3.3.3 connect-interface loopback 1
[*ASBR1-bgp] peer 3.3.3.3 ebgp-max-hop 2
[*ASBR1-bgp] peer 3.3.3.3 egress-engineering
[*ASBR1-bgp] link-state-family unicast
[*ASBR1-bgp-af-ls] quit
[*ASBR1-bgp] ipv4-family unicast
[*ASBR1-bgp-af-ipv4] network 2.2.2.2 32
[*ASBR1-bgp-af-ipv4] import-route isis 1
[*ASBR1-bgp-af-ipv4] commit
[~ASBR1-bgp-af-ipv4] quit
[~ASBR1-bgp] quit
# Configure ASBR2.
[~ASBR2] ip route-static 2.2.2.2 32 gigabitethernet1/0/0 10.1.1.1 description asbr2toasbr1
[*ASBR2] ip route-static 2.2.2.2 32 gigabitethernet2/0/0 10.2.1.1 description asbr2toasbr1
[*ASBR2] bgp 200
[*ASBR2-bgp] peer 2.2.2.2 connect-interface loopback 1
[*ASBR2-bgp] peer 2.2.2.2 ebgp-max-hop 2
[*ASBR2-bgp] peer 2.2.2.2 egress-engineering
[*ASBR2-bgp-af-ipv4] import-route isis 1
[*ASBR2-bgp-af-ipv4] commit
[~ASBR2-bgp-af-ipv4] quit
[~ASBR2-bgp] quit
After the configuration, run the display bgp egress-engineering command to

check BGP EPE information. For example:
[~ASBR1] display bgp egress-engineering
Peer Node : 3.3.3.3
Peer Adj Num :2
Local ASN : 100
Remote ASN : 200
Local Router Id : 2.2.2.2
Remote Router Id : 3.3.3.3
Local Interface Address : 2.2.2.2

(2020-10-09)
Remote Interface Address : 3.3.3.3

SID Label : 32768
Peer Set SID Label : --
Nexthop : 10.1.1.2
Out Interface : GigabitEthernet1/0/0
Nexthop : 10.2.1.2
Peer Adj : 10.1.1.2

Local ASN : 100
Remote ASN : 200
Interface Identifier :6
SID Label : 32770
Nexthop : 10.1.1.2
Peer Adj : 10.2.1.2

Local ASN : 100
Remote ASN : 200
SID Label : 32769
Nexthop : 10.2.1.2
Peer Node : 2.2.2.2
Peer Adj Num :2
Local ASN : 200
Remote ASN : 100
SID Label : 31768
Peer Set SID Label : --
Nexthop : 10.1.1.1
Nexthop : 10.2.1.1
Peer Adj : 10.1.1.1

Local ASN : 200
Remote ASN : 100
SID Label : 31770
Nexthop : 10.1.1.1
Peer Adj : 10.2.1.1

Local ASN : 200
Remote ASN : 100
SID Label : 31769

(2020-10-09)
Nexthop : 10.2.1.1
Step 6 Set binding SIDs for the SR-MPLS TE tunnels within AS domains.
In the direction from PE1 to PE2:
# Configure PE1.
[*PE1-Tunnel1] mpls te binding-sid label 1000
[~PE1-Tunnel1] quit
# Configure ASBR2.
[~ASBR2] interface tunnel2
[*ASBR2-Tunnel2] mpls te binding-sid label 2000

# Configure PE2.
[*PE2-Tunnel2] mpls te binding-sid label 3000
[~PE2-Tunnel2] quit
# Configure ASBR1.
[~ASBR1] interface tunnel1
[*ASBR1-Tunnel1] mpls te binding-sid label 4000
Step 7 Configure a bidirectional E2E SR-MPLS TE tunnel between PE1 and PE2.
# Configure PE1. There are multiple links between ASBRs. You can use one of
them. In this example, the link of ASBR1 (GE 1/0/0) -> ASBR2 (GE 1/0/0) is used.
[*PE1-explicit-path-path2pe2] next sid label 1000 type binding-sid
[*PE1-explicit-path-path2pe2] next sid label 32770 type adjacency
[~PE1-Tunnel3] quit

# Configure PE2. There are multiple links between ASBRs. You can use one of
them. In this example, the link of ASBR2 (GE 1/0/0) -> ASBR1 (GE 1/0/0) is used.
[*PE2-explicit-path-path2pe1] next sid label 31770 type adjacency

(2020-10-09)

[~PE2-Tunnel3] quit

tunnel-name command. The command output shows that the E2E SR-MPLS TE
tunnel named Tunnel3 is Up. For example:
# Check the status on PE1.
Tunnel Attributes :
Traffic Switch :-
Session ID : 100
FTid :2
Bfd Cap : None
Min BW :- Max BW :-
Readjust Value :-
Backup Tunnel :-
Ip-Prefix Name : -
Entropy Label :-
Binding Sid : 2001 Reverse Binding Sid : 2002

(2020-10-09)

IncludeAll : 0x0
IncludeAny : 0x0
ExcludeAny : 0x0
Explicit Path Name : path2pe2 Hop Limit: -
Route Pinning :-
FRR Flag :-
IdleTime Remain :-
BFD Status :-
Soft Preemption :-
Reroute Flag :-
Pce Flag : Normal
# Check the status on PE2.
Tunnel Attributes :
Traffic Switch :-
Session ID : 400
FTid : 65
Bfd Cap : None
Min BW :- Max BW :-
Readjust Value :-
Backup Tunnel :-

(2020-10-09)
Ip-Prefix Name : -
Entropy Label :-
Binding Sid : 2002 Reverse Binding Sid : 2001

IncludeAll : 0x0
IncludeAny : 0x0
ExcludeAny : 0x0
Explicit Path Name : path2pe1 Hop Limit: -
Route Pinning :-
FRR Flag :-
IdleTime Remain :-
BFD Status :-
Soft Preemption :-
Reroute Flag :-
Pce Flag : Normal
----End
Configuration Files
#
sysname PE1
#
mpls lsr-id 1.1.1.1
#
mpls
mpls te
#
explicit-path path2asbr1
#
next sid label 1000 type binding-sid

(2020-10-09)

#
segment-routing
#
isis 1
is-level level-2
cost-style wide
network-entity 10.0000.0000.0001.00
traffic-eng level-2
#
undo shutdown
ip address 10.0.1.1 255.255.255.0
isis enable 1
mpls
mpls te
#
interface LoopBack1
ip address 1.1.1.1 255.255.255.255
isis enable 1
#
interface Tunnel1
destination 2.2.2.2
mpls te tunnel-id 1
mpls te path explicit-path path2asbr1
mpls te binding-sid label 1000
#
interface Tunnel3
destination 4.4.4.4
#
return
● ASBR1 configuration file
#
sysname ASBR1
#
mpls lsr-id 2.2.2.2
#
mpls
mpls te
#
#
segment-routing
#
isis 1
is-level level-2
cost-style wide
network-entity 10.0000.0000.0002.00
traffic-eng level-2
#
undo shutdown
ip address 10.1.1.1 255.255.255.0
mpls
mpls te
#

(2020-10-09)
undo shutdown
ip address 10.2.1.1 255.255.255.0
mpls
mpls te
#
undo shutdown
ip address 10.0.1.2 255.255.255.0
isis enable 1
mpls
mpls te
#
interface LoopBack1
ip address 2.2.2.2 255.255.255.255
isis enable 1
#
interface Tunnel1
destination 1.1.1.1
mpls te tunnel-id 1
#
bgp 100
peer 3.3.3.3 ebgp-max-hop 2
peer 3.3.3.3 egress-engineering
#
ipv4-family unicast
network 2.2.2.2 255.255.255.255
network 10.1.1.0 255.255.255.0
network 10.2.1.0 255.255.255.0
import-route isis 1
#
#
ip route-static 3.3.3.3 255.255.255.255 gigabitethernet1/0/0 10.1.1.2 description asbr1toasbr2
#
return
#
sysname ASBR2
#
mpls lsr-id 3.3.3.3
#
mpls
mpls te
#
#
segment-routing
#
isis 1
is-level level-2
cost-style wide
network-entity 10.0000.0000.0003.00
traffic-eng level-2
#
undo shutdown
ip address 10.1.1.2 255.255.255.0
mpls

(2020-10-09)
mpls te
#
undo shutdown
ip address 10.2.1.2 255.255.255.0
mpls
mpls te
#
undo shutdown
ip address 10.9.1.1 255.255.255.0
isis enable 1
mpls
mpls te
#
interface LoopBack1
ip address 3.3.3.3 255.255.255.255
isis enable 1
#
interface Tunnel2
destination 4.4.4.4
mpls te tunnel-id 1
#
bgp 200
peer 2.2.2.2 connect-interface LoopBack 1
peer 2.2.2.2 egress-engineering
#
ipv4-family unicast
network 3.3.3.3 255.255.255.255
network 10.1.1.0 255.255.255.0
network 10.2.1.0 255.255.255.0
import-route isis 1
#
#
#
return
#
sysname PE2
#
mpls lsr-id 4.4.4.4
#
mpls
mpls te
#
explicit-path path2asbr2
#
#
segment-routing
#
isis 1
is-level level-2
cost-style wide

(2020-10-09)
network-entity 10.0000.0000.0004.00
traffic-eng level-2
#
undo shutdown
ip address 10.9.1.2 255.255.255.0
isis enable 1
mpls
mpls te
#
interface LoopBack1
ip address 4.4.4.4 255.255.255.255
isis enable 1
#
interface Tunnel2
destination 3.3.3.3
mpls te tunnel-id 1
mpls te path explicit-path path2asbr2
#
interface Tunnel3
destination 1.1.1.1
#
return
1.2.40.10 Example for Configuring CBTS in an L3VPN over SR-MPLS TE

Scenario
This section provides an example for configuring class-of-service-based tunnel
selection (CBTS) in an L3VPN over SR-MPLS TE scenario.
On the network shown in Figure 1-134, CE1 and CE2 belong to the same L3VPN.
They access the public network through PE1 and PE2, respectively. Various types of
services are transmitted between CE1 and CE2. Transmitting a large number of
common services deteriorates the efficiency of transmitting important services. To
prevent this problem, configure the CBTS function. This function allows traffic of a
specific service class to be transmitted along a specified tunnel.
In this example, Tunnel1 and Tunnel2 on PE1 transmit important services, and
Tunnel3 transmits other services.

(2020-10-09)
NOTICE
If the CBTS function is configured, you are advised not to configure any of the
following functions:
● Mixed load balancing
● Seamless MPLS
● Dynamic load balancing
Figure 1-134 CBTS networking in an L3VPN over SR-MPLS TE scenario

NOTE
1. Assign an IP address and its mask to each interface and configure a loopback
interface address as an LSR ID on each node.
2. Enable IS-IS globally, configure network entity names, specify the cost type,
and enable IS-IS TE. Enable IS-IS on interfaces, including loopback interfaces.
3. Set MPLS LSR IDs and enable MPLS and MPLS TE globally.
4. Enable MPLS and MPLS TE on each interface.
5. Configure the maximum reservable link bandwidth and BC for the outbound
interface of each involved tunnel.
6. Create a tunnel interface on the ingress and configure the IP address, tunnel
protocol, destination IP address, and tunnel bandwidth.
7. Configure multi-field classification on PE1.
8. Configure a VPN instance and apply a tunnel policy on PE1.
Data Preparation
● IS-IS area ID, originating system ID, and IS-IS level on each node
● Maximum reservable link bandwidth of each tunnel

(2020-10-09)
● Tunnel interface number, IP address, destination IP address, tunnel ID, and

tunnel bandwidth
● Traffic classifier name, traffic behavior name, and traffic policy name
Procedure
Step 1 Assign an IP address and its mask to each interface.
# Configure PE1.
[*HUAWEI] commit
[*PE1] commit
# Configure P1.
[*HUAWEI] commit
[*P1] commit
# Configure P2.
[*HUAWEI] commit
[*P2] commit
# Configure PE2.
[*HUAWEI] commit
[*PE2] commit
Step 2 Configure IS-IS to advertise routes.

(2020-10-09)
# Configure PE1.
[~PE1] isis 1
[*PE1-isis-1] network-entity 00.0005.0000.0000.0001.00
[*PE1-isis-1] quit
[*PE1-LoopBack1] commit
[~PE1-LoopBack1] quit
# Configure P1.
[~P1] isis 1
[*P1-isis-1] network-entity 00.0005.0000.0000.0002.00
[*P1-isis-1] quit
[*P1] interface gigabitethernet 1/0/0
[*P1-LoopBack1] commit
[~P1-LoopBack1] quit
# Configure P2.
[~P2] isis 1
[*P2-isis-1] network-entity 00.0005.0000.0000.0003.00
[*P2-isis-1] quit
# Configure PE2.
[~PE2] isis 1
[*PE2-isis-1] network-entity 00.0005.0000.0000.0004.00
[*PE2-isis-1] quit
After completing the preceding configurations, run the display ip routing-table

command on each node to check that both PEs have learned routes from each
other. The following example uses the command output on PE1.
------------------------------------------------------------------------------

(2020-10-09)



# Configure PE1.
[~PE1] bgp 100
[~PE1-bgp] quit
# Configure PE2.
[~PE2] bgp 100
[~PE2-bgp] quit
vpnv4 all peer command on the PEs to check whether a BGP peer relationship
4.4.4.9 4 100 2 6 0 00:11:25 Established 0
4.4.4.9 4 100 19 21 0 00:19:43 Established 0

# Enable MPLS and MPLS TE both globally and on specific interfaces for nodes
along each tunnel.
# Configure PE1.

(2020-10-09)

[*PE1] mpls
[*PE1-mpls] mpls te
[*PE1-mpls] quit
# Configure P1.
[*P1] mpls
[*P1-mpls] mpls te
[*P1-mpls] quit
[*P1-GigabitEthernet1/0/0] mpls
[*P1-GigabitEthernet1/0/0] mpls te
[*P1-GigabitEthernet2/0/0] commit
[~P1-GigabitEthernet2/0/0] quit
# Configure P2.
[*P2] mpls
[*P2-mpls] mpls te
[*P2-mpls] quit
# Configure PE2.
[*PE2] mpls
[*PE2-mpls] mpls te
[*PE2-mpls] quit
Step 5 Configure MPLS TE bandwidth attributes for links.

# Configure the maximum reservable link bandwidth and BC0 for the outbound
interfaces of each tunnel.
# Configure PE1.
[~PE1] interface gigabitethernet 1/0/0
[~PE1-GigabitEthernet1/0/0] mpls te bandwidth max-reservable-bandwidth 100000
[*PE1-GigabitEthernet1/0/0] mpls te bandwidth bc0 100000
# Configure P1.
[~P1] interface gigabitethernet 1/0/0

(2020-10-09)
[~P1-GigabitEthernet1/0/0] mpls te bandwidth max-reservable-bandwidth 100000

[*P1-GigabitEthernet1/0/0] mpls te bandwidth bc0 100000
[*P1-GigabitEthernet2/0/0] mpls te bandwidth max-reservable-bandwidth 100000
# Configure P2.
# Configure PE2.
[~PE2-GigabitEthernet1/0/0] mpls te bandwidth max-reservable-bandwidth 100000
[*PE2-GigabitEthernet1/0/0] mpls te bandwidth bc0 100000
Step 6 Configure QoS on each PE.

# Configure multi-field classification and set a service class for each type of
service packet on PE1.
[~PE1] acl 2001
[*PE1-acl4-basic-2001] rule 10 permit source 10.40.0.0 0.0.255.255
[*PE1-acl4-basic-2001] quit
[*PE1] acl 2002
[*PE1] traffic classifier service1
[*PE1-classifier-service1] if-match acl 2001
[*PE1-classifier-service1] commit
[~PE1-classifier-service1] quit
[~PE1] traffic behavior behavior1
[*PE1-behavior-behavior1] service-class af1 color green
[*PE1-behavior-behavior1] commit
[~PE1-behavior-behavior1] quit
[~PE1] traffic classifier service2
[~PE1] traffic policy policy1
[*PE1-trafficpolicy-policy1] classifier service1 behavior behavior1
[*PE1-trafficpolicy-policy1] classifier service2 behavior behavior2
[*PE1-trafficpolicy-policy1] commit
[~PE1-trafficpolicy-policy1] quit
[~PE1-GigabitEthernet2/0/0] traffic-policy policy1 inbound
Step 7 Enable SR and configure an explicit path.

In this example, the explicit path is used to establish an SR-MPLS TE tunnel.

(2020-10-09)
NOTE
# Configure PE1.
[*PE1] isis 1
[~PE1-isis-1] quit
[~PE1] interface LoopBack 1
[~PE1-LoopBack1] isis prefix-sid index 10
# Configure P1.
[*P1] isis 1
[*P1-isis-1] commit
[~P1-isis-1] quit
[~P1] interface LoopBack 1
[~P1-LoopBack1] isis prefix-sid index 20
# Configure P2.
[*P2] isis 1
[*P2-isis-1] commit
[~P2-isis-1] quit
[~P2] interface LoopBack 1
[~P2-LoopBack1] isis prefix-sid index 30
# Configure PE2.
[*PE2] isis 1
[~PE2-isis-1] quit
[~PE2] interface LoopBack 1
[~PE2-LoopBack1] isis prefix-sid index 40

(2020-10-09)
# Display the node SID of each node. The following example uses the command
output on PE1.
[~PE1] display segment-routing prefix mpls forwarding

--------------------------------------------------------------

-----------------------------------------------------------------------------------------------------------------
2.2.2.9/32 16020 3 GE1/0/0 10.1.1.2 I&T --- 1500 Active
3.3.3.9/32 16030 16030 GE1/0/0 10.1.1.2 I&T --- 1500 Active
4.4.4.9/32 16040 16040 GE1/0/0 10.1.1.2 I&T --- 1500 Active
# Configure an explicit path from PE1 to PE2.

[~PE1] explicit-path pe1_pe2
[*PE1-explicit-path-pe1_pe2] next sid label 16020 type prefix
[*PE1-explicit-path-pe1_pe2] commit
[~PE1-explicit-path-pe1_pe2] quit
# Configure an explicit path from PE2 to PE1.

[~PE2] explicit-path pe2_pe1
[*PE2-explicit-path-pe2_pe1] commit
[~PE2-explicit-path-pe2_pe1] quit
Step 8 Configure MPLS TE tunnel interfaces.

# On the ingress of each tunnel, create a tunnel interface and set the IP address,
tunnel protocol, destination IP address, tunnel ID, dynamic signaling protocol,
tunnel bandwidth, and service classes for packets transmitted on the tunnel.
NOTE
Run the mpls te service-class { service-class & <1-8> | default } command to set a service
class for packets carried by each tunnel.
# Configure PE1.
[*PE1-Tunnel1] mpls te bandwidth ct0 20000
[*PE1-Tunnel1] mpls te path explicit-path pe1_pe2
[*PE1-Tunnel1] mpls te service-class af1
[~PE1-Tunnel1] quit

(2020-10-09)
[*PE1-Tunnel2] mpls te service-class af2

[~PE1-Tunnel2] quit
[*PE1-Tunnel3] mpls te service-class default
[~PE1-Tunnel3] quit
[*PE1-tunnel-policy-policy1] tunnel select-seq sr-te load-balance-number 3
[*PE1-tunnel-policy-policy1] commit
[~PE1-tunnel-policy-policy1] quit
# Configure PE2.
[~PE2-Tunnel1] quit
[*PE2-tunnel-policy-policy1] tunnel select-seq sr-te load-balance-number 3
[*PE2-tunnel-policy-policy1] commit
[~PE2-tunnel-policy-policy1] quit
Step 9 Configure L3VPN access on each PE.
# Configure PE1.
[*PE1-vpn-instance-vpn1-af-ipv4] vpn-target 111:1 both
[*PE1-vpn-instance-vpn1-af-ipv4] tnl-policy policy1
[*PE1-vpn-instance-vpn1-af-ipv4] commit
[~PE1-vpn-instance-vpn1-af-ipv4] quit
[~PE1-vpn-instance-vpn1] quit
[~PE1-GigabitEthernet2/0/0] ip binding vpn-instance vpn1
# Configure PE2.
[*PE2-vpn-instance-vpn2-af-ipv4] vpn-target 111:1 both
[*PE2-vpn-instance-vpn1-af-ipv4] tnl-policy policy1
[*PE2-vpn-instance-vpn2-af-ipv4] commit
[~PE2-vpn-instance-vpn2-af-ipv4] quit
[~PE2-vpn-instance-vpn2] quit
[~PE2-GigabitEthernet2/0/0] ip binding vpn-instance vpn2

(2020-10-09)
Step 10 Establish an EBGP peer relationship between each PE and its connected CE.
# Configure CE1.
[*HUAWEI] commit
[~CE1] interface gigabitethernet1/0/0
[~CE1-GigabitEthernet1/0/0] ip address 10.10.1.2 24
[*CE1] bgp 65410
[*CE1-bgp] import-route direct
[*CE1-bgp] quit
[*CE1] commit
NOTE
The configuration of CE2 is similar to the configuration of CE1. For configuration details,
# Configure PE1.
[~PE1] bgp 100
[~PE1-bgp] ipv4-family vpn-instance vpn1
[*PE1-bgp-vpn1] peer 10.10.1.2 as-number 65410
[*PE1-bgp-vpn1] commit
[~PE1-bgp-vpn1] quit
[~PE1-bgp] quit
NOTE
The configuration of PE2 is similar to the configuration of PE1. For configuration details,
command on the PEs to check whether BGP peer relationships have been
established between the PEs and CEs. If the Established state is displayed in the
command output, the BGP peer relationships have been established successfully.
# Run the ping command on PE1 to check the connectivity of each SR-MPLS TE
CTRL_C to break
0.00% packet loss
CTRL_C to break

(2020-10-09)
0.00% packet loss
CTRL_C to break
0.00% packet loss
----End
Configuration Files
#
sysname PE1
#
ipv4-family
tnl-policy policy1
#
mpls lsr-id 1.1.1.9
#
mpls
mpls te
#
explicit-path pe1_pe2
#
acl number 2001
rule 10 permit source 10.40.0.0 0.0.255.255
#
acl number 2002
#
traffic classifier service1 operator or
if-match acl 2001
#
if-match acl 2002
#
traffic behavior behavior1
service-class af1 color green
#
#
traffic policy policy1
classifier service1 behavior behavior1 precedence 1
#
segment-routing

(2020-10-09)
#
isis 1
is-level level-2
cost-style wide
network-entity 00.0005.0000.0000.0001.00
traffic-eng level-2
#
undo shutdown
ip address 10.1.1.1 255.255.255.0
isis enable 1
mpls
mpls te
mpls te bandwidth max-reservable-bandwidth 100000
mpls te bandwidth bc0 100000
#
undo shutdown
ip address 10.10.1.1 255.255.255.0
traffic-policy policy1 inbound
#
interface LoopBack1
ip address 1.1.1.9 255.255.255.255
isis enable 1
#
interface Tunnel1
destination 4.4.4.9
mpls te bandwidth ct0 20000
mpls te tunnel-id 1
mpls te path explicit-path pe1_pe2
mpls te service-class af1
#
interface Tunnel2
destination 4.4.4.9
mpls te tunnel-id 2
mpls te service-class af2
#
interface Tunnel3
destination 4.4.4.9
mpls te tunnel-id 3
mpls te service-class default
#
bgp 100
#
ipv4-family unicast
peer 4.4.4.9 enable
#
ipv4-family vpnv4
policy vpn-target

(2020-10-09)
peer 4.4.4.9 enable

#
#
#
return
#
sysname P1
#
mpls lsr-id 2.2.2.9
#
mpls
mpls te
#
segment-routing
#
isis 1
is-level level-2
cost-style wide
network-entity 00.0005.0000.0000.0002.00
traffic-eng level-2
#
undo shutdown
ip address 10.1.1.2 255.255.255.0
isis enable 1
mpls
mpls te
#
undo shutdown
ip address 10.2.1.1 255.255.255.0
isis enable 1
mpls
mpls te
#
interface LoopBack1
ip address 2.2.2.9 255.255.255.255
isis enable 1
#
return
#
sysname P2
#
mpls lsr-id 3.3.3.9
#
mpls
mpls te
#
segment-routing
#
isis 1
is-level level-2
cost-style wide
network-entity 00.0005.0000.0000.0003.00
traffic-eng level-2

(2020-10-09)
#
undo shutdown
ip address 10.2.1.2 255.255.255.0
isis enable 1
mpls
mpls te
#
undo shutdown
ip address 10.3.1.1 255.255.255.0
isis enable 1
mpls
mpls te
#
interface LoopBack1
ip address 3.3.3.9 255.255.255.255
isis enable 1
#
return
#
sysname PE2
#
ipv4-family
tnl-policy policy1
#
mpls lsr-id 4.4.4.9
#
mpls
mpls te
#
explicit-path pe2_pe1
#
segment-routing
#
isis 1
is-level level-2
cost-style wide
network-entity 00.0005.0000.0000.0004.00
traffic-eng level-2
#
undo shutdown
ip address 10.3.1.2 255.255.255.0
isis enable 1
mpls
mpls te
#
undo shutdown

(2020-10-09)

ip address 10.11.1.1 255.255.255.0
#
interface LoopBack1
ip address 4.4.4.9 255.255.255.255
isis enable 1
#
interface Tunnel1
destination 1.1.1.9
mpls te tunnel-id 1
#
bgp 100
#
ipv4-family unicast
peer 1.1.1.9 enable
#
ipv4-family vpnv4
policy vpn-target
peer 1.1.1.9 enable
#
#
#
return
#
sysname CE1
#
undo shutdown
ip address 10.10.1.2 255.255.255.0
#
bgp 65410
#
ipv4-family unicast
import-route direct
#
return
#
sysname CE2
#
undo shutdown
ip address 10.11.1.2 255.255.255.0
#
bgp 65420
#
ipv4-family unicast
import-route direct

(2020-10-09)
#
return
1.2.40.11 Example for Configuring CBTS in an L3VPN over LDP over SR-MPLS
TE Scenario
This section provides an example for configuring class-of-service-based tunnel
selection (CBTS) in an L3VPN over LDP over SR-MPLS TE scenario.
On the network shown in Figure 1-135, CE1 and CE2 belong to the same L3VPN.
They access the public network through PE1 and PE2, respectively. Various types of
services are transmitted between CE1 and CE2. Transmitting a large number of
common services deteriorates the efficiency of transmitting important services. To
prevent this problem, configure the CBTS function. This function allows traffic of a
specific service class to be transmitted along a specified tunnel.
This example requires Tunnel1 to transmit important services and Tunnel2 to

transmit other services.
Figure 1-135 CBTS networking in an L3VPN over LDP over SR-MPLS TE scenario
NOTE
Precautions
The destination IP address of a tunnel must be equal to the LSR ID of the egress
of the tunnel.

(2020-10-09)
1. Assign an IP address and its mask to each interface and configure a loopback
interface address as an LSR ID on each node. In addition, configure an IGP to
advertise routes.
2. Create an SR-MPLS TE tunnel in each TE-capable area, and specify a service
class for packets that can be transmitted by the tunnel.
3. Enable MPLS LDP in the TE-incapable area, and configure a remote LDP peer
for each edge node in the TE-capable area.
4. Configure the TE forwarding adjacency function.
5. Configure multi-field classification on nodes connected to the L3VPN as well
as behavior aggregate classification on LDP over SR-MPLS TE links.
Data Preparation
● IS-IS process ID, level, network entity ID, and cost type
● Policy that is used for triggering LSP establishment
● Name and IP address of each remote LDP peer of P1 and P2
● Link bandwidth attributes of each tunnel
● Tunnel interface number, IP address, destination IP address, tunnel ID, tunnel
signaling protocol, tunnel bandwidth, TE metric value, and link cost on P1 and
P2
● Multi-field classifier name and traffic policy name
Procedure
Step 1 Assign an IP address and its mask to each interface.
# Configure PE1.
[*HUAWEI] commit
[*PE1] commit
# Configure P1.
[*HUAWEI] commit
[*P1] commit
# Configure P2.

(2020-10-09)
[*HUAWEI] commit
[*P2] commit
# Configure P3.
[*HUAWEI] commit
[*P3] commit
# Configure PE2.
[*HUAWEI] commit
[*PE2] commit
Step 2 Enable IS-IS to advertise the route of the network segment connected to each
interface and the host route destined for each LSR ID.
# Configure PE1.
[~PE1] isis 1
[*PE1-isis-1] quit
# Configure P1.
[~P1] isis 1
[*P1-isis-1] quit

(2020-10-09)
# Configure P2.
[~P2] isis 1
[*P2-isis-1] quit
# Configure P3.
[~P3] isis 1
[*P3-isis-1] quit
# Configure PE2.
[~PE2] isis 1
[*PE2-isis-1] quit
After completing the preceding configurations, run the display ip routing-table

command on each node to check that both PEs have learned routes from each
other.
# Configure PE1.
[~PE1] bgp 100

(2020-10-09)

[~PE1-bgp] quit
# Configure PE2.
[~PE2] bgp 100
[~PE2-bgp] quit
vpnv4 all peer command on the PEs to check whether a BGP peer relationship
5.5.5.5 4 100 2 6 0 00:00:12 Established 0
5.5.5.5 4 100 12 18 0 00:09:38 Established 0
Step 4 Configure basic MPLS functions, and enable LDP between PE1 and P1 and
between PE2 and P2.
# Configure PE1.
[*PE1] mpls
[*PE1-mpls] lsp-trigger all
[*PE1-mpls] quit
[*PE1] mpls ldp
# Configure P1.
[*P1] mpls
[*P1-mpls] mpls te
[*P1-mpls] lsp-trigger all
[*P1-mpls] quit
[*P1] mpls ldp
[*P1-mpls-ldp] quit
[*P1-GigabitEthernet1/0/0] mpls ldp

(2020-10-09)

# Configure P3.
[*P3] mpls
[*P3-mpls] mpls te
[*P3-mpls] quit
# Configure P2.
[*P2] mpls
[*P2-mpls] mpls te
[*P2-mpls] lsp-trigger all
[*P2-mpls] quit
[*P2] mpls ldp
[*P2-mpls-ldp] quit
[*P2-GigabitEthernet2/0/0] mpls ldp
# Configure PE2.
[*PE2] mpls
[*PE2-mpls] lsp-trigger all
[*PE2-mpls] quit
[*PE2] mpls ldp
After you complete the preceding configurations, local LDP sessions are
successfully established between PE1 and P1 and between PE2 and P2.
# Run the display mpls ldp session command on PE1, P1, P2, or PE2 to view LDP
session information.
[~PE1] display mpls ldp session
LDP Session(s) in Public Network
Codes: LAM(Label Advertisement Mode), SsnAge Unit(DDDD:HH:MM)
An asterisk (*) before a session means the session is being deleted.
--------------------------------------------------------------------------
PeerID Status LAM SsnRole SsnAge KASent/Rcv
--------------------------------------------------------------------------
2.2.2.2:0 Operational DU Passive 0000:00:05 23/23

(2020-10-09)
--------------------------------------------------------------------------
TOTAL: 1 Session(s) Found.
# Run the display mpls ldp peer command to view LDP peer information. The
[~PE1] display mpls ldp peer
LDP Peer Information in Public network
An asterisk (*) before a peer means the peer is being deleted.
-------------------------------------------------------------------------
PeerID TransportAddress DiscoverySource
-------------------------------------------------------------------------
2.2.2.2:0 2.2.2.2 GigabitEthernet1/0/0
-------------------------------------------------------------------------
TOTAL: 1 Peer(s) Found.
# Run the display mpls lsp command to view LDP LSP information. The following
[~PE1] display mpls lsp
Flag after Out IF: (I) - RLFA Iterated LSP, (I*) - Normal and RLFA Iterated LSP
Flag after LDP FRR: (L) - Logic FRR LSP
----------------------------------------------------------------------
LSP Information: LDP LSP
----------------------------------------------------------------------
FEC In/Out Label In/Out IF Vrf Name
1.1.1.1/32 3/NULL GE1/0/0/-
2.2.2.2/32 NULL/3 -/GE1/0/0
2.2.2.2/32 1024/3 -/GE1/0/0
10.1.1.0/24 3/NUL GE1/0/0/-
10.2.1.0/24 NULL/3 -/GE1/0/0
10.2.1.0/24 1025/3 -/GE1/0/0
Step 5 Set up a remote LDP session between P1 and P2.

# Configure P1.
[~P1] mpls ldp remote-peer lsrd
[*P1-mpls-ldp-remote-lsrd] remote-ip 4.4.4.4
[*P1-mpls-ldp-remote-lsrd] commit
[~P1-mpls-ldp-remote-lsrd] quit
# Configure P2.
[~P2] mpls ldp remote-peer lsrb
[*P2-mpls-ldp-remote-lsrb] remote-ip 2.2.2.2
[*P2-mpls-ldp-remote-lsrb] commit
[~P2-mpls-ldp-remote-lsrb] quit
After you complete the preceding configurations, a remote LDP session is set up
between P1 and P2. Run the display mpls ldp remote-peer command on P1 or
P2 to view information about the remote session entity. The following example
uses the command output on P1.
[~P1] display mpls ldp remote-peer lsrd
LDP Remote Entity Information
------------------------------------------------------------------------------
Remote Peer Name: lsrd
Description : ----
Remote Peer IP : 4.4.4.4 LDP ID : 2.2.2.2:0
Transport Address : 2.2.2.2 Entity Status : Active
Configured Keepalive Hold Timer : 45 Sec

Configured Keepalive Send Timer : ----
Configured Hello Hold Timer : 45 Sec
Negotiated Hello Hold Timer : 45 Sec
Configured Hello Send Timer : ----
Configured Delay Timer : ----

(2020-10-09)
Hello Packet sent/received : 425/382

Label Advertisement Mode : Downstream Unsolicited
Auto-config : ----
Session-Protect effect : NO
Session-Protect Duration : ----
Session-Protect Remain : ----
------------------------------------------------------------------------------
TOTAL: 1 Remote-Peer(s) Found.
Step 6 Configure bandwidth attributes for the outbound interface of each TE tunnel.
# Configure P1.
# Configure P3.
# Configure P2.
Step 7 Configure L3VPN access on PE1 and PE2 and multi-field classification on the
inbound interface of PE1.
# Configure PE1.
[~PE1] ip vpn-instance VPNA
[*PE1-vpn-instance-VPNA] ipv4-family
[*PE1-vpn-instance-VPNA-af-ipv4] route-distinguisher 100:1
[*PE1-vpn-instance-VPNA-af-ipv4] vpn-target 111:1 both
[*PE1-vpn-instance-VPNA-af-ipv4] quit
[*PE1-vpn-instance-VPNA] quit
[*PE1-GigabitEthernet2/0/0] ip binding vpn-instance VPNA
[*PE1] acl 2001
[*PE1] acl 2002
[*PE1] traffic classifier service1
[~PE1] traffic classifier service2

(2020-10-09)

[~PE1] traffic policy test
[*PE1-trafficpolicy-test] classifier service1 behavior behavior1
[*PE1-trafficpolicy-test] classifier service2 behavior behavior2
[*PE1-trafficpolicy-test] commit
[~PE1-trafficpolicy-test] quit
[~PE1-GigabitEthernet2/0/0] traffic-policy test inbound
# Configure PE2.
[~PE2] ip vpn-instance VPNB
[*PE2-vpn-instance-VPNB] ipv4-family
[*PE2-vpn-instance-VPNB-af-ipv4] route-distinguisher 200:1
[*PE2-vpn-instance-VPNB-af-ipv4] vpn-target 111:1 both
[*PE2-vpn-instance-VPNB-af-ipv4] quit
[*PE2-vpn-instance-VPNB] quit
[*PE2-GigabitEthernet2/0/0] ip binding vpn-instance VPNB
Step 8 Configure behavior aggregate classification on interfaces connecting PE1 and P1.
# Configure PE1.
[~PE1-GigabitEthernet1/0/0] trust upstream default
# Configure P1.
[~P1-GigabitEthernet1/0/0] trust upstream default
Step 9 Enable SR and configure an explicit path.
In this example, the explicit path is used to establish an SR-MPLS TE tunnel.
NOTE
# Configure P1.
[*P1] isis 1
[*P1-isis-1] commit
[~P1-isis-1] quit
# Configure P2.

(2020-10-09)
[*P2] isis 1
[*P2-isis-1] commit
[~P2-isis-1] quit
# Configure P3.
[*P3] isis 1
[*P3-isis-1] commit
[~P3-isis-1] quit
# Display the adjacency SID of each node.

[~P1] display segment-routing adjacency mpls forwarding

-----------------------------------------------------------------------------
48091 GE1/0/0 10.1.1.1 ISIS-V4 --- 1500
48092 GE2/0/0 10.2.1.2 ISIS-V4 --- 1500

-----------------------------------------------------------------------------
48090 GE1/0/0 10.2.1.1 ISIS-V4 --- 1500
48091 GE2/0/0 10.3.1.2 ISIS-V4 --- 1500

-----------------------------------------------------------------------------
48090 GE2/0/0 10.4.1.1 ISIS-V4 --- 1500
48091 GE1/0/0 10.3.1.1 ISIS-V4 --- 1500
# Configure an explicit path from P1 to P2.

[~P1] explicit-path p1_p2
[*P1-explicit-path-p1_p2] next sid label 48092 type adjacency
[*P1-explicit-path-p1_p2] commit
[~P1-explicit-path-p1_p2] quit
# Configure an explicit path from P2 to P1.

[~P2] explicit-path p2_p1
[*P2-explicit-path-p2_p1] commit
[~P2-explicit-path-p2_p1] quit

(2020-10-09)
Step 10 Configure TE tunnels from P1 to P2 and set a service class for each type of packet
that can be transmitted by the tunnels.
NOTE
Run the mpls te service-class { service-class & <1-8> | default } command to set a service
class for packets that are allowed to pass through tunnels.
# On P1, enable the IGP shortcut function on each tunnel interface and adjust the
metric value of the forwarding adjacency function to ensure that traffic destined
for P2 or PE2 passes through the corresponding tunnel.
[~P1] interface Tunnel1
[*P1-Tunnel1] ip address unnumbered interface LoopBack1
[*P1-Tunnel1] tunnel-protocol mpls te
[*P1-Tunnel1] destination 4.4.4.4
[*P1-Tunnel1] mpls te tunnel-id 100
[*P1-Tunnel1] mpls te bandwidth ct0 10000
[*P1-Tunnel1] mpls te igp shortcut
[*P1-Tunnel1] mpls te igp metric absolute 1
[*P1-Tunnel1] isis enable 1
[*P1-Tunnel1] mpls te signal-protocol segment-routing
[*P1-Tunnel1] mpls te path explicit-path p1_p2
[*P1-Tunnel1] mpls te service-class af1 af2
[*P1-Tunnel1] quit
[*P1] interface Tunnel2
[*P1-Tunnel2] mpls te service-class default
[*P1-Tunnel2] quit
[*P1] commit
Step 11 Configure a tunnel from P2 to P1.

# On P2, enable the forwarding adjacency function on each tunnel interface and
adjust the metric value of the forwarding adjacency function to ensure that traffic
destined for PE1 or P1 passes through the tunnel.
[~P2] interface Tunnel1
[*P2-Tunnel1] quit
[*P2] commit
# Configure CE1.
[*HUAWEI] commit

(2020-10-09)
[~CE1-GigabitEthernet1/0/0] ip address 10.10.1.2 24

[*CE1] bgp 65410
[*CE1-bgp] quit
[*CE1] commit
NOTE
# Configure PE1.
[~PE1] bgp 100
[*PE1-bgp] ipv4-family vpn-instance VPNA
[*PE1-bgp-VPNA] peer 10.10.1.2 as-number 65410
[*PE1-bgp-VPNA] commit
[~PE1-bgp-VPNA] quit
[~PE1-bgp] quit
NOTE
# Run the ping command on P1 to check the connectivity of each SR-MPLS TE
[~P1] ping lsp segment-routing te Tunnel 1
CTRL_C to break
0.00% packet loss
[~P1] ping lsp segment-routing te Tunnel 2
CTRL_C to break
0.00% packet loss
# Check information about LDP LSP establishment on each PE. The following

(2020-10-09)
[~PE1] display mpls lsp

Flag after LDP FRR: (L) - Logic FRR LSP
-------------------------------------------------------------------------------
LSP Information: LDP LSP
-------------------------------------------------------------------------------
1.1.1.1/32 3/NULL -/-
2.2.2.2/32 NULL/3 -/GE2/0/0
2.2.2.2/32 48151/3 -/GE2/0/0
3.3.3.3/32 NULL/48150 -/GE2/0/0
3.3.3.3/32 48152/48150 -/GE2/0/0
4.4.4.4/32 NULL/48153 -/GE2/0/0
4.4.4.4/32 48155/48153 -/GE2/0/0
5.5.5.5/32 NULL/48155 -/GE2/0/0
5.5.5.5/32 48157/48155 -/GE2/0/0
10.1.1.0/24 3/NULL -/-
10.2.1.0/24 NULL/3 -/GE2/0/0
10.2.1.0/24 48153/3 -/GE2/0/0
10.3.1.0/24 NULL/48151 -/GE2/0/0
10.3.1.0/24 48154/48151 -/GE2/0/0
10.4.1.0/24 NULL/48154 -/GE2/0/0
10.4.1.0/24 48156/48154 -/GE2/0/0
-------------------------------------------------------------------------------
LSP Information: BGP LSP
-------------------------------------------------------------------------------
-/32 48090/NULL -/- VPNA
----End
Configuration Files
#
sysname PE1
#
ip vpn-instance VPNA
ipv4-family
#
mpls lsr-id 1.1.1.1
#
mpls
lsp-trigger all
#
mpls ldp
#
ipv4-family
#
acl number 2001
#
acl number 2002
#
if-match acl 2001
#
if-match acl 2002
#
#

(2020-10-09)

#
traffic policy test
share-mode
#
segment-routing
#
isis 1
is-level level-2
cost-style wide
network-entity 10.0000.0000.0001.00
#
undo shutdown
ip address 10.1.1.1 255.255.255.0
isis enable 1
mpls
mpls ldp
trust upstream default
#
undo shutdown
ip binding vpn-instance VPNA
ip address 10.10.1.1 255.255.255.0
traffic-policy test inbound
#
interface LoopBack1
ip address 1.1.1.1 255.255.255.255
isis enable 1
#
bgp 100
#
ipv4-family unicast
peer 5.5.5.5 enable
#
ipv4-family vpnv4
policy vpn-target
peer 5.5.5.5 enable
#
ipv4-family vpn-instance VPNA
#
return
#
sysname P1
#
mpls lsr-id 2.2.2.2
#
mpls
mpls te
lsp-trigger all
#
explicit-path p1_p2
#
mpls ldp
#
ipv4-family
#
mpls ldp remote-peer lsrd
remote-ip 4.4.4.4

(2020-10-09)
#
segment-routing
#
isis 1
is-level level-2
cost-style wide
network-entity 10.0000.0000.0002.00
traffic-eng level-2
#
undo shutdown
ip address 10.1.1.2 255.255.255.0
isis enable 1
mpls
mpls ldp
trust upstream default
#
undo shutdown
ip address 10.2.1.1 255.255.255.0
isis enable 1
mpls
mpls te
#
interface LoopBack1
ip address 2.2.2.2 255.255.255.255
isis enable 1
#
interface Tunnel1
isis enable 1
destination 4.4.4.4
mpls te igp shortcut
mpls te igp metric absolute 1
mpls te path explicit-path p1_p2
mpls te service-class af1 af2
#
interface Tunnel2
isis enable 1
destination 4.4.4.4
mpls te service-class default
#
return
#
sysname P3
#
mpls lsr-id 3.3.3.3
#
mpls
mpls te
#
segment-routing

(2020-10-09)
#
isis 1
is-level level-2
cost-style wide
network-entity 10.0000.0000.0004.00
traffic-eng level-2
#
undo shutdown
ip address 10.2.1.2 255.255.255.0
isis enable 1
mpls
mpls te
#
undo shutdown
ip address 10.3.1.1 255.255.255.0
isis enable 1
mpls
mpls te
#
interface LoopBack1
ip address 3.3.3.3 255.255.255.255
isis enable 1
#
return
#
sysname P2
#
mpls lsr-id 4.4.4.4
#
mpls
mpls te
lsp-trigger all
#
explicit-path p2_p1
#
mpls ldp
#
ipv4-family
#
mpls ldp remote-peer lsrb
remote-ip 2.2.2.2
#
segment-routing
#
isis 1
is-level level-2
cost-style wide
network-entity 10.0000.0000.0003.00
traffic-eng level-2
#
undo shutdown
ip address 10.3.1.2 255.255.255.0
isis enable 1
mpls
mpls te

(2020-10-09)

#
undo shutdown
ip address 10.4.1.2 255.255.255.0
isis enable 1
mpls
mpls ldp
#
interface LoopBack1
ip address 4.4.4.4 255.255.255.255
isis enable 1
#
interface Tunnel1
isis enable 1
destination 2.2.2.2
#
return
#
sysname PE2
#
ip vpn-instance VPNB
ipv4-family
#
mpls lsr-id 5.5.5.5
#
mpls
lsp-trigger all
#
mpls ldp
#
segment-routing
#
isis 1
is-level level-2
cost-style wide
network-entity 10.0000.0000.0005.00
#
undo shutdown
ip address 10.4.1.1 255.255.255.0
isis enable 1
mpls
mpls ldp
#
undo shutdown
ip binding vpn-instance VPNB
ip address 10.11.1.1 255.255.255.0
#
interface LoopBack1
ip address 5.5.5.5 255.255.255.255
isis enable 1
#
bgp 100

(2020-10-09)

#
ipv4-family unicast
peer 1.1.1.1 enable
#
ipv4-family vpnv4
policy vpn-target
peer 1.1.1.1 enable
#
ipv4-family vpn-instance VPNB
#
return
#
sysname CE1
#
undo shutdown
ip address 10.10.1.2 255.255.255.0
#
bgp 65410
#
ipv4-family unicast
import-route direct
#
return
#
sysname CE2
#
undo shutdown
ip address 10.11.1.2 255.255.255.0
#
bgp 65420
#
ipv4-family unicast
import-route direct
#
return
1.2.40.12 Example for Configuring DSCP-Based IP Service Recursion to SR-

MPLS TE Tunnels
This section provides an example for configuring IP service recursion to SR-MPLS
TE tunnels based on the differentiated services code point (DSCP) values of IP
packets.
In SR-MPLS TE scenarios, you can configure the class-of-service-based tunnel
selection (CBTS) function to allow traffic of a specific service class to be
transmitted along a specified tunnel. However, with the increase of service classes,
the CBTS function is gradually incapable of meeting service requirements. Similar

(2020-10-09)
to the CBTS function, DSCP-based IP service recursion steers IPv4 or IPv6 packets
into SR-MPLS TE tunnels based on the DSCP values of the packets.
● CE1 and CE2 belong to vpna. The VPN target used by vpna is 111:1.
● Two SR-MPLS TE tunnels (tunnel 1 and tunnel 2) are created between PE1
and PE2.
There are multiple types of services between CE1 and CE2. To ensure the
forwarding quality of important services, you can configure the services to recurse
to SR-MPLS TE tunnels based on the DSCP values of IP packets.
This example requires Tunnel1 to transmit services with DSCP values ranging from
0 to 10 and Tunnel2 to transmit other services by default.
Figure 1-136 Networking for DSCP-based IP service recursion to SR-MPLS TE

tunnels
NOTE
Precautions
If a VPN instance is bound to a PE interface connected to a CE, Layer 3
configurations, such as IP address and routing protocol configurations, on this
interface are automatically deleted. If needed, these items need to be
reconfigured.

(2020-10-09)
1. Configure IS-IS on the backbone network for the PEs to communicate.

2. Enable MPLS on the backbone network and configure SR and static adjacency
labels.
3. Configure SR-MPLS TE tunnels between the PEs.
4. Establish an MP-IBGP peer relationship between the PEs.
5. Configure a VPN instance on each PE, enable the IPv4 address family for the
instance, and bind the instance to the PE interface connecting the PE to a CE.
6. Establish an EBGP peer relationship between each pair of a CE and a PE.
7. Configure a tunnel selection policy on each PE and set the number of tunnels
participating in load balancing to 2, indicating that Tunnel1 and Tunnel2
balance service traffic.
8. On each PE, configure tunnel 1 to transmit services with DSCP values ranging
from 0 to 10 and tunnel 2 to transmit other services.
Data Preparation
● MPLS LSR IDs on the PEs and Ps

Procedure
# Configure PE1.
[*HUAWEI] commit
[*PE1] commit
# Configure P1.
[*HUAWEI] commit
[*P1] commit
# Configure PE2.

(2020-10-09)
[*HUAWEI] commit
[*PE2] commit
# Configure P2.
[*HUAWEI] commit
[*P2] commit
Step 2 Configure an IGP on the backbone network for the PEs and Ps to communicate.
The following example uses IS-IS.
# Configure PE1.
[~PE1] isis 1
[*PE1-isis-1] quit
[*PE1] commit
# Configure P1.
[~P1] isis 1
[*P1-isis-1] quit
[*P1] commit
# Configure PE2.
[~PE2] isis 1

(2020-10-09)

[*PE2-isis-1] quit
[*PE2] commit
# Configure P2.
[~P2] isis 1
[*P2-isis-1] quit
[*P2] commit
Step 3 Configure basic MPLS functions on the backbone network.

# Configure PE1.
[*PE1] mpls
[*PE1-mpls] mpls te
[*PE1-mpls] commit
[~PE1-mpls] quit
# Configure P1.
[*P1] mpls
[*P1-mpls] mpls te
[*P1-mpls] commit
[~P1-mpls] quit
# Configure PE2.
[*PE2] mpls
[*PE2-mpls] mpls te
[*PE2-mpls] commit
[~PE2-mpls] quit
# Configure P2.
[*P2] mpls
[*P2-mpls] mpls te
[*P2-mpls] commit
[~P2-mpls] quit
Step 4 Configure SR on the backbone network.

# Configure PE1.
[*PE1-segment-routing] ipv4 adjacency local-ip-addr 10.11.1.1 remote-ip-addr 10.11.1.2 sid 330000

(2020-10-09)

[*PE1] isis 1
[*PE1-isis-1] quit
[*PE1] commit
# Configure P1.
[*P1-segment-routing] ipv4 adjacency local-ip-addr 10.11.1.2 remote-ip-addr 10.11.1.1 sid 330003
[*P1] isis 1
[*P1-isis-1] quit
[*P1] commit
# Configure PE2.
[*PE2] isis 1
[*PE2-isis-1] quit
[*PE2] commit
# Configure P2.
[*P2] isis 1
[*P2-isis-1] quit
[*P2] commit
Step 5 Configure SR-MPLS TE tunnels.

# Configure PE1.
[~PE1] explicit-path path1
[*PE1-explicit-path-path1] next sid label 330000 type adjacency
[*PE1-explicit-path-path1] quit
[*PE1] explicit-path path2
[*PE1] interface Tunnel1
[*PE1-Tunnel1] mpls te path explicit-path path1
[*PE1-Tunnel1] quit

(2020-10-09)

[*PE1-Tunnel2] quit
[*PE1] commit
# Configure PE2.
[~PE2] explicit-path path1
[*PE2] explicit-path path2
[*PE2-Tunnel1] quit
[*PE2-Tunnel2] quit
[*PE2] commit
Step 6 Establish an MP-IBGP peer relationship between the PEs.

# Configure PE1.
[~PE1] bgp 100
[~PE1-bgp] quit
# Configure PE2.
[~PE2] bgp 100
[~PE2-bgp] quit
vpnv4 all peer command on the PEs and check whether a BGP peer relationship
3.3.3.9 4 100 2 6 0 00:00:12 Established 0

(2020-10-09)

3.3.3.9 4 100 12 18 0 00:09:38 Established 0
Step 7 Configure a VPN instance on each PE, enable the IPv4 address family for the
instance, and bind the instance to the PE interface connecting the PE to a CE.
# Configure PE1.
[*PE1] commit
# Configure PE2.
[*PE2] commit
Step 8 Configure a tunnel policy on each PE, so that SR-MPLS TE tunnels are prioritized.
# Configure PE1.
[*PE1-tunnel-policy-p1] tunnel select-seq sr-te load-balance-number 2 unmix
[*PE1] ip vpn-instance vpna
[*PE1] commit
# Configure PE2.
[*PE2-tunnel-policy-p1] tunnel select-seq sr-te load-balance-number 2 unmix
[*PE2] commit
# Configure CE1.

(2020-10-09)
[*HUAWEI] commit
[*CE1] bgp 65410
[*CE1-bgp] network 10.11.1.1 32
[*CE1-bgp] quit
[*CE1] commit
NOTE
Repeat this step on CE2. For configuration details, see Configuration Files in this section.
# Configure PE1.
[~PE1] bgp 100
[~PE1-bgp] quit
NOTE
Repeat this step on PE2. For configuration details, see Configuration Files in this section.

command on the PEs to check VPN instance configurations. The command output
shows that each PE can successfully ping its connected CE.
NOTE
If a PE has multiple interfaces bound to the same VPN instance, use the -a source-ip-
address parameter to specify a source IP address when running the ping -vpn-instance
vpn-instance-name -a source-ip-address dest-ip-address command to ping the CE that is
connected to the remote PE. If the source IP address is not specified, the ping operation
may fail.
The following example uses the command output on PE1 to show that a BGP peer
relationship has been established between PE1 and CE1.


10.1.1.1 4 65410 91 90 0 01:15:39 Established 1
Run the display ip routing-table vpn-instance command on each PE. The

command output shows the routes to CE loopback interfaces.

(2020-10-09)

------------------------------------------------------------------------------
Routing Table: vpna
10.22.2.2/32 IBGP 255 0 RD 3.3.3.9 Tunnel1
Run the display ip routing-table vpn-instance vpna verbose command on each

PE. The command output shows details about the routes to CE loopback
interfaces.
[~PE1] display ip routing-table vpn-instance vpna 10.22.2.2 verbose
route
------------------------------------------------------------------------------
Routing Table : vpna
Summary Count : 1
Destination: 10.22.2.2/32
Protocol: IBGP Process ID: 0
Preference: 255 Cost: 0
NextHop: 3.3.3.9 Neighbour: 3.3.3.9
State: Active Adv Relied Age: 00h49m58s
Tag: 0 Priority: low
Label: 48120 QoSInfo: 0x0
IndirectID: 0x10000DA Instance:
RelayNextHop: 0.0.0.0 Interface: Tunnel1
TunnelID: 0x000000000300000001 Flags: RD
The preceding command output shows that the corresponding VPN route has
successfully recursed to an SR-MPLS TE tunnel.
Run the ping command. The command output shows that CEs in the same VPN
can ping each other. For example, CE1 can ping CE2 at 10.22.2.2.
[~CE1] ping -a 10.11.1.1 10.22.2.2
0.00% packet loss
Step 10 Configure the SR-MPLS TE tunnels to transmit services with different DSCP values.
# Configure PE1.
[*PE1-Tunnel1] match dscp ipv4 0 to 10
[*PE1-Tunnel1] quit
[*PE1-Tunnel2] match dscp ipv4 default
[*PE1-Tunnel2] quit
[*PE1] commit
# Configure PE2.

(2020-10-09)

[*PE2-Tunnel1] match dscp ipv4 0 to 10
[*PE2-Tunnel1] quit
[*PE2-Tunnel2] match dscp ipv4 default
[*PE2-Tunnel2] quit
[*PE2] commit
IP packets have a default DSCP value. You can also configure multi-field
classification to configure desired DSCP values for the IP packets. After the
configuration is complete, Tunnel1 transmits services with DSCP values ranging
from 0 to 10, and Tunnel2 transmits other services by default.
----End
Configuration Files
#
sysname PE1
#
ipv4-family
tnl-policy p1
#
mpls lsr-id 1.1.1.9
#
mpls
mpls te
#
explicit-path path1
#
explicit-path path2
#
segment-routing
ipv4 adjacency local-ip-addr 10.11.1.1 remote-ip-addr 10.11.1.2 sid 330000
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0001.00
#
undo shutdown
ip address 10.13.1.1 255.255.255.0
isis enable 1
#
undo shutdown
ip address 10.1.1.2 255.255.255.0
#
undo shutdown
ip address 10.11.1.1 255.255.255.0
isis enable 1
#
interface LoopBack1

(2020-10-09)
ip address 1.1.1.9 255.255.255.255

isis enable 1
#
interface Tunnel1
destination 3.3.3.9
mpls te tunnel-id 1
mpls te path explicit-path path1
match dscp ipv4 0 to 10
#
interface Tunnel2
destination 3.3.3.9
mpls te tunnel-id 2
match dscp ipv4 default
#
bgp 100
#
ipv4-family unicast
peer 3.3.3.9 enable
#
ipv4-family vpnv4
policy vpn-target
peer 3.3.3.9 enable
#
#
tunnel-policy p1
tunnel select-seq sr-te load-balance-number 2 unmix
#
return
#
sysname P1
#
mpls lsr-id 2.2.2.9
#
mpls
#
segment-routing
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0002.00
#
undo shutdown
ip address 10.11.1.2 255.255.255.0
isis enable 1
#
undo shutdown
ip address 10.12.1.1 255.255.255.0
isis enable 1
#
interface LoopBack1

(2020-10-09)
ip address 2.2.2.9 255.255.255.255

isis enable 1
#
return
#
sysname PE2
#
ipv4-family
tnl-policy p1
#
mpls lsr-id 3.3.3.9
#
mpls
mpls te
#
explicit-path path1
#
explicit-path path2
#
segment-routing
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0003.00
#
undo shutdown
ip address 10.14.1.2 255.255.255.0
isis enable 1
#
undo shutdown
ip address 10.2.1.2 255.255.255.0
#
undo shutdown
ip address 10.12.1.2 255.255.255.0
isis enable 1
#
interface LoopBack1
ip address 3.3.3.9 255.255.255.255
isis enable 1
#
interface Tunnel1
destination 1.1.1.9
mpls te tunnel-id 1
match dscp ipv4 0 to 10
#
interface Tunnel2

(2020-10-09)
destination 1.1.1.9
mpls te tunnel-id 2
match dscp ipv4 default
#
bgp 100
#
ipv4-family unicast
peer 1.1.1.9 enable
#
ipv4-family vpnv4
policy vpn-target
peer 1.1.1.9 enable
#
#
tunnel-policy p1
tunnel select-seq sr-te load-balance-number 2 unmix
#
return
#
sysname P2
#
mpls lsr-id 4.4.4.9
#
mpls
#
segment-routing
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0004.00
#
undo shutdown
ip address 10.13.1.2 255.255.255.0
isis enable 1
#
undo shutdown
ip address 10.14.1.1 255.255.255.0
isis enable 1
#
interface LoopBack1
ip address 4.4.4.9 255.255.255.255
isis enable 1
#
return
#
sysname CE1
#
undo shutdown
ip address 10.1.1.1 255.255.255.0
#
interface LoopBack1
ip address 10.11.1.1 255.255.255.255

(2020-10-09)
#
bgp 65410
#
ipv4-family unicast
network 10.11.1.1 255.255.255.255
#
return

#
sysname CE2
#
undo shutdown
ip address 10.2.1.1 255.255.255.0
#
interface LoopBack1
ip address 10.22.2.2 255.255.255.255
#
bgp 65420
#
ipv4-family unicast
network 10.22.2.2 255.255.255.255
#
return
1.2.41 Configuration Examples for SR-MPLS TE Policy

This section provides several configuration examples of SR-MPLS TE Policy.
1.2.41.1 Example for Configuring L3VPN Routes to Be Recursed to Manually

Configured SR-MPLS TE Policies (Color-Based)
This section provides an example for configuring L3VPN routes to be recursed to
manually configured SR-MPLS TE Policies based on the Color Extended
Community to ensure secure communication between users of the same VPN.
● CE1 and CE2 belong to a VPN instance named vpna.
Configure L3VPN routes to be recursed to SR-MPLS TE Policies to ensure secure

communication between users of the same VPN. Because multiple links exist
between PEs on the public network, other links must be able to provide protection
for the primary link.
Figure 1-137 L3VPN route recursion to manually configured SR-MPLS TE Policies

NOTE

(2020-10-09)
Precautions
If an interface connecting a PE to a CE is bound to a VPN instance, Layer 3
configurations, such as the IP address and routing protocol configuration, on the
interface will be deleted. Reconfigure them if needed.
1. Configure IS-IS for each device on the backbone network to implement

interworking between PEs and Ps.
2. Enable MPLS and SR for each device on the backbone network, and configure
static adjacency SIDs.
3. Configure an SR-MPLS TE Policy with primary and backup paths on each PE.
4. Configure SBFD and HSB on each PE to enhance SR-MPLS TE Policy reliability.
5. Apply an import or export route-policy to a specified VPNv4 peer on each PE,
and set the Color Extended Community. In this example, an import route-
policy with the Color Extended Community is applied.
6. Establish an MP-IBGP peer relationship between PEs for them to exchange
7. Create a VPN instance and enable the IPv4 address family on each PE. Then,
bind each PE's interface connecting the PE to a CE to the corresponding VPN
instance.
8. Configure a tunnel selection policy on each PE.
9. Establish an EBGP peer relationship between each CE-PE pair for the CE and
PE to exchange routing information.

(2020-10-09)
Data Preparation
● MPLS LSR IDs of PEs and Ps
Procedure
Step 1 Configure interface IP addresses for each device on the backbone network.
# Configure PE1.
[*HUAWEI] commit
[*PE1] commit
# Configure P1.
[*HUAWEI] commit
[*P1] commit
# Configure PE2.
[*HUAWEI] commit
[*PE2] commit
# Configure P2.
[*HUAWEI] commit

(2020-10-09)

[*P2] commit
Step 2 Configure an IGP for each device on the backbone network to implement
interworking between PEs and Ps. In this example, the IGP is IS-IS.
# Configure PE1.
[~PE1] isis 1
[*PE1-isis-1] quit
[*PE1] commit
# Configure P1.
[~P1] isis 1
[*P1-isis-1] quit
[*P1] commit
# Configure PE2.
[~PE2] isis 1
[*PE2-isis-1] quit
[*PE2] commit
# Configure P2.
[~P2] isis 1
[*P2-isis-1] quit

(2020-10-09)
[*P2] commit
Step 3 Configure basic MPLS functions for each device on the backbone network.
# Configure PE1.
[*PE1] mpls
[*PE1-mpls] commit
[~PE1-mpls] quit
# Configure P1.
[*P1] mpls
[*P1-mpls] commit
[~P1-mpls] quit
# Configure PE2.
[*PE2] mpls
[*PE2-mpls] commit
[~PE2-mpls] quit
# Configure P2.
[*P2] mpls
[*P2-mpls] commit
[~P2-mpls] quit
Step 4 Enable SR for each device on the backbone network.

# Configure PE1.
[*PE1] isis 1
[*PE1-isis-1] quit
[*PE1] commit
# Configure P1.
[*P1] isis 1
[*P1-isis-1] quit
[*P1] commit
# Configure PE2.

(2020-10-09)
[*PE2] isis 1
[*PE2-isis-1] quit
[*PE2] commit
# Configure P2.
[*P2] isis 1
[*P2-isis-1] quit
[*P2] commit
Step 5 Configure an SR-MPLS TE Policy on each PE.
# Configure PE1.
[~PE1-segment-routing] segment-list pe1
[*PE1-segment-routing-segment-list-pe1] index 10 sid label 330000
[*PE1-segment-routing-segment-list-pe1] quit
[*PE1-segment-routing] segment-list pe1backup
[*PE1-segment-routing-segment-list-pe1backup] index 10 sid label 330001
[*PE1-segment-routing-segment-list-pe1backup] quit
[*PE1-segment-routing] sr-te policy policy100 endpoint 3.3.3.9 color 100
[*PE1-segment-routing-te-policy-policy100] binding-sid 115
[*PE1-segment-routing-te-policy-policy100] mtu 1000
[*PE1-segment-routing-te-policy-policy100] candidate-path preference 100
[*PE1-segment-routing-te-policy-policy100-path] segment-list pe1backup
[*PE1-segment-routing-te-policy-policy100-path] quit
[*PE1-segment-routing-te-policy-policy100-path] segment-list pe1
[*PE1-segment-routing-te-policy-policy100] quit
[*PE1] commit
# Configure PE2.
[*PE2] commit

(2020-10-09)
After completing the configuration, run the display sr-te policy command to
check SR-MPLS TE Policy information. The following example uses the command
output on PE1.
[~PE1] display sr-te policy
PolicyName : policy100
Endpoint : 3.3.3.9 Color : 100
TunnelId :1 TunnelType : SR-TE Policy
Binding SID : 115 MTU : 1000
Policy State : Up State Change Time : 2020-05-18 11:23:39
Admin State : UP Traffic Statistics : Disable
BFD : Disable Backup Hot-Standby : Disable
DiffServ-Mode :-
Candidate-path Count : 2
Candidate-path Preference: 200

Path State : Active Path Type : Primary
Protocol-Origin : Configuration(30) Originator : 0, 0.0.0.0
Discriminator : 200 Binding SID :-
GroupId :2 Policy Name : policy100
Template ID :-
Segment-List Count : 1
Segment-List : pe1
Segment-List ID : 129 XcIndex : 68
List State : Up BFD State :-
EXP :- TTL :-
DeleteTimerRemain : -
Label : 330000, 330002

Path State : Inactive (Valid) Path Type :-
Template ID :-
Segment-List : pe1backup
Segment-List ID : 194 XcIndex :-
EXP :- TTL :-
Label : 330001, 330003
Step 6 Configure SBFD and HSB on each PE.

# Configure PE1.
[~PE1] bfd
[*PE1-bfd] quit
[*PE1] sbfd
[*PE1-sbfd] quit
[*PE1-segment-routing] sr-te-policy seamless-bfd enable
[*PE1-segment-routing] sr-te-policy backup hot-standby enable
# Configure PE2.
[~PE2] bfd
[*PE2-bfd] quit
[*PE2] sbfd
[*PE2-sbfd] quit

(2020-10-09)
Step 7 Configure a route-policy on each PE.

# Configure PE1.
[~PE1] route-policy color100 permit node 1
[*PE1-route-policy] apply extcommunity color 0:100
[*PE1-route-policy] quit
[*PE1] commit
# Configure PE2.
[*PE2] commit
Step 8 Establish an MP-IBGP peer relationship between PEs, apply an import route-policy
to a specified VPNv4 peer on each PE, and set the Color Extended Community.
# Configure PE1.
[~PE1] bgp 100
[*PE1-bgp-af-vpnv4] peer 3.3.3.9 route-policy color100 import
[~PE1-bgp] quit
# Configure PE2.
[~PE2] bgp 100
[~PE2-bgp] quit
After completing the configuration, run the display bgp peer or display bgp
vpnv4 all peer command on each PE. The following example uses the command
output on PE1. The command output shows that a BGP peer relationship has been
established between the PEs and is in the Established state.
3.3.3.9 4 100 2 6 0 00:00:12 Established 0
3.3.3.9 4 100 12 18 0 00:09:38 Established 0
Step 9 Create a VPN instance and enable the IPv4 address family on each PE. Then, bind
each PE's interface connecting the PE to a CE to the corresponding VPN instance.
# Configure PE1.

(2020-10-09)
[*PE1] commit
# Configure PE2.
[*PE2] commit
Step 10 Configure a tunnel selection policy on each PE for the specified SR-MPLS TE Policy
to be preferentially selected.
# Configure PE1.
[*PE1-tunnel-policy-p1] tunnel select-seq sr-te-policy load-balance-number 1 unmix
[*PE1] commit
# Configure PE2.
[*PE2] commit
Step 11 Establish an EBGP peer relationship between each CE-PE pair.
# Configure CE1.
[*HUAWEI] commit
[*CE1] bgp 65410
[*CE1-bgp] network 10.11.1.1 32
[*CE1-bgp] quit

(2020-10-09)
[*CE1] commit
NOTE

NOTE
may fail.
# Configure PE1.
[~PE1] bgp 100
[~PE1-bgp] quit
NOTE
After completing the configuration, run the display bgp vpnv4 vpn-instance peer
command on each PE. The following example uses the peer relationship between
PE1 and CE1. The command output shows that a BGP peer relationship has been
established between the PE and CE and is in the Established state.


10.1.1.1 4 65410 91 90 0 01:15:39 Established 1

After completing the configuration, run the display ip routing-table vpn-
instance command on each PE to check information about the loopback interface
route toward a CE.
------------------------------------------------------------------------------
Routing Table: vpna

(2020-10-09)

10.22.2.2/32 IBGP 255 0 RD 3.3.3.9 policy100

PE to check details about the loopback interface route toward a CE.
------------------------------------------------------------------------------
Summary Count : 1
IndirectID: 0x10000B9 Instance:
RelayNextHop: 0.0.0.0 Interface: policy100
The command output shows that the VPN route has been successfully recursed to
the specified SR-MPLS TE Policy.
CEs in the same VPN can ping each other. For example, CE1 can ping CE2 at
10.22.2.2.
[~CE1] ping -a 10.11.1.1 10.22.2.2
0.00% packet loss
----End
Configuration Files
#
sysname PE1
#
ipv4-family
tnl-policy p1
#
bfd
#
sbfd

(2020-10-09)

#
mpls lsr-id 1.1.1.9
#
mpls
#
segment-routing
sr-te-policy backup hot-standby enable
sr-te-policy seamless-bfd enable
segment-list pe1
index 10 sid label 330000
segment-list pe1backup
sr-te policy policy100 endpoint 3.3.3.9 color 100
binding-sid 115
mtu 1000
candidate-path preference 200
segment-list pe1
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0001.00
#
undo shutdown
ip address 10.13.1.1 255.255.255.0
isis enable 1
#
undo shutdown
ip address 10.1.1.2 255.255.255.0
#
undo shutdown
ip address 10.11.1.1 255.255.255.0
isis enable 1
#
interface LoopBack1
ip address 1.1.1.9 255.255.255.255
isis enable 1
#
bgp 100
#
ipv4-family unicast
peer 3.3.3.9 enable
#
ipv4-family vpnv4
policy vpn-target
peer 3.3.3.9 enable
peer 3.3.3.9 route-policy color100 import
#
#
route-policy color100 permit node 1
apply extcommunity color 0:100
#

(2020-10-09)
tunnel-policy p1
tunnel select-seq sr-te-policy load-balance-number 1 unmix
#
return
#
sysname P1
#
mpls lsr-id 2.2.2.9
#
mpls
#
segment-routing
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0002.00
#
undo shutdown
ip address 10.11.1.2 255.255.255.0
isis enable 1
#
undo shutdown
ip address 10.12.1.1 255.255.255.0
isis enable 1
#
interface LoopBack1
ip address 2.2.2.9 255.255.255.255
isis enable 1
#
return
#
sysname PE2
#
ipv4-family
tnl-policy p1
#
bfd
#
sbfd
#
mpls lsr-id 3.3.3.9
#
mpls
#
segment-routing
segment-list pe2

(2020-10-09)

binding-sid 115
mtu 1000
segment-list pe2
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0003.00
#
undo shutdown
ip address 10.14.1.2 255.255.255.0
isis enable 1
#
undo shutdown
ip address 10.2.1.2 255.255.255.0
#
undo shutdown
ip address 10.12.1.2 255.255.255.0
isis enable 1
#
interface LoopBack1
ip address 3.3.3.9 255.255.255.255
isis enable 1
#
bgp 100
#
ipv4-family unicast
peer 1.1.1.9 enable
#
ipv4-family vpnv4
policy vpn-target
peer 1.1.1.9 enable
#
#
#
tunnel-policy p1
#
return
#
sysname P2
#
mpls lsr-id 4.4.4.9
#
mpls
#
segment-routing
#
isis 1

(2020-10-09)
is-level level-1
cost-style wide
network-entity 10.0000.0000.0004.00
#
undo shutdown
ip address 10.13.1.2 255.255.255.0
isis enable 1
#
undo shutdown
ip address 10.14.1.1 255.255.255.0
isis enable 1
#
interface LoopBack1
ip address 4.4.4.9 255.255.255.255
isis enable 1
#
return

#
sysname CE1
#
undo shutdown
ip address 10.1.1.1 255.255.255.0
#
interface LoopBack1
ip address 10.11.1.1 255.255.255.255
#
bgp 65410
#
ipv4-family unicast
network 10.11.1.1 255.255.255.255
#
return

#
sysname CE2
#
undo shutdown
ip address 10.2.1.1 255.255.255.0
#
interface LoopBack1
ip address 10.22.2.2 255.255.255.255
#
bgp 65420
#
ipv4-family unicast
network 10.22.2.2 255.255.255.255
#
return
1.2.41.2 Example for Configuring L3VPN Routes to Be Recursed to Manually

Configured SR-MPLS TE Policies (DSCP-Based)
manually configured SR-MPLS TE Policies based on the DSCP value to ensure
secure communication between users of the same VPN.

(2020-10-09)

Figure 1-138 L3VPN route recursion to manually configured SR-MPLS TE Policies

NOTE
Precautions


(2020-10-09)
instance.
7. Configure an SR-MPLS TE Policy group on each PE and define mappings
between the color and DSCP values.
8. Configure a tunnel selection policy on each PE for the specified SR-MPLS TE
Policy group to be preferentially selected.
Data Preparation
Procedure
# Configure PE1.
[*HUAWEI] commit
[*PE1] commit
# Configure P1.
[*HUAWEI] commit
[*P1] commit
# Configure PE2.

(2020-10-09)

[*HUAWEI] commit
[*PE2] commit
# Configure P2.
[*HUAWEI] commit
[*P2] commit
# Configure PE1.
[~PE1] isis 1
[*PE1-isis-1] quit
[*PE1] commit
# Configure P1.
[~P1] isis 1
[*P1-isis-1] quit
[*P1] commit
# Configure PE2.
[~PE2] isis 1

(2020-10-09)

[*PE2-isis-1] quit
[*PE2] commit
# Configure P2.
[~P2] isis 1
[*P2-isis-1] quit
[*P2] commit
# Configure PE1.
[*PE1] mpls
[*PE1-mpls] commit
[~PE1-mpls] quit
# Configure P1.
[*P1] mpls
[*P1-mpls] commit
[~P1-mpls] quit
# Configure PE2.
[*PE2] mpls
[*PE2-mpls] commit
[~PE2-mpls] quit
# Configure P2.
[*P2] mpls
[*P2-mpls] commit
[~P2-mpls] quit

# Configure PE1.
[*PE1] isis 1

(2020-10-09)

[*PE1-isis-1] quit
[*PE1] commit
# Configure P1.
[*P1] isis 1
[*P1-isis-1] quit
[*P1] commit
# Configure PE2.
[*PE2] isis 1
[*PE2-isis-1] quit
[*PE2] commit
# Configure P2.
[*P2] isis 1
[*P2-isis-1] quit
[*P2] commit

# Configure PE1.
[*PE1-segment-routing-te-policy-policy100] diffserv-mode pipe af1 green
[*PE1] commit
# Configure PE2.

(2020-10-09)

[*PE2-segment-routing-te-policy-policy200] diffserv-mode pipe af1 green
[*PE2] commit
After the configuration is complete, run the display sr-te policy command to
output on PE1.
DiffServ-Mode : Pipe, AF1, Green

Template ID :-
Segment-List : pe1
EXP :- TTL :-
Label : 330000, 330002

Template ID :-
EXP :- TTL :-
Label : 330001, 330003

# Configure PE1.
[~PE1] bfd

(2020-10-09)
[*PE1-bfd] quit
[*PE1] sbfd
[*PE1-sbfd] quit
# Configure PE2.
[~PE2] bfd
[*PE2-bfd] quit
[*PE2] sbfd
[*PE2-sbfd] quit

# Configure PE1.
[~PE1] bgp 100
[~PE1-bgp] quit
# Configure PE2.
[~PE2] bgp 100
[~PE2-bgp] quit
After completing the configuration, run the display bgp peer or display bgp
vpnv4 all peer command on each PE. The following example uses the command
output on PE1. The command output shows that a BGP peer relationship has been
established between the PEs and is in the Established state.
3.3.3.9 4 100 2 6 0 00:00:12 Established 0
3.3.3.9 4 100 12 18 0 00:09:38 Established 0
# Configure PE1.

(2020-10-09)

[*PE1] commit
# Configure PE2.
[*PE2] commit
group to be preferentially selected.
# Configure PE1.
[~PE1-segment-routing] sr-te-policy group 1
[*PE1-segment-routing-te-policy-group-1] endpoint 3.3.3.9
[*PE1-segment-routing-te-policy-group-1] color 100 match dscp ipv4 20
[*PE1-segment-routing-te-policy-group-1] quit
[*PE1] tunnel-policy p1
[*PE1-tunnel-policy-p1] tunnel binding destination 3.3.3.9 sr-te-policy group 1
[*PE1] commit
# Configure PE2.
[~PE2-segment-routing] sr-te-policy group 1
[*PE2-segment-routing-te-policy-group-1] endpoint 1.1.1.9
[*PE2-segment-routing-te-policy-group-1] color 200 match dscp ipv4 20
[*PE2-segment-routing-te-policy-group-1] quit
[*PE2-tunnel-policy-p1] tunnel binding destination 1.1.1.9 sr-te-policy group 1
[*PE2] commit
After completing the configuration, run the display sr-te policy group 1
command on each PE. The command output shows the SR-MPLS TE Policy group
status.

(2020-10-09)

[~PE1] display sr-te policy group 1
SR-TE Policy Group Information
-------------------------------------------------------------------------------
GroupID : 1 GroupState : UP
GTunnelID : 67 GTunnelType : SR-TE Policy Group
Endpoint : 3.3.3.9 UP/ALL Num : 1/1
-------------------------------------------------------------------------------
TunnelId AfType Color Dscp
-------------------------------------------------------------------------------
65 IPV4 100 20
-------------------------------------------------------------------------------
# Configure CE1.
[*HUAWEI] commit
[*CE1] bgp 65410
[*CE1-bgp] network 10.11.1.1 32
[*CE1-bgp] quit
[*CE1] commit
NOTE

NOTE
may fail.
# Configure PE1.
[~PE1] bgp 100
[~PE1-bgp] quit
NOTE

(2020-10-09)


10.1.1.1 4 65410 91 90 0 01:15:39 Established 1

instance vpn-instance-name command on each PE to check information about
the loopback interface route toward a CE.
------------------------------------------------------------------------------
Routing Table: vpna
10.22.2.2/32 IBGP 255 0 RD 3.3.3.9 SR-TE Policy Group

------------------------------------------------------------------------------
Summary Count : 1
RelayNextHop: 0.0.0.0 Interface: SR-TE Policy Group
10.22.2.2.
[~CE1] ping -a 10.11.1.1 10.22.2.2

(2020-10-09)

0.00% packet loss
----End
Configuration Files
#
sysname PE1
#
ipv4-family
tnl-policy p1
#
bfd
#
sbfd
#
mpls lsr-id 1.1.1.9
#
mpls
#
segment-routing
segment-list pe1
sr-te-policy group 1
endpoint 3.3.3.9
color 100 match dscp ipv4 20
diffserv-mode pipe af1 green
binding-sid 115
mtu 1000
segment-list pe1
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0001.00
#
undo shutdown
ip address 10.13.1.1 255.255.255.0

(2020-10-09)
isis enable 1
#
undo shutdown
ip address 10.1.1.2 255.255.255.0
#
undo shutdown
ip address 10.11.1.1 255.255.255.0
isis enable 1
#
interface LoopBack1
ip address 1.1.1.9 255.255.255.255
isis enable 1
#
bgp 100
#
ipv4-family unicast
peer 3.3.3.9 enable
#
ipv4-family vpnv4
policy vpn-target
peer 3.3.3.9 enable
#
#
tunnel-policy p1
tunnel binding destination 3.3.3.9 sr-te-policy group 1
#
return
#
sysname P1
#
mpls lsr-id 2.2.2.9
#
mpls
#
segment-routing
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0002.00
#
undo shutdown
ip address 10.11.1.2 255.255.255.0
isis enable 1
#
undo shutdown
ip address 10.12.1.1 255.255.255.0
isis enable 1
#
interface LoopBack1
ip address 2.2.2.9 255.255.255.255
isis enable 1
#
return

(2020-10-09)

#
sysname PE2
#
ipv4-family
tnl-policy p1
#
bfd
#
sbfd
#
mpls lsr-id 3.3.3.9
#
mpls
#
segment-routing
segment-list pe2
sr-te-policy group 1
endpoint 1.1.1.9
color 200 match dscp ipv4 20
diffserv-mode pipe af1 green
binding-sid 115
mtu 1000
segment-list pe2
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0003.00
#
undo shutdown
ip address 10.14.1.2 255.255.255.0
isis enable 1
#
undo shutdown
ip address 10.2.1.2 255.255.255.0
#
undo shutdown
ip address 10.12.1.2 255.255.255.0
isis enable 1
#
interface LoopBack1
ip address 3.3.3.9 255.255.255.255
isis enable 1
#
bgp 100

(2020-10-09)

#
ipv4-family unicast
peer 1.1.1.9 enable
#
ipv4-family vpnv4
policy vpn-target
peer 1.1.1.9 enable
#
#
tunnel-policy p1
tunnel binding destination 1.1.1.9 sr-te-policy group 1
#
return
#
sysname P2
#
mpls lsr-id 4.4.4.9
#
mpls
#
segment-routing
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0004.00
#
undo shutdown
ip address 10.13.1.2 255.255.255.0
isis enable 1
#
undo shutdown
ip address 10.14.1.1 255.255.255.0
isis enable 1
#
interface LoopBack1
ip address 4.4.4.9 255.255.255.255
isis enable 1
#
return
#
sysname CE1
#
undo shutdown
ip address 10.1.1.1 255.255.255.0
#
interface LoopBack1
ip address 10.11.1.1 255.255.255.255
#
bgp 65410
#
ipv4-family unicast
network 10.11.1.1 255.255.255.255

(2020-10-09)
#
return

#
sysname CE2
#
undo shutdown
ip address 10.2.1.1 255.255.255.0
#
interface LoopBack1
ip address 10.22.2.2 255.255.255.255
#
bgp 65420
#
ipv4-family unicast
network 10.22.2.2 255.255.255.255
#
return
1.2.41.3 Example for Configuring L3VPN Routes to Be Recursed to

Dynamically Delivered SR-MPLS TE Policies (Color-Based)
dynamically delivered SR-MPLS TE Policies based on the Color Extended
Community to ensure secure communication between users of the same VPN.
Manual SR-MPLS TE Policy configuration is complex and cannot adapt to dynamic
network changes. In this example, a controller is deployed. Therefore, the
controller is used to dynamically deliver SR-MPLS TE Policies. Because the
controller is capable of detecting adjacency SID changes through BGP-LS, it is
recommended that an IGP be used to dynamically generate adjacency SIDs.
Figure 1-139 L3VPN route recursion to dynamically delivered SR-MPLS TE Policies

NOTE
Interfaces 1 through 4 in this example represent GE 1/0/0, GE 2/0/0, GE 3/0/0, and GE 4/0/0,
respectively.

(2020-10-09)
Precautions
2. Enable MPLS and SR for each device on the backbone network. In addition,
configure IS-IS SR and use IS-IS to dynamically generate adjacency SIDs and
advertise the SIDs to neighbors.
3. Establish a BGP IPv4 SR-MPLS TE Policy address family-specific peer
relationship between each PE and the controller, and configure the PEs to
report network topology and label information to the controller through BGP-
LS. After completing path computation, the controller delivers SR-MPLS TE
Policy routes to the PEs through BGP.

(2020-10-09)
instance.
Data Preparation
● SRGB ranges on PEs and Ps
Procedure
# Configure PE1.
[*HUAWEI] commit
[*PE1] commit
# Configure P1.
[*HUAWEI] commit
[*P1] commit
# Configure PE2.
[*HUAWEI] commit

(2020-10-09)

[*PE2] commit
# Configure P2.
[*HUAWEI] commit
[*P2] commit
# Configure a controller.
[~HUAWEI] sysname Controller
[*HUAWEI] commit
[~Controller] interface gigabitethernet1/0/0
[~Controller-GigabitEthernet1/0/0] ip address 10.3.1.2 24
[*Controller-GigabitEthernet1/0/0] quit
[*Controller] interface gigabitethernet2/0/0
[*Controller-GigabitEthernet2/0/0] ip address 10.4.1.2 24
[*Controller-GigabitEthernet2/0/0] quit
[*Controller] commit
# Configure PE1.
[~PE1] isis 1
[*PE1-isis-1] quit
[*PE1] commit
# Configure P1.
[~P1] isis 1
[*P1-isis-1] quit

(2020-10-09)
[*P1] commit
# Configure PE2.
[~PE2] isis 1
[*PE2-isis-1] quit
[*PE2] commit
# Configure P2.
[~P2] isis 1
[*P2-isis-1] quit
[*P2] commit
# Configure PE1.
[*PE1] mpls
[*PE1-mpls] commit
[~PE1-mpls] quit
# Configure P1.
[*P1] mpls
[*P1-mpls] commit
[~P1-mpls] quit
# Configure PE2.
[*PE2] mpls
[*PE2-mpls] commit
[~PE2-mpls] quit
# Configure P2.
[*P2] mpls
[*P2-mpls] commit
[~P2-mpls] quit

(2020-10-09)

# Configure PE1.
[*PE1] isis 1
NOTE
reference only.
[*PE1-isis-1] quit
[*PE1] commit
# Configure P1.
[*P1] isis 1
NOTE
reference only.
[*P1-isis-1] quit
[*P1] commit
# Configure PE2.
[*PE2] isis 1
[PE2-isis-1] traffic-eng level-1
NOTE
reference only.
[*PE2-isis-1] quit
[*PE2] commit
# Configure P2.
[*P2] isis 1

(2020-10-09)

NOTE
reference only.
[*P2-isis-1] quit
[*P2] commit
Step 5 Configure BGP LS address family-specific and BGP IPv4 SR-MPLS TE Policy address
family-specific peer relationships.
To allow a PE to report topology information to a controller through BGP LS, you
must enable IS-IS-based topology advertisement on the PE. Generally, in an IGP
domain, only one device requires this function to be enabled. In this example, this
function is enabled on both PE1 and PE2 to improve reliability.
# Enable IS-IS SR-MPLS TE on PE1.
[~PE1] isis 1
[~PE1-isis-1] bgp-ls enable level-1
[~PE1-isis-1] quit
# Enable IS-IS SR-MPLS TE on PE2.

[~PE2] isis 1
[~PE2-isis-1] bgp-ls enable level-1
[~PE2-isis-1] quit
# Configure BGP LS address family-specific and BGP IPv4 SR-MPLS TE Policy

address family-specific peer relationships on PE1.
[~PE1] bgp 100
[*PE1-bgp] link-state-family unicast
[*PE1-bgp-af-ls] peer 10.3.1.2 enable
[*PE1-bgp-af-ls] quit
[*PE1-bgp] ipv4-family sr-policy
[*PE1-bgp-af-ipv4-srpolicy] peer 10.3.1.2 enable
[*PE1-bgp-af-ipv4-srpolicy] commit
[~PE1-bgp-af-ipv4-srpolicy] quit
[~PE1-bgp] quit

address family-specific peer relationships on PE2.
[~PE2] bgp 100
[*PE2-bgp] link-state-family unicast
[*PE2-bgp-af-ls] peer 10.4.1.2 enable
[*PE2-bgp-af-ls] quit
[*PE2-bgp] ipv4-family sr-policy
[*PE2-bgp-af-ipv4-srpolicy] peer 10.4.1.2 enable
[*PE2-bgp-af-ipv4-srpolicy] commit
[~PE2-bgp-af-ipv4-srpolicy] quit
[~PE2-bgp] quit

address family-specific peer relationships on the controller.

(2020-10-09)
[~Controller] bgp 100

[*Controller-bgp] link-state-family unicast
[*Controller-bgp-af-ls] quit
[*Controller-bgp] ipv4-family sr-policy
[*Controller-bgp-af-ipv4-srpolicy] peer 10.3.1.1 enable
[*Controller-bgp-af-ipv4-srpolicy] peer 10.4.1.1 enable
[*Controller-bgp-af-ipv4-srpolicy] commit
[~Controller-bgp-af-ipv4-srpolicy] quit
[~Controller-bgp] quit
After the configuration is complete, the PEs can receive the SR-MPLS TE Policy
routes delivered by the controller and then generate SR-MPLS TE Policies. You can
run the display sr-te policy command to check SR-MPLS TE Policy information.
DiffServ-Mode :-

Protocol-Origin : BGP(20) Originator : 0, 0.0.0.0
Template ID :-
Segment-List : pe1
EXP :- TTL :-
Label : 330000, 330002

Protocol-Origin : BGP(20) Originator : 0, 0.0.0.0
Template ID :-
EXP :- TTL :-
Label : 330001, 330003

# Configure PE1.
[~PE1] bfd
[*PE1-bfd] quit
[*PE1] sbfd
[*PE1-sbfd] quit

(2020-10-09)

# Configure PE2.
[~PE2] bfd
[*PE2-bfd] quit
[*PE2] sbfd
[*PE2-sbfd] quit

# Configure PE1.
[*PE1] commit
# Configure PE2.
[*PE2] commit
# Configure PE1.
[~PE1] bgp 100
[~PE1-bgp] quit
# Configure PE2.
[~PE2] bgp 100
[~PE2-bgp] quit

(2020-10-09)

3.3.3.9 4 100 2 6 0 00:00:12 Established 0
3.3.3.9 4 100 12 18 0 00:09:38 Established 0
# Configure PE1.
[*PE1] commit
# Configure PE2.
[*PE2] commit
# Configure PE1.
[*PE1] commit
# Configure PE2.
[*PE2] commit

(2020-10-09)
# Configure CE1.
[*HUAWEI] commit
[*CE1] bgp 65410
[*CE1-bgp] network 10.11.1.1 32
[*CE1-bgp] quit
[*CE1] commit
NOTE

NOTE
may fail.
# Configure PE1.
[~PE1] bgp 100
[~PE1-bgp] quit
NOTE


10.1.1.1 4 65410 91 90 0 01:15:39 Established 1

(2020-10-09)

route toward a CE.

------------------------------------------------------------------------------
Routing Table: vpna
10.22.2.2/32 IBGP 255 0 RD 3.3.3.9 policy100


------------------------------------------------------------------------------
Summary Count : 1
10.22.2.2.
[~CE1] ping -a 10.11.1.1 10.22.2.2
0.00% packet loss
----End

(2020-10-09)
Configuration Files
#
sysname PE1
#
ipv4-family
tnl-policy p1
#
bfd
#
sbfd
#
mpls lsr-id 1.1.1.9
#
mpls
#
segment-routing
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0001.00
traffic-eng level-1
#
undo shutdown
ip address 10.13.1.1 255.255.255.0
isis enable 1
#
undo shutdown
ip address 10.1.1.2 255.255.255.0
#
undo shutdown
ip address 10.11.1.1 255.255.255.0
isis enable 1
#
undo shutdown
ip address 10.3.1.1 255.255.255.0
isis enable 1
#
interface LoopBack1
ip address 1.1.1.9 255.255.255.255
isis enable 1
#
bgp 100
#
ipv4-family unicast
peer 3.3.3.9 enable

(2020-10-09)
#
#
ipv4-family vpnv4
policy vpn-target
peer 3.3.3.9 enable
#
#
ipv4-family sr-policy
#
#
tunnel-policy p1
#
return
#
sysname P1
#
mpls lsr-id 2.2.2.9
#
mpls
#
segment-routing
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0002.00
traffic-eng level-1
#
undo shutdown
ip address 10.11.1.2 255.255.255.0
isis enable 1
#
undo shutdown
ip address 10.12.1.1 255.255.255.0
isis enable 1
#
interface LoopBack1
ip address 2.2.2.9 255.255.255.255
isis enable 1
#
return
#
sysname PE2
#
ipv4-family
tnl-policy p1
#
bfd

(2020-10-09)
#
sbfd
#
mpls lsr-id 3.3.3.9
#
mpls
#
segment-routing
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0003.00
traffic-eng level-1
#
undo shutdown
ip address 10.14.1.2 255.255.255.0
isis enable 1
#
undo shutdown
ip address 10.2.1.2 255.255.255.0
#
undo shutdown
ip address 10.12.1.2 255.255.255.0
isis enable 1
#
undo shutdown
ip address 10.4.1.1 255.255.255.0
isis enable 1
#
interface LoopBack1
ip address 3.3.3.9 255.255.255.255
isis enable 1
#
bgp 100
#
ipv4-family unicast
peer 1.1.1.9 enable
#
#
ipv4-family vpnv4
policy vpn-target
peer 1.1.1.9 enable
#
#

(2020-10-09)
#
#
tunnel-policy p1
#
return
#
sysname P2
#
mpls lsr-id 4.4.4.9
#
mpls
#
segment-routing
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0004.00
traffic-eng level-1
#
undo shutdown
ip address 10.13.1.2 255.255.255.0
isis enable 1
#
undo shutdown
ip address 10.14.1.1 255.255.255.0
isis enable 1
#
interface LoopBack1
ip address 4.4.4.9 255.255.255.255
isis enable 1
#
return
#
sysname Controller
#
undo shutdown
ip address 10.3.1.2 255.255.255.0
isis enable 1
#
undo shutdown
ip address 10.4.1.2 255.255.255.0
isis enable 1
#
bgp 100
#
ipv4-family unicast
#

(2020-10-09)
#
#
return
#
sysname CE1
#
undo shutdown
ip address 10.1.1.1 255.255.255.0
#
interface LoopBack1
ip address 10.11.1.1 255.255.255.255
#
bgp 65410
#
ipv4-family unicast
network 10.11.1.1 255.255.255.255
#
return
#
sysname CE2
#
undo shutdown
ip address 10.2.1.1 255.255.255.0
#
interface LoopBack1
ip address 10.22.2.2 255.255.255.255
#
bgp 65420
#
ipv4-family unicast
network 10.22.2.2 255.255.255.255
#
return
1.2.41.4 Example for Configuring L3VPNv6 Routes to Be Recursed to

Manually Configured SR-MPLS TE Policies
This section provides an example for configuring L3VPNv6 routes to be recursed to
manually configured SR Policies to ensure secure communication between users of
the same VPN.
To ensure secure communication between CE1 and CE2, configure L3VPNv6 routes
to be recursed to SR-MPLS TE Policies. Because multiple links exist between PEs on
the public network, other links must be able to provide protection for the primary
link.

(2020-10-09)
Figure 1-140 L3VPNv6 route recursion to manually configured SR-MPLS TE

Policies
NOTE
Precautions
configurations, such as the IPv6 address and routing protocol configuration, on the
instance.

(2020-10-09)

Data Preparation
Procedure
# Configure PE1.
[*HUAWEI] commit
[*PE1] commit
# Configure P1.
[*HUAWEI] commit
[*P1] commit
# Configure PE2.
[*HUAWEI] commit
[*PE2] commit
# Configure P2.

(2020-10-09)
[*HUAWEI] commit
[*P2] commit
interworking between PEs and Ps. The following example uses IS-IS.
# Configure PE1.
[~PE1] isis 1
[*PE1-isis-1] quit
[*PE1] commit
# Configure P1.
[~P1] isis 1
[*P1-isis-1] quit
[*P1] commit
# Configure PE2.
[~PE2] isis 1
[*PE2-isis-1] quit
[*PE2] commit
# Configure P2.
[~P2] isis 1

(2020-10-09)

[*P2-isis-1] quit
[*P2] commit
# Configure PE1.
[*PE1] mpls
[*PE1-mpls] commit
[~PE1-mpls] quit
# Configure P1.
[*P1] mpls
[*P1-mpls] commit
[~P1-mpls] quit
# Configure PE2.
[*PE2] mpls
[*PE2-mpls] commit
[~PE2-mpls] quit
# Configure P2.
[*P2] mpls
[*P2-mpls] commit
[~P2-mpls] quit
# Configure PE1.
[*PE1] isis 1
[*PE1-isis-1] quit
[*PE1] commit
# Configure P1.
[*P1] isis 1
[*P1-isis-1] quit
[*P1] commit

(2020-10-09)
# Configure PE2.
[*PE2] isis 1
[*PE2-isis-1] quit
[*PE2] commit
# Configure P2.
[*P2] isis 1
[*P2-isis-1] quit
[*P2] commit
Step 5 Configure SR-MPLS TE Policies.

# Configure PE1.
[*PE1] commit
# Configure PE2.

(2020-10-09)
[*PE2] commit
output on PE1.
DiffServ-Mode :-

Template ID :-
Segment-List : pe1
EXP :- TTL :-
Label : 330000, 330002

Template ID :-
EXP :- TTL :-
Label : 330001, 330003

# Configure PE1.
[~PE1] bfd
[*PE1-bfd] quit
[*PE1] sbfd
[*PE1-sbfd] quit
# Configure PE2.
[~PE2] bfd
[*PE2-bfd] quit
[*PE2] sbfd
[*PE2-sbfd] quit

(2020-10-09)
# Configure PE1.
[*PE1] commit
# Configure PE2.
[*PE2] commit
# Configure PE1.
[~PE1] bgp 100
[~PE1-bgp] quit
# Configure PE2.
[~PE2] bgp 100
[~PE2-bgp] quit
3.3.3.9 4 100 2 6 0 00:00:12 Established 0
3.3.3.9 4 100 12 18 0 00:09:38 Established 0

(2020-10-09)
# Configure PE1.
[*PE1-GigabitEthernet2/0/0] ipv6 address 2001:db8::1:2 96
[*PE1] commit
# Configure PE2.
[*PE2-GigabitEthernet2/0/0] ipv6 address 2001:db8::2:2 96
[*PE2] commit
Step 10 Configure a tunnel policy on each PE to preferentially select an SR-MPLS TE Policy.

# Configure PE1.
[*PE1] commit
# Configure PE2.
[*PE2] commit

# Configure CE1.
[*HUAWEI] commit
[*CE1-LoopBack1] ipv6 address 2001:db8::11:1 128

(2020-10-09)
[*CE1-GigabitEthernet1/0/0] ipv6 address 2001:db8::1:1 96
[*CE1] bgp 65410
[*CE1-bgp] peer 2001:db8::1:2 as-number 100
[*CE1-bgp] ipv6-family
[*CE1-bgp-af-ipv6] network 2001:db8::11:1 128
[*CE1-bgp-af-ipv6] peer 2001:db8::1:2 enable
[*CE1-bgp] quit
[*CE1] commit
NOTE
After completing the configuration, run the display ip vpn-instance verbose

command on each PE to check VPN instance configurations. The command output
shows that each PE can ping its connected CE.
NOTE
If a PE has multiple interfaces bound to the same VPN instance, use the -a source-ipv6-
address parameter to specify a source IP address when running the ping ipv6 vpn-instance
vpn-instance-name -a source-ipv6-address dest-ipv6-address command to ping the CE that
is connected to the remote PE. If the source IP address is not specified, the ping operation
may fail.
# Configure PE1.
[~PE1] bgp 100
[*PE1-bgp-6-vpna] peer 2001:db8::1:1 as-number 65410
[*PE1-bgp-6-vpna] commit
[~PE1-bgp-6-vpna] quit
[~PE1-bgp] quit
NOTE
After completing the configuration, run the display bgp vpnv6 vpn-instance peer
command on each PE. The following example uses the peer relationship between
PE1 and CE1. The command output shows that a BGP peer relationship has been
established between the PE and CE and is in the Established state.

2001:DB8::1:1 4 65410 7 8 0 00:02:38 Established 1
After completing the configuration, run the display ipv6 routing-table vpn-
route toward a CE.

(2020-10-09)

[~PE1] display ipv6 routing-table vpn-instance vpna
Destination : 2001:DB8:: PrefixLength : 96

NextHop : 2001:DB8::1:2 Preference : 0
Destination : 2001:DB8::1:2 PrefixLength : 128


RelayNextHop : ::FFFF:10.13.1.2 TunnelID : 0x000000002900000006
Interface : policy100 Flags : RD


Run the display ipv6 routing-table vpn-instance vpna verbose command on

each PE to check details about the loopback interface route toward a CE.
[~PE1] display ipv6 routing-table vpn-instance vpna 2001:db8::22:2 verbose
------------------------------------------------------------------------------
Summary Count : 1

Neighbour : ::3.3.3.9 ProcessID : 0
Label : 48180 Protocol : IBGP
State : Active Adv Relied Cost :0
Entry ID :0 EntryFlags : 0x00000000
Reference Cnt: 0 Tag :0
Priority : low Age : 722sec
IndirectID : 0x10000B8 Instance :
The preceding command output shows that the corresponding VPN route has
successfully recursed to an SR-MPLS TE tunnel.
2001:db8::22:2.
[~CE1] ping ipv6 -a 2001:db8::11:1 2001:db8::22:2
PING 2001:DB8::22:2 : 56 data bytes, press CTRL_C to break

(2020-10-09)
Reply from 2001:DB8::22:2

bytes=56 Sequence=1 hop limit=62 time = 170 ms
--- 2001:DB8::22:2 ping statistics ---

0.00% packet loss
----End
Configuration Files
#
sysname PE1
#
ipv6-family
tnl-policy p1
#
bfd
#
sbfd
#
mpls lsr-id 1.1.1.9
#
mpls
#
segment-routing
segment-list pe1
binding-sid 115
mtu 1000
segment-list pe1
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0001.00
#
undo shutdown

(2020-10-09)
ip address 10.13.1.1 255.255.255.0

isis enable 1
#
undo shutdown
ipv6 enable
ipv6 address 2001:DB8::1:2/96
#
undo shutdown
ip address 10.11.1.1 255.255.255.0
isis enable 1
#
interface LoopBack1
ip address 1.1.1.9 255.255.255.255
isis enable 1
#
bgp 100
#
ipv4-family unicast
peer 3.3.3.9 enable
#
ipv6-family vpnv6
policy vpn-target
peer 3.3.3.9 enable
#
peer 2001:DB8::1:1 as-number 65410
#
#
tunnel-policy p1
#
return
#
sysname P1
#
mpls lsr-id 2.2.2.9
#
mpls
#
segment-routing
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0002.00
#
undo shutdown
ip address 10.11.1.2 255.255.255.0
isis enable 1
#
undo shutdown
ip address 10.12.1.1 255.255.255.0
isis enable 1
#

(2020-10-09)
interface LoopBack1
ip address 2.2.2.9 255.255.255.255
isis enable 1
#
return
#
sysname PE2
#
ipv6-family
tnl-policy p1
#
bfd
#
sbfd
#
mpls lsr-id 3.3.3.9
#
mpls
#
segment-routing
segment-list pe2
binding-sid 115
mtu 1000
segment-list pe2
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0003.00
#
undo shutdown
ip address 10.14.1.2 255.255.255.0
isis enable 1
#
undo shutdown
ipv6 enable
#
undo shutdown
ip address 10.12.1.2 255.255.255.0
isis enable 1
#
interface LoopBack1
ip address 3.3.3.9 255.255.255.255
isis enable 1

(2020-10-09)
#
bgp 100
#
ipv4-family unicast
peer 1.1.1.9 enable
#
ipv6-family vpnv6
policy vpn-target
peer 1.1.1.9 enable
#
#
#
tunnel-policy p1
#
return
#
sysname P2
#
mpls lsr-id 4.4.4.9
#
mpls
#
segment-routing
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0004.00
#
undo shutdown
ip address 10.13.1.2 255.255.255.0
isis enable 1
#
undo shutdown
ip address 10.14.1.1 255.255.255.0
isis enable 1
#
interface LoopBack1
ip address 4.4.4.9 255.255.255.255
isis enable 1
#
return
#
sysname CE1
#
undo shutdown
ipv6 enable
#
interface LoopBack1
ipv6 enable

(2020-10-09)
ipv6 address 2001:DB8::11:1/128

#
bgp 65410
router-id 10.10.10.10
#
ipv6-family unicast
network 2001:DB8::11:1 128
peer 2001:DB8::1:2 enable
#
return

#
sysname CE2
#
undo shutdown
ipv6 enable
#
interface LoopBack1
ipv6 enable
ipv6 address 2001:DB8::22:2/128
#
bgp 65420
router-id 10.20.20.20
#
ipv6-family unicast
network 2001:DB8::22:2 128
#
return
1.2.41.5 Example for Configuring Non-labeled Public BGP Routes to Be

Recursed to Manually Configured SR-MPLS TE Policies
This section provides an example for configuring non-labeled public BGP routes to
be recursed to manually configured SR-MPLS TE Policies to forward public BGP
traffic through the SR-MPLS TE Policies.
If an Internet user uses a carrier network that performs IP forwarding to access
the Internet, core carrier devices on the forwarding path need to learn many
Internet routes. This imposes heavy loads on core carrier devices and affects the
performance of these devices. To solve this problem, configure the corresponding
access device to recurse non-labeled public routes to SR-MPLS TE Policies, so that
packets can be forwarded over the SR-MPLS TE Policies.
Figure 1-141 shows an example for configuring non-labeled public BGP routes to
be recursed to manually configured SR-MPLS TE Policies.
Figure 1-141 Recursion of non-labeled public BGP routes to manually configured

SR-MPLS TE Policies
NOTE

(2020-10-09)
Precautions
When creating a peer, if the IP address of the peer is a loopback interface address
or a sub-interface address, you need to run the peer connect-interface command
on both ends of the peer relationship to ensure that the two ends are correctly
connected.

8. Enable the function to recurse non-labeled public BGP routes to SR-MPLS TE
Policies on each PE.
Data Preparation


(2020-10-09)
Procedure
# Configure PE1.
[*HUAWEI] commit
[*PE1] commit
# Configure P1.
[*HUAWEI] commit
[*P1] commit
# Configure PE2.
[*HUAWEI] commit
[*PE2] commit
# Configure P2.
[*HUAWEI] commit
[*P2] commit

(2020-10-09)
# Configure PE1.
[~PE1] isis 1
[*PE1-isis-1] quit
[*PE1] commit
# Configure P1.
[~P1] isis 1
[*P1-isis-1] quit
[*P1] commit
# Configure PE2.
[~PE2] isis 1
[*PE2-isis-1] quit
[*PE2] commit
# Configure P2.
[~P2] isis 1
[*P2-isis-1] quit
[*P2] commit

(2020-10-09)
# Configure PE1.
[*PE1] mpls
[*PE1-mpls] commit
[~PE1-mpls] quit
# Configure P1.
[*P1] mpls
[*P1-mpls] commit
[~P1-mpls] quit
# Configure PE2.
[*PE2] mpls
[*PE2-mpls] commit
[~PE2-mpls] quit
# Configure P2.
[*P2] mpls
[*P2-mpls] commit
[~P2-mpls] quit

# Configure PE1.
[*PE1] isis 1
[*PE1-isis-1] quit
[*PE1] commit
# Configure P1.
[*P1] isis 1
[*P1-isis-1] quit
[*P1] commit
# Configure PE2.
[*PE2] isis 1
[*PE2-isis-1] quit
[*PE2] commit
# Configure P2.

(2020-10-09)

[*P2] isis 1
[*P2-isis-1] quit
[*P2] commit

# Configure PE1.
[*PE1] commit
# Configure PE2.
[*PE2] commit
output on PE1.

(2020-10-09)

DiffServ-Mode :-

Template ID :-
Segment-List : pe1
EXP :- TTL :-
Label : 330000, 330002

Template ID :-
EXP :- TTL :-
Label : 330001, 330003

# Configure PE1.
[~PE1] bfd
[*PE1-bfd] quit
[*PE1] sbfd
[*PE1-sbfd] quit
# Configure PE2.
[~PE2] bfd
[*PE2-bfd] quit
[*PE2] sbfd
[*PE2-sbfd] quit

# Configure PE1.
[*PE1] commit
# Configure PE2.

(2020-10-09)

[*PE2] commit
# Configure PE1.
[~PE1] bgp 100
[*PE1-bgp] peer 3.3.3.9 route-policy color100 import
[*PE1-bgp] commit
[~PE1-bgp] quit
# Configure PE2.
[~PE2] bgp 100
[*PE2-bgp] peer 1.1.1.9 route-policy color200 import
[*PE2-bgp] commit
[~PE2-bgp] quit
output on PE1.
3.3.3.9 4 100 2 6 0 00:00:12 Established 0
# Configure PE1.
[*PE1] route recursive-lookup tunnel tunnel-policy p1
[*PE1] commit
# Configure PE2.
[*PE2] route recursive-lookup tunnel tunnel-policy p1
[*PE2] commit
Step 10 Configure each PE to import a local route.

In this example, loopback addresses 8.8.8.8/32 and 9.9.9.9/32 are used to simulate
the local network on PE1 and PE2, respectively.
# Configure PE1.

(2020-10-09)
[*PE1] bgp 100
[*PE1-bgp] network 8.8.8.8 32
[*PE1-bgp] quit
[*PE1] commit
# Configure PE2.
[*PE2] bgp 100
[*PE2-bgp] quit
[*PE2] commit

After completing the configuration, run the display ip routing-table verbose
command on each PE to check detailed routing information. The following
example uses the command output on PE1. The command output shows that the
route advertised by the peer PE has been successfully recursed to the specified SR-
MPLS TE Policy.
[~PE1] display ip routing-table 9.9.9.9 32 verbose
------------------------------------------------------------------------------
Summary Count : 1
Label: NULL QoSInfo: 0x0
IndirectID: 0x10000C7 Instance:
----End
Configuration Files
#
sysname PE1
#
bfd
#
sbfd
#
mpls lsr-id 1.1.1.9
#
mpls
#
segment-routing
segment-list pe1

(2020-10-09)

binding-sid 115
mtu 1000
segment-list pe1
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0001.00
#
undo shutdown
ip address 10.13.1.1 255.255.255.0
isis enable 1
#
undo shutdown
ip address 10.11.1.1 255.255.255.0
isis enable 1
#
interface LoopBack1
ip address 1.1.1.9 255.255.255.255
isis enable 1
#
interface LoopBack2
ip address 8.8.8.8 255.255.255.255
#
bgp 100
#
ipv4-family unicast
network 8.8.8.8 255.255.255.255
peer 3.3.3.9 enable
#
#
route recursive-lookup tunnel tunnel-policy p1
#
tunnel-policy p1
#
return
#
sysname P1
#
mpls lsr-id 2.2.2.9
#
mpls
#
segment-routing
#
isis 1
is-level level-1
cost-style wide

(2020-10-09)
network-entity 10.0000.0000.0002.00
#
undo shutdown
ip address 10.11.1.2 255.255.255.0
isis enable 1
#
undo shutdown
ip address 10.12.1.1 255.255.255.0
isis enable 1
#
interface LoopBack1
ip address 2.2.2.9 255.255.255.255
isis enable 1
#
return
#
sysname PE2
#
bfd
#
sbfd
#
mpls lsr-id 3.3.3.9
#
mpls
#
segment-routing
segment-list pe2
binding-sid 115
mtu 1000
segment-list pe2
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0003.00
#
undo shutdown
ip address 10.14.1.2 255.255.255.0
isis enable 1
#
undo shutdown
ip address 10.12.1.2 255.255.255.0
isis enable 1
#
interface LoopBack1
ip address 3.3.3.9 255.255.255.255
isis enable 1

(2020-10-09)
#
interface LoopBack2
ip address 9.9.9.9 255.255.255.255
#
bgp 100
#
ipv4-family unicast
network 9.9.9.9 255.255.255.255
peer 1.1.1.9 enable
#
#
route recursive-lookup tunnel tunnel-policy p1
#
tunnel-policy p1
#
return
#
sysname P2
#
mpls lsr-id 4.4.4.9
#
mpls
#
segment-routing
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0004.00
#
undo shutdown
ip address 10.13.1.2 255.255.255.0
isis enable 1
#
undo shutdown
ip address 10.14.1.1 255.255.255.0
isis enable 1
#
interface LoopBack1
ip address 4.4.4.9 255.255.255.255
isis enable 1
#
return
1.2.41.6 Example for Configuring BGP4+ 6PE Routes to Be Recursed to

Manually Configured SR-MPLS TE Policies
This section provides an example for configuring BGP4+ 6PE routes to be recursed
to manually configured SR-MPLS TE Policies to connect discontinuous IPv6
networks through an SR network.

(2020-10-09)
If an SR network is deployed between two discontinuous IPv6 networks, you can
recurse BGP4+ 6PE routes to SR-MPLS TE Policies for the IPv6 networks to
communicate with each other.
On the network shown in Figure 1-142, there is no direct link between CE1 and
CE2 on the IPv6 network. CE1 and CE2 need to communicate through the SR
network. To meet this requirement, a 6PE peer relationship can be established
between PE1 and PE2. The 6PE peers exchange IPv6 routes learned from their
attached CEs using MP-BGP, and forward IPv6 data over SR-MPLS TE Policies.
Figure 1-142 BGP4+ 6PE route recursion to manually configured SR-MPLS TE

Policies
NOTE
Precautions
In the BGP4+ 6PE scenario, no VPN instance needs to be configured.

(2020-10-09)

6. Establish an MP-IBGP peer relationship between PEs and enable them to
advertise labeled routes.
Data Preparation
Procedure
# Configure PE1.
[*HUAWEI] commit
[*PE1] commit
# Configure P1.
[*HUAWEI] commit
[*P1] commit
# Configure PE2.
[*HUAWEI] commit

(2020-10-09)

[*PE2] commit
# Configure P2.
[*HUAWEI] commit
[*P2] commit
# Configure PE1.
[~PE1] isis 1
[*PE1-isis-1] quit
[*PE1] commit
# Configure P1.
[~P1] isis 1
[*P1-isis-1] quit
[*P1] commit
# Configure PE2.
[~PE2] isis 1
[*PE2-isis-1] quit

(2020-10-09)

[*PE2] commit
# Configure P2.
[~P2] isis 1
[*P2-isis-1] quit
[*P2] commit
# Configure PE1.
[*PE1] mpls
[*PE1-mpls] commit
[~PE1-mpls] quit
# Configure P1.
[*P1] mpls
[*P1-mpls] commit
[~P1-mpls] quit
# Configure PE2.
[*PE2] mpls
[*PE2-mpls] commit
[~PE2-mpls] quit
# Configure P2.
[*P2] mpls
[*P2-mpls] commit
[~P2-mpls] quit

# Configure PE1.
[*PE1] isis 1
[*PE1-isis-1] quit
[*PE1] commit
# Configure P1.

(2020-10-09)

[*P1] isis 1
[*P1-isis-1] quit
[*P1] commit
# Configure PE2.
[*PE2] isis 1
[*PE2-isis-1] quit
[*PE2] commit
# Configure P2.
[*P2] isis 1
[*P2-isis-1] quit
[*P2] commit

# Configure PE1.
[*PE1] commit
# Configure PE2.

(2020-10-09)

[*PE2] commit
output on PE1.
DiffServ-Mode :-

Template ID :-
Segment-List : pe1
EXP :- TTL :-
Label : 330000, 330002

Template ID :-
EXP :- TTL :-
Label : 330001, 330003
# Configure PE1.
[~PE1] bfd
[*PE1-bfd] quit
[*PE1] sbfd
[*PE1-sbfd] quit

(2020-10-09)
# Configure PE2.
[~PE2] bfd
[*PE2-bfd] quit
[*PE2] sbfd
[*PE2-sbfd] quit

# Configure PE1.
[*PE1] commit
# Configure PE2.
[*PE2] commit
Step 8 Establish an MP-IBGP peer relationship between PEs and enable them to advertise
labeled routes. Apply an import route-policy to a specified BGP4+ peer on each PE,
and set the Color Extended Community.
# Configure PE1.
[~PE1] bgp 100
[*PE1-bgp] ipv6-family unicast
[*PE1-bgp-af-ipv6] peer 3.3.3.9 enable
[*PE1-bgp-af-ipv6] peer 3.3.3.9 label-route-capability
[*PE1-bgp-af-ipv6] peer 3.3.3.9 route-policy color100 import
[*PE1-bgp-af-ipv6] commit
[~PE1-bgp-af-ipv6] quit
[~PE1-bgp] quit
# Configure PE2.
[~PE2] bgp 100
[*PE2-bgp-af-ipv6] peer 1.1.1.9 label-route-capability
[*PE2-bgp-af-ipv6] peer 1.1.1.9 route-policy color200 import
[~PE2-bgp] quit
After the configuration is complete, run the display bgp ipv6 peer command on
the PEs to check whether the BGP peer relationship has been established. If the
output on PE1.
[~PE1] display bgp ipv6 peer

(2020-10-09)

3.3.3.9 4 100 6 7 0 00:01:16 Established 0
# Configure PE1.
[*PE1] bgp 100
[*PE1-bgp-af-ipv6] peer 3.3.3.9 tnl-policy p1
[*PE1-bgp-af-ipv6] quit
[*PE1-bgp] quit
[*PE1] commit
# Configure PE2.
[*PE2] bgp 100
[*PE2-bgp-af-ipv6] peer 1.1.1.9 tnl-policy p1
[*PE2-bgp-af-ipv6] quit
[*PE2-bgp] quit
[*PE2] commit

# Configure CE1.
[*HUAWEI] commit
[*CE1-LoopBack1] ipv6 address 2001:db8::11:1 128
[*CE1-GigabitEthernet1/0/0] ipv6 address 2001:db8::1:1 96
[*CE1] bgp 65410
[*CE1-bgp] peer 2001:db8::1:2 as-number 100
[*CE1-bgp] ipv6-family
[*CE1-bgp-af-ipv6] peer 2001:db8::1:2 enable
[*CE1-bgp-af-ipv6] network 2001:db8::11:1 128
[*CE1-bgp] quit
[*CE1] commit
NOTE
# Configure PE1.
[~PE1] bgp 100
[~PE1-bgp] peer 2001:db8::1:1 as-number 65410
[*PE1-bgp-af-ipv6] peer 2001:db8::1:1 enable

(2020-10-09)
[~PE1-bgp] quit
NOTE
After completing the configuration, run the display bgp ipv6 peer command on
each PE. The following example uses the peer relationship between PE1 and CE1.
The command output shows that a BGP4+ peer relationship has been established
between the PE and CE and is in the Established state.

3.3.3.9 4 100 6 7 0 00:01:16 Established 0
2001:DB8::1:1 4 65410 5 4 0 00:01:16 Established 1

After completing the configuration, run the display ipv6 routing-table command
on each PE to check information about the loopback interface route toward a CE.
[~PE1] display ipv6 routing-table
Destination : ::1 PrefixLength : 128

Interface : InLoopBack0 Flags :D
Destination : ::FFFF:127.0.0.0 PrefixLength : 104

Destination : ::FFFF:127.0.0.1 PrefixLength : 128

Destination : 2001:DB8:: PrefixLength : 96



RelayNextHop : 2001:DB8::1:1 TunnelID : 0x0

(2020-10-09)

RelayNextHop : 2001:DB8::1:1 TunnelID : 0x000000003200000001

Run the display ipv6 routing-table verbose command on each PE to check

details about the loopback interface route toward a CE.
[~PE1] display ipv6 routing-table 2001:db8:22::2 verbose
------------------------------------------------------------------------------
Summary Count : 1

Neighbour : ::3.3.3.9 ProcessID : 0
Label : 48183 Protocol : IBGP
IndirectID : 0x10000C8 Instance :
RelayNextHop : 0.0.0.0 TunnelID : 0x000000003200000001
The command output shows that the BGP4+ route has been successfully recursed
to the specified SR-MPLS TE Policy.
CEs can ping each other. For example, CE1 can ping CE2 at 2001:db8::22:2.
[~CE1] ping ipv6 -a 2001:db8::11:1 2001:db8::22:2
PING 2001:DB8::22:2 : 56 data bytes, press CTRL_C to break
Reply from 2001:DBD8::22:2
Reply from 2001:B8::22:2
--- 2001:DB8::22:2 ping statistics ---

0.00% packet loss
----End
Configuration Files
#
sysname PE1
#

(2020-10-09)
bfd
#
sbfd
#
mpls lsr-id 1.1.1.9
#
mpls
#
segment-routing
segment-list pe1
binding-sid 115
mtu 1000
segment-list pe1
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0001.00
#
undo shutdown
ip address 10.13.1.1 255.255.255.0
isis enable 1
#
undo shutdown
ipv6 enable
#
undo shutdown
ip address 10.11.1.1 255.255.255.0
isis enable 1
#
interface LoopBack1
ip address 1.1.1.9 255.255.255.255
isis enable 1
#
bgp 100
#
ipv4-family unicast
peer 3.3.3.9 enable
#
ipv6-family unicast
peer 3.3.3.9 label-route-capability
peer 3.3.3.9 tnl-policy p1
#

(2020-10-09)

#
tunnel-policy p1
#
return
#
sysname P1
#
mpls lsr-id 2.2.2.9
#
mpls
#
segment-routing
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0002.00
#
undo shutdown
ip address 10.11.1.2 255.255.255.0
isis enable 1
#
undo shutdown
ip address 10.12.1.1 255.255.255.0
isis enable 1
#
interface LoopBack1
ip address 2.2.2.9 255.255.255.255
isis enable 1
#
return
#
sysname PE2
#
bfd
#
sbfd
#
mpls lsr-id 3.3.3.9
#
mpls
#
segment-routing
segment-list pe2
binding-sid 115
mtu 1000

(2020-10-09)
segment-list pe2
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0003.00
#
undo shutdown
ip address 10.14.1.2 255.255.255.0
isis enable 1
#
undo shutdown
ipv6 enable
#
undo shutdown
ip address 10.12.1.2 255.255.255.0
isis enable 1
#
interface LoopBack1
ip address 3.3.3.9 255.255.255.255
isis enable 1
#
bgp 100
#
ipv4-family unicast
peer 1.1.1.9 enable
#
ipv6-family unicast
peer 1.1.1.9 tnl-policy p1
#
#
tunnel-policy p1
#
return
#
sysname P2
#
mpls lsr-id 4.4.4.9
#
mpls
#
segment-routing
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0004.00

(2020-10-09)
#
undo shutdown
ip address 10.13.1.2 255.255.255.0
isis enable 1
#
undo shutdown
ip address 10.14.1.1 255.255.255.0
isis enable 1
#
interface LoopBack1
ip address 4.4.4.9 255.255.255.255
isis enable 1
#
return

#
sysname CE1
#
undo shutdown
ipv6 enable
#
interface LoopBack1
ipv6 enable
ipv6 address 2001:DB8::11:1/128
#
bgp 65410
router-id 10.10.10.10
#
ipv6-family unicast
network 2001:DB8::11:1 128
#
return

#
sysname CE2
#
undo shutdown
ipv6 enable
#
interface LoopBack1
ipv6 enable
ipv6 address 2001:DB8::22:2/128
#
bgp 65420
router-id 10.20.20.20
#
ipv6-family unicast
network 2001:DB8::22:2 128
#
return

(2020-10-09)
1.2.41.7 Example for Configuring EVPN Route Recursion Based on an SR-

MPLS TE Policy
This section provides an example for configuring EVPN route recursion based on
an SR-MPLS TE Policy.
On the network shown in Figure 1-143, PE1, P1, P2, and PE2 are in the same AS.
IS-IS is required to implement network connectivity. An SR-MPLS TE Policy needs
to be configured on PE1 and PE2 to carry EVPN services.
Figure 1-143 Networking of EVPN route recursion based on an SR-MPLS TE Policy

NOTE
When configuring EVPN route recursion based on an SR-MPLS TE Policy, note the
following:

1. Assign IP addresses to each device interface.

2. Configure an IGP on each device so that PEs and Ps on the backbone network
can communicate with each other. IS-IS is used as an example.

(2020-10-09)
4. Configure an SR-MPLS TE Policy on PEs, and configure path information for
the SR-MPLS TE Policy.
5. Configure SBFD and HSB on the PE to enhance the reliability of the SR-MPLS
TE Policy.
6. Establish BGP EVPN peer relationships between PEs, apply an import route-
policy, and add the extended community attribute Color to routes.
7. Configure MP-IBGP on PEs to exchange VPN routing information.
8. Configure IPv4 address family VPN instances on PEs and bind each interface
that connects a PE to a CE to a VPN instance.
9. Configure a tunnel policy on each PE.
10. Configure EBGP between CEs and PEs to exchange VPN routing information.
Data Preparation
● VPN targets and RDs of the EVPN instance named evrf1 and the L3VPN
instance named vpn1
Procedure
Step 1 Configure interface IP addresses on each device.
# Configure PE1.
[*HUAWEI] commit
[*PE1] commit
# Configure P1.
[*HUAWEI] commit
[*P1] commit
# Configure PE2.

(2020-10-09)
[*HUAWEI] commit
[*PE2] commit
# Configure P2.
[*HUAWEI] commit
[*P2] commit
Step 2 Configure an IGP on each device so that PEs and Ps on the backbone network can
communicate with each other. IS-IS is used as an example.
# Configure PE1.
[~PE1] isis 1
[*PE1-isis-1] quit
[*PE1] commit
# Configure P1.
[~P1] isis 1
[*P1-isis-1] quit
[*P1] commit
# Configure PE2.
[~PE2] isis 1

(2020-10-09)

[*PE2-isis-1] quit
[*PE2] commit
# Configure P2.
[~P2] isis 1
[*P2-isis-1] quit
[*P2] commit
Step 3 Configure basic MPLS functions on each device.

# Configure PE1.
[*PE1] mpls
[*PE1-mpls] commit
[~PE1-mpls] quit
# Configure P1.
[*P1] mpls
[*P1-mpls] commit
[~P1-mpls] quit
# Configure PE2.
[*PE2] mpls
[*PE2-mpls] commit
[~PE2-mpls] quit
# Configure P2.
[*P2] mpls
[*P2-mpls] commit
[~P2-mpls] quit
Step 4 Configure SR on each device.

# Configure PE1.
[*PE1] isis 1

(2020-10-09)

[*PE1-isis-1] quit
[*PE1] commit
# Configure P1.
[*P1] isis 1
[*P1-isis-1] quit
[*P1] commit
# Configure PE2.
[*PE2] isis 1
[*PE2-isis-1] quit
[*PE2] commit
# Configure P2.
[*P2] isis 1
[*P2-isis-1] quit
[*P2] commit

# Configure PE1.
[~PE1-segment-routing] segment-list path1
[*PE1-segment-routing-segment-list-path1] index 10 sid label 330000
[*PE1-segment-routing-segment-list-path1] quit
[*PE1-segment-routing] segment-list path2
[*PE1-segment-routing-te-policy-policy100-path] segment-list path1
[*PE1] commit

(2020-10-09)
# Configure PE2.
[~PE2-segment-routing] segment-list path1
[*PE2-segment-routing] segment-list path2
[*PE2] commit
Step 6 Configure SBFD and HSB functions

# Configure PE1.
[~PE1] bfd
[*PE1-bfd] quit
[*PE1] sbfd
[*PE1-sbfd] quit
# Configure PE2.
[~PE2] bfd
[*PE2-bfd] quit
[*PE2] sbfd
[*PE2-sbfd] quit
Step 7 Configure tunnel policies on PEs.

# Configure PE1.
[*PE1-route-policy] if-match route-type evpn mac
[*PE1] route-policy color100 permit node 2
[*PE1-route-policy] if-match route-type evpn prefix

(2020-10-09)
[*PE1] commit
# Configure PE2.
[*PE2-route-policy] if-match route-type evpn mac
[*PE2-route-policy] if-match route-type evpn prefix
[*PE2] commit
Step 8 Establish BGP EVPN peer relationships between PEs, apply an import route-policy,
and add the extended community attribute Color to routes.
# Configure PE1.
[~PE1] bgp 100
[*PE1-bgp-af-evpn] peer 3.3.3.9 route-policy color100 import
[*PE1-bgp] quit
[*PE1] commit
# Configure PE2.
[~PE2] bgp 100
[*PE2-bgp-af-evpn] peer 1.1.1.9 route-policy color100 import
[*PE2-bgp] quit
[*PE2] commit
After the configuration is complete, run the display bgp evpn peer command on
the PEs to check whether the BGP EVPN peer relationships have been established.
If the Established state is displayed in the command output, the BGP EVPN peer
relationships have been established successfully. The following example uses the

3.3.3.9 4 100 4 4 0 00:00:28 Established 0
Step 9 Configure EVPN instances and L3VPN instances on PEs and connect sites to the
PEs
# Configure PE1.

(2020-10-09)

[*PE1] evpn source-address 1.1.1.9
[*PE1-bd10] quit
[*PE1-GigabitEthernet3/0/0] esi 0011.1001.1001.1001.1001
[*PE1] interface gigabitethernet3/0/0.1 mode l2
[*PE1-GigabitEthernet3/0/0.1] encapsulation dot1q vid 10
[*PE1-GigabitEthernet3/0/0.1] rewrite pop single
[*PE1-GigabitEthernet3/0/0.1] bridge-domain 10
[*PE1] interface Vbdif10
[*PE1-Vbdif10] arp collect host enable
[*PE1-Vbdif10] quit
[*PE1] bgp 100
[*PE1-bgp] quit
[*PE1] commit
# Configure PE2.
[*PE2] evpn source-address 3.3.3.9
[*PE2-bd10] quit
[*PE2-Vbdif10] quit
[*PE2] bgp 100
[*PE2-bgp] quit
[*PE2] commit

(2020-10-09)
Step 10 Configure a tunnel policy on each PE to preferentially select an SR-MPLS TE Policy.

# Configure PE1.
[*PE1-vpn-instance-vpn1-af-ipv4] tnl-policy p1 evpn
[*PE1-evpn-instance-evrf1] tnl-policy p1
[*PE1] commit
# Configure PE2.
[*PE2-vpn-instance-vpn1-af-ipv4] tnl-policy p1 evpn
[*PE2-evpn-instance-evrf1] tnl-policy p1
[*PE2] commit

prefix-route command on PE1 to view information about the IP prefix routes sent
from PE2.
[~PE1] display bgp evpn all routing-table prefix-route


*> 0:10.1.1.0:24 0.0.0.0
*>i 0:10.2.1.0:24 3.3.3.9
Run the display bgp evpn all routing-table prefix-route 0:10.2.1.0:24 command
on PE1 to view information about the IP prefix routes sent from PE2.
[~PE1] display bgp evpn all routing-table prefix-route 0:10.2.1.0:24
BGP routing table entry information of 0:10.2.1.0:24:
From: 3.3.3.9 (3.3.3.9)
Relay IP Out-Interface:GigabitEthernet1/0/0

(2020-10-09)

Ext-Community: RT <1 : 1>, Color <0 : 200>
cost 20
Ethernet Tag ID: 0, IP Prefix/Len: 10.2.1.0/24, ESI: 0000.0000.0000.0000.0000, GW IP Address: 0.0.0.0
Run the display ip routing-table vpn-instance vpn1 command on PE1 to view

information about the VPN routes sent from PE2.
[~PE1] display ip routing-table vpn-instance vpn1
------------------------------------------------------------------------------
10.1.1.0/24 Direct 0 0 D 10.1.1.1 Vbdif10

10.1.1.1/32 Direct 0 0 D 127.0.0.1 Vbdif10
10.1.1.255/32 Direct 0 0 D 127.0.0.1 Vbdif10
10.2.1.0/24 IBGP 255 0 RD 3.3.3.9 policy100
10.2.1.1/32 IBGP 255 0 RD 3.3.3.9 policy100
Run the display bgp evpn all routing-table mac-route command on PE1 to view
information about the MAC routes sent from PE2.
[~PE1] display bgp evpn all routing-table mac-route


*>i 0:48:38ba-2e49-fa04:0:0.0.0.0 3.3.3.9
*>i 0:48:38ba-2e49-fa04:32:10.2.1.1 3.3.3.9
*> 0:48:38ba-d70d-3801:0:0.0.0.0 0.0.0.0
*> 0:48:38ba-d70d-3801:32:10.1.1.1 0.0.0.0
*>i 0:48:38ba-2e49-fa04:0:0.0.0.0 3.3.3.9
*>i 0:48:38ba-2e49-fa04:32:10.2.1.1 3.3.3.9
*> 0:48:38ba-d70d-3801:0:0.0.0.0 0.0.0.0
*> 0:48:38ba-d70d-3801:32:10.1.1.1 0.0.0.0
Run the display bgp evpn all routing-table mac-route 0:48:38ba-2e49-

fa04:0:0.0.0.0 command on PE1 to view details about the MAC routes sent from
PE2.
[~PE1] display bgp evpn all routing-table mac-route 0:48:38ba-2e49-fa04:0:0.0.0.0
BGP routing table entry information of 0:48:38ba-2e49-fa04:0:0.0.0.0:
From: 3.3.3.9 (3.3.3.9)

(2020-10-09)

Ext-Community: RT <1 : 1>, RT <2 : 2>, Color <0 : 100>, Mac Mobility <flag:1 seq:0 res:0>
Ethernet Tag ID: 0, MAC Address/Len: 38ba-2e49-fa04/48, IP Address/Len: 0.0.0.0/0, ESI:
0000.0000.0000.0000.0000
BGP routing table entry information of 0:48:38ba-2e49-fa04:0:0.0.0.0:
Remote-Cross route
From: 3.3.3.9 (3.3.3.9)
Relay Tunnel Out-Interface: policy100(srtepolicy)
Ext-Community: RT <1 : 1>, RT <2 : 2>, Color <0 : 100>, Mac Mobility <flag:1 seq:0 res:0>
AS-path Nil, origin incomplete, localpref 100, pref-val 0, valid, internal, best, select, pre 255
Ethernet Tag ID: 0, MAC Address/Len: 38ba-2e49-fa04/48, IP Address/Len: 0.0.0.0/0, ESI:
0000.0000.0000.0000.0000
----End
Configuration Files
#
sysname PE1
#
tnl-policy p1
#
ipv4-family
tnl-policy p1 evpn
#
bfd
#
sbfd
#
mpls lsr-id 1.1.1.9
#
mpls
#
bridge-domain 10
#
segment-routing

(2020-10-09)

segment-list path1
segment-list path2
binding-sid 115
mtu 1000
segment-list path1
binding-sid 215
mtu 1000
segment-list path2
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0001.00
#
interface Vbdif10
ip address 10.1.1.1 255.255.255.0
arp collect host enable
#
undo shutdown
ip address 10.11.1.1 255.255.255.0
isis enable 1
#
undo shutdown
ip address 10.13.1.1 255.255.255.0
isis enable 1
#
undo shutdown
esi 0011.1001.1001.1001.1001
#
rewrite pop single
bridge-domain 10
#
interface LoopBack1
ip address 1.1.1.9 255.255.255.255
isis enable 1
#
bgp 100
#
ipv4-family unicast
peer 3.3.3.9 enable
#
import-route direct
#
l2vpn-family evpn
peer 3.3.3.9 enable

(2020-10-09)

#
if-match route-type evpn mac
#
if-match route-type evpn prefix
#
#
tunnel-policy p1
#
#
return
#
sysname P1
#
mpls lsr-id 2.2.2.9
#
mpls
#
segment-routing
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0002.00
#
undo shutdown
ip address 10.11.1.2 255.255.255.0
isis enable 1
#
undo shutdown
ip address 10.12.1.1 255.255.255.0
isis enable 1
#
interface LoopBack1
ip address 2.2.2.9 255.255.255.255
isis enable 1
#
return
#
sysname P2
#
mpls lsr-id 4.4.4.9
#
mpls
#
segment-routing
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0004.00

(2020-10-09)
#
undo shutdown
ip address 10.13.1.2 255.255.255.0
isis enable 1
#
undo shutdown
ip address 10.14.1.1 255.255.255.0
isis enable 1
#
interface LoopBack1
ip address 4.4.4.9 255.255.255.255
isis enable 1
#
return
#
sysname PE2
#
tnl-policy p1
#
ipv4-family
tnl-policy p1 evpn
#
bfd
#
sbfd
#
mpls lsr-id 3.3.3.9
#
mpls
#
bridge-domain 10
#
segment-routing
segment-list path1
segment-list path2
binding-sid 115
mtu 1000
segment-list path1
binding-sid 215
mtu 1000
segment-list path2
#
isis 1

(2020-10-09)
is-level level-1
cost-style wide
network-entity 10.0000.0000.0003.00
#
interface Vbdif10
ip address 10.2.1.1 255.255.255.0
#
undo shutdown
ip address 10.12.1.2 255.255.255.0
isis enable 1
#
undo shutdown
ip address 10.14.1.2 255.255.255.0
isis enable 1
#
undo shutdown
esi 0011.1001.1001.1001.1002
#
rewrite pop single
bridge-domain 10
#
interface LoopBack1
ip address 3.3.3.9 255.255.255.255
isis enable 1
#
bgp 100
#
ipv4-family unicast
peer 1.1.1.9 enable
#
import-route direct
#
l2vpn-family evpn
peer 1.1.1.9 enable
#
if-match route-type evpn mac
#
if-match route-type evpn prefix
#
#
tunnel-policy p1
#
#
return

(2020-10-09)
1.2.41.8 Example for Redirecting Public IPv4 BGP FlowSpec Routes to SR-
MPLS TE Policies
This section provides an example for redirecting public IPv4 BGP FlowSpec routes
to SR-MPLS TE Policies to meet the steering requirements of different services.
redirect a public IPv4 BGP FlowSpec route to an SR-MPLS TE Policy, a device can
to different SR-MPLS TE Policies.
On the network shown in Figure 1-144, there are two SR-MPLS TE Policies in the
direction from PE1 to PE2. PE2 is connected to two local networks (10.8.8.8/32
and 10.9.9.9/32). It is required that traffic destined for different networks be
redirected to different SR-MPLS TE Policies.
Figure 1-144 Networking for redirecting public IPv4 BGP FlowSpec routes to SR-
MPLS TE Policies
NOTE
Precautions
None
1. Configure IS-IS on the backbone network for the PEs to communicate.
2. Enable MPLS on the backbone network and configure SR and static adjacency
labels.
3. Configure two SR-MPLS TE Policies from PE1 to PE2.

(2020-10-09)
4. Configure static FlowSpec routes on PE1 and redirect the routes to the SR-
MPLS TE Policies.
5. Establish a BGP FlowSpec peer relationship between the PEs.
Data Preparation
● MPLS LSR IDs on the PEs and Ps
● Adjacency labels on the PEs and Ps
Procedure
# Configure PE1.
[*HUAWEI] commit
[*PE1] commit
# Configure P1.
[*HUAWEI] commit
[*P1] commit
# Configure PE2.
[*HUAWEI] commit
[*PE2] commit
# Configure P2.

(2020-10-09)
[*HUAWEI] commit
[*P2] commit
Step 2 Configure an IGP on the backbone network for the PEs and Ps to communicate.
The following example uses IS-IS.
# Configure PE1.
[~PE1] isis 1
[*PE1-isis-1] quit
[*PE1] commit
# Configure P1.
[~P1] isis 1
[*P1-isis-1] quit
[*P1] commit
# Configure PE2.
[~PE2] isis 1
[*PE2-isis-1] quit
[*PE2] commit
# Configure P2.
[~P2] isis 1

(2020-10-09)

[*P2-isis-1] quit
[*P2] commit
Step 3 Configure basic MPLS functions on the backbone network.
# Configure PE1.
[*PE1] mpls
[*PE1-mpls] commit
[~PE1-mpls] quit
# Configure P1.
[*P1] mpls
[*P1-mpls] commit
[~P1-mpls] quit
# Configure PE2.
[*PE2] mpls
[*PE2-mpls] commit
[~PE2-mpls] quit
# Configure P2.
[*P2] mpls
[*P2-mpls] commit
[~P2-mpls] quit
Step 4 Configure SR on the backbone network.
# Configure PE1.
[*PE1] isis 1
[*PE1-isis-1] quit
[*PE1] commit
# Configure P1.
[*P1] isis 1
[*P1-isis-1] quit
[*P1] commit

(2020-10-09)
# Configure PE2.
[*PE2] isis 1
[*PE2-isis-1] quit
[*PE2] commit
# Configure P2.
[*P2] isis 1
[*P2-isis-1] quit
[*P2] commit
Step 5 Configure SR-MPLS TE Policies.
# Configure PE1.
[*PE1] commit
After the configuration is complete, you can run the display sr-te policy
command to check SR-MPLS TE Policy information.
TunnelId : 8193 TunnelType : SR-TE Policy
DiffServ-Mode :-

(2020-10-09)

Discriminator : 200 Binding SID : 115
GroupId : 8193 Policy Name : policy100
Template ID :-
Segment-List : pe1
EXP :- TTL :-
Label : 330000, 330002
TunnelId : 8194 TunnelType : SR-TE Policy
DiffServ-Mode :-

Discriminator : 200 Binding SID : 125
Template ID :-
EXP :- TTL :-
Label : 330001, 330003
Step 6 Establish a BGP peer relationship between the PEs and import local network
routes to PE2.
In this example, loopback addresses 10.8.8.8/32 and 10.9.9.9/32 are used to
simulate two local networks on PE2.
# Configure PE1.
[~PE1] bgp 100
[*PE1-bgp] commit
[~PE1-bgp] quit
# Configure PE2.
[*PE2] bgp 100
[*PE2-bgp] commit
[~PE2-bgp] quit
PEs and check whether a BGP peer relationship has been established between the

(2020-10-09)
PEs. If the Established state is displayed in the command output, the BGP peer
relationship has been established successfully. The following example uses the


3.3.3.9 4 100 201 202 0 02:51:56 Established 2
Step 7 Establish a BGP FlowSpec peer relationship between the PEs.

# Configure PE1.
[~PE1] bgp 100
[~PE1] ipv4-family flow
[*PE1-bgp-af-ipv4-flow] peer 3.3.3.9 enable
[*PE1-bgp-af-ipv4-flow] commit
[~PE1-bgp-af-ipv4-flow] quit
[~PE1-bgp] quit
# Configure PE2.
[~PE2] bgp 100
[~PE2] ipv4-family flow
[*PE2-bgp-af-ipv4-flow] peer 1.1.1.9 enable
[*PE2-bgp-af-ipv4-flow] commit
[~PE2-bgp-af-ipv4-flow] quit
[~PE2-bgp] quit
After the configuration is complete, run the display bgp flow peer command on
the PEs and check whether a BGP FlowSpec peer relationship has been established
between the PEs. If the Established state is displayed in the command output, the
BGP FlowSpec peer relationship has been established successfully. The following
[~PE1] display bgp flow peer


3.3.3.9 4 100 208 209 0 02:58:16 Established 0
Step 8 Configure static BGP FlowSpec route redirection on PE1.

BGP FlowSpec route redirection is based on <Redirection IP address, Color>. If the
redirection IP address and color attributes of a BGP FlowSpec route match the
endpoint and color attributes of an SR-MPLS TE Policy, the route can be
successfully redirected to the SR-MPLS TE Policy.
In this example, the traffic destined for 10.8.8.8/32 needs to be redirected to the
SR-MPLS TE Policy named policy100, and the traffic destined for 10.9.9.9/32 needs
to be redirected to the SR-MPLS TE Policy named policy200.
# Configure PE1.
[~PE1] flow-route PE1toPE2
[*PE1-flow-route] if-match destination 10.8.8.8 255.255.255.255
[*PE1-flow-route] apply redirect ip 3.3.3.9:0 color 0:100
[*PE1-flow-route] quit
[*PE1] flow-route PE1toPE2b

(2020-10-09)
[*PE1-flow-route] if-match destination 10.9.9.9 255.255.255.255

[*PE1-flow-route] apply redirect ip 3.3.3.9:0 color 0:200
[*PE1-flow-route] commit
[~PE1-flow-route] quit

# Display BGP FlowSpec route information on PE1.
[~PE1] display bgp flow routing-table
RPKI validation codes: V - valid, I - invalid, N - not-found
Total Number of Routes: 2

* > ReIndex : 24577
Dissemination Rules:
Destination IP : 10.8.8.8/32
MED :0 PrefVal : 0
LocalPref:
Path/Ogn : i
* > ReIndex : 24578
Dissemination Rules:
MED :0 PrefVal : 0
LocalPref:
Path/Ogn : i
# Display the traffic redirection information carried in a single BGP FlowSpec route
based on the ReIndex value shown in the preceding command output.
[~PE1] display bgp flow routing-table 24577
ReIndex : 24577
Dissemination Rules :
BGP flow-ipv4 routing table entry information of 24577:

Local : PE1toPE2
Match action :
apply redirect ip 3.3.3.9:0 color 0:100
AS-path Nil, origin igp, MED 0, pref-val 0, valid, local, best, pre 255
Advertised to such 1 peers:
3.3.3.9
[~PE1] display bgp flow routing-table 24578
ReIndex : 24578
Dissemination Rules :
BGP flow-ipv4 routing table entry information of 24578:

Local : PE1toPE2b
Match action :
AS-path Nil, origin igp, MED 0, pref-val 0, valid, local, best, pre 255
3.3.3.9
----End

(2020-10-09)
Configuration Files
#
sysname PE1
#
mpls lsr-id 1.1.1.9
#
mpls
#
segment-routing
segment-list pe1
binding-sid 115
mtu 1000
segment-list pe1
binding-sid 125
mtu 1000
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0001.00
#
undo shutdown
ip address 10.1.1.1 255.255.255.0
isis enable 1
#
undo shutdown
ip address 10.3.1.1 255.255.255.0
isis enable 1
#
interface LoopBack1
ip address 1.1.1.9 255.255.255.255
isis enable 1
#
bgp 100
#
ipv4-family unicast
peer 3.3.3.9 enable
#
ipv4-family flow
peer 3.3.3.9 enable
#
flow-route PE1toPE2
if-match destination 10.8.8.8 255.255.255.255
#
flow-route PE1toPE2b
if-match destination 10.9.9.9 255.255.255.255

(2020-10-09)
#
return
#
sysname P1
#
mpls lsr-id 2.2.2.9
#
mpls
#
segment-routing
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0002.00
#
undo shutdown
ip address 10.1.1.2 255.255.255.0
isis enable 1
#
undo shutdown
ip address 10.2.1.1 255.255.255.0
isis enable 1
#
interface LoopBack1
ip address 2.2.2.9 255.255.255.255
isis enable 1
#
return
#
sysname PE2
#
mpls lsr-id 3.3.3.9
#
mpls
#
segment-routing
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0003.00
#
undo shutdown
ip address 10.2.1.2 255.255.255.0
isis enable 1
#
undo shutdown
ip address 10.4.1.2 255.255.255.0
isis enable 1
#
interface LoopBack1
ip address 3.3.3.9 255.255.255.255
isis enable 1
#
interface LoopBack2

(2020-10-09)
ip address 10.8.8.8 255.255.255.255

#
interface LoopBack3
ip address 10.9.9.9 255.255.255.255
#
bgp 100
#
ipv4-family unicast
network 10.8.8.8 255.255.255.255
network 10.9.9.9 255.255.255.255
peer 1.1.1.9 enable
#
ipv4-family flow
peer 1.1.1.9 enable
#
return
#
sysname P2
#
mpls lsr-id 4.4.4.9
#
mpls
#
segment-routing
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0004.00
#
undo shutdown
ip address 10.3.1.2 255.255.255.0
isis enable 1
#
undo shutdown
ip address 10.4.1.1 255.255.255.0
isis enable 1
#
interface LoopBack1
ip address 4.4.4.9 255.255.255.255
isis enable 1
#
return

(2020-10-09)
New IP Technologies 2 Segment Routing IPv6
2 Segment Routing IPv6
2.1 Segment Routing IPv6
2.1.1 Overview of Segment Routing IPv6
Definition
Segment Routing IPv6 (SRv6) forwards IPv6 packets using the source routing
model. It implements hop-by-hop forwarding by adding a Segment Routing
header (SRH) into IPv6 packets, encapsulating an explicit IPv6 address stack into
the SRH, and continuously updating IPv6 destination addresses while offsetting
the address stack on transit nodes.
Purpose
Future networks will be 5G oriented. Transport networks need to be adjusted to
meet 5G requirements for network simplification, low latency, and SDN and
network functions virtualization (NFV) implementation.
To develop 5G networks, users hope to implement VPN functionality more easily

using IPv6 addresses. SRv6 uses existing IPv6 forwarding techniques and extends
IPv6 headers to implement label forwarding-like processing. Some IPv6 addresses
are instantiated as SIDs, each of which has its own explicit functions. SIDs are
operated to implement simplified VPNs and flexible path planning.
Benefits
SRv6 offers the following benefits to users:
● Simplified network configuration and easier VPN implementation
SRv6 is based on IPv6 forwarding. It does not involve MPLS techniques and is
fully compatible with existing IPv6 networks. Transit nodes can forward SRH-
encapsulated IPv6 packets through routes, without the need to support SRv6.
● Improved fast reroute (FRR) capability

(2020-10-09)
SRv6 works with the remote loop-free alternate (RLFA) FRR algorithm,
providing topology-independent loop-free alternate (TI-LFA) protection that
theoretically supports all topologies and compensates for conventional tunnel
protection techniques.
● Flexible traffic optimization on IPv6 forwarding paths
Various types of SIDs are used, enabling the ingress to flexibly plan explicit
paths and adjust service traffic.
2.1.2 Understanding Segment Routing IPv6
2.1.2.1 SRv6 Fundamentals
SRH
An IPv6 packet consists of an IPv6 header, 0 to N (N ≥ 1) extension headers, and
payload. The Segment Routing header (SRH) is an extension header added to IPv6
packets to implement Segment Routing IPv6 (SRv6) based on the IPv6 forwarding
plane. It specifies an IPv6 explicit path and stores IPv6 segment lists that function
in the same way as segment lists in SR-MPLS.
The ingress adds an SRH to each IPv6 packet, allowing transit nodes to forward
the packets based on path information contained in the SRH. Figure 2-1 shows
the SRH format.
Figure 2-1 SRH format

(2020-10-09)
Table 2-1 describes fields in an SRH.
Table 2-1 Fields in an SRH

Next 8 bits Type of the header immediately following the SRH.

Header The common types are as follows:
● 4: IPv4 encapsulation
● 41: IPv6 encapsulation
● 43: routing header for IPv6 (IPv6-Route)
● 58: ICMPv6
● 59: no Next Header for IPv6
Hdr Ext Len 8 bits Length of the SRH, not including the first 8 bytes.
Routing 8 bits Routing header type. SRHs have a routing type value
Type of 4.
Segments 8 bits Number of explicitly listed transit nodes to be visited

Left before traffic reaches the destination.
Last Entry 8 bits Index of the last element in a segment list.
Flags 8 bits Packet flags.
Tag 16 bits Tag indicating a packet as part of a class or group of

packets.
Segment 128 bits Segment lists expressed using 128-bit IPv6 addresses
List [0] to and encoded from the last segment of a path.
Segment Segment List [0] indicates the last segment of a path.
List [n]
Segment List [1] indicates the penultimate segment
of a path.
...
Segment List [n–1] indicates the second segment of a
path.
Segment List [n] indicates the first segment of a path.
Figure 2-2 shows the abstract SRH format.
Figure 2-2 Abstract SRH format

(2020-10-09)
Fields involved are as follows:

● IPv6 Destination Address (IPv6 DA): destination address of an IPv6 packet,
which is fixed for ordinary IPv6 packets. In SRv6, the IPv6 DA only identifies
the next hop of a packet and changes constantly.
● <Segment List [0], Segment List [1], ..., Segment List [n–1], Segment List [n]>:
segment list information in an SRv6 packet. It is similar to an MPLS label
stack in SR-MPLS and generated on the ingress. On an SRv6 path, Segment
List [n] is the first segment list to be processed, Segment List [n–1] is the
second, Segment List [1] is the penultimate, and Segment List [0] is the last.
SRH Processing
In SRv6, every time a packet passes through an SRv6-capable node, the value of
the Segments Left (SL) field is decremented by 1 and the IPv6 DA is updated, as
shown in Figure 2-3. The SL and Segment List fields are both used to determine
an IPv6 DA.
● If the value of the SL field is n, the IPv6 DA value is equal to the Segment List
[n] value.
● If the value of the SL field is n–1, the IPv6 DA value is equal to the Segment
List [n–1] value.
● ...
● If the value of the SL field is 1, the IPv6 DA value is equal to the Segment List
[1] value.
● If the value of the SL field is 0, the IPv6 DA value is equal to the Segment List
[0] value.
Figure 2-3 SRH processing
According to the preceding description, segment lists in an SRv6 SRH are

processed from the bottom up, which is different from SR-MPLS processing.
Another difference between SRv6 and SR-MPLS is that segments in SRv6 SRHs are
not removed after being processed by nodes. This is mainly caused by three
reasons. First, because the earliest IPv6 RH design was not closely related to MPLS,
the segment removal option did not exist at the time. Second, in contrast to MPLS
labels that are independently placed on the top of packets and therefore can be
directly removed, SRv6 segments are placed in the SRH and associated with

(2020-10-09)
information (such as security encryption and verification information) in other

extension headers. Third, SRv6 segments can be used for path backtracking based
on the path information kept in the SRv6 header. In addition, some innovative
factors regarding SRv6 segments have been taken into account to reuse the
segments for new function extensions.
2.1.2.2 SRv6 Segments
SRv6 segments are identified using segment identifiers (SIDs) encoded as IPv6
addresses. An SRv6 SID consists of two parts: Locator and Function, expressed in
the Locator:Function format, as shown in Figure 2-4. The Locator part occupies
the most significant bits, and the Function part occupies the remaining bits.
Figure 2-4 SRv6 SID
The Locator part provides the location function. In general, each locator value
must be unique in an SR domain. However, in certain scenarios, such as the
scenario where anycast protection is configured, multiple devices may be
configured with the same locator value. After a locator value is configured for a
node, the system generates a locator route and propagates the route in the SR
domain through an IGP, allowing other nodes to locate the node based on the
route information received. In addition, all SRv6 SIDs advertised by the node can
be reached through the route.
The Function part identifies an instruction bound to the node that generates the
SRv6 SID.
In addition to the Locator and Function parts, an SRv6 SID can also include the
Arguments part. If this is the case, the SRv6 SID is expressed in the
Locator:Function:Arguments format. The Arguments part occupies the least
significant bits of the IPv6 address and can be used to define packet flow and
service information. Currently, an important application is to use arguments to
implement split horizon for broadcast, unknown-unicast, and multicast (BUM)
traffic forwarding in an EVPN VPLS scenario where CE multi-homing is deployed.
For details about the application, see Split Horizon.
The Function and Arguments parts can both be defined, resulting in an SRv6 SID
structure that improves network programmability.
Local SID Table

Each SRv6-capable node keeps a local SID table (named My Local SID Table)
containing all SRv6 SIDs generated on the node. An SRv6 forwarding table (FIB)
can be generated based on this table. The local SID table provides the following
functions:
● Defines locally generated SIDs, such as End.X SIDs.
● Specifies instructions bound to the SIDs.

(2020-10-09)
● Stores forwarding information related to the instructions, such as outbound

interface and next hop information.
There are a wide range of SRv6 SIDs associated with different functions.
End SID
An End SID is an endpoint SID that identifies a destination node. It is similar to a
node SID in SR-MPLS.
After an End SID is generated on a node, the node propagates the SID to all other
nodes in the SRv6 domain through an IGP. All nodes in the SRv6 domain know
how to implement the instruction bound to the SID.
Figure 2-5 End SID
End.X SID
An End.X SID is a Layer 3 cross-connect endpoint SID that identifies a link. It is
similar to an adjacency SID in SR-MPLS.
After an End.X SID is generated on a node, the node propagates the SID to all the
other nodes in the SRv6 domain through an IGP. Although the other nodes can all
obtain the SID, only the node generating the SID knows how to implement the
instruction bound to the SID.
Figure 2-6 End.X SID
End.DT4 SID
An End.DT4 SID is a provider edge (PE)-specific endpoint SID that identifies an
IPv4 VPN instance. The instruction bound to the End.DT4 SID is to decapsulate
packets and search the routing table of an IPv4 VPN instance for packet
forwarding. The End.DT4 SID is equivalent to an IPv4 VPN label and used in
L3VPNv4 scenarios. It can also be used to identify a public network instance.

(2020-10-09)
An End.DT4 SID can either be manually configured or automatically allocated by

BGP within the dynamic SID range of the specified locator.
Figure 2-7 End.DT4 SID
End.DT6 SID
An End.DT6 SID is a PE-specific endpoint SID that identifies an IPv6 VPN instance.
The instruction bound to the End.DT6 SID is to decapsulate packets and search the
routing table of an IPv6 VPN instance for packet forwarding. The End.DT6 SID is
equivalent to an IPv6 VPN label and used in L3VPNv6 scenarios. It can also be
used to identify a public network instance.
An End.DT6 SID can either be manually configured or automatically allocated by
Figure 2-8 End.DT6 SID
End.DX4 SID
An End.DX4 SID is a PE-specific Layer 3 cross-connect endpoint SID that identifies
an IPv4 CE. The instruction bound to the End.DX4 SID is to decapsulate packets
and forward the decapsulated IPv4 packets over the Layer 3 interface bound to
the SID. The End.DX4 SID is equivalent to a label identifying a CE-connected
adjacency and used in L3VPNv4 scenarios.
An End.DX4 SID can either be manually configured or automatically allocated by
Figure 2-9 End.DX4 SID

(2020-10-09)
End.DX6 SID
An End.DX6 SID is a PE-specific Layer 3 cross-connect endpoint SID that identifies
an IPv6 CE. The instruction bound to the End.DX6 SID is to decapsulate packets
and forward the decapsulated IPv6 packets over the Layer 3 interface bound to
the SID. The End.DX6 SID is equivalent to a label identifying a CE-connected
adjacency and used in L3VPNv6 scenarios.
An End.DX6 SID can either be manually configured or automatically allocated by
Figure 2-10 End.DX6 SID
End.DX2 and End.DX2L SIDs

An End.DX2 SID is a Layer 2 cross-connect endpoint SID that identifies an
endpoint. The instruction bound to the End.DX2 SID is to pop the IPv6 header and
extension headers and then forward the remaining packet content to the
outbound interface bound to the SID. The End.DX2 SID can be used in EVPN VPWS
scenarios.
If a bypass tunnel exists on the network, an End.DX2L SID is generated
automatically.
Figure 2-11 End.DX2 and End.DX2L SIDs

(2020-10-09)
End.DT2U and End.DT2UL SIDs

An End.DT2U SID is a Layer 2 cross-connect endpoint SID to which unicast MAC
table lookup is bound. It also identifies an endpoint. The instruction bound to the
End.DT2U SID is to pop the IPv6 header and extension headers, search the MAC
address table based on the exposed destination MAC address, and then forward
the remaining packet content to the outbound interface bound to the SID. The
End.DT2U SID can be used in EVPN VPLS unicast scenarios.
Figure 2-12 End.DT2U SID
If a bypass tunnel exists on the network, an End.DT2UL SID is generated

automatically. The SID can be used to send unicast traffic over the bypass tunnel
when a CE is dual-homed to PEs.
End.DT2M SID
An End.DT2M SID is a Layer 2 cross-connect endpoint SID to which broadcast-
based flooding is bound. It also identifies an endpoint. The instruction bound to
the End.DT2M SID is to pop the IPv6 header and extension headers and then
broadcast the remaining packet content in the bridge domain (BD). The End.DT2M
SID is used in EVPN VPLS BUM scenarios.

(2020-10-09)
Figure 2-13 End.DT2M SID
End.OP SID
An End.OP SID (OAM endpoint with punt) is an OAM SID that specifies the punt
behavior to be implemented for OAM packets in ping and tracert scenarios. On
the network shown in Figure 2-14, if ingress node A attempts to ping the End.X
SID A4:4::45 between nodes D and E through the End.X SID A2:2::23, node D needs
to process and respond to the ICMPv6 Echo Request packet sent by node A. When
constructing the ping packet, node A needs to insert the End.OP SID A4:4::1 of
node D into the packet. After receiving the packet, node D finds that the
destination address of the packet is its own End.OP SID. Then, node D checks
whether A4:4::45 is its local SID. If yes, node D returns a ping success packet. If
not, node D reports an error indicating that the SID is not its local SID.
Figure 2-14 End.OP SID

(2020-10-09)
End.M SID
An End.M SID is used in an SRv6 egress protection scenario. For details about the
functions of the End.M SID, see Egress Protection.
2.1.2.3 SRv6 Nodes
SRv6 Node Roles

SRv6 nodes perform the following roles:
● SRv6 source node: a source node that encapsulates packets into SRv6 packets
● Transit node: an IPv6 node that forwards SRv6 packets but does not perform
SRv6 processing
● SRv6 segment endpoint node: a node that receives and processes SRv6
packets in which the destination IPv6 address is the node's local SID or local
interface address
A node plays a role based on the task it takes in SRv6 packet forwarding, and it
may play two or more roles. For example, it can be the source node on one SRv6
path and a transit or endpoint node on another SRv6 path.
On the network shown in Figure 2-15, the SRv6 source node encapsulates packets
into SRv6 packets, the transit node processes and forwards the packets as
common IPv6 packets, and the endpoint nodes process SRv6 SIDs and SRHs in the
packets.
Figure 2-15 SRv6 nodes
Endpoint Node Behaviors

Behaviors performed by endpoint nodes are determined by instructions specified
by SIDs. Such instructions include data packet forwarding, encapsulation, and
decapsulation. They are called End series instructions because they are executed
by SRv6 endpoints.
For details about common instructions, see SRv6 Segments.

(2020-10-09)
Source Node Behaviors

An SRv6 source node steers packets into an SRv6 TE Policy and, if possible,
encapsulates SRHs into the packets. Table 2-2 describes the behaviors of an SRv6
source node.
Table 2-2 Source node behaviors

Behavior Description
H.Insert Inserts an SRH into a received IP packet and forwards the

packet by searching the IPv6 routing table.
H.Encaps Encapsulates an outer IPv6 header and an SRH for a received IP

packet and forwards the packet by searching the IPv6 routing
table.
H.Encaps.L2 Encapsulates an outer IPv6 header and an SRH for a received

Layer 2 packet and forwards the packet by searching the IPv6
routing table.
Flavors
Flavors are behaviors defined to enhance the End series instructions. They are
supplements to endpoint and transit node behaviors. Flavors are optional and will
change the End series instructions once used, meeting diverse service
requirements. Table 2-3 lists the common flavors and their functions.
Table 2-3 Flavors

Flavor Function Description
Penultimate Removes the SRH on the penultimate segment. As a function

segment pop similar to penultimate hop popping (PHP) in MPLS, it improves
of the SRH forwarding efficiency.
(PSP)
Ultimate Removes the SRH on the ultimate segment.

segment pop
of the SRH
(USP)
2.1.2.4 IS-IS for SRv6
Segment routing (SR) uses an IGP to advertise topology, prefix, locator, and SID
information. To complete the preceding functions, the IGP extends some TLVs of
protocol packets. Table 2-4 shows IS-IS extensions for SRv6.

(2020-10-09)
Table 2-4 Extended IS-IS TLVs for SRv6
Type Name Function TLV/Sub-TLV Location
TLV SRv6 Locator TLV Advertises an SRv6 IS-IS packet

locator and the End
SIDs associated with it.
Sub-TLV SRv6 Capabilities Advertises SRv6 IS-IS TLV of type 242

sub-TLV capabilities.
SRv6 End SID Advertises SRv6 SIDs. SRv6 Locator TLV

sub-TLV
SRv6 End.X SID Advertises SRv6 SIDs IS-IS TLVs of types 22,
sub-TLV on a point-to-point 23, 141, 222, and 223
(P2P) network.
SRv6 LAN End.X Advertises SRv6 SIDs IS-IS TLVs of types 22,
SID sub-TLV on a local area 23, 141, 222, and 223
network (LAN).
Node MSD sub- Advertises the IS-IS router capability

TLV maximum SID depth TLV
(MSD) supported by a
device.
SRv6 Locator TLV

The SRv6 Locator TLV is used to advertise an SRv6 locator and the End SIDs
associated with it. Figure 2-16 shows the format of the SRv6 Locator TLV.
Figure 2-16 SRv6 Locator TLV
Table 2-5 Fields in the SRv6 Locator TLV
Type 8 bits Type.

(2020-10-09)
Length 8 bits Length.
MTID 12 bits Multi-topology identifier.
Metric 32 bits Metric.
Flags 8 bits Flags bit, expressed using the format shown in Figure
2-17. Currently, only the D bit is available. When a SID
is leaked from Level-2 to Level-1, the D bit must be
set. SIDs with the D bit set must not be leaked from
Level-1 to Level-2 to prevent route loops.
Figure 2-17 Flags field format
Algorithm 8 bits Associated algorithm:

● 0: shortest path first
● 1: strict shortest path first
Loc Size 8 bits Number of bits in the Locator field.
Locator Variable Advertised SRv6 locator.

(variable) length
sub-tlv-len 8 bits Sub-TLV length.
Sub-TLVs Variable Included sub-TLVs, for example, SRv6 End SID sub-TLV.
(variable) length
SRv6 locators can be advertised using the SRv6 Locator TLV. After receiving the
TLV, SRv6-capable IS-IS devices install corresponding locator route entries to their
local forwarding tables, but SRv6-incapable IS-IS devices do not.
SRv6 locators can also be advertised using the Prefix Reachability TLV 236 or 237.
In this advertisement mode, SRv6-incapable devices can install corresponding
locator route entries to their local forwarding tables, thereby achieving
interworking with SRv6-capable devices. In cases where a locator advertisement is
received in both a Prefix Reachability TLV and an SRv6 Locator TLV, the Prefix
Reachability TLV is preferentially used.
SRv6 Capabilities Sub-TLV

In SRv6, segment list information is stored in the Segment Routing header (SRH).
SRv6-capable nodes must be able to process SRH information under certain
restrictions. The SRv6 Capabilities sub-TLV is used to advertise the SRv6
capabilities supported by the local node. Figure 2-18 shows the format of the
SRv6 Capabilities sub-TLV.

(2020-10-09)
Figure 2-18 SRv6 Capabilities sub-TLV
Table 2-6 Fields in the SRv6 Capabilities sub-TLV
Type 8 bits Type.
Flags 16 bits Flag bit.
Optional Variable Optional sub-sub-TLVs.

sub-sub- length
TLVs
SRv6 End SID Sub-TLV

The SRv6 End SID sub-TLV is used to advertise SRv6 End SIDs with endpoint
functions. Figure 2-19 shows the format of the SRv6 End SID sub-TLV.
Figure 2-19 SRv6 End SID sub-TLV
Table 2-7 Fields in the SRv6 End SID sub-TLV
Type 8 bits Type.

(2020-10-09)
Flags 8 bits Flag bit.
SRv6 16 bits SRv6 endpoint function. For details about supported

Endpoint values, see SRv6 Endpoint Function.
Function
SID 16 octets Advertised SRv6 SID.
Sub-sub- 8 bits Sub-sub-TLV length.

tlv-len
Sub-sub- Variable Included sub-sub-TLVs.

TLVs length
(variable)
SRv6 End.X SID Sub-TLV

The SRv6 End.X SID sub-TLV is used to advertise an SRv6 End.X SID associated with
a P2P adjacency. Figure 2-20 shows the format of the SRv6 End.X SID sub-TLV.
Figure 2-20 SRv6 End.X SID sub-TLV
Table 2-8 Fields in the SRv6 End.X SID sub-TLV
Type 8 bits Type.

(2020-10-09)
Flags 8 bits Flag bit. Figure 2-21 shows the format of this field.
Figure 2-21 Flags field format
● B-Flag: backup flag.

● S-Flag: set flag. When set, it indicates that the
End.X SID represents a set of adjacencies.
● P-Flag: persistent flag. When set, it indicates that
the End.X SID is persistently allocated.
Algorithm 8 bits Associated algorithm.
Weight 8 bits Weight of the End.X SID for the purpose of load
balancing.
SRv6 16 bits SRv6 endpoint function. For details about supported

Endpoint values, see SRv6 Endpoint Function.
Function
SID 16 octets Advertised SRv6 SID.
Sub-sub- 8 bits Sub-sub-TLV length.

tlv-len
Sub-sub- Variable Included sub-sub-TLVs.

TLVs length
(variable)
SRv6 LAN End.X SID Sub-TLV

The SRv6 LAN End.X SID sub-TLV is used to advertise an SRv6 End.X SID associated
with a LAN adjacency. Figure 2-22 shows the format of the SRv6 LAN End.X SID
sub-TLV.

(2020-10-09)
Figure 2-22 SRv6 LAN End.X SID sub-TLV
Compared with the SRv6 End.X SID sub-TLV, the SRv6 LAN End.X SID sub-TLV
simply has an additional System ID field. Table 2-9 describes the fields in this sub-
TLV.
Table 2-9 Fields in the SRv6 LAN End.X SID sub-TLV

System ID 48 bits IS-IS system ID
Node MSD Sub-TLV

The Node MSD sub-TLV is used to advertise the MSD supported by a device.
Figure 2-23 shows the format of the Node MSD sub-TLV.
Figure 2-23 Node MSD sub-TLV
Table 2-10 describes the fields in the Node MSD sub-TLV.

(2020-10-09)
Table 2-10 Fields in the Node MSD sub-TLV

Type 8 bits Type.
MSD-Type 8 bits MSD type:

● Maximum Segments Left MSD Type: specifies the
maximum value of the Segments Left (SL) field in
the SRH of a received packet before the SRv6
endpoint function associated with a SID is applied.
● Maximum End Pop MSD Type: specifies the
maximum number of SIDs in the top SRH in an
SRH stack. Value 0 indicates that the local node
cannot perform the penultimate segment pop of
the SRH (PSP) or ultimate segment pop of the SRH
(USP) operation.
● Maximum H.Insert MSD Type: specifies the
maximum number of SIDs that can be inserted as
part of the H.Insert operation. Value 0 indicates
that the local node cannot perform an H.Insert
operation.
● Maximum H.Encaps MSD Type: specifies the
maximum number of SIDs that can be included as
part of the H.Encaps operation.
● Maximum End D MSD Type: specifies the
maximum number of SIDs in an SRH when
performing decapsulation associated with End.D
(for example, End.DX6 and End.DT6) functions.
MSD Value 8 bits MSD value.
SRv6 Endpoint Function

SRv6 uses endpoint functions to define the behaviors associated with different
SIDs. In addition to advertising locator routes, IS-IS advertises SRv6 SIDs and their
associated SRv6 endpoint functions through various SID sub-TLVs for path/service
programming units to perform network programming. Table 2-11 shows the SRv6
endpoint functions that can be advertised by IS-IS. In this table, "Y" indicates that
the corresponding sub-TLV can advertise the specified type of SRv6 endpoint
function, and "N" indicates that the corresponding sub-TLV cannot advertise the
specified type of SRv6 endpoint function.

(2020-10-09)
Table 2-11 SRv6 endpoint functions that can be advertised by IS-IS

SRv6 SRv6 End SID Sub- SRv6 End.X SID SRv6 LAN End.X
Endpoint TLV Sub-TLV SID Sub-TLV
Function
End (no PSP, Y N N

no USP)
End (with Y N N
PSP)
End (with Y N N
USP)
End (with PSP Y N N

& USP)
End.X (no PSP, N Y Y

no USP)
End.X (with N Y Y
PSP)
End.X (with N Y Y
USP)
End.X (with N Y Y
PSP & USP)
End.DT4 Y N N
End.DT6 Y N N
End.DX4 N Y Y
End.DX6 N Y Y
End.OP Y N N
2.1.2.5 BGP for SRv6
IGP for SR allocates SIDs only within an autonomous system (AS). Proper SID
orchestration in an AS facilitates the planning of an optimal path in the AS.
However, IGP for SR does not work if paths cross multiple ASs on a large-scale
network. BGP for SRv6 is an extension of BGP for Segment Routing. This function
enables a device to allocate BGP peer SIDs based on BGP peer information and
report the SID information to a controller. An SRv6 TE Policy uses BGP peer SIDs
for path orchestration, thereby obtaining the optimal inter-AS path. BGP for SRv6
mainly involves the BGP egress peer engineering (EPE) extension and BGP-LS
extension.
BGP EPE
BGP EPE allocates BGP peer SIDs to inter-AS paths. BGP-LS advertises the BGP
peer SIDs to the controller. A forwarder that does not establish a BGP-LS peer

(2020-10-09)
relationship with the controller can run BGP-LS to advertise a peer SID to a BGP
peer that has established a BGP-LS peer relationship with the controller. The BGP
peer then runs BGP-LS to advertise the peer SID to the network controller. As
shown in Figure 2-24, BGP EPE can allocate peer node segments (Peer-Node SIDs)
and peer adjacency segments (Peer-Adj SIDs).
● A Peer-Node SID identifies a peer node. The peers at both ends of each BGP
session are assigned Peer-Node SIDs. An EBGP peer relationship established
based on loopback interfaces may traverse multiple physical links. In this case,
the Peer-Node SID of a peer is mapped to multiple outbound interfaces.
Traffic can be forwarded through any outbound interface or be load-balanced
among multiple outbound interfaces.
● A Peer-Adj SID identifies an adjacency to a peer. An EBGP peer relationship
established based on loopback interfaces may traverse multiple physical links.
In this case, each adjacency is assigned a Peer-Adj SID. Only a specified link
(mapped to a specified outbound interface) can be used for forwarding.
Figure 2-24 BGP EPE networking
On the network shown in Figure 2-24, ASBR1 and ASBR3 are directly connected
through two physical links. An EBGP peer relationship is established between
ASBR1 and ASBR3 through loopback interfaces. ASBR1 runs BGP EPE to assign the
Peer-Node SID 2001:db8::1 to its peer (ASBR3) and to assign the Peer-Adj SIDs
2001:db8:1::2 and 2001:db8:1::3 to the physical links. For EBGP peers that are
directly connected through physical interfaces, BGP EPE allocates only Peer-Node
SIDs rather than Peer-Adj SIDs. For example, on the network shown in Figure
2-24, BGP EPE allocates only Peer-Node SIDs 2001:db8::4, 2001:db8::5, and
2001:db8::6 to ASBR1-ASBR5, ASBR2-ASBR4, and ASBR2-ASBR5, respectively.

(2020-10-09)
Peer-Node and Peer-Adj SIDs are effective only on local devices. Different devices
can have the same Peer-Node SID or Peer-Adj SID. Currently, BGP EPE supports
only EBGP peers.
BGP EPE allocates SIDs only to BGP peers and links, but cannot be used to
construct a forwarding path. BGP peer SIDs must be used with IGP SIDs to form
an E2E path.
BGP-LS
Inter-AS SRv6 TE Policies can be established by manually specifying explicit paths,
or they can be orchestrated by a controller. In a controller-based orchestration
scenario, intra- and inter-AS SIDs are reported to the controller using BGP-LS.
Inter-AS links must support TE link attribute configuration and reporting to the
controller. This enables the controller to compute primary and backup paths based
on the link attributes. BGP EPE discovers network topology information and
allocates SIDs. BGP-LS reports the topology and SID information to the controller
through the Link network layer reachability information (NLRI) field and SRv6 SID.
Figure 2-25 and Figure 2-26 show Link NLRI formats.
Figure 2-25 Format of link information (Peer-Adj SIDs) advertised by BGP-LS

(2020-10-09)
Table 2-12 Description of involved fields

Field Description

following parts:
● Local Descriptor: local descriptor,
which contains a local router ID, a
local AS number, and a BGP-LS ID
● Remote Descriptor: remote
descriptor, which contains a peer
router ID and a peer AS number
● Link Descriptor: link descriptor,
which contains addresses used by a
BGP session
Link Attribute Link information. It is a part of the

Link NLRI.
● Administrative Group: link
management group attribute
● Max Link BW: maximum link
bandwidth
● Max Reservable Link BW: maximum
reservable link bandwidth
● Unreserved BW: remaining link
bandwidth
● Shared Risk Link Group: SRLG
● SRv6 End.x TLV: Peer-Adj-SID TLV
Figure 2-26 Format of SRv6 SID information (Peer-Node SIDs) advertised by BGP-
LS

(2020-10-09)
Table 2-13 Description of involved fields

Field Description

following parts:
● Local Descriptor: local descriptor,
which contains a local BGP router
ID, a local AS number, and a BGP-LS
ID
● SRv6 SID Descriptor: SRv6 SID
descriptor, which contains an
allocated SID
SRv6 SID Attribute SRv6 SID attribute information. It is a

part of the SRv6 SID NLRI.
● SRv6 Endpoint Function: SRv6
function description, which specifies
the instruction corresponding to a
SID
● SRv6 BGP Peer Node SID: BGP peer
information
Figure 2-27 shows the format of an SRv6 BGP Peer-Node SID.
Figure 2-27 SRv6 BGP Peer-Node SID format
Table 2-14 Fields in an SRv6 BGP Peer-Node SID TLV


(2020-10-09)
Flags 8 bits Flags field used in an SRv6 BGP Peer-Node SID TLV.
Figure 2-28 shows the format of this field.
In this field:
● B: backup flag. If set, the SID is eligible for
protection.
● S: set flag. If set, the SID refers to a set of BGP
peering sessions.
● P: persistent flag. If set, the SID is persistently
allocated.
Weight 8 bits SID weight used for load balancing purposes.

(not
currently
supported)
Peer AS 32 bits BGP AS number of the peer router.

Number
Peer BGP 32 bits BGP identifier of the peer router.

Identifier
2.1.2.6 SRv6 BE
2.1.2.6.1 L3VPNv4 over SRv6 BE
L3VPNv4 over SRv6 BE Overview

L3VPNv4 over SRv6 BE transmits L3VPNv4 data over SRv6 BE paths. Table 2-15
describes the characteristics of L3VPNv4 over SRv6 BE.
Table 2-15 Characteristics of L3VPNv4 over SRv6 BE
Item Characteristics
VPN service type IPv4 VPN over SRv6 BE.
VPNv4 route distinguisher and RD: distinguishes the routes of different VPN
leaking instances.
RT: used for route leaking.

(2020-10-09)
Item Characteristics
Route transfer IPv6 peering is enabled in the BGP VPNv4

address family to transfer IPv4 routes.
Public network routing BGP4+ and IS-ISv6.

protocols
VPN label Not involved. VPN labels are replaced with

SRv6 VPN SIDs (for example, End.DT4 SIDs).
MPLS label Not involved.
VPN routing table lookup An egress identifies a VPN instance based on

an SRv6 VPN SID (for example, an End.DT4
SID) and searches the IP routing table of the
VPN instance.
Figure 2-29 shows the typical L3VPNv4 over SRv6 BE networking.
Figure 2-29 Typical L3VPNv4 over SRv6 BE networking
L3VPNv4 over SRv6 BE has the following characteristics:
● Transmits routes using extended BGP.

● Uses SRv6 BE to encapsulate and transmit VPN data packets.
● A PE, P, and CE cannot perform each other's functions. For example, a PE
cannot provide CE functions.
L3VPNv4 over SRv6 BE Implementation

The implementation of L3VPNv4 over SRv6 BE involves establishing SRv6 BE paths,
advertising VPN routes, and forwarding data.
Figure 2-30 shows how L3VPNv4 over SRv6 BE is implemented from CE1 to CE2.

(2020-10-09)
Figure 2-30 L3VPNv4 over SRv6 BE implementation
The implementation process is as follows:

1. SRv6 and SRv6 VPN functions are configured on each PE, and IPv6 is enabled
on the transit node.
2. PE2 advertises an SRv6 locator route to PE1.
3. Route advertisement from CE2 to PE2: CE2 advertises its IPv4 route to PE2. A
static route or a dynamic routing protocol such as RIP, OSPF, IS-IS, or BGP can
be configured for the communication between CE2 and PE2.
4. After learning the route advertised by CE2, PE2 installs the route in its routing
table of the corresponding VPN instance and converts the route into a VPNv4
route.
5. Route advertisement from PE2 to PE1: PE2 advertises the VPNv4 route to
egress node PE1 through MP-BGP update messages carrying RT and SRv6
VPN SID attributes.
6. After PE1 receives the VPNv4 route, if the next hop in the VPNv4 route is
reachable and the route matches the BGP route import policy, PE1 performs a
series of actions to determine whether to install the route in the routing table
of the corresponding VPN instance. These actions include route leaking, route
recursion to an SRv6 BE path, and route selection. If PE1 installs the route,
this route is then associated with an SRv6 VPN SID.
7. PE1 advertises the route to CE1. CE1 then learns the route from PE1 using RIP,
OSPF, IS-IS, or BGP. This process is similar to that from CE2 to PE2.
Figure 2-31 describes route advertisement and data forwarding from CE2 to CE1
in an L3VPNv4 over SRv6 BE scenario.

(2020-10-09)
Figure 2-31 Route advertisement and data forwarding in an L3VPNv4 over SRv6
BE scenario
In the route advertisement phase:

1. After a locator is configured on PE2, PE2 generates an End SID and advertises
the End SID to PE1 through an IGP.
2. PE2 advertises the locator route A2:1::/64 corresponding to the SID to PE1
through the IGP. PE1 then installs the route in its IPv6 routing table.
3. After a VPN SID (End.DT4 SID A2:1::B100) within the locator range is
configured on PE2, PE2 generates a local SID entry.
4. After receiving an IPv4 VPN route advertised by CE2, PE2 converts the route to
a BGP VPNv4 route and advertises it to its MP-BGP peer PE1. The route carries
an SRv6 VPN SID, that is, End.DT4 SID A2:1::B100.
5. After receiving the VPNv4 route, PE1 leaks the route to the routing table of
the corresponding VPN instance, converts it into a common IPv4 route, and
advertises it to CE1.
In the data forwarding phase:
1. CE1 sends a common IPv4 packet to PE1.
2. After receiving the packet through the interface to which a VPN instance is
bound, PE1 searches the routing table of the VPN instance for a prefix entry
that matches the destination IPv4 address of the packet. After finding
associated SRv6 VPN SID and next hop information, PE1 encapsulates the
packet into an IPv6 packet using the SRv6 VPN SID A2:1::B100 as the
3. PE1 finds the route A2:1::/64 based on the longest match rule and forwards
the packet to the P device over the shortest path.
4. Likewise, the P device finds the route A2:1::/64 based on the longest match
rule and forwards the packet to PE2 over the shortest path.

(2020-10-09)
5. PE2 searches My Local SID Table for an End.DT4 SID that matches A2:1::B100.
According to the instruction specified by the SID, PE2 removes the IPv6 packet
header and searches the routing table of the VPN instance identified by the
End.DT4 SID for packet forwarding. At this time, the packet is restored to a
common IPv4 packet.
2.1.2.6.2 EVPN L3VPNv4 over SRv6 BE
The implementation of Ethernet virtual private network (EVPN) L3VPNv4 over

SRv6 BE involves establishing SRv6 BE paths, advertising VPN routes, and
forwarding data. Figure 2-32 shows how EVPN L3VPNv4 over SRv6 BE is
implemented.
Figure 2-32 EVPN L3VPNv4 over SRv6 BE implementation
1. SRv6 and SRv6 VPN functions are configured on each PE, and IPv6 is enabled
on the transit node.
3. Route advertisement from CE2 to PE2: CE2 advertises its IPv4 route to PE2. A
static route or a dynamic routing protocol such as RIP, OSPF, IS-IS, or BGP can
be configured for the communication between CE2 and PE2.
4. After learning the IPv4 route advertised by CE2, PE2 installs the route in its
VPNv4 routing table and converts it into a type 5 EVPN route (IP prefix route).
5. Route advertisement from PE2 to PE1: PE2 advertises the EVPN route to its
BGP EVPN peer PE1 through update messages carrying RT and SRv6 VPN SID
attributes.
6. After PE1 receives the EVPN route, if the next hop in the EVPN route is
reachable and the route matches the BGP route import policy, PE1 performs a
series of actions to determine whether to install the route in the IPv4 routing
table of the corresponding EVPN instance. These actions include route
leaking, route recursion to an SRv6 BE path, and route selection. If PE1 installs
the route, this route is then associated with an SRv6 VPN SID.

(2020-10-09)
7. PE1 advertises the route to CE1. CE1 then learns the route from PE1 using RIP,
OSPF, IS-IS, or BGP. This process is similar to that from CE2 to PE2.
Figure 2-33 shows route advertisement and data forwarding in an EVPN L3VPNv4
over SRv6 BE scenario.
Figure 2-33 Route advertisement and data forwarding in an EVPN L3VPNv4 over
SRv6 BE scenario

it to PE1 through an IGP.
through the IGP. PE1 then installs the route in its own IPv6 routing table.
3. A VPN SID (End.DT4 SID A2:1::C100) within the locator range is configured on
PE2, which then generates a local SID entry.
4. After receiving the IPv4 route advertised by CE2, PE2 converts the route into a
type 5 EVPN route (IP prefix route) and advertises it to PE1 through BGP
EVPN. The EVPN route carries the SRv6 VPN SID – End.DT4 SID A2:1::C100.
5. After receiving the EVPN route, PE1 leaks the route to its VPNv4 routing table,
converts it into a common IPv4 route, and advertises it to CE1.

bound, PE1 searches the routing table of the VPN instance for a prefix entry
that matches the destination IPv4 address of the packet. After finding the
associated SRv6 VPN SID and next hop, PE1 encapsulates the packet into an
IPv6 packet using the SRv6 VPN SID A2:1::C100 as the destination address.

(2020-10-09)
5. PE2 searches My Local SID Table for an End.DT4 SID that matches A2:1::C100.
header and searches the IPv4 routing table of the VPN instance identified by
the End.DT4 SID for packet forwarding.
2.1.2.6.3 EVPN L3VPNv6 over SRv6 BE
The implementation of EVPN L3VPNv6 over SRv6 BE involves establishing SRv6 BE

paths, advertising VPN routes, and forwarding data.
Figure 2-34 shows how EVPN L3VPNv6 over SRv6 BE is implemented.
Figure 2-34 EVPN L3VPNv6 over SRv6 BE implementation
The implementation process is as follows:

1. SRv6 and SRv6 VPN are configured on each PE. Transit nodes support IPv6.
3. CE2 advertises its local IPv6 route to PE2.
Specifically, a static route or a dynamic routing protocol such as RIPng,
OSPFv3, IS-IS, or BGP4+ can be configured for the communication between
CE2 and PE2.
4. After learning the route advertised by CE2, PE2 installs the route in its VPNv6
routing table and converts it into a type 5 EVPN route (IP prefix route).
5. PE2 advertises the EVPN route to its BGP EVPN peer PE1 through a BGP
Update message, which also carries RT and SRv6 VPN SID attributes.
6. PE1 receives the EVPN route.

(2020-10-09)
If the next hop carried in the EVPN route is reachable and the route matches
the BGP route import policy, PE1 performs a series of actions to determine
whether to install the route in its IPv6 routing table of the EVPN instance.
These actions include route leaking, route recursion to an SRv6 BE path, and
preferential route selection. If PE1 determines to install the route, this route is
associated with an SRv6 VPN SID.
7. PE1 advertises the route to CE1.
CE1 learns the route from PE1 using a static route or using RIPng, OSPFv3, IS-
IS, or BGP4+. This process is similar to that from CE2 to PE2.
Figure 2-35 shows route advertisement and data forwarding in an EVPN L3VPNv6
over SRv6 BE scenario.
Figure 2-35 Route advertisement and data forwarding in an EVPN L3VPNv6 over
SRv6 BE scenario

it to PE1 through an IGP.
through the IGP. PE1 then installs the route in its own IPv6 routing table.
3. A VPN SID (End.DT6 SID A2:1::D100) within the locator range is configured on
PE2, which then generates a local SID entry.
4. After receiving the IPv6 route advertised by CE2, PE2 converts the route into a
type 5 EVPN route (IP prefix route) and advertises it to PE1 through BGP
EVPN. The EVPN route carries the VPN SID – End.DT6 SID A2:1::D100.
5. After receiving the EVPN route, PE1 leaks the route to its VPNv6 routing table,
converts it into a common IPv6 route, and advertises it to CE1.

(2020-10-09)

bound, PE1 searches the IPv6 routing table of the VPN instance for a prefix
entry that matches the destination IPv6 address of the packet. After finding
associated SRv6 VPN SID and next hop information, PE1 encapsulates the
packet into an IPv6 packet using the SRv6 VPN SID A2:1::D100 as the
5. PE2 searches My Local SID Table for an End.DT6 SID that matches A2:1::D100.
header and searches the IPv6 routing table of the VPN instance identified by
the End.DT6 SID for packet forwarding.
2.1.2.6.4 EVPN VPWS over SRv6 BE

The EVPN virtual private wire service (VPWS) over SRv6 BE solution uses SRv6 BE
over a backbone network to simplify EVPN VPWS — a technology that provides a
P2P L2VPN service based on the EVPN service architecture. This solution allows
Layer 2 packets to be forwarded along access circuit (AC) connections without the
need to search for MAC forwarding entries. It can be deployed in single-homing,
dual-homing single-active, and dual-homing active-active scenarios.
EVPN VPWS over SRv6 BE Single-Homing Scenario

Figure 2-36 shows how routes are advertised in an EVPN VPWS over SRv6 BE
single-homing scenario.
Figure 2-36 Route advertisement in an EVPN VPWS over SRv6 BE single-homing

scenario
The route advertisement process is as follows:

(2020-10-09)
1. An EVPL instance and an EVPN VPWS instance are configured both on PE1
and PE2. Each EVPL instance is bound to an AC interface and an EVPN VPWS
instance and configured with a local service ID and a remote service ID. After
the configuration, each PE generates a forwarding entry associating the AC
interface with the EVPL instance.
2. PE1 and PE2 exchange the Ethernet A-D per EVI route, which carries
information such as the RD, route target (RT), next hop, local service ID, and
SRv6 SID.
3. After receiving the route from the peer end, PE1 and PE2 leak the route to the
desired EVPN VPWS instance based on RTs and recurse the route to an SRv6
BE path based on SRv6 SIDs. If the service ID of the received route is the same
as the remote service ID configured for the local EVPL instance, PE1 and PE2
generate a forwarding entry associating the SRv6 BE routes with their local
EVPL instances.
Figure 2-37 shows how data is forwarded in an EVPN VPWS over SRv6 BE single-
homing scenario.
Figure 2-37 Data forwarding in an EVPN VPWS over SRv6 BE single-homing

scenario

1. CE1 sends a common Layer 2 packet to PE1.
2. After receiving the packet from the AC interface bound to the EVPL instance,
PE1 searches the VPWS forwarding table and finds the SRv6 VPN SID and the
next hop associated with the configured ESI. PE1 then encapsulates the
packet into an IPv6 packet using the SRv6 SID A2:1::150 as the destination
address.
5. PE2 searches My Local SID Table for an End.DX2 SID that matches A2:1::150.
header and forwards the original Layer 2 packet to CE2 through the AC
interface bound to the EVPL instance corresponding to the End.DX2 SID.

(2020-10-09)
EVPN VPWS over SRv6 BE Dual-Homing Active-Active Scenario

dual-homing active-active scenario.
Figure 2-38 Route advertisement in an EVPN VPWS over SRv6 BE dual-homing

active-active scenario
The route advertisement process is as follows:

1. An EVPL instance and an EVPN VPWS instance are configured both on PE1,
PE2, and PE3. Each EVPL instance is bound to an AC interface and EVPN
VPWS instance and configured with a local service ID and a remote service ID.
After the configuration, each PE generates a forwarding entry associating the
AC interface with the EVPL instance.
2. PE2 and PE3 both send an Ethernet A-D per EVI route to PE1 using BGP EVPN.
The Ethernet A-D per EVI routes carry RDs, RTs, next hops, local service IDs,
SRv6 SIDs, and all-active mode information. The SRv6 SIDs also include
End.DX2L SIDs used for bypass protection.
3. After PE1 receives the Ethernet A-D per EVI routes from PE2 and PE3, PE1
processes the route in the same way as that in the EVPN VPWS over SRv6 BE
single-homing scenario. In the dual-homing active-active scenario, PE1 selects
both PE2 and PE3 to balance traffic.

(2020-10-09)
The data forwarding process in the EVPN VPWS over SRv6 BE dual-homing active-
active scenario is similar to that in the single-homing scenario. For details, see
related description in the single-homing scenario.
EVPN VPWS over SRv6 BE Dual-Homing Single-Active Scenario

dual-homing single-active scenario.
Figure 2-39 Route advertisement in an EVPN VPWS over SRv6 BE dual-homing

single-active scenario
The route advertisement process in the EVPN VPWS over SRv6 BE dual-homing
single-active scenario is similar to that in the dual-homing active-active scenario.
The only difference is that the all-active mode information carried by PE2 and PE3
is different in the two scenarios. In Figure 2-39, the master/backup status of PE2
and PE3 is determined by E-Trunk negotiation. Through negotiation, PE2 stays in
the master state and PE3 in the backup state.
After receiving the Ethernet A-D per EVI routes from PE2 and PE3, PE1 selects the
route advertised by PE2 as the preferred route and preferentially forwards user
traffic to PE2.

(2020-10-09)
AC-Side Fault Protection in Dual-homing Scenarios

On the network shown in Figure 2-40, if the link between PE2 and CE2 fails, PE2
detects the fault and performs an FRR switchover. It then adds an End.DX2L SID to
the data traffic, with the next hop pointing to PE3, and forwards the traffic to PE3
along the shortest path. After receiving the traffic, PE3 searches My Local SID
Table for a matching End.DX2L SID. According to the instruction specified by the
SID, PE3 removes the IPv6 packet header and forwards the original Layer 2 packet
to CE2 through the AC interface bound to the EVPL instance corresponding to the
End.DX2L SID.
PE2 then sends a BGP Withdraw message to its BGP EVPN peer PE1 to withdraw
the advertised Ethernet A-D per EVI route. After receiving the message, PE1 selects
the Ethernet A-D per EVI route received from PE3 as the preferred route and
forwards subsequent data traffic to PE3.
Figure 2-40 AC-side fault protection in dual-homing scenarios
2.1.2.6.5 EVPN VPLS over SRv6 BE

EVPN VPLS uses the EVPN E-LAN model to carry MP2MP VPLS services. EVPN
VPLS over SRv6 BE builds on this technology and uses SRv6 BE paths over public
networks to carry EVPN E-LAN services. The implementation of EVPN VPLS over
SRv6 BE involves establishing SRv6 BE paths, advertising EVPN routes, and
forwarding data.
MAC Address Learning in an EVPN VPLS over SRv6 BE Scenario

Figure 2-41 shows how MAC addresses are learned in an EVPN VPLS over SRv6 BE
scenario. Each PE is configured with EVI 1, RT 100:1, and BD 1, and connected to a
CE through an AC interface that belongs to VLAN 10.

(2020-10-09)
Figure 2-41 MAC address learning in an EVPN VPLS over SRv6 BE scenario
The process is described as follows:

1. CE1 sends an ARP Request message to ask for the MAC address of CE3. In this
message, the source MAC address is MAC1.
2. PE1 receives the ARP Request message through the AC interface connecting
to CE1 and learns the MAC address of CE1 (MAC1) of CE1. PE1 then
generates a MAC advertisement route carrying the MAC address of CE1 and
floods the route to PE2 and PE3.
3. PE2 and PE3 each receive the broadcast ARP Request message and flood
them to CE2 and CE3, respectively.
4. PE2 and PE3 learn CE1's MAC address MAC1 from their BGP EVPN peer PE1.
They use the VPN SID as the next hop for IPv6 route recursion, and install the
MAC1 entry in their local MAC address tables.
5. PE3 receives an ARP Reply message from CE3 and learns CE3's MAC address
(MAC3) through the AC interface. PE3 then generates a MAC advertisement
route carrying MAC3 and advertises the route to PE1. CE1 then learns CE3's
MAC address from PE1.
Unicast Traffic Forwarding

Figure 2-42 shows how unicast data is forwarded in an EVPN VPLS over SRv6 BE
scenario.

(2020-10-09)
Figure 2-42 Unicast data forwarding in an EVPN VPLS over SRv6 BE scenario

1. CE1 sends a common Layer 2 packet to PE1. In the packet, the destination
MAC address is CE3's MAC address MAC3.
2. After receiving the packet through the BD interface, PE1 searches its MAC
address table and finds the SRv6 VPN SID and the next hop associated with
MAC3. PE1 then encapsulates the packet into an IPv6 packet using the SRv6
SID A3:1::B300 as the destination address.
4. Similarly, the P device finds the route A3:1::/96 based on the longest match
5. PE3 searches My Local SID Table for an End.DT2U SID that matches
A3:1::B300. According to the instruction specified by the SID, PE3 removes the
IPv6 packet header and finds the BD corresponding to the End.DT2U SID. PE3
then forwards the original Layer 2 packet to CE3 based on the destination
MAC address MAC3.
BUM Traffic Forwarding

Figure 2-43 shows a multicast distribution tree (MDT) for BUM traffic in an EVPN
VPLS over SRv6 BE scenario. In this example, PEs exchange inclusive multicast
Ethernet tag routes and advertise PMSI tunnel attributes that carry routable PE
addresses and End.DT2M VPN SIDs. After receiving the inclusive multicast Ethernet
tag routes, each PE establishes an MDT for each EVI.

(2020-10-09)
Figure 2-43 MDT for BUM traffic in an EVPN VPLS over SRv6 BE scenario
Figure 2-44 shows how BUM traffic is forwarded in an EVPN VPLS over SRv6 BE
scenario.

(2020-10-09)
Figure 2-44 BUM traffic forwarding in an EVPN VPLS over SRv6 BE scenario
1. CE1 sends a Layer 2 broadcast packet to PE1. In this packet, the destination
MAC address is a broadcast address.
2. After receiving the packet through the BD interface, PE1 searches its MDT for
leaf node information. After encapsulating the BUM traffic into IPv6 packets
using the SRv6 VPN SIDs of the leaf nodes as the destination addresses, PE1
replicates the packets to all the involved leaf nodes in the MDT. The SRv6 VPN
SID is A2:1::B201 for BUM traffic from CE1 to CE2, and is A3:1::B301 for BUM
traffic from CE1 to CE3.
3. PE1 finds the desired routes based on the longest match rule and forwards
the packets to the P device over the shortest path. The route is A2:1::/96 for
BUM traffic from CE1 to CE2, and is A3:1::/96 for BUM traffic from CE1 to
CE3.
4. The P device finds the desired routes based on the longest match rule and
forwards the packets to PE2 and PE3 over the shortest path.
5. PE2 and PE3 search their My Local SID Table based on SRv6 VPN SIDs and
find End.DT2M SIDs. According to the instruction specified by the End.DT2M
SIDs, PE2 and PE3 remove the IPv6 packet headers and find the BDs

(2020-10-09)
corresponding to the End.DT2M SIDs. PE2 and PE3 then flood the original
Layer 2 packet through their AC interfaces to receivers.
Split Horizon
In a CE multi-homing scenario, after an MDT is established, split horizon needs to
be used to prune BUM traffic to prevent BUM traffic loops. The following example
uses a dual-homing scenario to describe the control and forwarding processes
related to split horizon. On the network shown in Figure 2-45, CE2 is dual-homed
to PE2 and PE3, and CE3 is single-homed to PE3. CE2 sends a copy of BUM traffic.
The process of creating control entries is as follows:
1. PE2 and PE3 to which CE2 is dual-homed both allocate a locally unique
Arg.FE2 to the access interface on CE2 and advertise the Arg.FE2 to other PEs.
For example, PE3 advertises a per-ES Ethernet A-D route carrying the
advertised Arg.FE2 to PE1 and PE2.
2. PE1 does not have the same ES configuration as PE3. Therefore, after
receiving the route, PE1 does not process it.
3. PE2 has the same ES configuration as PE3. Therefore, after receiving the
route, PE2 performs the Or operation on the Arg.FE2 (::C2) advertised by PE3
and the End.DT2M SID (A3:1B::F300) of PE3 to change the destination address
of the local MDT to A3:1B::F3C2.
Figure 2-45 EVPN E-LAN over SRv6 BUM traffic forwarding in a CE dual-homing
scenario

1. When the ingress node PE2 receives BUM traffic, it replicates the traffic to
other PEs along the MDT formed based on EVIs. For the BUM traffic

(2020-10-09)
replicated to PE1, the destination address is the End.DT2M SID of PE1. For the
BUM traffic replicated to PE3, the destination address is A3:1B::F3C2, which is
obtained after the Or operation is performed on End.DT2M SID and Arg.FE2.
2. After receiving BUM traffic from the network side, PE1 performs operations
corresponding to the End.DT2M SID.
3. Before receiving BUM traffic destined for A3:1B::F3C2, PE3 generates a
flooding prune table and uses Arg.FE2 as the index to query the outbound AC
interface.
After receiving the BUM traffic, PE3 searches the flood prune table based on
the last eight bits (that is, the length of the configured Arg.FE2) of the
destination address to determine the pruning interface. Finally, PE3 replicates
BUM traffic to all AC interfaces except the AC interface bound to Arg.FE2,
preventing BUM traffic loops.
2.1.2.6.6 Public IP over SRv6 BE
When users access the Internet, if packets are forwarded based on IP, core devices
between the users and the Internet are forced to learn a large number of Internet
routes. This puts huge strain on the core devices and negatively impacts their
performance. A solution is to configure public BGP route recursion to SRv6 BE on
the user access device. This enables packets to be forwarded over SRv6 BE when
users access the Internet, preventing problems induced by insufficient
performance, heavy load, and service processing on core devices.
Public IPv4 over SRv6 BE

To implement public BGP IPv4 route recursion to SRv6 BE, perform the following
operations. The network shown in Figure 2-46 is used as an example.
● Deploy an IGP and SRv6 on DeviceB, DeviceC, and DeviceD to set up an SRv6
BE path.
● Establish a BGP IPv6 peer relationship between DeviceB and DeviceD for them
to learn the SRv6 SID carried in the peer IPv4 route.
● Configure BGP service route recursion to SRv6 BE on DeviceB.
how DeviceE-to-DeviceA route advertisement and DeviceA-to-DeviceE data
forwarding are implemented to achieve public BGP IPv4 route recursion to SRv6
BE.
1. After a locator is configured on DeviceD, DeviceD generates an End SID and
advertises it to DeviceB through the IGP.
2. DeviceD advertises the locator route corresponding to the SRv6 SID to
DeviceB through the IGP. DeviceB then installs the route in its own IPv6
routing table.
3. An End.DT4 SID is configured for the IPv4 public network instance within the
locator range on DeviceD. DeviceD then generates a local SID entry.
4. After receiving the IPv4 route advertised by DeviceE, DeviceD advertises the
route to DeviceB through BGP. The route carries the End.DT4 SID of the IPv4
public network instance.

(2020-10-09)
5. After receiving the route advertised by DeviceD, DeviceB advertises it to

DeviceA.
Figure 2-46 Public BGP IPv4 route recursion to SRv6 BE

1. DeviceA sends a common IPv4 packet to DeviceB.
2. After receiving the IPv4 packet, DeviceB searches the routing table of the
public network instance for a prefix entry that matches the destination IPv4
address of the packet. After finding associated End.DT4 SID and next hop
information, DeviceB encapsulates the packet into an IPv6 packet using the
End.DT4 SID A2:1::B100 as the destination address.
3. DeviceB finds the route A2:1::/64 based on the longest match rule and
forwards the packet to DeviceC over the shortest path.
4. Likewise, DeviceC finds the route A2:1::/64 based on the longest match rule
and forwards the packet to DeviceD over the shortest path.
5. DeviceD searches My Local SID Table for an End.DT4 SID that matches
A2:1::B100. According to the instruction specified by the SID, DeviceD removes
the IPv6 packet header and searches the IPv4 routing table of the public
network instance based on the End.DT4 SID for packet forwarding. At this
time, the packet is restored to a common IPv4 packet.
Public IPv6 over SRv6 BE

To implement public BGP IPv6 route recursion to SRv6 BE, perform the following
operations. The network shown in Figure 2-47 is used as an example.
● Deploy an IGP and SRv6 on DeviceB, DeviceC, and DeviceD to set up an SRv6
BE path.

(2020-10-09)
● Establish a BGP IPv6 peer relationship between DeviceB and DeviceD for them
to learn the SRv6 SID carried in the peer IPv6 route.
● Configure BGP route recursion to SRv6 BE on DeviceB.
how DeviceE-to-DeviceA route advertisement and DeviceA-to-DeviceE data
forwarding are implemented to achieve public BGP IPv6 route recursion to SRv6
BE.
1. After a locator is configured on DeviceD, DeviceD generates an End SID and
advertises it to DeviceB through the IGP.
2. DeviceD advertises the locator route corresponding to the SRv6 SID to
DeviceB through the IGP. DeviceB then installs the route in its own IPv6
routing table.
3. An End.DT6 SID is configured for the IPv6 public network instance within the
locator range on DeviceD. DeviceD then generates a local SID entry.
4. After receiving the IPv6 route advertised by DeviceE, DeviceD advertises the
route to DeviceB through BGP. The route carries the End.DT6 SID of the IPv6
public network instance.
5. After receiving the route advertised by DeviceD, DeviceB advertises it to
DeviceA.
Figure 2-47 Public BGP IPv6 route recursion to SRv6 BE

1. DeviceA sends a common IPv6 packet to DeviceB.
2. After receiving the IPv6 packet, DeviceB searches the routing table of the
public network instance for a prefix entry that matches the destination IPv6

(2020-10-09)
address of the packet. After finding associated End.DT6 SID and next hop
information, DeviceB encapsulates the packet into an IPv6 packet using the
End.DT6 SID A2:1::D100 as the destination address.
3. DeviceB finds the route A2:1::/64 based on the longest match rule and
forwards the packet to DeviceC over the shortest path.
4. Likewise, DeviceC finds the route A2:1::/64 based on the longest match rule
and forwards the packet to DeviceD over the shortest path.
5. DeviceD searches My Local SID Table for an End.DT6 SID that matches
A2:1::D100. According to the instruction specified by the SID, DeviceD removes
the IPv6 packet header and searches the IPv6 routing table of the public
network instance based on the End.DT6 SID for packet forwarding. At this
time, the packet is restored to a common IPv6 packet.
2.1.2.7 SRv6 TE Policy
Definition
SRv6 TE Policy is a tunneling technology developed based on SRv6. An SRv6 TE
Policy is a set of candidate paths consisting of one or more segment lists, that is,
segment ID (SID) lists. Each SID list identifies an end-to-end path from the source
to the destination, instructing a device to forward traffic through the path rather
than the shortest path computed using an IGP. The header of a packet steered
into an SRv6 TE Policy is augmented with an ordered list of segments associated
with that SRv6 TE Policy, so that other devices on the network can execute the
instructions encapsulated into the list.
An SRv6 TE Policy consists of the following parts:
● Headend: node where an SRv6 TE Policy originates.
● Color: extended community attribute of an SRv6 TE Policy. A BGP route can
recurse to an SRv6 TE Policy if they have the same color attribute.
● Endpoint: destination address of an SRv6 TE Policy.
Color and endpoint information is added to an SRv6 TE Policy through
configuration. The headend steers traffic into an SRv6 TE Policy whose color and
endpoint attributes match the color value and next-hop address in the associated
route, respectively. The color attribute defines an application-level network Service
Level Agreement (SLA) policy. This allows network paths to be planned based on
specific SLA requirements for services, realizing service value in a refined manner,
and helping build new business models.
SRv6 TE Policy Model

The SRv6 TE Policy model is the same as the SR-MPLS TE Policy model, as shown
in Figure 2-48. One SRv6 TE Policy may contain multiple candidate paths with the
preference attribute. The valid candidate path with the highest preference
functions as the primary path of the SRv6 TE Policy.
A candidate path can contain multiple segment lists, each of which carries a
Weight attribute. Each segment list is an explicit SID stack that instructs a network
device to forward packets, and multiple segment lists can work in load balancing
mode.

(2020-10-09)
Figure 2-48 SRv6 TE Policy model
2.1.2.7.1 SRv6 TE Policy Creation
An SRv6 TE Policy can be manually configured on a forwarder through CLI or

NETCONF. Alternatively, it can be delivered to a forwarder after being dynamically
generated by a protocol, such as BGP, on a controller. The dynamic mode
facilitates network deployment. If the same SRv6 TE Policies generated in both
modes exist, the forwarder selects an SRv6 TE Policy based on the same rules
adopted for SR-MPLS TE Policy selection. For details about SR-MPLS TE Policy
selection rules, see 1.1.2.10.1 SR-MPLS TE Policy Creation.
An SRv6 TE Policy can be created using End SIDs, End.X SIDs, anycast SIDs, binding
SIDs, or a combination of them.
Figure 2-49 shows an example of manually configuring an SRv6 TE Policy through
CLI or NETCONF. For a manually configured SRv6 TE Policy, information, such as
the endpoint and color attributes, the preference values of candidate paths, and
segment lists, must be configured. In addition, the preference values of candidate
paths in the same SRv6 TE Policy cannot be the same. The first-hop SID of a
segment list can be an End SID or End.X SID, but cannot be any binding SID.

(2020-10-09)
Figure 2-49 Manual SRv6 TE Policy configuration
Figure 2-50 shows the process in which a controller dynamically generates and
delivers an SRv6 TE Policy to a forwarder. The process is as follows:
1. The controller collects information, such as network topology and SID
2. The controller and headend forwarder establish a BGP peer relationship in the
BGP IPv6 SR-Policy address family.
3. The controller computes an SRv6 TE Policy and delivers it to the headend
generates SRv6 TE Policy entries.

(2020-10-09)
Figure 2-50 SRv6 TE Policy delivery by a controller
If an SRv6 TE Policy is manually configured, you can specify a binding SID in the
static locator range for the SRv6 TE Policy. If a controller delivers an SRv6 TE Policy
to a forwarder, the SRv6 TE Policy itself does not carry any binding SID when
being delivered. After receiving the SRv6 TE Policy, the forwarder randomly
allocates a binding SID in the dynamic locator range to the SRv6 TE Policy and
then reports the policy's status information carrying the binding SID to the
controller through BGP-LS. In so doing, the controller can obtain the binding SID
of the SRv6 TE Policy and use the binding SID to orchestrate an SRv6 path.
2.1.2.7.2 Traffic Steering into an SRv6 TE Policy
SRv6 TE Policies support traffic steering based on the specified color value and the
DSCP value of packets. Route coloring is required before you perform traffic
steering.
In route coloring, the Color Extended Community attribute is added to a route

through a route-policy. This enables the route to recurse to an SRv6 TE Policy
based on the color value and next-hop address in the route.

policy.

(2020-10-09)
Color-based Traffic Steering

SRv6 TE Policies support color-based traffic steering where traffic is steered into
an SRv6 TE Policy through route recursion based on the color value and
destination address in the route. Figure 2-51 shows the color-based traffic
steering process.
Figure 2-51 Color-based traffic steering
The process of color-based traffic steering is as follows:
1. Use a controller to deliver an SRv6 TE Policy to headend device A. The color

value for the SRv6 TE Policy is 123 and the endpoint is 2001:db8::1 (device B).
2. Configure a BGP or VPN export policy on device B (or a BGP or VPN import
policy on device A), and set the color value to 123 for route prefix
2001:db8::/96 and the next hop to 2001:db8::1 (device B). Then, configure
device B to send routing information to device A through a BGP peer
relationship.
3. Configure a tunnel policy on device A. After receiving the BGP route
2001:db8::/96, device A recurses the route to the SRv6 TE Policy based on the
color value 123 and the next hop 2001:db8::1. Before forwarding a packet
destined for 2001:db8::/96, device A adds a specific SID list <C, E, G, B> to the
packet.
DSCP-based Traffic Steering

In DSCP-based traffic steering, the headend recurses traffic based on the next hop
of the corresponding route in compliance with the configured tunnel policy. If

(2020-10-09)
traffic recursion to an SRv6 TE Policy group is configured, the headend matches

the traffic with an SRv6 mapping policy that has the same color value as the
route. If such a mapping policy exists, the headend dynamically generates an SRv6
TE Policy group that contains multiple SRv6 TE Policies with the same endpoint
but different color values.
If such a mapping policy does not exist, the headend does not create an SRv6 TE
Policy group.
If multiple flows with the same color value but different next-hop addresses need
to recurse to SRv6 TE Policy groups, multiple dynamic SRv6 TE Policy groups with
different endpoints are created based on the configuration of a matching SRv6
mapping policy.
Figure 2-52 shows the DSCP-based traffic steering process.
Figure 2-52 DSCP-based traffic steering
The process of DSCP-based traffic steering is as follows:

1. Two SRv6 TE Policies are delivered to headend device A through a controller.
The color values for the two SRv6 TE Policies are 123 and 124, respectively;
both of their endpoints are 2001:db8::1 (device B).
2. Device B sends the BGP route 2001:db8::/96 to device A through a BGP peer
relationship.

(2020-10-09)
3. After a tunnel selection policy and an SRv6 mapping policy are configured on
device A, the device dynamically generates an SRv6 TE Policy group based on
the configurations.
4. On device A, services are associated with the SRv6 TE Policy group based on
the next hop of the involved service route, and carry DSCP information when
being forwarded. Based on the SRv6 mapping policy configuration, the
services are first associated with a specific color and then a specific SRv6 TE
Policy in the SRv6 TE Policy group, thereby implementing DSCP-based traffic
steering.
2.1.2.7.3 SRv6 TE Policy-based Data Forwarding
This section uses L3VPNv4 over SRv6 TE Policy as an example to describe how
data is forwarded over an SRv6 TE Policy. Figure 2-53 shows the data forwarding
process.
1. A controller delivers an SRv6 TE Policy to headend device PE1.
2. Endpoint device PE2 advertises the BGP VPNv4 route 10.2.2.2/32 to PE1. The
next-hop address in the BGP route is PE2's address 2001:db8::1/128.
3. A tunnel policy is configured on PE1. After receiving the BGP route, PE1
recurses the route to the SRv6 TE Policy based on the color value and next
hop of the route. The SID list encapsulated into the SRv6 TE Policy is <2::1,
3::1, 4::1>, which can also be expressed as (4::1, 3::1, 2::1) in data forwarding
scenarios.
4. After receiving a common unicast packet from CE1, PE1 searches the routing
table of the corresponding VPN instance and finds that the outbound
interface of the route is an SRv6 TE Policy interface. Then, PE1 inserts an SRH
carrying the SID list of the SRv6 TE Policy and encapsulates an IPv6 header
into the packet. After completing the operations, PE1 forwards the packet to
P1.
5. Transit nodes P1 and P2 forward the packet hop by hop based on the SRH
information.
6. After the packet arrives at PE2, PE2 searches its "My Local SID Table" for a
matching End SID based on the IPv6 destination address (DA) 4::1 in the
packet. According to the instruction bound to the SID, PE2 decreases the SL
field value of the packet by 1 and updates the IPv6 DA to the VPN SID 4::100.
Based on the VPN SID 4::100, PE2 searches its "My Local SID Table" for a
matching End.DT4 SID. According to the instruction bound to the SID, PE2
decapsulates the packet, pops the SRH and IPv6 header, searches the routing
table of the VPN instance corresponding to the VPN SID 4::100 based on the
destination address in the packet payload, and forwards the packet to CE2.

(2020-10-09)
Figure 2-53 SRv6 TE Policy-based data forwarding
2.1.2.7.4 SBFD for SRv6 TE Policy
Bidirectional forwarding detection (BFD) techniques are mature. However, if a

large number of BFD sessions are configured to detect links, the negotiation time
of the existing BFD state machine is prolonged. In this situation, seamless
bidirectional forwarding detection (SBFD) can be configured to detect SRv6 TE
policies. With a simplified BFD state machine, SBFD shortens the negotiation time
and improves network-wide flexibility.
SBFD Implementation
Figure 2-54 shows how SBFD is implemented through the communication
between an initiator and a reflector. Before link detection, the initiator and
reflector exchange SBFD control packets to advertise information, such as the
SBFD discriminator. In link detection, the initiator proactively sends an SBFD echo
packet, and the reflector loops this packet back. The initiator then determines the
local status based on the looped packet.
● The initiator is responsible for detection and runs an SBFD state machine and
a detection mechanism. The state machine only has up and down states, so
the initiator can only send packets in the up or down state and only receive
packets in the up or admin down state.
The initiator first sends an SBFD packet with an initial down state and a
destination port number of 7784 to the reflector.
● The reflector does not run any SBFD state machine or detection mechanism.
Therefore, it does not proactively send any SBFD echo packet, but constructs
an SBFD packet to be looped back instead.

(2020-10-09)
After receiving the SBFD packet sent by the initiator, the reflector checks
whether the SBFD discriminator carried by the packet matches the locally
configured global SBFD discriminator. If they do not match, the packet is
discarded. If they match and the reflector is in the working state, the reflector
constructs an SBFD packet to be looped back. If they match and the reflector
is not in the working state, the reflector sets the packet state to admin down.
Figure 2-54 SBFD Implementation
SBFD State Machine of the Initiator

The initiator's SBFD state machine has only two alternating states: up and down.
Figure 2-55 shows how the SBFD state machine works.
Figure 2-55 SBFD state machine of the initiator
● Initial state: Before an SBFD packet is sent from the initiator to the reflector,
the initial state on the initiator is down.
● State transition: After receiving a looped packet that is in the up state, the
initiator sets the local state to up. If the initiator receives a looped packet that
is in the admin down state, it sets the local state to down. However, if the
initiator does not receive any looped packet before the timer expires, it also
sets the local state to down.
● State retention: If the initiator is in the up state and receives a looped packet
that is also in the up state, the initiator remains in the local up state. If the
initiator is in the down state and receives a looped packet that is in the admin
down state or receives no packet after the timer expires, the initiator remains
in the local down state.

(2020-10-09)
Implementation of SBFD for SRv6 TE Policy

Unlike RSVP-TE, which exchanges Hello messages between forwarders to maintain
tunnel status, an SRv6 TE Policy cannot maintain its status in the same way. An
SRv6 TE Policy is established immediately after the headend delivers a SID stack. It
will not go down unless it is withdrawn. Therefore, seamless bidirectional
forwarding detection (SBFD) for SRv6 TE Policy is introduced for SRv6 TE Policy
fault detection. SBFD for SRv6 TE Policy is an end-to-end fast detection
mechanism that quickly detects faults on the link through which an SRv6 TE Policy
passes.
Figure 2-56 shows the SBFD for SRv6 TE Policy detection process.
Figure 2-56 SBFD for SRv6 TE Policy
The SBFD for SRv6 TE Policy detection process is as follows:

1. After SBFD for SRv6 TE Policy is enabled on the headend, the mapping
between the destination IPv6 address and discriminator is configured on the
headend. If multiple segment lists exist in the SRv6 TE Policy, the remote
discriminators of the corresponding SBFD sessions are the same.
2. The headend sends an SBFD packet encapsulated with a SID stack
corresponding to the SRv6 TE Policy.
3. After the endpoint device receives the SBFD packet, it returns an SBFD reply
through the shortest IPv6 link.
4. If the headend receives the SBFD reply, it considers that the corresponding
segment list in the SRv6 TE Policy is normal. Otherwise, it considers that the
segment list is faulty. If all the segment lists referenced by a candidate path
are faulty, SBFD triggers a candidate path switchover.
SBFD return packets are forwarded over IPv6. If the primary paths of multiple
SRv6 TE Policies between two nodes differ due to different path constraints but
SBFD return packets are transmitted over the same path, a fault in the return path
may cause all involved SBFD sessions to go down. As a result, all the SRv6 TE

(2020-10-09)
Policies between the two nodes go down. The SBFD sessions of multiple segment
lists in the same SRv6 TE Policy also have this problem.
By default, if HSB protection is not enabled for an SRv6 TE Policy, SBFD detects all
the segment lists only in the candidate path with the highest preference in the
SRv6 TE Policy. With HSB protection enabled, SBFD can detect all the segment lists
referenced by candidate paths with the highest and second highest priorities in the
SRv6 TE Policy. If all the segment lists referenced by the candidate path with the
highest preference are faulty, a switchover to the HSB path is triggered.
2.1.2.7.5 SRv6 TE Policy Failover
MBB and Delayed Deletion for SRv6 TE Policies

SRv6 TE Policies support make-before-break (MBB). enabling a forwarder to
establish a new segment list before deleting the original. During the establishment
process, traffic continues to be forwarded using the original segment list, which is
deleted only after a specified delay elapses. This prevents packet loss during a
segment list switchover.
This delayed deletion mechanism takes effect only for up segment lists (including
backup segment lists) in an SRv6 TE Policy.
SRv6 TE Policy Failover

On the network shown in Figure 2-57, an SRv6 TE Policy is deployed between PE1
and PE3 and between PE2 and PE4. Figure 2-57 lists possible failure points and
corresponding protection schemes.
Figure 2-57 SRv6 TE Policy-related fault scenarios

(2020-10-09)
Table 2-16 Protection schemes for possible failure points

Failu Protection Scheme
re
Point
1 or When the BGP peer relationships between the controller and all
8 forwarders go down, the following protection measures can be taken:
1. Configure BGP GR between the controller and forwarders, and
continue to use the specified SRv6 TE Policy for packet forwarding
during the GR period until the BGP peer relationships go up again.
2. Deploy controllers in redundancy mode to protect the active
controller using the standby one. If the BGP peer relationships
between the active controller and forwarders are not restored when
the GR period expires, the forwarders switch the BGP peer
relationships to the standby controller.
If none of the preceding protection measures is taken or both protection
measures do not work, the SRv6 TE Policy is deleted. As a result, VPNv4
route recursion to the SRv6 TE Policy fails, causing the route to recurse
again. If an SRv6 BE path exists in this scenario, the VPNv4 route will
recurse to the path. In this hard convergence scenario, packet loss
occurs when traffic is switched to the SRv6 BE path.
2 or An access-side equal-cost multi-path (ECMP) switchover is performed

3 on CE1 to switch traffic to PE2 for forwarding.
4, 5, Assume that a BGP peer relationship is established between PE1 and

or 6 PE3 using loopback addresses. If point 4, 5, or 6 is faulty, the loopback
addresses are still reachable through P2, keeping the BGP peer
relationship uninterrupted and the route sent from PE3 to PE1
undeleted. In this case, a fast reroute (FRR) switchover is performed
within the SRv6 TE Policy.
7 1. If PE3 is faulty, PE1 continuously sends traffic to P1 before detecting

the fault. SRv6 egress protection can be configured on P1, enabling it to
push an End.M SID into packets and forward them to PE4.
2. After PE1 detects the PE3 fault, the BGP peer relationship established
between PE1 and PE3 is interrupted. The BGP module on PE1 deletes
the BGP route received from PE3, selects a route advertised through
PE4, and switches traffic to PE4.
Egress Protection
Services that recurse to an SRv6 TE Policy must be strictly forwarded through the
path defined using the segment lists in the SRv6 TE Policy. Considering that the
egress of the SRv6 TE Policy is also fixed, if a single point of failure occurs on the
egress, service forwarding may fail. To prevent this problem, configure egress
protection for the SRv6 TE Policy.
Figure 2-58 shows a typical SRv6 egress protection scenario where an SRv6 TE
Policy is deployed between PE3 and PE1. PE1 is the egress of the SRv6 TE Policy,
and PE2 provides protection for PE1 to enhance reliability.

(2020-10-09)
Figure 2-58 SRv6 egress protection
SRv6 egress protection is implemented as follows:

1. Locators A1::/64 and A2::/64 are configured on PE1 and PE2, respectively.
2. An IPv6 VPNv4 peer relationship is established between PE3 and PE1 as well
as between PE2 and PE1. A VPN instance VPN1 and SRv6 VPN SIDs are
configured on both PE1 and PE2. In addition, IPv4 prefix SID advertisement is
enabled on the two PEs.
3. After receiving the VPN route advertised by CE2, PE1 encapsulates the route
as a VPNv4 route and sends it to PE3. The route carries the VPN SID, RT, RD,
and color information.
4. An End.M SID is configured on PE2 to protect PE1, generating an <End.M SID,
Locator> mapping entry (for example, <A2::100, A1::>).
5. PE2 propagates the End.M SID through an IGP and generates a local SID
entry. After receiving the End.M SID, P1 generates an FRR entry with the next-
hop address being PE2 and the action being Push End.M SID. In addition, P1
generates a low-priority route that cannot be recursed.
6. BGP subscribes to End.M SID configuration. After receiving the VPNv4 route
from PE1, PE2 leaks the route into the routing table of VPN1 based on the RT,
and matches the VPN SID carried by the route against the local <End.M SID,
Locator> table. If a matching locator is found according to the longest match
rule, PE2 generates a <Remote SRv6 VPN SID, VPN> entry.

(2020-10-09)
1. In normal situations, PE3 forwards traffic to the private network through the
PE3-P1-PE1-CE2 path. If PE1 fails, P1 detects that the next hop PE1 is
unreachable and switches traffic to the FRR path.
2. P1 pushes the End.M SID into the packet header and forwards the packet to
PE2. After parsing the received packet, PE2 obtains the End.M SID, queries the
local SID table, and finds that the instruction specified by the End.M SID is to
query the remote SRv6 VPN SID table. As instructed, PE2 queries the remote
SRv6 VPN SID table based on the VPN SID in the packet and finds the
corresponding VPN instance. PE2 then searches the VPN routing table and
forwards the packet to CE2.
If PE1 fails, the peer relationship between PE2 and PE1 is also interrupted. As a
result, PE2 deletes the VPN route received from PE1, causing the <Remote SRv6
VPN SID, VPN> entry to be deleted on PE2. To prevent this, enable GR on PE2 and
PE1 to maintain routes or enable delayed deletion (enabled by default currently)
for the <Remote SRv6 VPN SID, VPN> entry on PE2.
Headend-based Fault Detection

An SRv6 TE Policy selects a forwarding path from the candidate paths that are
either delivered by a controller or manually configured. Currently, BFD detection is
not allowed for SRv6 TE Policies in some scenarios. As such, if the segment list of
a candidate path in an SRv6 TE Policy fails, the headend cannot quickly detect the
fault. The SRv6 TE Policy can be updated only after the controller detects a
topology change and re-converges the topology.
If the controller or the connection between the controller and headend fails, the
SRv6 TE Policy cannot immediately be aware of the fault and perform a traffic
switchover. This may cause traffic loss. To speed up traffic switching in the case of
a fault, headend-based fault detection is introduced. With this function, if a
segment list fails, the headend sets the segment list to down, triggering path or
service switching in the SRv6 TE Policy.
To detect faults, a headend must be able to collect network topology information.

It determines the validity of a segment list based on whether the SRv6 SIDs in the
segment list exist in the topology and whether routes are reachable.
If all SRv6 SIDs in the segment list exist in the topology and routes are reachable,
the headend sets the segment list to up. If an SRv6 SID in the segment list does
not exist in the topology or routes are unreachable, the headend sets the segment
list to down and deletes the segment list.
When a segment list fails, the headend performs operations according to the
following rules:
1. If the preferred candidate path of an SRv6 TE Policy has multiple segment

lists for load balancing and one of them fails, the segment list is deleted and
removed from the load balancing list.
2. If all segment lists in the preferred candidate path of an SRv6 TE Policy fail
and the SRv6 TE Policy has a backup candidate path, traffic is switched to the
backup.
3. If both the primary and backup candidate paths of an SRv6 TE Policy fail, the
headend is notified of the down state of the SRv6 TE Policy, triggering a
service switchover.

(2020-10-09)
Because the SRv6 SID status and route status need to be detected on the headend,
the headend must learn all SRv6 SIDs and routes in an IGP domain. If a segment
list contains binding SIDs, path verification fails because the binding SIDs are not
flooded in the IGP topology. To prevent this issue, do not configure headend-based
fault detection in binding SID scenarios.
SRv6 TE Policy Multi-Level Protection

Technologies including SBFD for SRv6 TE Policy and headend-based fault detection
can be used to detect segment list reliability. If a segment list fails, an SRv6 TE
Policy failover is triggered.
As shown in Figure 2-59 and Figure 2-60, the headend and egress of SRv6 TE
Policy 1 is PE1 and PE2, respectively. The headend and egress of SRv6 TE Policy 2
is PE1 and PE3, respectively. SRv6 TE Policy 1 and SRv6 TE Policy 2 can form VPN
FRR relationship. SRv6 TE Policy 1 provides the primary and backup paths for hot-
standby protection. Segment list 1 specifies the End SIDs to P1, P2, and PE2. This
list can use all SRv6 protection technologies, such as TI-LFA.
Figure 2-59 SRv6 TE Policy failover

(2020-10-09)
Figure 2-60 SRv6 TE Policy SID stack information
● If the link between P1 and P2 fails, TI-LFA local protection takes effect on
both P1 and P2. If SBFD for segment list 1 on PE1 detects the fault before
traffic is restored using TI-LFA, SBFD sets segment list 1 to down and instructs
SRv6 TE Policy 1 to switch traffic to the backup path.
● If P2 fails and no local protection is available, SRv6 TE Policy 1 switches traffic
to the backup path (segment list 2) only after SBFD detects the fault and sets
segment list 1 to down.
● If PE2 fails, all candidate paths of SRv6 TE Policy 1 are unavailable. SBFD can
detect the fault. After fault detection, SBFD sets SRv6 TE Policy 1 to down and
triggers VPN FRR to switch traffic to SRv6 TE Policy 2. Egress protection can
also be used to detect the PE2 fault.
2.1.2.7.6 TTL Processing by an SRv6 TE Policy
In scenarios where public IP routes are recursed to SRv6 TE Policies, TTLs are
processed in either of the following modes:
● Uniform mode: The headend reduces the TTL value in an inner packet by 1
and maps it to the IPv6 TTL field. The TTL is then processed on the IPv6
network in a standard way. The endpoint reduces the IPv6 TTL value by 1 and
maps it to the TTL field in the inner packet.
● Pipe mode: The TTL value in an inner packet is reduced by 1 only on the
headend and endpoint, with the entire SRv6 TE Policy being treated as one
hop.
2.1.2.8 SRv6 TI-LFA FRR
Conventional loop-free alternate (LFA) requires that at least one neighbor be a

loop-free next hop to a destination. Remote LFA (RLFA) requires that there be at
least one node that connects to the source and destination nodes along links
without passing through any faulty node. Unlike LFA or RLFA, Topology-

(2020-10-09)
Independent Loop-free Alternate (TI-LFA) FRR uses an explicit path to represent a

backup path, which poses no topology constraints and provides more reliable FRR.
SRv6 TI-LFA FRR applies to both SRv6 BE and SRv6 TE Policy scenarios. In normal
cases, SRv6 BE packets do not need to carry SRH information. However, in TI-LFA
FRR scenarios, to encapsulate repair list information, SRv6 BE packets are required
to carry SRH information.
SRv6 TI-LFA
In Figure 2-61, if the P space and Q space do not intersect, RLFA requirements fail
to be fulfilled, and RLFA cannot compute a backup path. If a fault occurs on the
link between DeviceB and DeviceE, DeviceB forwards data packets to DeviceC.
DeviceC is not a Q node and has no FRR entry directly to the destination IP
address of DeviceF. In this situation, DeviceC has to recompute a path. The cost of
the link between DeviceC and DeviceD is 1000. DeviceC considers that the optimal
path to DeviceF passes through DeviceB. Therefore, DeviceC transmits the packet
back to DeviceB, leading to a loop and resulting in a forwarding failure.
Figure 2-61 RLFA
TI-LFA FRR provides link and node protection for SRv6. Figure 2-62 shows how
SRv6 TI-LFA FRR is implemented.
If a fault occurs on the link between DeviceB and DeviceE, DeviceB directly
enables TI-LFA FRR backup entries and adds new path information (End.X SIDs of
DeviceC and DeviceD) to the packets to ensure that the data packets can be
forwarded along the backup path.

(2020-10-09)
Figure 2-62 TI-LFA
2.1.2.9 SRv6 Midpoint Protection
TI-LFA FRR Failure Scenario

In SRv6 TE Policy scenarios, the forwarding path of data packets usually needs to
be constrained by specifying the nodes or links they will traverse. For example, on
the network shown in Figure 2-63, node A is required to send a packet to node F
over a forwarding path that passes through node D. Because the backup path also
needs to pass through node D even if this node fails, TI-LFA FRR cannot provide
protection in this case.

(2020-10-09)
Figure 2-63 TI-LFA FRR protection failure
SRv6 Midpoint Protection

To resolve the TI-LFA FRR protection failure caused by strict node constraints in an
SRv6 TE Policy scenario, a proxy forwarding node (a node upstream to the faulty
midpoint) takes over from the faulty midpoint to complete the forwarding.
Specifically, when the proxy forwarding node detects that the next-hop interface
of the packet is faulty, the next-hop address is the destination address of the
packet, and the SL value is greater than 0, the proxy forwarding node replaces the
midpoint to perform the End behavior. The behavior involves decrementing the SL
value by 1, copying the next SID to the DA field in the outer IPv6 header, and then
forwarding the packet according to the instruction bound to the SID. In this way,
the faulty midpoint is bypassed, achieving SRv6 midpoint protection.
As shown in Figure 2-64, SRv6 midpoint protection is implemented as follows:
1. Node A forwards a packet to destination node F, with an SRv6 SRH instructing
the packet to pass through the midpoint D.
2. If node D is faulty, node B detects that the next-hop interface of the received
packet is faulty. It also learns that the next-hop address is the current
destination address 4:: of the packet, and the SL value is greater than 0. In
this case, node B functions as a proxy forwarding node, decrementing the SL
value by 1 and copying the next SID 6:: to the DA field in the outer IPv6
header. Because the SL value is now 0, node B can remove the SRH and then
search the corresponding table to forward the packet based on the
destination address 6::.
3. The primary next hop to the destination address 6:: is still node E. Because the
SL value is 0 and node B is not the penultimate hop of the destination
address, node B can no longer perform proxy forwarding. Instead, it switches
the packet to a backup path according to the normal TI-LFA process, with the
repair segment list on the backup path as <3::5>. As such, node B executes the
H.Insert behavior, which involves encapsulating the segment list 3::5 into the

(2020-10-09)
packet, adding an SRH, and then forwarding the packet to node F over the
backup path.
4. After node A detects that node D is faulty and that IGP convergence is
completed, it deletes the forwarding entry towards node D. Consequently,
when node A searches the corresponding table based on 4::, it cannot find any
matching route. In this case, node A needs to function as a proxy forwarding
node to perform proxy forwarding, so it decrements the SL value by 1, copies
the next SID 6:: to the outer IPv6 header, searches the corresponding table
based on the destination address 6::, and then forwards the packet to node B
accordingly. If node B has already completed convergence, it forwards the
packet to node F over the post-convergence shortest path; otherwise, it
forwards the packet to node F over the backup path according to the TI-LFA
process. In this way, the faulty node D is bypassed.
Figure 2-64 SRv6 midpoint protection
NOTE
SRv6 midpoint protection uses the next SID to guide packet forwarding over the
bypass path, thereby bypassing the failure point. This mechanism is similar to MPLS TE
FRR that enables traffic to bypass the failure point using a bypass LSP. Therefore, SRv6
midpoint protection is also called SRv6 TE FRR.
Differences Between TI-LFA FRR and Midpoint Protection

In essence, the difference between SRv6 TI-LFA FRR and midpoint protection lies
in whether the next-hop node is a transit node or a midpoint.
On the network shown in Figure 2-65, node A sends a packet carrying the
segment list <E, F>. Because SRv6 TI-LFA FRR performs backup path computation
based on the destination address of the packet, the backup path computed by
SRv6 TI-LFA passes through node E. If node E is faulty, SRv6 TI-LFA FRR cannot
provide protection. In contrast, in an SRv6 midpoint protection scenario, a backup
path is computed based on the next SID to be processed. This ensures that the

(2020-10-09)
faulty midpoint E is bypassed, thereby implementing SRv6 TE Policy midpoint

protection.
Figure 2-65 Differences between TI-LFA FRR and midpoint protection
2.1.2.10 SRv6 Microloop Avoidance
Because IGP link state databases (LSDBs) are distributed, network nodes running
an IGP may converge at different times. This may in turn result in microloops, a
kind of transient loop that disappears after all the nodes on the forwarding path
have converged. Microloops result in a series of issues, including packet loss, jitter,
and out-of-order packets, and therefore must be avoided.
SR uses a method with minimal impact on the network to effectively avoid
potential loops. Specifically, if a network topology change may cause a loop, SR
allows network nodes to insert loop-free SRv6 segment lists to guide traffic to the
destination address. Normal traffic forwarding is restored only when all the
involved network nodes complete convergence.
SRv6 Local Microloop Avoidance in a Traffic Switchover Scenario

In a traffic switchover scenario, a local microloop is formed when a node adjacent
to the faulty node converges earlier than the other nodes on the network. On the
network shown in Figure 2-66, SRv6 TI-LFA is deployed on all nodes. If node B is
faulty, node A undergoes the following process to perform convergence for the
route to node C:
1. Node A detects the fault and enters the TI-LFA FRR process, during which
node A inserts the SRv6 repair list <5::1> into the packet to direct the packet
to the TI-LFA-computed PQ node, that is, node E. To direct the packet to node
E, node A needs to forward the packet to the next-hop node D first. The SIDs
encapsulated into the packet are <5::1, 3::1>.
2. After performing route convergence, node A searches for the route to node C
and forwards the packet to the next-hop node D through the route. In this
case, the packet does not carry any SRv6 repair list and is directly forwarded
based on the destination address 3::1.

(2020-10-09)
3. If node D has not completed convergence when receiving the packet, its
routing table has node A as the next hop of the route to node C. As a result,
node D forwards the packet back to node A, which in turn causes a microloop
Figure 2-66 SRv6 local microloop in a traffic switchover scenario
According to the preceding convergence process, node A completes convergence,

exits the TI-LFA FRR process, and implements normal forwarding before other
nodes on the network complete convergence, resulting in a microloop. The issue is
that node A converges earlier than the other nodes, so by postponing its
convergence, the microloop can be avoided. As TI-LFA backup paths are loop-free,
the packet can be forwarded along a TI-LFA backup path for a period of time.
Node A can then wait for the other nodes to complete convergence before exiting
the TI-LFA FRR process and performing convergence, thereby avoiding the
microloop.

(2020-10-09)
Figure 2-67 SRv6 local microloop avoidance in a traffic switchover scenario
After microloop avoidance is deployed on the network shown in Figure 2-67, the
convergence process is as follows:
1. After node A detects the fault, it enters the TI-LFA FRR process, encapsulating
the SRv6 repair list <5::1> into the packet and forwarding the packet along
the TI-LFA backup path, with node D as the next hop.
2. Node A starts the timer T1. During T1, node A does not respond to topology
changes, the forwarding table remains unchanged, and the TI-LFA backup
path continues to be used for packet forwarding. Other nodes on the network
converge properly.
3. When T1 expires, other nodes on the network have completed convergence.
Node A can now perform convergence and exit the TI-LFA FRR process to
forward the packet along a post-convergence path.
The preceding solution can protect only a point of local repair (PLR) against
microloops in a traffic switchover scenario. This is because only a PLR can enter
the TI-LFA FRR process and forward packets along a TI-LFA backup path. In
addition, this solution applies only to single point of failure. In a multiple-point
fault scenario, the TI-LFA backup path may also be adversely affected and
therefore cannot be used for packet forwarding.
SRv6 Local Microloop Avoidance in a Traffic Switchback Scenario

In addition to traffic switchover scenarios, microloops may also occur in traffic
switchback scenarios. The following uses the network shown in Figure 2-68 as an
example to describe how a microloop occurs in a traffic switchback scenario. The
process is as follows:
1. Node A sends a packet to destination node F along the path A->B->C->E->F. If

the B-C link fails, node A sends the packet to destination node F along the
post-convergence path A->B->D->E->F.
convergence.

(2020-10-09)
the pre-recovery path, as shown in Figure 2-68.
4. Because node D has completed convergence, it forwards the packet to node B
along the post-recovery path, resulting in a microloop between the two
nodes.
Traffic switchback does not involve the TI-LFA FRR process. Therefore, delayed
convergence cannot be used for microloop avoidance in such scenarios.
Figure 2-68 SRv6 local microloop in a traffic switchback scenario
According to the preceding process, a transient loop occurs when node D

converges earlier than node B during fault recovery. Node D is unable to predict
link up events on the network and so is unable to pre-compute any loop-free path
for such events. To avoid loops that may occur during traffic switchback, node D
needs to be able to converge to a loop-free path.
On the network shown in Figure 2-69, after node D detects that the B-C link goes
up, it re-converges to the D->B->C->E->F path.
In addition, the B-C link up event does not affect the path from node D and node
B, proving that the path is loop-free.

(2020-10-09)
NOTICE
Topology changes triggered by a link up event affect only the post-convergence

forwarding path that passes through the link. As such, if the post-convergence
forwarding path from node D to node B does not pass through the B-C link, it is
not affected by the B-C link up event. Similarly, topology changes triggered by a
link down event affect only the pre-convergence forwarding path that passes
through the link.
A loop-free path from node D to node F can be constructed without specifying the
path from node D to node B. Because the path from node C to node F is not
affected by the B-C link up event, it is definitely loop-free. In this scenario, only
the path from node B to node C is affected. Given this, to compute a loop-free
path from node D to node F, you only need to specify a path from node B to node
C. According to the preceding analysis, a loop-free path from node D to node F
can be formed by inserting only an End.X SID that instructs packet forwarding
from node B to node C into the post-convergence path of node D.
Figure 2-69 SRv6 local microloop avoidance in a traffic switchback scenario
convergence.
2. Node D starts the timer T1. Before T1 expires, node D computes a microloop
avoidance segment list <2::3> for the packet destined for node F.
the pre-recovery path.
4. Node D inserts the microloop avoidance segment list <2::3> into the packet

(2020-10-09)
NOTICE
Although the packet is sent from node B to node D and then back to node B,
no loop occurs because node D has changed the destination address of the
packet to End.X SID 2::3.
5. According to the instruction bound to the End.X SID 2::3, node B forwards the
packet to node C through the outbound interface specified by the End.X SID,
decrements the SL value by 1, and updates the destination address in the IPv6
packet header to 6::.
6. Node C forwards the packet to destination node F along the shortest path.
As previously described, node D inserts the microloop avoidance segment list
<2::3> into the packet, avoiding loops.
When T1 of node D expires, other nodes on the network have completed
path A->B->C->E->F.
SRv6 Remote Microloop Avoidance in a Traffic Switchover Scenario

In a traffic switchover scenario, a remote microloop may also occur between two
nodes on a packet forwarding path if the node close to the point of failure
converges earlier than one farther from the point. The following uses the network
shown in Figure 2-70 as an example to describe how a remote microloop occurs
in a traffic switchover scenario. The process is as follows:
convergence, whereas node B has not converged.
2. Nodes A and B forward the packet to node G along the path used before the
fault occurs.
3. Because node G has completed convergence, it forwards the packet to node B
according to the next hop of the corresponding route, resulting in a microloop

(2020-10-09)
Figure 2-70 SRv6 remote microloop in a traffic switchover scenario
To minimize computation workload, generally, a network node can pre-compute a

loop-free path only when a directly connected link or node fails. That is, no loop-
free path can be pre-computed against any other potential fault on the network.
Given this, the microloop can be avoided only by installing a loop-free path after
node G converges.
As mentioned above, topology changes triggered by a link down event affect only
the pre-convergence forwarding path that passes through the link. If the path
from a node to the destination node does not pass through the faulty link before
convergence, the path is not affected by the link fault. In the topology shown in
Figure 2-70, the path from node G to node D is not affected by the C-E link fault,
and therefore does not need to be specified for computing a loop-free path from
node G to node F. Similarly, the path from node E to node F is not affected by the
C-E link fault, and therefore does not need to be specified, either. Because only the
path from node D to node E is affected by the C-E link fault, you only need to
specify the End.X SID 4::5 identifying the path from node D to node E to determine
the loop-free path, as shown in Figure 2-71.

(2020-10-09)
Figure 2-71 SRv6 remote microloop avoidance in a traffic switchover scenario

convergence.
2. Node G starts the timer T1. Before T1 expires, node G computes a microloop
avoidance segment list <4::5> for the packet destined for node F.
convergence and therefore continues to forward the packet to node G along
the path used before the fault occurs.
4. Node G inserts the microloop avoidance segment list <4::5> into the packet
NOTICE
Although the packet is sent from node B to node G and then back to node B,
no loop occurs because node G has changed the destination address of the
packet to End.X SID 4::5.
5. Node B searches the routing table for the route to destination address 4::5
and forwards the packet to node D through the route.
6. According to the instruction bound to the End.X SID 4::5, node D forwards the
packet to node E through the outbound interface specified by the End.X SID,
decrements the SL value by 1, and updates the destination address in the IPv6
packet header to 6::.
7. Node E forwards the packet to destination node F along the shortest path.
As previously described, node G inserts the microloop avoidance segment list
<4::5> into the packet, avoiding loops.

(2020-10-09)
When T1 of node G expires, other nodes on the network have completed

path A->B->D->E->F.
SRv6 Remote Microloop Avoidance in a Traffic Switchback Scenario

how a remote microloop occurs in a traffic switchback scenario. The process is as
follows:
1. After the C-E link recovers, a node (for example, node B) first completes
convergence, whereas node G has not converged.
2. Node B forwards the packet to node G.
3. Because node G has not completed convergence, it continues to forward the
packet to node B along the pre-recovery path, resulting in a microloop
To avoid the microloop, start the timer T1 on node B. Then, before T1 expires,
node B inserts an End.X SID identifying the path between nodes G and C into the
packet destined for node F to ensure that the packet can be forwarded to node C.
In this way, node C can forward the packet to destination node F according to the
destination IPv6 address 6:: along the shortest path.
2.1.2.11 SRv6 OAM
SRv6 operation, administration, and maintenance (OAM) monitors SRv6 tunnel

connectivity and rapidly detects faults. It is implemented through IPv6 ping and
tracert functions.
2.1.2.11.1 SRv6 OAM Extensions

As SRv6 simply adds a new type of routing extension header to implement
forwarding based on the IPv6 data plane, ICMPv6 ping & tracert can be directly
used on an SRv6 network for continuity check based on common IPv6 addresses,
without requiring any changes to hardware or software. ICMPv6 ping and tracert
both support packet forwarding to a destination address over the shortest path,
thereby checking the reachability to the destination.
If the destination address is an SRv6 SID, ICMPv6 ping & tracert require the use of
SRv6 OAM extensions to check the reachability to the address. If this requirement
is not met, ICMPv6 ping & tracert do not work in this case. Currently, SRv6 OAM
extensions are implemented by setting the O-bit (OAM bit) in the SRH or by
inserting an End.OP SID at an appropriate place in the SRH.
SRH O-bit
O-bit is located in the Flags field of the SRH shown in Figure 2-1. Figure 2-72
shows the format of the Flags field.
Figure 2-72 Format of the Flags field in the SRH

(2020-10-09)
O-bit indicates that the local packet is an OAM packet. If O-bit is set, each SRv6
endpoint node needs to copy the received data packet, add a timestamp to the
packet, and then send the packet to the control plane for further processing, for
example, for analysis by an analyzer. To prevent reprocessing the same packet, the
control plane does not need to respond to upper-layer IPv6 protocol operations,
such as ICMPv6 ping & tracert.
As each SRv6 endpoint node needs to process ICMPv6 packets carrying the O-bit,
segment-by-segment detection can be implemented based on the O-bit.
End.OP SID
End.OP SID is a variant of the End function. It instructs a data packet to be sent to
the control plane for OAM processing. For details about the function of the
End.OP SID, see End.OP SID.
Only the SRv6 endpoint node that generates an End.OP SID can process ICMPv6
packets. Therefore, end-to-end detection can be implemented based on the
End.OP SID.
2.1.2.11.2 SRv6 SID Ping and Tracert
Overview
On an SRv6 network, if data forwarding fails over SRv6, the control plane for SRv6
tunnel establishment cannot detect this failure, making network maintenance
difficult. SRv6 SID ping and tracert can be used to detect such faults. Both SRv6
SID ping and tracert check network connectivity and host reachability. The
difference is that SRv6 SID tracert can also locate faulty points.
SRv6 SID Ping

On the network shown in Figure 2-73, Device A, Device B, and Device C have SRv6
capabilities, and an SRv6 path is established between Device A and Device C.
Figure 2-73 SRv6 SID ping or tracert
Assume that an SRv6 SID ping operation is initiated on Device A. The ping
operation process is as follows:
● For a segment-by-segment test:
a. Device A specifies SRv6 SIDs for Device B and Device C in turn, and
constructs and sends an ICMPv6 request packet.
NOTE
If no SRv6 SID is assigned to the last hop, Device A must specify Device C's SRv6
SID as the destination IPv6 address of the SRv6 path.

(2020-10-09)
b. After receiving the ICMPv6 request packet, Device B sends an ICMPv6

response packet to Device A and forwards the ICMPv6 request packet to
Device C.
▪ If SRv6 is enabled on Device B, Device B forwards the ICMPv6 request

packet based on the segment routing header (SRH).
▪ If SRv6 is disabled on Device B, Device B forwards the ICMPv6

request packet based on the route.
c. After receiving the ICMPv6 request packet, Device C sends an ICMPv6
response packet to Device A.
● For a non-segment-by-segment test, an End.OP SID must be configured on
Device C.
a. Device A specifies an SRv6 SID for Device B and an End.OP SID and SRv6
SID for Device C in turn, and constructs and sends an ICMPv6 request
packet.
b. After receiving the ICMPv6 request packet, Device B forwards the packet
to Device C.
▪ If SRv6 is enabled on Device B, Device B forwards the ICMPv6 request

packet based on the SRH.
▪ If SRv6 is disabled on Device B, Device B forwards the ICMPv6

request packet based on the route.
c. After receiving the ICMPv6 request packet, Device C determines that the
SID type is End.OP SID and checks whether the next-layer SID is Device
C's SRv6 SID.
▪ If the next-layer SID is Device C's SRv6 SID, the check is successful.
Device C then sends an ICMPv6 response packet to Device A. In this
case, you can view detailed information about the ping operation on
Device A.
▪ If the next-layer SID is not Device C's SRv6 SID, the check fails.
Device C then discards the ICMPv6 request packet. In this case, a
timeout message is displayed on Device A.
SRv6 SID Tracert

Assume that an SRv6 SID tracert operation is initiated on Device A as shown in
Figure 2-73. The tracert operation process is as follows:
● For an overlay test:
a. Device A specifies SRv6 SIDs for Device B and Device C in turn, constructs
a UDP packet, and encapsulates an SRH into the packet for forwarding.
In this case, the value of the TTL field in the IPv6 packet header is set to
64. The value of the TTL field decreases by 1 each time the packet passes
through a device. When the value of the TTL field is 0, the packet is
discarded. An ICMPv6 timeout packet is then sent to Device A.
NOTE
If no SRv6 SID is assigned to the last hop, Device A must specify Device C's SRv6
SID as the destination IPv6 address of the SRv6 tunnel.

(2020-10-09)
b. After receiving the UDP packet, Device B changes the value of the TTL
field to 63, sends an ICMPv6 Port Unreachable packet to Device A, and
forwards the UDP packet to Device C.
▪ If SRv6 is enabled on Device B, Device B forwards the UDP packet

based on the SRH.
▪ If SRv6 is disabled on Device B, Device B forwards the UDP packet

based on the route.
c. After Device C receives the UDP packet, the value of the TTL field
changes to 62. Device C then sends an ICMPv6 Port Unreachable packet
to Device A.
● For non-overlay test, an End.OP SID must be configured on Device C.
a. Device A specifies an SRv6 SID for Device B and an End.OP SID and SRv6
SID for Device C, constructs a UDP packet, and encapsulates an SRH into
the packet for forwarding. In this case, the value of the TTL field in the
IPv6 packet header is set to 1. The value of the TTL field decreases by 1
each time the packet passes through a device. When the value of the TTL
field is 0, the packet is discarded. An ICMPv6 timeout packet is then sent
to Device A.
b. After receiving the UDP packet, Device B changes the value of the TTL
field to 0 and sends an ICMPv6 timeout packet to Device A.
c. After receiving the ICMPv6 timeout packet, Device A increases the value
of the TTL field by 1 (the value now becomes 2) and continues to send
the UDP packet.
d. After receiving the UDP packet, Device B changes the value of the TTL
field to 1 and sends the packet to Device C.
▪ If SRv6 is enabled on Device B, Device B forwards the UDP packet

based on the SRH.
▪ If SRv6 is disabled on Device B, Device B forwards the UDP packet

based on the route.
e. After receiving the UDP packet, Device C changes the value of the TTL
field to 0. Device C then determines that the SID type is End.OP SID and
checks whether the next-layer SID is Device C's SRv6 SID.
▪ If the next-layer SID is Device C's SRv6 SID, the check is successful.
Device C then sends an ICMPv6 Port Unreachable packet to Device A.
In this case, you can view detailed information about the tracert
operation on Device A.
▪ If the next-layer SID is not Device C's SRv6 SID, the check fails.
Device C then discards the UDP packet. In this case, a timeout
message is displayed on Device A.
2.1.2.11.3 SRv6 TE Policy Ping/Tracert
Overview
On an SRv6 network, if data forwarding fails over SRv6, the control plane for SRv6
tunnel establishment cannot detect this failure, making network maintenance

(2020-10-09)
difficult. SRv6 TE Policy ping and tracert can be used to detect such faults. SRv6 TE
Policy ping checks network connectivity and host reachability, and SRv6 TE Policy
tracert checks network connectivity and locates fault points.
SRv6 TE Policy Ping

On the network shown in Figure 2-74, Device A, Device B, and Device C have SRv6
capabilities, and an SRv6 TE Policy tunnel is established between Device A and
Device C.
Figure 2-74 SRv6 TE Policy Ping/Tracert
Assume that an SRv6 TE Policy ping operation is initiated on Device A. The ping
operation process is as follows:
1. Device A obtains the bottom SID from the SID stack of a segment list to
match an End.OP SID. Device A then encapsulates the matching End.OP SID
and segment list into an SRH, and constructs and sends an ICMPv6 request
packet to Device B.
NOTE
If the bottom SID of the segment list is an End.X SID or binding SID, you must
manually specify an End.OP SID when initiating a ping operation to the SRv6 TE Policy.
– If SRv6 is enabled on Device B, Device B forwards the ICMPv6 request
packet based on the segment routing header (SRH).
– If SRv6 is disabled on Device B, Device B forwards the ICMPv6 request
packet based on the route.
2. After receiving the ICMPv6 request packet, Device C checks whether the SID
type is End.OP SID.
– If the SID type is End.OP SID, Device C sends an ICMPv6 response packet
to Device A. In this case, you can view detailed information about the
ping operation on Device A.
– If the SID type is not End.OP SID, Device C discards the ICMPv6 request
packet. In this case, a message is displayed on Device A, indicating that
the ping operation times out.
SRv6 TE Policy Tracert

Assume that an SRv6 SID tracert operation is initiated on Device A as shown in
Figure 2-74. The tracert operation process is as follows:
1. Device A obtains the bottom SID from the SID stack of a segment list to
match an End.OP SID. Device A then encapsulates the matching End.OP SID
and segment list into an SRH, constructs a UDP packet and encapsulates the
SRH into the packet, and forwards the packet to Device B. In this case, the
value of the TTL field in the IPv6 packet header is set to 1. The value of the

(2020-10-09)
TTL field decreases by 1 each time the packet passes through a device. When
the value of the TTL field is 0, the packet is discarded. An ICMPv6 timeout
packet is then sent to Device A.
NOTE
If the bottom SID of the segment list is an End.X SID or binding SID, you must
manually specify an End.OP SID when initiating a tracert operation to the SRv6 TE
Policy.
2. After receiving the UDP packet, Device B changes the value of the TTL field to
0 and sends an ICMPv6 timeout packet to Device A.
3. After receiving the ICMPv6 timeout packet, Device A increases the value of
the TTL field by 1 (the value now becomes 2) and continues to send the UDP
packet.
4. After receiving the UDP packet, Device B changes the value of the TTL field to
1 and sends the packet to Device C.
– If SRv6 is enabled on Device B, Device B forwards the UDP packet based
on the SRH.
– If SRv6 is disabled on Device B, Device B forwards the UDP packet based
on the route.
5. After receiving the UDP packet, Device C changes the value of the TTL field to
0 and checks whether the SID type is End.OP SID.
– If the SID type is End.OP SID, Device C sends an ICMPv6 port unreachable
packet to Device A. In this case, you can view detailed information about
the tracert operation on Device A.
– If the SID type is not End.OP SID, Device C discards the UDP packet. In
this case, a message is displayed on Device A, indicating that the tracert
operation times out.
6. If multiple segment lists are available for the SRv6 TE Policy, steps 1 through
5 repeat until the test on each segment list is complete, because each
segment list is serially tested.
2.1.2.12 SRv6 SFC
2.1.2.12.1 SRv6 SFC Implementation
SFC Definition
Service Function Chain (SFC) logically connects services on network devices to
provide an ordered service set for the application layer. By adding service function
path (SFP) information in original packets, SFC enables packets to pass through
service functions (SFs) along a specified path.
Data packets on a network usually pass through various SFs to provide users with
secure, fast, and stable services as planned. These SFs include firewalls, intrusion
prevention systems (IPSs), application accelerators, and network address
translation (NAT) devices. User-required services can be implemented only when
network traffic passes through SFs in a sequence defined by the service logic.

(2020-10-09)
Basic SFC Concepts

Depending on SRv6 encapsulation awareness, SFs are classified into SRv6-aware
and SRv6-unaware SFs.
● SRv6-aware SFs can identify and process received SRv6 packets. In this case,
the SIDs of SFs are directly added into SFPs to implement SFC.
● SRv6-unaware SFs cannot identify SRv6 packets and therefore discard them
once received. In this case, SF proxies must be configured to implement SFC.
NOTE
This section focuses on SFC implementation by SRv6-unaware SFs. Unless otherwise

specified, SFs mentioned later all refer to SRv6-unaware SFs.
Figure 2-75 shows typical SRv6 SFC networking.
Figure 2-75 Typical SRv6 SFC networking
Table 2-17 describes other SFC concepts.
Table 2-17 Other SFC concepts

Concept Description
SFC domain A domain where SFs are deployed.
Service classifier (SC) Located at the ingress of an SFC domain, an SC

classifies traffic entering the domain. The
classification granularity can be coarse or fine,
depending on the SC capability and SFC policy.

(2020-10-09)
Concept Description
Service function An SFF forwards received packets to its associated

forwarder (SFF) SFs based on SRv6 encapsulation information. After
processing the packets, these SFs return the packets
to the SFF, which then determines whether to send
the packets back to the network.
Because SFs cannot process SRv6 packets, SF proxies
are required. An SF proxy processes packets from an
SFF on behalf of an SF. Specifically, the SF proxy
deletes SRv6 encapsulation information and then
sends the packets to the represented SF using the
local logical component. The SF proxy also receives
packets from the SF and then re-adds SRv6
encapsulation information to the packets. In Figure
2-75, the SFFs function as SF proxies.
Service function path An SFP is calculated based on configurations and

(SFP) precisely defines the location of each SF. On an SRv6
network, an SRv6 TE Policy can function as an SFP.
SRv6 TE Policy-based SFC Forwarding

By using segment lists, an SRv6 TE Policy instructs network devices to forward
traffic along a specified path. This mechanism is suitable for implementing SFC.
After a data packet is redirected into an SRv6 TE Policy, the headend adds the
segment lists of the SRv6 TE Policy to the data packet, and other devices on the
network execute the instructions embedded in the segment lists.
As shown in Figure 2-76, SF1 and SF2 are SRv6-unaware SFs. To implement SFC,
SF proxy must be configured on SFF1 and SFF2, and SRv6 SIDs must be allocated
to SF1 and SF2 proxies. On the SC, the SF1 Proxy SID, SF2 Proxy SID, and Tail End
SID form a segment list of an SRv6 TE Policy. The SRv6 TE Policy functions as an
SFP.

(2020-10-09)
Figure 2-76 SRv6 TE Policy-based SFC forwarding
The data forwarding process is as follows:

1. After receiving an original IPv4 packet from a user network, the SC classifies
the packet based on 5-tuple information and redirects the classified traffic to
an SRv6 TE Policy. Based on the SRv6 TE Policy, the SC encapsulates the
packet into an SRv6 packet, with the SF1 Proxy SID as the destination address.
In Figure 2-76, in addition to containing SRv6 TE Policy information, the SRH
contains the Tail End.DT4 SID that represents VPN or public network services.
2. After receiving the SRv6 packet, SFF1 executes the instruction corresponding
to the SF1 Proxy SID by decapsulating the packet and sending the original
packet to SF1 for processing.
3. After processing the packet, SF1 sends the packet back to SFF1.
4. Based on information about the interface through which SFF1 receives the
IPv4 packet, SFF1 searches for the relevant configuration. After finding the
configuration, SFF1 encapsulates the packet into an SRv6 packet by re-adding
SRH information according to the configuration. The destination address of
the SRv6 packet is the SF2 Proxy SID.
5. After receiving the SRv6 packet, SFF2 executes the instruction corresponding
to the SF2 Proxy SID by decapsulating the packet and sending the original
packet to SF2 for processing.
6. After processing the packet, SF2 sends the packet back to SFF2.
7. Based on information about the interface through which SFF2 receives the
IPv4 packet, SFF2 searches for the relevant configuration. After finding the
configuration, SFF2 encapsulates the packet into an SRv6 packet by re-adding
SRH information according to the configuration. The destination address of
the SRv6 packet is the Tail End SID. The packet is then forwarded to the tail
end node along the shortest IGP path.
8. After receiving the SRv6 packet, the tail end finds that the destination address
of the packet is its own End SID. The tail end then executes the instruction
corresponding to the End SID by decapsulating the packet, decreasing the

(2020-10-09)
Segment Left (SL) field value by 1 (meaning that the value changes to 0), and
updating the IPv6 destination address field. The IPv6 destination address field
of the current packet is the Tail End.DT4 SID. The tail end searches My Local
SID Table for an instruction matching the Tail End.DT4 SID, and then executes
the instruction to forward the original IPv4 packet to the corresponding IPv4
VPN or public network.
2.1.2.12.2 SRv6 SFC Reliability

SFC services are forwarded in serial mode, meaning that a single link or node
failure causes SFC service interruptions. To improve service reliability, SRv6 SFC
provides backup link protection and bypass link protection.
● In backup link protection, an SF is dual-homed to two SFFs, with one as the
master, and the other as the backup. The backup SFF protects the master SFF.
If the master SFF becomes unreachable, services are switched to the backup
SFF.
● In bypass link protection, if an SF is unreachable, SFC traffic is switched to the
bypass service path, without being processed by the current SF. An SFF usually
discards SFC packets if an SF is unreachable. After bypass link protection is
configured, SFC packets can continue to be forwarded as follows:
a. If no bypass SF is available for the current SF, SRv6 forwarding is
implemented for SFC packets.
b. If the current SF has a bypass SF to provide protection, SFC packets are
switched to the bypass SF for processing.
The protection schemes can be selected according to specific SFC networking
scenarios. The following describes their applications.
SFC Scenario with a Single-Homed SF That Does Not Have a Bypass SF

On the network shown in Figure 2-77, SF1 is single-homed to SFF1 and has no
bypass SF. One-arm BFD is configured on SFF1 to detect SF1 reachability. When
BFD detects that SF1 is unreachable, the SF1 Proxy SID is skipped, and the next
Tail End SID is used to guide SFC traffic forwarding.

(2020-10-09)
Figure 2-77 SFC scenario with a single-homed SF that does not have a bypass SF
SFC Scenario with a Single-Homed SF That Has a Bypass SF

On the network shown in Figure 2-78, SF1 is single-homed to SFF1 and has a
bypass SF – SF2. A bypass protection path is configured for the SF1 Proxy SID. The
SF2 Proxy SID is configured on SFF2.
One-arm BFD is configured on SFF1 to detect SF1 reachability. When BFD detects
that SF1 is unreachable, the SFC traffic is switched to the bypass service path.
SFF1 removes the SRH and searches the IPv6 routing table for packet forwarding,
using the SF2 Proxy SID as the destination IPv6 address. After receiving the packet,
SFF2 forwards it to SF2 based on the SF2 Proxy SID.

(2020-10-09)
Figure 2-78 SFC scenario with a single-homed SF that has a bypass SF
SFC Scenario with a Dual-Homed SF That Does Not Have a Bypass SF

On the network shown in Figure 2-79, SF1 is dual-homed to SFF1 and SFF2, and
has no bypass SF.
In this case, a backup path needs to be configured for protection. Because SF1 is
dual-homed to SFF1 and SFF2, SFF1 and SFF2 can provide protection for each
other. Specifically, the same SF1 Proxy SID of the End.AS type needs to be
configured on SFF1 and SFF2 to implement the anycast function. (For ease of
description, the SF1 Proxy SID on SFF2 in Figure 2-79 is called SF1 Backup Proxy
SID.) In addition, SFF1 and SFF2 need to be configured as peers of each other. The
peer SID of SFF1 is the End SID of SFF2, and the peer SID of SFF2 is the End SID of
SFF1.
One-arm BFD also needs to be configured on SFF1 to detect SF1 reachability.
When BFD detects that SF1 is unreachable, the SFC traffic is switched to the
backup service path. SFF1 replaces the original SRv6 segment list with the SF1
Proxy Backup SID and SFF2 End SID, and forwards the SFC packet to SFF2. After
receiving the packet, SFF2 identifies that both the SF1 Proxy Backup SID and SFF2
End SID are its own SIDs. SFF2 then forwards the packet to SF1 based on the SF1
Proxy Backup SID. After the packet returns from SF1 to SFF2, SFF2 re-encapsulates
the initial SRv6 segment list of the packet based on the configuration and
forwards the packet to a downstream device.

(2020-10-09)
Figure 2-79 SFC scenario with a dual-homed SF that does not have a bypass SF
SFC Scenario with a Dual-Homed SF That Has a Bypass SF

On the network shown in Figure 2-80, SF1 is dual-homed to SFF1 and SFF2, and
has a bypass SF – SF2.
In this case, a backup path needs to be configured for protection. Because SF1 is
dual-homed to SFF1 and SFF2, SFF1 and SFF2 can provide protection for each
other. Specifically, the same SF1 Proxy SID of the End.AS type needs to be
configured on SFF1 and SFF2 to implement the anycast function. (For ease of
description, the SF1 Proxy SID on SFF2 in Figure 2-80 is called SF1 Backup Proxy
SID.) In addition, SFF1 and SFF2 need to be configured as peers of each other. The
peer SID of SFF1 is the End SID of SFF2, and the peer SID of SFF2 is the End SID of
SFF1.
One-arm BFD is configured on SFF1 to detect SF1 reachability. When BFD detects
that SF1 is unreachable, the SFC traffic is switched to the backup service path.
SFF1 replaces the original SRv6 segment list with the SF1 Proxy Backup SID and
SFF2 End SID, and forwards the SFC packet to SFF2. After receiving the packet,
SFF2 identifies that both the SF1 Proxy Backup SID and SFF2 End SID are its own
SIDs. SFF2 then forwards the packet to SF1 based on the SF1 Proxy Backup SID.
If one-arm BFD on SFF2 detects that SF1 is unreachable, the SFC traffic is switched
to the bypass service path. SFF2 removes the SRH and searches the IPv6 routing
table for packet forwarding, using the SF2 Proxy SID as the destination IPv6
address. After receiving the packet, SFF3 forwards it to SF2 based on the SF2 Proxy
SID.

(2020-10-09)
Figure 2-80 SFC scenario with a dual-homed SF that has a bypass SF
2.1.3 Terminology for Segment Routing IPv6
Terms
Term Definition
SRv6 BE Segment Routing IPv6 best effort (SRv6 BE) uses an

IGP to run the shortest path algorithm to compute an
optimal SRv6 path.
Acronyms and Abbreviations

Abbreviation
CSPF constraint shortest path first
FRR fast re-route
MSD maximum SID depth
NETCONF Network Configuration Protocol
PHP penultimate hop popping

(2020-10-09)

Abbreviation
PSP penultimate segment pop of the SRH
SBFD seamless bidirectional forwarding detection
SID segment ID
SR Segment Routing
SRv6 Segment Routing IPv6
SRH Segment Routing header
TE traffic engineering
TI-LFA FRR topology-independent loop-free alternate FRR
USP ultimate segment pop of the SRH
2.2 Segment Routing IPv6 Configuration

This chapter describes the basic principles, configuration procedures, and
configuration examples for Segment Routing IPv6 (SRv6).
2.2.1 Overview of Segment Routing IPv6

Segment Routing IPv6 (SRv6) forwards IPv6 packets using the source routing
model. It implements hop-by-hop forwarding by adding a Segment Routing
header (SRH) into IPv6 packets, encapsulating an explicit IPv6 address stack into
the SRH, and continuously updating IPv6 destination addresses while offsetting
the address stack on transit nodes.
SRv6 offers the following benefits to users:
● Simplified network configuration and easier VPN implementation
SRv6 is based on IPv6 forwarding. It does not involve MPLS techniques and is
fully compatible with existing IPv6 networks. Transit nodes can forward SRH-
encapsulated IPv6 packets through routes, without the need to support SRv6.
● Improved fast reroute (FRR) capability
SRv6 works with the remote loop-free alternate (RLFA) FRR algorithm,
providing topology-independent loop-free alternate (TI-LFA) protection that
theoretically supports all topologies and compensates for conventional tunnel
protection techniques.
● Flexible traffic optimization on IPv6 forwarding paths
Various types of SIDs are used, enabling the ingress to flexibly plan explicit
paths and adjust service traffic.

(2020-10-09)
2.2.2 Segment Routing IPv6 Licensing Requirements and

EVPL SRv6 does not NA If EVPL SRv6 services

support LPUF-50/ pass through LPUF-50/
LPUF-50-L/LPUI-21-L/ LPUF-50-L/LPUI-21-L/
LPUI-51-L/LPUF-51/ LPUI-51-L/LPUF-51/
LPUF-51-B/LPUI-51/ LPUF-51-B/LPUI-51/
LPUI-51-B/LPUS-51/ LPUI-51-B/LPUS-51/
LPUF-101/LPUF-101-B/ LPUF-101/LPUF-101-B/
LPUI-101/LPUI-101-B/ LPUI-101/LPUI-101-B/
LPUS-101 boards. LPUS-101 boards, the
services may be
interrupted.

(2020-10-09)
In the scenario where an Plan the function Regardless of the pipe or

EVPN L3VPN over SRv6 properly. If the DiffServ short-pipe mode, packets
and a BGP L3VPN over mode is set to pipe on cannot enter specific
MPLS are spliced, the the splicing node, ensure queues based on
DiffServ mode that the DiffServ mode is configured priorities, or
configured in the L3VPN also set to pipe on the the EXP or TC field
instance on the splicing PEs at both ends. cannot be encapsulated
node and that based on configured
configured in the L3VPN priorities.
instance bound to the AC
interface are different. In
the former case, when
traffic leaves the SRv6
tunnel and enters the
MPLS tunnel:
If the DiffServ mode is
set to pipe, the EXP field
in the MPLS label is
encapsulated based on
the priority in the
original IPv6 packet.
set to short-pipe, the EXP
field in the MPLS label is
the priority in the inner
packet.
Conversely, when traffic
leaves the MPLS tunnel
and enters the SRv6
tunnel:
set to pipe, the TC field
in the IPv6 packet is
the EXP priority in the
MPLS label.
set to short-pipe, the TC
field in the IPv6 packet is
the priority in the inner
packet.
IS-IS Segment Routing None None

IPv6: The END must be
globally unique.

(2020-10-09)
When L3VPN traffic is When L3VPN traffic is Incorrect BFD switching

iterated to an SRv6 iterated to an SRv6 may occur.
tunnel functioning as a tunnel functioning as a
public network tunnel public network tunnel
and BFD for peer IP and BFD for peer IP
protection is supported, protection is supported,
set the peer IP address set the peer IP address
to the network segment to the network segment
address of a VPN SID address of a VPN SID
locator. locator.
When L3VPN traffic is None IPv6 forwarding fails.

iterated to an SRv6
tunnel functioning as a
public network tunnel,
the outbound interface
cannot be set to a
VLANIF interface, BDIF
interface, or MPLS tunnel
interface.
When L3VPN traffic is None The sampling

iterated to an SRv6 information is
tunnel functioning as a incomplete.
public network tunnel,
packet information is
sampled, but the
forwarding information,
such as next-hop and
outbound interface
information cannot be
sampled.
Segment Routing IPv6 Properly plan service IPv6 forwarding fails.

SRH does not support configurations. Setting a
fragmentation within a small MTU on the
tunnel. A maximum of inbound interface of a
10 labels can be added tunnel to prevent too big
to a packet header at a packets from traveling
time. through the tunnel.
Segment Routing IPv6 None Dynamic load balancing

next hops do not support does not take effect on
dynamic load balancing the next hops of the
adjustment. outbound interfaces on
the Segment Routing
ingress and transit
nodes.

(2020-10-09)
The SRv6 ingress does None Packet information

not support the sampling cannot be collected.
of outgoing SRH packets.
An SRv6 transit node
does not support the
sampling of the
incoming and outgoing
SRH packets. The SRv6
egress does not support
the sampling of
incoming SRH packets.
The SRv6 egress does Properly plan services. The unexpected load
not support deep load imbalance may occur.
balancing.
SRv6 allows a packet to None If a packet carries

carry multiple SRHs but multiple SRHs, only the
parses only the first SRH. first SRH can be parsed.
When strict URPF is None Service traffic is

configured, SRv6 packets interrupted.
may be discarded due to
a check failure.
After direct next hop is None SRv6 does not support

configured on a device, if TE FRR.
the explicit path label
has only one outbound
interface, SRv6 does not
support TE FRR.
When the Segment Properly plan MTUs. Packets may fail to be

Routing IPv6 feature is sent or received.
deployed on a network,
an IPv6 packet header
consumes a lot of
payload space. Therefore,
properly plan MTUs and
reserve some space for
the SRH address stack.
The SRH with the Next None This type of packet is not
Header set to an IPv6 identified and therefore
header is only supported. cannot be forwarded
The SRH extension through IPv6.
header is at the first IPv6
extension header field,
not at the other
extension headers.

(2020-10-09)
End.DX4 and End.DX6 None In telco cloud scenarios,

SIDs do not support VBDIF interfaces can be
VLANIF, low-speed, or VE used to meet service
interfaces. requirements. At present,
other scenarios do not
have such requirements.
For End.DX4 and None This feature is not used

End.DX6 SIDs, if the in telco cloud scenarios.
outbound interface of At present, other
services is a VBDIF scenarios do not have
interface, the services this requirement.
cannot access any
VXLAN or VPLS network.
The following four levels Plan services properly. Load balancing is

of load balancing may adversely affected.
be performed for services
over SRv6 TE Policies:
1. VPN ECMP
2. Segment list ECMP
3. End SID load
balancing
4. Load balancing among
trunk member interfaces
when the outbound
interface is a trunk
interface
A device supports a
maximum of three levels
of load balancing. If four
levels of load balancing
exist, load balancing
among trunk member
interfaces does not take
effect.

(2020-10-09)
In a telco cloud scenario Configure hash Load balancing fails

where BGP routes algorithm 3 to among trunk member
recurse to SRv6 remote implement four-level interfaces.
cross routes, multiple load balancing. However,
VPN BGP peers are this configuration may
established for a PE, adversely affect the load
each peer address balancing of other
recurses to multiple SIDs services.
for load balancing, and
SIDs recurse to routes for
trunk interface load
balancing, load
balancing may fail
among trunk member
interfaces.
The ingress does not None If the outermost SID of a

detect the reachability of segment list is
the outermost SID. If unreachable, traffic
multiple segment lists cannot be quickly
work in load balancing switched to other
mode and the outermost segment lists, affecting
SID of a segment list is traffic forwarding.
unreachable, traffic
forwarded through this
segment list cannot be
quickly switched to other
segment lists. Traffic can
be switched only when
the controller detects a
segment list fault, re-
computes a path, and
deletes the faulty
segment list.
The ingress does not None If the outermost SID is

detect the reachability of unreachable, traffic
the outermost SID. If an cannot be quickly
SRv6 TE Policy consists switched to the VPN FRR
of only one segment list backup or best-effort
and the outermost SID path.
of the segment list is
unreachable, the SRv6 TE
Policy does not go down,
and traffic cannot be
quickly switched to the
VPN FRR backup or best-
effort path.

(2020-10-09)
In a binding SID stitching Ensure that the Bandwidth resources are

scenario, the outermost configuration is correct exhausted.
SID of SRv6 TE Policy 1 is and binding SIDs are not
a binding SID that nested infinitely.
identifies SRv6 TE Policy
2, and the outermost SID
of SRv6 TE Policy 2 is
also a binding SID. In this
case, traffic is always
looped back on the
ingress until bandwidth
resources are exhausted.
If SRv6 TE Policy traffic None SRv6 TE Policy traffic

statistics collection is statistics decrease
enabled and a board sharply.
whose traffic statistics
are collected fails, the
faulty board cannot
report historical
statistics. As a result,
SRv6 TE Policy traffic
statistics decrease
sharply.
In inter-board VPN FRR None Packet loss may occur

switchback scenarios, the during inter-board VPN
local device cannot FRR switchback.
guarantee the entry
delivery sequence for
upstream and
downstream paths,
which may cause inter-
board packet loss.
In a scenario where Perform any of the Packet loss occurs.

public IPv4 traffic is following operations to
redirected to an SRv6 TE prevent this problem:
Policy, if the redirection 1. Delete the policy
configuration or SRv6 TE bound to the involved
Policy is deleted, or if the interface.
SRv6 TE Policy goes
down, packet loss occurs 2. Delete the classifier
when traffic is switched behavior command
from the SRv6 TE Policy configuration in the
to an IP tunnel. traffic policy view.
3. Delete the configured
traffic matching rule.

(2020-10-09)
In a scenario where SRv6 Plan the SRv6 MTU The switchover

TI-LFA is deployed properly. performance does not
between the ingress and meet the 50 ms
a transit node, when requirement.
traffic is switched to the
backup path due to a
fault of the primary
path, the SRH
information about the
primary path and the
SRH of the backup path
are encapsulated into
SRv6 packets. In this
case, the packet length
may exceed the interface
MTU. However, the
packets are sent to the
CPU without being
fragmented. Packet loss
occurs during the
primary/backup
switchover.
In an SRv6 egress Plan the SRv6 MTU The switchover

protection scenario, properly. performance does not
when traffic is switched meet the 50 ms
to the backup path due requirement.
to a fault of the primary
path, the SRH
information about the
primary path and the
SRH of the backup path
are encapsulated into
SRv6 packets. In this
case, the packet length
may exceed the interface
MTU. However, the
packets are sent to the
CPU without being
fragmented. Packet loss
occurs during the
primary/backup
switchover.
Nodes that use SRv6 Plan the SRv6 MTU Packets with a length
binding SIDs for properly. exceeding the IPv6 MTU
forwarding do not are discarded.
support packet
fragmentation.

(2020-10-09)
In the telecom cloud In the telecom cloud If no route-policy is

scenario, after the egress scenario, after the egress configured, traffic cannot
of an SR tunnel is of an SR tunnel is be forwarded.
configured to assign SIDs configured to assign SIDs
per-next-hop, the per-next-hop, if the
assigned SID for an egress is connected to
indirectly connected next the peer end that is an
hop cannot be used to indirectly connected next
guide traffic forwarding hop, configure a route-
bydefault. policy on the egress so
that the route advertised
to the peer end carries
the gateway IP address
attribute.
BGP routes cannot None If BGP routes recurse to

recurse to an SRv6 TE an SRv6 TE Policy tunnel
Policy tunnel during the during the second
second recursion. recursion, FIB entries
cannot be delivered and
traffic fails to be
forwarded.
In an SRv6 BE/SRv6 TE None In an SRv6 BE/TE Policy

Policy scenario, TI-LFA scenario, if TI-LFA/TE
FRR/TE FRR and poison FRR and poison reverse
reverse cannot both be are both configured,
configured. traffic forwarding may
be interrupted.
In an SRv6 BE/SRv6 TE Properly plan the Traffic forwarding is

Policy scenairo with TI- interface MTU and SRv6 adversely affected.
LFA FRR configured, if path MTU.
the interface MTU of the
standby link is smaller
than the SRv6 path MTU
but but the packet
length is greater than
the interface MTU, the
packets fail to be
forwarded.

(2020-10-09)
If a packet is Properly plan the Traffic forwarding is

encapsulated with an interface IPv6 MTU. adversely affected.
SRH on an SRv6 ingress
or transit node, the
packet length may
exceed the interface IPv6
MTU. In this case, if the
first SID in a segment list
to be configured on a
local node is the local
End SID or binding SID,
the local node directly
sends the packet to its
CPU without
fragmenting the packet,
causing a packet
forwarding failure.
Types of interfaces None Services interrupted.

supported by SRv6 BE:
only Layer 3 Ethernet
main interface, Ethernet
sub-interface, Layer 3
Eth-Trunk interface, Eth-
Trunk sub-interface, IP-
Trunk interface, and POS
interface

(2020-10-09)
In the source version, None If the configured path

VPN traffic that enters MTU is decreased to be
an SRv6 BE path is less than the interface
limited by the interface MTU, more packets will
MTU. In the target be fragmented in the
version, VPN traffic that case of IPv4 VPN
enters an SRv6 BE tunnel packets, and more
is limited by the smaller packets will be discarded
value between the in the case of IPv6 VPN
interface MTU and the packets.
path MTU configured in
the SRv6 view. If the
interface MTU is set to
be greater than 1500
bytes in the source
version, VPN traffic that
enters an SRv6 BE tunnel
is limited to 1500 bytes
after the upgrade
because the default SRv6
path MTU is 1500 bytes
in the target version.
This ensures that the
length of a packet
encapsulated with the
SRv6 BE IPv6 header
does not exceed 1500
bytes. If the VPN traffic
involves IPv4 packets
and the length of a
single IPv4 packet plus
the SRv6 BE IPv6 header
exceeds 1500 bytes, the
IPv4 packet is
fragmented first and
then encapsulated with
the SRv6 BE IPv6 header.
If the VPN traffic
involves IPv6 packets
and the length of a
single IPv6 packet plus
the SRv6 BE IPv6 header
exceeds 1500 bytes, the
IPv6 packet is discarded
and an ICMPv6 Packet
Too BIG packet is
returned.

(2020-10-09)
2.2.3 Activating an SRv6 Port License for a Board

If only an SRv6 port license rather than a device-based license is purchased, you
can configure SRv6 services only after activating the SRv6 port license.
Usage Scenario
Before you configure SRv6 services, run the active port-srv6 command to activate
SRv6 licenses in batches.
Procedure
Step 2 Run license
The license view is displayed.
Step 3 Run active port-srv6 slot slot-id card cardid port port-list
The SRv6 port license is activated for a specified board.
Step 4 Run commit
----End

Run the display license resource usage port-srv6 { all | slot slot-id } [ active |
deactive ] command to check whether the SRv6 port license has been activated
for the board.
2.2.4 Configuring SRv6 BE

This section describes how to configure SRv6 BE services.
2.2.4.1 Configuring L3VPNv4 over SRv6 BE

This section describes how to configure L3VPNv4 over SRv6 BE.
Usage Scenario
L3VPNv4 over SRv6 BE allows SRv6 BE paths on public networks to carry L3VPNv4
data. The implementation of L3VPNv4 over SRv6 BE involves establishing SRv6 BE
paths, advertising VPN routes, and forwarding data.
As shown in Figure 2-81, PE1 and PE2 communicate through an IPv6 public
network. The VPN is a traditional IPv4 network. SRv6 BE paths can be deployed on
the IPv6 public network to carry L3VPNv4 services on the VPN.

(2020-10-09)
Figure 2-81 L3VPNv4 over SRv6 BE networking
Before configuring L3VPNv4 over SRv6 BE, complete the following tasks:
● Configure a link layer protocol.

● Configure IP addresses for interfaces to ensure that neighboring devices are
reachable at the network layer.
Procedure
Step 1 Configure IPv6 IS-IS on each PE and P. For configuration details, see Configuring
Basic IPv6 IS-IS Functions.
Step 2 Configure a VPN instance on each PE and enable the IPv4 address family for the
instance.
1. Run system-view

2. Run ip vpn-instance vpn-instance-name
A VPN instance is created, and the VPN instance view is displayed.

3. Run ipv4-family
The VPN instance IPv4 address family is enabled, and the view of this address
family is displayed.
4. Run route-distinguisher route-distinguisher
An RD is configured for the VPN instance IPv4 address family.

5. Run vpn-target vpn-target &<1-8> [ both | export-extcommunity | import-
extcommunity ]
A VPN target is configured for the VPN instance IPv4 address family.
6. Run commit

7. Run quit
Exit the VPN instance IPv4 address family view.

8. Run quit

(2020-10-09)
Exit the VPN instance view.

The view of the interface to be bound to the VPN instance is displayed.
10. Run ip binding vpn-instance vpn-instance-name
The VPN instance is bound to the interface.
NOTE
Running the ip binding vpn-instance command deletes Layer 3 (including IPv4 and
IPv6) configurations, such as IP address and routing protocol configurations, on the
involved interface. If needed, reconfigure them after running the command.
An IP address is assigned to each interface.
Some Layer 3 functions, such as route exchange between the PE and CE, can
be configured only after an IP address is configured for the VPN interface on
the PE.
12. Run commit
13. Run quit
Exit the interface view.
Step 3 Configure IPv4 route exchange between the PE and CE. For configuration details,
see Configuring Route Exchange Between PEs and CEs.
1. Run bgp { as-number-plain | as-number-dot }
2. Run router-id ipv4-address
A router ID is configured.
3. Run peer ipv6-address as-number { as-number-plain | as-number-dot }
The peer PE is configured as a BGP peer.
4. Run peer ipv6-address connect-interface loopback interface-number
The interface on which a TCP connection to the specified BGP peer is
established is specified.
5. Run ipv4-family vpnv4
The function to exchange VPN-IPv4 routes with the BGP peer is enabled.
7. Run commit
8. Run quit
Exit the BGP VPNv4 address family view.

(2020-10-09)
9. Run quit
Exit the BGP view.
Step 5 Establish an SRv6 BE path between PEs.
1. Run segment-routing ipv6
SRv6 is enabled, and the SRv6 view is displayed.
2. Run encapsulation source-address ipv6-address [ ip-ttl ttl-value ]
A source address is specified for SRv6 EVPN encapsulation.
3. Run locator locator-name [ ipv6-prefix ipv6-address prefix-length [ static
static-length | args args-length ] * ]
An SRv6 locator is configured.
4. (Optional) Run opcode func-opcode end-dt4 vpn-instance vpn-instance-
name
A static SID operation code (opcode) is configured.
An End.DT4 SID can be either dynamically allocated by BGP or manually
configured. If you want to enable dynamic End.DT4 SID allocation using the
segment-routing ipv6 locator locator-name command, skip this step.
5. Run quit
Exit the SRv6 locator view.
6. Run quit
Exit the SRv6 view.
9. Run peer ipv6-address prefix-sid
The device is enabled to exchange IPv4 prefix SIDs with a specified IPv6 peer.
10. Run quit
11. Run ipv4-family vpn-instance vpn-instance-name
The BGP-VPN instance IPv4 address family view is displayed.
12. Run segment-routing ipv6 best-effort
The device is enabled to perform private network route recursion based on
the SIDs carried by routes.
13. Run segment-routing ipv6 locator locator-name [ auto-sid-disable ]
The device is enabled to add SIDs to VPN routes.
If auto-sid-disable is not specified, dynamic SID allocation is supported. If
there are static SIDs in the range of the locator specified using locator-name,
the static SIDs are used. Otherwise, dynamically allocated SIDs are used.

(2020-10-09)
If auto-sid-disable is specified, BGP does not dynamically allocate SIDs.

14. Run commit

15. Run quit
Exit the BGP-VPN instance IPv4 address family view.

16. Run quit
Exit the BGP view.
Step 6 Enable IS-IS SRv6 on PEs.


IS-IS SRv6 is enabled.

3. Run commit
----End

After configuring L3VPNv4 over SRv6 BE, verify the configuration.
● Run the display segment-routing ipv6 locator [ locator-name ] verbose

command to check SRv6 locator information.
● Run the display segment-routing ipv6 local-sid { end | end-x | end-dt4 }
[ sid ] forwarding command to check information about the SRv6 local SID
table.
● Run the display bgp vpnv4 { all | route-distinguisher route-distinguisher |
vpn-instance vpn-instance-name } routing-table [ network [ prefix-
length ] ] command to check BGP VPNv4 routing information.
● Run the ping command to check the connectivity between CEs.
2.2.4.2 Configuring EVPN L3VPN over SRv6 BE

This section describes how to configure EVPN L3VPN over SRv6 BE.
Usage Scenario
EVPN L3VPN over SRv6 BE uses public SRv6 BE to carry EVPN L3VPN services. The
implementation of EVPN L3VPN over SRv6 BE involves deploying SRv6 BE,
implementing EVPN route interworking, and forwarding data.
network. SRv6 BE is deployed on the public IPv6 network to carry EVPN L3VPN
services.

(2020-10-09)
Figure 2-82 EVPN L3VPN over SRv6 BE networking
Before configuring EVPN L3VPN over SRv6 BE, complete the following tasks:

Procedure
Step 2 Configure an L3VPN instance.
For IPv4 services, configure an IPv4 L3VPN instance.

2. Run ipv4-family
extcommunity ] evpn
VPN targets are added to the VPN target list of the VPN instance IPv4 address
family, so that routes of the VPN instance can be added to the routing table
of the EVPN instance configured with a matching VPN target.
5. (Optional) Run tnl-policy policy-name evpn
The EVPN routes imported to the VPN instance IPv4 address family are
enabled to be associated with a tunnel policy.
6. (Optional) Run import route-policy policy-name evpn
The VPN instance IPv4 address family is associated with an import route-
policy that is used to filter routes imported from the EVPN instance to the
VPN instance IPv4 address family. To control route import more precisely,
specify an import route-policy to filter routes and set route attributes for
routes that meet the filter criteria.

(2020-10-09)
7. (Optional) Run export route-policy policy-name evpn

The VPN instance IPv4 address family is associated with an export route-
policy that is used to filter routes advertised from the VPN instance IPv4
address family to the EVPN instance. To control route advertisement more
precisely, specify an export route-policy to filter routes and set route
attributes for routes that meet the filter criteria.
8. Run quit
9. Run quit
2. Run ipv6-family
extcommunity ] evpn
The EVPN routes imported to the VPN instance IPv6 address family are
enabled to be associated with a tunnel policy.
8. Run quit
9. Run quit
Step 3 Bind the L3VPN instance to an access-side interface.

(2020-10-09)

The L3VPN instance is bound to the interface.

3. (Optional) Run ipv6 enable
IPv6 is enabled on the interface.

4. Run ip address ip-address { mask | mask-length } or ipv6 address { ipv6-
address prefix-length | ipv6-address/prefix-length }
An IPv4/IPv6 address is configured for the interface.

5. Run quit
Step 4 Configure BGP EVPN peer relationships.

NOTE
If a BGP RR needs to be configured on the network, establish BGP EVPN peer relationships
between all the PEs and the RR.

2. Run peer { ipv6-address | group-name } as-number { as-number-plain | as-
number-dot }
The remote PE is configured as a peer.

3. (Optional) Run peer { ipv6-address | group-name } connect-interface
interface-type interface-number
A source interface and a source address are specified to set up a TCP

connection with the BGP peer.
NOTE
If loopback interfaces are used to establish a BGP connection, you are advised to run
the peer connect-interface command on both ends to ensure the connectivity. If this
command is run on one end only, the BGP connection may fail to be established.
4. Run ipv4-family vpn-instance vpn-instance-name or ipv6-family vpn-
instance vpn-instance-name
The BGP-VPN instance IPv4/IPv6 address family view is displayed.

5. Run import-route { direct | isis process-id | ospf process-id | rip process-id |
static | ospfv3 process-id | ripng process-id } [ med med | route-policy route-
policy-name ] *
Other protocol routes are imported to the BGP-VPN instance IPv4/IPv6

address family. To advertise host IP routes, configure import of direct routes.
To advertise routes on the network segment where the host resides, use a
dynamic routing protocol (such as OSPF) to advertise routes on the network
segment and configure the dynamic routing protocol to import routes.
6. Run advertise l2vpn evpn [ import-route-multipath ]

(2020-10-09)
The device is enabled to advertise IP prefix routes. IP prefix routes are used to
advertise host IP routes as well as routes on the network segment where the
host resides.
To implement SID-based load balancing, specify the import-route-multipath

parameter for the device to advertise all IP prefix routes with the same
7. Run quit
Exit the BGP-VPN instance IPv4/IPv6 address family view.

8. Run l2vpn-family evpn

9. Run peer { ipv6-address | group-name } enable
The device is enabled to exchange EVPN routes with the specified peer or
peer group.
10. (Optional) Run nexthop recursive-lookup default-route
The device is enabled to send packets over a default route when the recursive
next-hop IP address is unavailable.
In an EVPN over SRv6 BE scenario, problems, such as a configuration error or

fault, may cause the PE at one end to fail to recurse services to SRv6 BE due
to route unreachability, resulting in a service forwarding failure. To prevent
this, run the nexthop recursive-lookup default-route command on the PE
and configure the remote PE to send a default route to the local PE. In this
way, if the next hop of a specific route on the local PE is unreachable, services
can recurse to the default route and then to SRv6 BE for forwarding, ensuring
service continuity.
11. Run quit
Exit the BGP EVPN address family view.

12. Run quit
Exit the BGP view.

13. Run commit
Step 5 Deploy SRv6 BE between PEs.

1. (Optional) Run evpn srv6 next-header-field { 59 | 143 }
A value is set for the Next Header field in an SRv6 extension header.



(2020-10-09)
5. (Optional) Run opcode func-opcode { end-dt4 | end-dt6 } vpn-instance vpn-

instance-name evpn
A static SID operation code (opcode) is configured. The end-dt4 parameter is
used for IPv4 services, and the end-dt6 parameter is used for IPv6 services.
Alternatively, run the opcode func-opcode { end-dx4 | end-dx6 } vpn-
instance vpn-instance-name evpn interface interface-type interface-number
nexthop nexthop-address command to configure a static SID opcode. The
end-dx4 parameter is used for IPv4 services, and the end-dx6 parameter is
used for IPv6 services.
In EVPN scenarios, end-dx4 and end-dx6 are used to allocate SIDs based on
interfaces to which VPN instances are bound, and end-dt4 and end-dt6 are
used to allocate SIDs based on VPN instances.
The preceding SIDs can be either dynamically allocated by BGP or manually
configured. If you want to enable dynamic SID allocation using the segment-
routing ipv6 locator locator-name command, skip this step.
6. Run quit
7. Run quit
Exit the SRv6 view.
10. Run peer { ipv6-address | group-name } advertise encap-type srv6
The device is enabled to send EVPN routes carrying the SRv6 encapsulation
attribute to peers.
11. Run quit
13. Run segment-routing ipv6 locator locator-name evpn
The device is enabled to add SIDs to VPN routes before sending the routes to
EVPN.
14. Run segment-routing ipv6 best-effort evpn
The device is enabled to perform route recursion based on the SIDs carried by
EVPN routes.
15. (Optional) Configure the device to allocate SIDs to BGP VPN routes based on
next hops, thereby implementing SID-based load balancing.
To configure the device to allocate SIDs to BGP VPN routes based on all next
hops:

(2020-10-09)
– For EVPN L3VPNv4 services, run the segment-routing ipv6 apply-sid all-
nexthop evpn command in the BGP-VPN instance IPv4 address family
view.
– For EVPN L3VPNv6 services, run the segment-routing ipv6 apply-sid all-
nexthop evpn command in the BGP-VPN instance IPv6 address family
view.
To configure the device to allocate a SID to a BGP VPN route with a specified
next hop:
– For EVPN L3VPNv4 services, run the segment-routing ipv6 apply-sid
specify-nexthop evpn command in the BGP-VPN instance IPv4 address
family view, and then run the nexthop nexthop-address interface
{ interface-name | interfaceType interfaceNum } command to specify a
next hop and an outbound interface.
– For EVPN L3VPNv6 services, run the segment-routing ipv6 apply-sid
specify-nexthop evpn command in the BGP-VPN instance IPv6 address
family view, and then run the nexthop nexthop-address interface
{ interface-name | interfaceType interfaceNum } command to specify a
next hop and an outbound interface.
16. Run commit
17. Run quit
Exit the BGP-VPN instance IPv4 address family view or BGP-VPN instance IPv6
address family view.
18. Run quit
Exit the BGP view.
Step 6 Enable IS-IS SRv6 on PEs.
3. Run commit
----End

After configuring EVPN L3VPN over SRv6 BE, verify the configuration.
length ] ] command to check BGP VPNv4 route information.
length ] ] command to check BGP VPNv6 route information.

(2020-10-09)
● Run the display bgp evpn all routing-table prefix-route prefix command to
check EVPN IP prefix route information.
● Run the display ip routing-table vpn-instance vpn-instance-name or display
ipv6 routing-table vpn-instance vpn-instance-name command to check
information about the VPN routes received from the remote device.
2.2.4.3 Configuring EVPN VPWS over SRv6 BE

This section describes how to configure EVPN VPWS over SRv6 BE.
Usage Scenario
EVPN VPWS over SRv6 BE uses public SRv6 BE to carry EVPN services. The
implementation of EVPN VPWS over SRv6 BE involves establishing SRv6 BE paths,
advertising EVPN routes, and forwarding data.
network. SRv6 BE is deployed on the public IPv6 network to carry Layer 2 EVPN
services.
Figure 2-83 EVPN VPWS over SRv6 BE networking
Before configuring EVPN VPWS over SRv6 BE, complete the following tasks:

Procedure
Step 1 Configure IPv6 IS-IS on each PE and P. For details, see Configuring Basic IPv6 IS-IS
Functions.
Step 2 Configure EVPN and EVPL instances on each PE.

1. Run system-view

2. Run evpn source-address ip-address

(2020-10-09)
An EVPN source address is configured.

In scenarios where a CE is dual-homed or multi-homed to PEs, you need to
configure an EVPN source address on each PE to generate route distinguishers
(RDs) for Ethernet segment routes and Ethernet auto-discovery per ES routes.
3. Run evpn vpn-instance vpn-instance-name vpws
An EVPN instance that works in VPWS mode is created.
An RD is configured for the EVPN instance.
An EVPN instance takes effect only after an RD is configured for it. The RDs of
different EVPN instances on a PE must be different.
NOTE
After being configured, an RD cannot be modified but can be deleted. If the RD of an

EVPN instance is deleted, VPN targets configured for the EVPN instance are also
deleted.
extcommunity ]
VPN targets are configured for the EVPN instance.
VPN targets are BGP extended community attributes used to control the
receiving and advertisement of EVPN routes. A maximum of eight VPN targets
can be configured using the vpn-target command. To configure more VPN
targets for an EVPN instance address family, run the vpn-target command
multiple times.
NOTE
An RT of an Ethernet segment route is generated using the middle six bytes of an ESI.
For example, if the ESI is 0011.1001.1001.1001.1002, the Ethernet segment route uses
11.1001.1001.10 as its RT.
6. Run quit
7. Run evpl instance evpl-id srv6-mode
An EVPL instance that works in SRv6 mode is created.
8. Run evpn binding vpn-instance vpn-instance-name
A specified EVPN instance that works in VPWS mode is bound to the current
EVPL instance.
9. Run local-service-id service-id remote-service-id service-id
The packets of the current EVPL instance are configured to carry the local and
remote service IDs.
10. (Optional) Run mtu-match ignore
The MTU matching check is ignored for the EVPL instance. In scenarios where
a Huawei device interworks with a non-Huawei device through an EVPN
VPWS, if the non-Huawei device does not support any MTU matching check
for an EVPL instance working in SRv6 mode, run the mtu-match ignore
command to ignore the MTU matching check.

(2020-10-09)
11. (Optional) Run load-balancing ignore-esi
The device is disabled from checking ESI validity during EVPL instance load
balancing.
In an EVPN VPWS scenario where active-active protection is deployed, if each

access-side device is single-homed to an aggregation-side device and no ESI is
configured on the access interface, to implement active-active load balancing,
you can run this command on the aggregation-side device to enable the
device to ignore ESI validity check during EVPL instance load balancing.
12. Run quit
Step 3 Configure an AC interface.

1. Run interface interface-type interface-number.subnum mode l2
A Layer 2 sub-interface is created, and the sub-interface view is displayed.
NOTE
Before running this command, ensure that the Layer 2 interface on which a Layer 2
sub-interface is to be created does not have the port link-type dot1q-tunnel
command configuration. If this configuration exists, run the undo port link-type
command to delete the configuration.
In addition to a Layer 2 sub-interface, an Ethernet main interface, Layer 3 sub-
interface, or Eth-Trunk interface can also function as an AC interface.
2. Run evpl instance evpl-id
A specified EVPL instance is bound to the Layer 2 sub-interface.

3. (Optional) Run evpn-vpws ignore-ac-state
The interface is enabled to ignore the AC status.
On a network with primary and backup links, if CFM is associated with an AC

interface, run this command to ensure EVPN VPWS continuity. When the AC
status of the interface becomes down, a primary/backup link switchover is
triggered. As the interface has been enabled to ignore the AC status using this
command, the EVPN VPWS does not need to be re-established during the link
switchover.
4. Run quit
Exit the Layer 2 sub-interface view.
Step 4 Establish a BGP EVPN peer relationship between PEs.


A BGP router ID is configured.



(2020-10-09)
The interface used to set up a TCP connection with the specified BGP peer is
specified.
The device is enabled to exchange EVPN routes with the specified peer.
7. Run quit
8. Run quit
Exit the BGP view.
9. Run commit
If the value is 59 in earlier versions, you can perform this step to change the
value to 59 to ensure compatibility with the earlier versions.
5. Run opcode func-opcode end-dx2 evpl-instance evpl-instance-id
6. (Optional) Run opcode func-opcode end-dx2l evpl-instance evpl-instance-id
An End.DX2L SID opcode is configured. You can run this command to
manually specify a SID for a bypass path.
7. Run quit
8. Run quit
Exit the SRv6 view.

(2020-10-09)
In this command, the value of locator-name must be the same as that

configured using locator locator-name [ ipv6-prefix ipv6-address prefix-
length [ static static-length | args args-length ] * ].
11. Run quit
Exit the IS-IS view.
The device is enabled to send EVPN routes carrying SRv6-encapsulated
attributes to a specified peer or peer group.
15. Run quit
16. Run quit
Exit the BGP view.
The view of an EVPL instance that works in SRv6 mode is displayed.
18. Run segment-routing ipv6 locator locator-name
The device is enabled to add SIDs to EVPN routes to be sent.
If there are static SIDs in the range of the locator specified using locator-
name, use the static SIDs. Otherwise, use dynamically allocated SIDs.
19. Run quit
Exit the view of the EVPL instance that works in SRv6 mode.
The view of the EVPN instance that works in VPWS mode is displayed.
routes.
22. Run quit
23. Run commit
Step 6 (Optional) Verify EVPN VPWS connectivity.
1. Configure an End.OP SID on the remote PE.
a. Run segment-routing ipv6
The SRv6 view is displayed.
b. Run locator locator-name

(2020-10-09)
The locator view is displayed.

c. Run opcode func-opcode end-op
An End.OP SID opcode is configured.
d. Run commit
2. Perform the following steps on the local PE:
b. Run remote end-op op-sid prefix-length
A remote End.OP SID is configured.
c. Run commit
– Run ping evpn vpws local-ce-id remote-ce-id end-op endOp [ -a source-
ip | -c count | -exp exp-value | -m interval | -s packet-size | -t time-out | -r
reply-mode | -tc tc ] *
A ping operation is performed to check the EVPN VPWS status.
– Run tracert evpn vpws local-ce-id remote-ce-id end-op endOp [ -a
source-ip | -exp exp-value | -s packet-size | -t timeout | -h max-ttl | -r
reply-mode | -tc tc ] * [ pipe | uniform ]
A tracert operation is performed to check the EVPN VPWS status.
----End

After configuring EVPN VPWS over SRv6 BE, verify the configuration.
● Run the display bgp evpn evpl command to check all EVPL instance
information.
● Run the display bgp evpn { all | route-distinguisher route-distinguisher |
vpn-instance vpn-instance-name } routing-table [ { ad-route | es-route |
inclusive-route | mac-route | prefix-route } prefix ] command to check BGP
EVPN route information.
● Run the display segment-routing ipv6 local-sid end-dx2 evpl-instance
evpl-id forwarding command to check information about the SRv6 BE local
SID table.
2.2.4.4 Configuring EVPN VPLS over SRv6 BE

When the EVPN E-LAN model is used to carry multipoint-to-multipoint (MP2MP)
VPLSs, EVPN VPLS over SRv6 BE can be configured to transmit EVPN E-LAN data
over public SRv6 BE paths.
Usage Scenario
EVPN VPLS uses the EVPN E-LAN model to carry MP2MP VPLSs. EVPN VPLS over
SRv6 BE uses public SRv6 BE paths to carry EVPN E-LAN services. The

(2020-10-09)
implementation of EVPN VPLS over SRv6 BE involves establishing SRv6 BE paths,

advertising EVPN routes, and forwarding data.
network. SRv6 BE is deployed on the public IPv6 network to carry EVPN E-LAN
services.
Figure 2-84 EVPN VPLS over SRv6 BE networking
Before configuring EVPN VPLS over SRv6 BE, complete the following tasks:
● Configure basic IPv6 IS-IS functions on PEs and the P.
● Configure BD-EVPN functions on PEs.
Procedure
1. Run system-view
3. (Optional) Run router-id ipv4-address

(2020-10-09)

9. Run quit
10. Run quit
Exit the BGP view.
11. Run commit
5. (Optional) Run opcode func-opcode end-dt2m bridge-domain bd-id
A static End.DT2M SID operation code (opcode) is configured.
Perform this step if a static locator is configured using the static static-length
parameter. End.DT2M SIDs are used for BUM traffic forwarding through VPLS.
6. (Optional) Run opcode func-opcode { end-dt2u | end-dt2ul } bridge-domain
bd-id
Static End.DT2U and End.DT2UL SID opcodes are configured.
parameter. End.DT2U SIDs are used for the forwarding of known unicast
traffic through VPLS. In dual-homing scenarios, an End.DT2UL SID opcode
needs to be specified for the bypass path to prevent traffic loops between PEs.
7. Run quit
8. Run quit
Exit the SRv6 view.

(2020-10-09)

length [ static static-length | args args-length ] * ]. If a separate locator is
configured for each of BUM traffic and known unicast traffic of EVPN VPLS
services, you need to run this command once for each locator for IS-IS to
advertise them both.
11. Run quit
12. Run evpn vpn-instance vpn-instance-name bd-mode
The view of the EVPN instance that works in BD mode is displayed.
13. Run segment-routing ipv6 locator locator-name [ unicast-locator unicast-
locator-name ]
In this command:
– locator-name must be set to an End.DT2M SID, with the args parameter
specified. unicast-locator-name must be set to an End.DT2U or
End.DT2UL SID, without having the args parameter specified. If the
locator-name and unicast-locator-name parameters are both required,
you need to run the locator locator-name [ ipv6-prefix ipv6-address
prefix-length [ static static-length | args args-length ] * ] command to
create two corresponding locators before setting the two parameters.
– In EVPN VPLS dual-homing scenarios, the args parameter is used to
splice ESI labels for End.DT2M SIDs only, which causes a waste of
End.DT2U SIDs. In this case, you can separately configure a locator for
End.DT2U SIDs and a locator for End.DT2M SIDs. The former locator does
not require the args parameter to be specified. The two locators can then
be bound to the same EVPN instance to conserve SIDs.
– If there are static SIDs in the range of the locator specified using locator-
name or unicast-locator-name, use the static SIDs. Otherwise, use
dynamically allocated SIDs.
routes.
15. Run commit
----End

After configuring EVPN VPLS over SRv6 BE, verify the configuration.
● Run the display segment-routing ipv6 local-sid { end-dt2u | end-dt2ul |
end-dt2m } [ sid ] [ bridge-domain bd-id ] forwarding command to check
information about the SRv6 BE local SID table.

(2020-10-09)

2.2.4.5 Configuring Public IPv4 over SRv6 BE

This section describes how to configure public IPv4 over SRv6 BE.
Usage Scenario
Public IPv4 over SRv6 BE allows SRv6 BE paths on a public network to carry public
IPv4 data. The implementation of public IPv4 over SRv6 BE involves establishing
SRv6 BE paths, advertising BGP routes, and forwarding data. As shown in Figure
2-85, PE1 and PE2 communicate through an IPv6 public network. An SRv6 BE path
can be deployed on the IPv6 public network to carry public IPv4 services.
Figure 2-85 Public IPv4 over SRv6 BE networking
Before configuring public IPv4 over SRv6 BE, complete the following tasks:

Procedure
Step 2 Establish an EBGP peer relationship between PE1 and DeviceA and another one
between PE2 and DeviceB.
1. Run system-view



(2020-10-09)
4. Run peer ipv4-address as-number as-number
The IPv4 address of a peer and the number of the AS where the peer resides
are specified.
5. Run ipv4-family unicast
The BGP-IPv4 unicast address family view is displayed.

The device is enabled to exchange routing information with the specified IPv4
peer.
7. Run commit

8. Run quit
Exit the BGP-IPv4 unicast address family view.

9. Run quit
Exit the BGP view.



are specified.
4. Run peer ipv6-address connect-interface interface-type interface-number

connection.

peer.
7. Run commit

8. Run quit

9. Run quit
Exit the BGP view.
Step 4 Establish an SRv6 BE path between the PEs.

(2020-10-09)

A source address is specified for SRv6 encapsulation.
4. (Optional) Run opcode func-opcode end-dt4
configured. If a dynamically allocated SID and a manually configured SID
both exist, the manually configured SID takes effect. If you want to enable
dynamic End.DT4 SID allocation using the segment-routing ipv6 locator
locator-name command, skip this step.
5. Run quit
6. Run quit
Exit the SRv6 view.
The device is enabled to exchange prefix SID information with a specified
peer.
The device is enabled to perform public route recursion based on the SIDs
carried by routes.
The device is enabled to add SIDs to public routes.
12. Run commit
13. Run quit
Exit the BGP IPv4 unicast address family view.
14. Run quit
Exit the BGP view.
Step 5 Enable IS-IS SRv6 on the PEs.

(2020-10-09)


3. Run commit
----End

After configuring public IPv4 over SRv6 BE, verify the configuration.
● Run the display bgp routing-table ipv4-address [ mask | mask-length ]

command to check BGP IPv4 routing table information.
● Run the display segment-routing ipv6 local-sid [ locator-name ]
forwarding command to check information about the SRv6 local SID table.
2.2.4.6 Configuring Public IPv6 over SRv6 BE

This section describes how to configure public IPv6 over SRv6 BE.
Usage Scenario
Public IPv6 over SRv6 BE allows SRv6 BE paths on a public network to carry public
IPv6 data. The implementation of public IPv6 over SRv6 BE involves establishing
SRv6 BE paths, advertising BGP routes, and forwarding data. As shown in Figure
2-86, PE1 and PE2 communicate through an IPv6 public network. An SRv6 BE path
can be deployed on the IPv6 public network to carry public IPv6 services.
Before configuring public IPv6 over SRv6 BE, complete the following tasks:


(2020-10-09)
Procedure
1. Run system-view
are specified.
peer.
7. Run commit
8. Run quit
9. Run quit
Exit the BGP view.
are specified.
4. Run peer ipv6-address connect-interface interface-type interface-number
connection.

(2020-10-09)
peer.
7. Run commit

8. Run quit

9. Run quit
Exit the BGP view.


A source address is specified for SRv6 encapsulation.

4. (Optional) Run opcode func-opcode end-dt6

configured. If a dynamically allocated SID and a manually configured SID
both exist, the manually configured SID takes effect. If you want to enable
dynamic End.DT6 SID allocation using the segment-routing ipv6 locator
locator-name command, skip this step.
5. Run quit

6. Run quit
Exit the SRv6 view.



The device is enabled to exchange prefix SID information with a specified

peer.
The device is enabled to perform public route recursion based on the SIDs
carried by routes.

(2020-10-09)

The device is enabled to add SIDs to public routes.
12. Run commit
13. Run quit
Exit the BGP IPv6 unicast address family view.
14. Run quit
Exit the BGP view.
Step 5 Enable IS-IS SRv6 on the PEs.
3. Run commit
----End

After configuring public IPv6 over SRv6 BE, verify the configuration.
● Run the display bgp ipv6 routing-table ipv6-address [ mask | mask-length ]
command to check BGP IPv6 routing table information.
● Run the display segment-routing ipv6 local-sid [ locator-name ]
forwarding command to check information about the SRv6 local SID table.
2.2.4.7 Configuring L3VPNv4 HoVPN over SRv6 BE

This section describes how to configure L3VPNv4 HoVPN over SRv6 BE.
Usage Scenario
Currently, the typical structure of a MAN consists of three layers: core layer,
aggregation layer, and access layer. To implement VPN functions on such a
hierarchical network for achieving end-to-end VPN data transmission and
improving the performance and scalability of the entire network, you need to
deploy hierarchical VPN solutions, among which the hierarchy of VPN (HoVPN)
solution is commonly used.
During network evolution, the core and aggregation layers may use different
forwarding modes, that is, SRv6 forwarding and MPLS forwarding. When the
HoVPN solution is used to implement hierarchical VPN deployment, the methods
used to forward L3VPNv4 data over a public network fall into three categories (as

(2020-10-09)
shown in Figure 2-87): L3VPNv4 over MPLS plus SRv6, L3VPNv4 over SRv6 plus
MPLS, and L3VPNv4 over SRv6 plus SRv6.
Figure 2-87 HoVPN solution networking
This section uses L3VPNv4 over SRv6 BE plus SRv6 BE as an example. On the
network shown in Figure 2-88, L3VPNv4 HoVPN over SRv6 BE is deployed. It
allows SRv6 BE paths on a public network to carry L3VPNv4 data on condition
that hierarchical VPN deployment is implemented through the HoVPN solution.
Figure 2-88 L3VPNv4 HoVPN over SRv6 BE networking
Before configuring L3VPNv4 HoVPN over SRv6 BE, complete the following tasks:

Procedure
Step 1 Configure IPv6 IS-IS on the UPE, SPE, and NPE. For configuration details, see
Configuring Basic IPv6 IS-IS Functions.
Step 2 Configure IPv4 route exchange between the UPE and CE1 and between the NPE
and CE2. For configuration details, see Configuring Route Exchange Between PEs
and CEs.
Step 3 Enable IS-IS SRv6 on the UPE, SPE, and NPE, and establish an MP-IBGP peer
relationship between the UPE and SPE and another one between the NPE and SPE.
In addition, configure a VPN instance, enable the IPv4 address family for the VPN

(2020-10-09)
instance, and configure SRv6 BE on each of the three devices. For configuration
details, see 2.2.4.1 Configuring L3VPNv4 over SRv6 BE.
Step 4 Specify the UPE as the peer of the SPE and configure the SPE to advertise the
default route to the UPE.
1. Run system-view
The BGP-VPNv4 address family view is displayed.
4. Run peer peerIpv6Addr upe
The UPE is specified as the peer, and a default route is automatically
generated.
If the peer peerIpv6Addr upe command is not run to automatically generate
a default route, you can manually configure a static route as a default route,
with the next hop being the public or private network address of the NPE
rather than the SPE itself. Otherwise, a traffic black hole may occur when a
fault occurs on the link between the SPE and NPE. Then, run the ip route-
static recursive-lookup inherit-label-route segment-routing-ipv6 or ipv6
route-static recursive-lookup inherit-label-route segment-routing-ipv6
command to recurse the default route to an SRv6 route.
5. Run peer ipv6-address default-originate vpn-instance vpn-instance-name
The SPE is configured to advertise the default route to the UPE.
6. Run commit
7. Run quit
Exit the BGP-VPNv4 address family view.
Step 5 Enable route regeneration on the SPE and configure the SPE to advertise
regenerated routes to the NPE.
2. Run advertise best-route route-reoriginate
Route regeneration is enabled.
3. Run quit
5. Run peer ipv6-address advertise route-reoriginated vpnv4
The SPE is configured to advertise regenerated routes in the BGP-VPNv4
address family to the NPE.

(2020-10-09)
6. Run commit
----End

After configuring L3VPNv4 HoVPN over SRv6 BE, verify the configuration.
● Run the display bgp vpnv4 all routing-table command to check BGP VPNv4
● Run the display ip routing-table vpn-instance vpn-instance command to
check the routing tables of the NPE and UPE.
2.2.5 Configuring an SRv6 TE Policy (Manual Configuration)

SRv6 TE Policy is a tunneling technology developed based on SRv6.
Before configuring an SRv6 TE Policy, configure an IGP to implement network
layer connectivity.
Context
An SRv6 TE Policy is a set of candidate paths consisting of one or more segment
lists, that is, segment ID (SID) lists. Each SID list identifies an end-to-end path
from the source to the destination, instructing a device to forward traffic through
the path rather than the shortest path computed using an IGP. The header of a
packet steered into an SRv6 TE Policy is augmented with an ordered list of
segments associated with that SR Policy, so that other devices on the network can
execute the instructions encapsulated into the list.
An SRv6 TE Policy consists of the following parts:
● Headend: node where an SRv6 TE Policy is generated.
● Color: extended community attribute of an SRv6 TE Policy. A BGP route can
recurse to an SRv6 TE Policy if the route has the same color attribute as the
policy.
● Endpoint: destination address of an SRv6 TE Policy.
Color and endpoint information is added to an SRv6 TE Policy through
configuration. In path computation, a forwarding path is computed based on the
color attribute that meets SLA requirements. The headend steers traffic into an
SRv6 TE Policy whose color and endpoint attributes match the color value and
next-hop address in the associated route, respectively. The color attribute defines
an application-level network SLA policy. This allows network paths to be planned
based on specific SLA requirements for services, realizing service value in a refined
manner and helping build new business models.
2.2.5.1 Configuring SRv6 SIDs

The headend can orchestrate network paths only if SIDs are allocated to
adjacencies and nodes on the network.

(2020-10-09)
Context
An SRv6 TE Policy can contain multiple candidate paths defined using segment
lists. SIDs, such as End and End.X SIDs, are mandatory for SRv6 TE Policies. The
SIDs can either be configured manually or generated dynamically using an IGP.
● In scenarios where SRv6 TE Policies are configured manually, if dynamic SIDs
are used for the SRv6 TE Policies, the SIDs may change after an IGP restart. In
this case, you need to manually adjust the SRv6 TE Policies for them to
remain up. This complicates maintenance and therefore dynamic SIDs cannot
be used on a large scale. You are advised to configure SIDs manually and not
to use dynamic SIDs.
● In scenarios where SRv6 TE Policies are delivered dynamically by a controller,
you are also advised to configure SIDs manually. Although the controller can
detect SID changes through BGP-LS, SIDs that are generated dynamically
using an IGP change randomly, complicating routine maintenance and fault
locating.
Procedure
Step 1 Enable SRv6.
1. Run system-view

SRv6 is enabled.
4. Run commit
Step 2 Configure SRv6 SIDs.
SRv6 paths are established based on SIDs. The SIDs can either be configured
manually or generated dynamically using IS-IS. Use either of the following
methods to configure SRv6 SIDs:
● Configure SIDs manually.

a. Run locator locator-name [ ipv6-prefix ipv6-address prefix-length
[ static static-length | args args-length ] * ]
b. Run opcode func-opcode end [ no-psp ]
A static End SID opcode is configured.
c. Run opcode func-opcode end-x interface interface-name nexthop
nexthop-address [ no-psp ]
A static End.X SID opcode is configured.

(2020-10-09)
d. Run quit
e. (Optional) Run timer end-x update-delay delay-time
A delay in delivering a static End.X SID to an FES table is configured.
The timer end-x update-delay command is mainly used in scenarios
where the outbound interface associated with a static End.X SID changes
from down to up and IS-IS routes reconverge.
f. Run quit
Exit the SRv6 view.
g. Run isis [ process-id ]
h. Run ipv6 enable topology ipv6
IPv6 is enabled for the IS-IS process.
i. Run cost-style { compatible [ relax-spf-limit ] | wide | wide-
compatible }
IS-IS wide metric is configured.
j. Run segment-routing ipv6 locator locator-name
k. Run commit
● Configure IS-IS to dynamically generate SIDs.
b. Run quit
c. Run quit
Exit the SRv6 view.
d. Run isis [ process-id ]
e. Run ipv6 enable topology ipv6
f. Run cost-style { compatible [ relax-spf-limit ] | wide | wide-
compatible }
g. Run segment-routing ipv6 locator locator-name
h. Run commit
----End

(2020-10-09)
2.2.5.2 Configuring an SRv6 TE Policy

An SRv6 TE Policy can either be configured manually or delivered by a controller.
This section describes how to configure an SRv6 TE Policy manually.
Context
SRv6 TE Policies are used to direct traffic to traverse an SRv6 TE network. Each
SRv6 TE Policy can have multiple candidate paths with different preferences. A
valid candidate path with the highest preference is selected as the primary path of
the SRv6 TE Policy, and a valid candidate path with the second highest preference
as the hot-standby path.
Procedure
Step 1 Configure a segment list.
1. Run system-view
3. Run segment-list list-name
A segment list is created for SRv6 TE Policy candidate paths, and the segment
list view is displayed.
4. Run index index sid ipv6 ipv6address
A next-hop SID is configured for the segment list.
You can run the command multiple times to configure multiple SIDs. The
system generates a SID stack by index index in ascending order. If a candidate
path in the SRv6 TE Policy is preferentially selected, traffic is forwarded using
the segment list of the candidate path. A maximum of 10 SIDs can be
configured for each segment list.
5. Run commit
Step 2 Configure an SRv6 TE Policy.
1. Run system-view
3. (Optional) Run ttl-mode{ uniform | pipe }
A TTL processing mode is configured for SRv6 TE Policies to which public IP
routes recurse.
4. (Optional) Run srv6-te-policy switch-delay switch-delaytime delete-delay
delete-delaytime
Global switching and deletion delays are configured.

(2020-10-09)
5. Run srv6-te-policy locator locator-name

A locator is configured for you to specify a binding SID for the SRv6 TE Policy
to be created.
6. Run srv6-te policy policy-name endpoint ipv6-address color color-value
An SRv6 TE Policy is created, and the SRv6 TE Policy view is displayed.
7. (Optional) Run binding-sid binding-sid
A binding SID is specified for the SRv6 TE Policy.
The value of binding-sid must be within the static range defined using the
locator locator-name [ ipv6-prefix ipv6-address prefix-length [ static static-
length | args args-length ] * ] command.
8. Run candidate-path preference preference
A candidate path with a specified preference is configured for the SRv6 TE
Policy.
Each SRv6 TE Policy supports multiple candidate paths. A larger preference
value indicates a higher candidate path preference. If multiple candidate
paths are configured, the one with the highest preference takes effect.
9. Run segment-list list-name [ weight weight-value | path-mtu mtu-value ] *
A segment list is referenced by the candidate path of an SRv6 TE Policy.

The segment list must have been created using the segment-list (Segment-
routing IPv6 view) command.
10. Run commit
----End

Extended Community, to a route through a route-policy, enabling the route to
recurse to an SRv6 TE Policy based on the color value and next-hop address in the
route.
Context
policy.
Procedure
1. Run system-view

(2020-10-09)

A route-policy is created and the route-policy view is displayed.
Clause.
The BGP Color Extended Community is configured.
The color value ranges from 0 to 4294967295. However, it can only be set to
0 at present.
5. Run commit
a. Run system-view
c. Run peer { ipv6-address | group-name } as-number as-number
{ import | export }
g. Run commit
a. Run system-view
d. Run l2vpn-family evpn

(2020-10-09)

{ import | export }
g. Run commit
a. Run system-view
c. Run ipv4-family
family.
family.
f. Run commit
a. Run system-view
c. Run ipv6-family
family.
family.
f. Run commit
----End

This section describes how to configure traffic steering to recurse a route to an
SRv6 TE Policy so that traffic can be forwarded through the path specified by the
SRv6 TE Policy.

(2020-10-09)
Context
After an SRv6 TE Policy is configured, traffic needs to be steered into the SRv6 TE
Policy for forwarding. This process is called traffic steering. Currently, SRv6 TE
Policies can be used for various services, such as BGP L3VPN and EVPN services.
Procedure
a. Run system-view
A tunnel policy is created, and the tunnel policy view is displayed.
d. Run tunnel select-seq ipv6 srv6-te-policy load-balance-number load-
balance-number
are configured.
NOTE
After the preceding configurations are complete, routes are allowed to recurse to
SRv6 TE Policies. If the color and next hop of a route are the same as the color
and endpoint of an SRv6 TE Policy, respectively, the route can successfully recurse
to the SRv6 TE Policy, and the traffic forwarded through the route can then be
steered into the SRv6 TE Policy.
e. Run commit
NOTE
EVPN VPWS and EVPN VPLS services do not support DSCP-based traffic steering.
a. Run system-view
b. Run segment-routing ipv6
c. Run mapping-policy color color-value
An SRv6 mapping policy is created, and the SRv6 mapping policy view is
displayed.
d. (Optional) Run description description-value
Description information is configured for the SRv6 mapping policy.
e. Run match-type srv6-te-policy dscp
The mapping type of the SRv6 mapping policy is set to DSCP.

(2020-10-09)
f. Run color color-value match dscp { ipv4 | ipv6 } { { dscpBegin [ to

dscpEnd ] } &<1-10> | default }
The mapping between the color values of SRv6 TE Policies in an SRv6 TE
Policy group and the DSCP values of packets to be steered into the SRv6
TE Policies is configured.
In the SRv6 mapping policy view, a separate color-DSCP mapping can be
configured for each of the IPv4 and IPv6 address families. In the same
address family (IPv4 or IPv6), each DSCP value can be mapped to only
one color value. Furthermore, only the color value of an up SRv6 TE
Policy can be mapped to a DSCP value.
During IPv4/IPv6 traffic forwarding, packets with DSCP values are
matched against SRv6 TE Policies in an SRv6 TE Policy group in the
following order:
1. The packets are first strictly matched against the SRv6 TE Policy
carrying the color value mapped to the DSCP value of these packets in
the corresponding address family.
2. If the matching fails, the packets are matched against the SRv6 TE
Policy with the default priority in the corresponding address family.
Policy carrying the color value mapped to the smallest DSCP value in the
corresponding address family.
Policy with the default priority in the other address family.
5. If the matching fails, the packets are directly steered into the SRv6 TE
other address family.
g. Run quit
Return to the SRv6 view.
h. Run quit
i. Run tunnel-policy policy-name
j. (Optional) Run description description-information
k. Run tunnel select-seq ipv6 srv6-te-policy-group load-balance-number
loadBalanceNumber
A tunnel selection policy is configured.
l. Run commit
Step 2 Configure a service to recurse to an SRv6 TE Policy.
● Configure a BGP L3VPN service to recurse to an SRv6 TE Policy.
a. Run system-view

(2020-10-09)

c. Run ipv4-family
e. Run commit
● Configure an EVPN service to recurse to an SRv6 TE Policy.
BD-EVPN Functions.
steps:
a. Run system-view
e. Run commit
a. Run system-view
d. Run commit
a. Run system-view
displayed.
mode.

(2020-10-09)
d. Run commit
steps:
a. Run system-view
The basic EVPN instance view is displayed.
d. Run commit
----End
2.2.5.5 Verifying the SRv6 TE Policy Configuration

After configuring SRv6 TE Policies, verify the configuration.
Prerequisites
SRv6 TE Policies have been configured.
Procedure
Step 1 Run the display srv6-te policy [ endpoint endpoint-ip color color-value | policy-
name name-value | binding-sid binding-sid ] command to check SRv6 TE Policy
details.
Step 2 Run the display srv6-te policy statistics command to check SRv6 TE Policy
statistics.
Step 3 Run the display srv6-te policy status { endpoint endpoint-ip color color-value |
policy-name name-value | binding-sid binding-sid } command to check SRv6 TE
Policy status to determine the reason why a specified SRv6 TE Policy cannot go up.
Step 4 Run the display srv6-te policy last-down-reason { endpoint endpoint-ip color
color-value | policy-name name-value | binding-sid binding-sid } command to
check records about events where SRv6 TE Policies or segment lists in SRv6 TE
Policies go down.
Step 5 Run the ping srv6-te policy { policy-name policyname | endpoint-ip
endpointipv6 color colorid | binding-sid bsid } [ end-op endop ] [ -a sourceaddr6
| -c count | -m interval | -s packetsize | -t timeout | -tc tc | -h hoplimit ] *
command with the policy-name policyname, endpoint-ip endpointipv6 color
colorid, or binding-sid bsid parameter configured to ping the specified SRv6 TE
Policy to check its connectivity.
Step 6 Run the display srv6-te policy group command to check SRv6 TE Policy group
details.
----End

(2020-10-09)
2.2.6 Configuring an SRv6 TE Policy (Dynamic Delivery by a

Controller)
SRv6 TE Policy is a tunneling technology developed based on SRv6.
Before configuring an SRv6 TE Policy, configure an IGP to implement network
layer connectivity.
Context
An SRv6 TE Policy can either be manually configured on a forwarder through CLI
or NETCONF, or be delivered to a forwarder after being dynamically generated
through a protocol, such as BGP, on a controller. The dynamic mode facilitates
network deployment.
The process for a controller to dynamically generate and deliver an SRv6 TE Policy
to a forwarder is as follows:

2. The controller and headend forwarder establish an IPv6 SR Policy address
family-specific BGP peer relationship.
2.2.6.1 Configuring SRv6 SIDs

The headend can orchestrate network paths only if SIDs are allocated to
adjacencies and nodes on the network.
Context
An SRv6 TE Policy can contain multiple candidate paths defined using segment
lists. SIDs, such as End and End.X SIDs, are mandatory for SRv6 TE Policies. The
SIDs can either be configured manually or generated dynamically using an IGP.
● In scenarios where SRv6 TE Policies are configured manually, if dynamic SIDs
are used for the SRv6 TE Policies, the SIDs may change after an IGP restart. In
this case, you need to manually adjust the SRv6 TE Policies for them to
remain up. This complicates maintenance and therefore prevents dynamic
SIDs from being used on a large scale. You are advised to configure SIDs
manually and not to use dynamic SIDs.
● In scenarios where SRv6 TE Policies are delivered dynamically by a controller,
you are also advised to configure SIDs manually. Although the controller can
detect SID changes through BGP-LS, SIDs that are generated dynamically
using an IGP change randomly, complicating routine maintenance and fault
locating.

(2020-10-09)
Procedure
Step 1 Enable SRv6.
1. Run system-view
3. Run te ipv6-router-id ipv6-address
A global TE IPv6 router ID is configured.
5. Run commit
Step 2 Configure SRv6 SIDs.
SRv6 tunnels are established based on SIDs. The SIDs can either be configured
manually or generated dynamically using IS-IS. Use either of the following
methods to configure SRv6 SIDs:
● Configure SIDs manually.
b. Run opcode func-opcode end [ no-psp ]
A static End SID opcode is configured.
c. Run opcode func-opcode end-x interface interface-name nexthop
nexthop-address [ no-psp ]
A static End.X SID opcode is configured.
d. Run quit
e. (Optional) Run timer end-x update-delay delay-time
A delay in delivering a static End.X SID to an FES table is configured.
The timer end-x update-delay command is mainly used in scenarios
where the outbound interface associated with a static End.X SID changes
from down to up and IS-IS routes reconverge.
f. Run quit
Exit the SRv6 view.
g. Run isis [ process-id ]
h. Run ipv6 enable topology ipv6

(2020-10-09)
i. Run cost-style { compatible [ relax-spf-limit ] | wide | wide-

compatible }
j. Run segment-routing ipv6 locator locator-name
k. Run commit
● Configure IS-IS to dynamically generate SIDs.
b. Run quit
c. Run quit
Exit the SRv6 view.
d. Run isis [ process-id ]
e. Run ipv6 enable topology ipv6
f. Run cost-style { compatible [ relax-spf-limit ] | wide | wide-
compatible }
g. Run segment-routing ipv6 locator locator-name
h. Run commit
----End
2.2.6.2 Configuring TE Attributes

TE attributes configured for links are transmitted to IS-IS. After IS-IS advertises the
attributes to BGP-LS, BGP-LS transmits the attributes to a controller, enabling the
controller to adjust links based on the TE attributes during SRv6 TE Policy
computation.
Context
TE link attributes are as follows:
● Link bandwidth
This attribute is mandatory if you want to limit the bandwidth of a path of an
SRv6 TE Policy.
● Link-specific TE metric

(2020-10-09)
The IGP metric or link-specific TE metric can be used for SRv6 TE Policy
computation by a controller. This makes SRv6 TE Policy computation more
independent of the IGP, facilitating path control.
● Administrative group and affinity attribute
The affinity attribute of an SRv6 TE Policy determines the link attributes used
by the policy. The administrative group and affinity attribute are used
together to determine the links that can be used by the policy.
● SRLG
A shared risk link group (SRLG) is a group of links that share a public physical
resource, such as an optical fiber. Links in an SRLG are at the same risk of
faults. If one of the links fails, other links in the SRLG also fail.
An SRLG enhances SRv6 TE Policy reliability on a network with CR-LSP hot
standby or TE FRR enabled. Links that share the same physical resource have
the same risk. For example, links on an interface and its sub-interfaces are in
an SRLG. The interface and its sub-interfaces have the same risk. If the
interface goes down, its sub-interfaces will also go down. If the link of the
primary path of an SRv6 TE Policy and the links of the backup paths of the
SRv6 TE Policy are in an SRLG and the primary path goes down, the backup
paths will most likely go down.
Procedure
● Enable TE attributes.
a. Run system-view
b. Run te attribute enable
The function to convert MPLS TE attributes into TE attributes and to
configure TE attributes is enabled.
If MPLS TE has been enabled, this function converts MPLS TE attributes
into TE attributes. You can also configure new TE attributes. The
converted TE attributes can be used for both MPLS TE tunnels and SRv6
TE Policies.
● (Optional) Configure link bandwidth.
In real-world applications, link bandwidth only needs to be configured for
outbound interfaces along the links of an SRv6 TE Policy that requires
sufficient bandwidth.
a. Run system-view
b. Run interface interface-type interface-number
The interface view of a TE link is displayed.
c. Run te bandwidth max-reservable-bandwidth max-bw-value
The maximum reservable link bandwidth is configured.
d. Run te bandwidth bc0 bc0-bandwidth
The BC bandwidth is configured for the link.

(2020-10-09)
NOTE
● The maximum reservable link bandwidth cannot be higher than the physical
link bandwidth. You are advised to set the maximum reservable link
bandwidth to be less than or equal to 80% of the physical link bandwidth.
● The BC0 bandwidth cannot be higher than the maximum reservable link
bandwidth.
e. Run commit
● (Optional) Configure a TE metric value for a link.
a. Run system-view
c. Run te metric value
A TE metric value is configured for the link.
d. Run commit
● (Optional) Configure the administrative group and affinity attribute in
hexadecimal format.
a. Run system-view
c. Run te link administrative group group-value
A TE link administrative group is configured.
d. Run commit
● (Optional) Configure the administrative group and affinity attribute through
affinity names and the group name.
a. Run system-view
b. Run path-constraint affinity-mapping
An affinity name mapping template is configured, and the template view
is displayed.
This template must be configured on each node that is involved in
computing an SRv6 TE Policy, and the same mappings between affinity
names and values must be configured on each node.
c. Run attribute bit-name bit-sequence bit-number
Mappings between affinity bits and names are configured.

(2020-10-09)
This step can be performed to configure one affinity bit. Repeat this step
to configure more affinity bits. You can configure some or all the 32 bits
in the affinity attribute.
d. Run quit

e. Run interface interface-type interface-number

f. Run te link administrative group name name-string &<1-32>
A TE link administrative group is configured.
The bit-name value must be in the range specified in the affinity name
mapping template.
g. Run commit

● (Optional) Configure an SRLG.
a. Run system-view


c. Run te srlg srlg-number
The interface is added to an SRLG.
On a network with hot standby or TE FRR, the SRLG attribute needs to be

configured for the outbound interface of the ingress on an SRv6 TE Policy
as well as other members in the SRLG. A link joins an SRLG after the
SRLG attribute is configured on an outbound interface of the link.
NOTE
To delete the SRLG configuration from all interfaces on a device, run the undo te srlg
all-config command.
d. Run commit
----End
2.2.6.3 Configuring IS-IS Topology Advertisement to BGP-LS

After IS-IS topology information is advertised to BGP-LS, BGP-LS reports the
topology information to a controller for path planning.
Procedure

(2020-10-09)

Step 3 Run ipv6 enable topology ipv6
Step 4 Run cost-style { compatible [ relax-spf-limit ] | wide | wide-compatible }
Step 5 Run ipv6 bgp-ls enable [ level-1 | level-2 | level-1-2 ]
IS-IS IPv6 topology advertisement is enabled.
Step 6 Run ipv6 advertise link attributes
The IS-IS process is enabled to advertise IPv6 link attribute TLVs in LSPs. IPv6 link
attributes include the IPv6 address and interface index.
----End
2.2.6.4 Configuring BGP Peer Relationships Between the Controller and

Forwarder
This section describes how to configure BGP peer relationships between a
controller and a forwarder, so that the controller can deliver SRv6 TE Policies to
the forwarder. This improves SRv6 TE Policy deployment efficiency.
Context
The process for a controller to dynamically generate and deliver an SRv6 TE Policy
to a forwarder is as follows:
2. The controller and headend forwarder establish an IPv6 SR Policy address
family-specific BGP peer relationship.
To implement the preceding operations, you need to establish a BGP-LS peer
relationship and a BGP IPv6 SR Policy peer relationship between the controller and
the specified forwarder.
Procedure
Step 1 Configure a BGP-LS peer relationship.
information collection simpler and more efficient. You must configure a BGP-LS
peer relationship between the controller and forwarder, so that topology
information can be properly reported from the forwarder to the controller. This
example provides the procedure for configuring BGP-LS on the forwarder. The
procedure on the controller is similar to that on the forwarder.

(2020-10-09)
1. Run system-view

BGP is enabled and the BGP view is displayed.

3. Run peer { group-name | ipv6-address } as-number { as-number-plain | as-
number-dot }

4. Run link-state-family unicast
BGP-LS is enabled and the BGP-LS address family view is displayed.

5. Run peer { group-name | ipv6-address } enable
A specified BGP-LS peer is enabled.

6. Run commit
Step 2 Configure a BGP IPv6 SR Policy peer relationship.
This example provides the procedure for configuring a BGP IPv6 SR Policy peer
relationship on the forwarder. The procedure on the controller is similar to that on
the forwarder.
1. Run system-view

BGP is enabled and the BGP view is displayed.

3. Run peer { group-name | ipv6-address } as-number { as-number-plain | as-
number-dot }

4. Run ipv6-family sr-policy
The BGP IPv6 SR Policy address family view is displayed.

5. Run peer { group-name | ipv6-address } enable
A specified BGP IPv6 SR Policy peer is enabled.

6. Run commit
----End
2.2.6.5 Configuring SRv6 TE Policy Status Advertisement to BGP-LS

Configure a forwarder to advertise SRv6 TE Policy status to BGP-LS. BGP-LS can
then advertise the status to peers.

(2020-10-09)
Procedure
Step 2 Run segment-routing ipv6
Step 3 Run srv6-te-policy bgp-ls enable
The forwarder is enabled to advertise SRv6 TE Policy status to BGP-LS.
Step 4 Run commit
----End

Extended Community, to a route through a route-policy, enabling the route to
recurse to an SRv6 TE Policy based on the color value and next-hop address in the
route.
Context
policy.
Procedure
1. Run system-view
A route-policy is created and the route-policy view is displayed.
Clause.
The color value ranges from 0 to 4294967295. However, it can only be set to
0 at present.

(2020-10-09)
5. Run commit
a. Run system-view
{ import | export }
g. Run commit
a. Run system-view
d. Run l2vpn-family evpn
{ import | export }
g. Run commit
a. Run system-view

(2020-10-09)
c. Run ipv4-family
family.
family.
f. Run commit
a. Run system-view
c. Run ipv6-family
family.
family.
f. Run commit
----End

This section describes how to configure traffic steering to recurse a route to an
SRv6 TE Policy so that traffic can be forwarded through the path specified by the
SRv6 TE Policy.
Context
After an SRv6 TE Policy is configured, traffic needs to be steered into the SRv6 TE
Policy for forwarding. This process is called traffic steering. Currently, SRv6 TE
Policies can be used for various services, such as BGP L3VPN and EVPN services.
Procedure

(2020-10-09)
a. Run system-view
d. Run tunnel select-seq ipv6 srv6-te-policy load-balance-number load-
balance-number
are configured.
NOTE
After the preceding configurations are complete, routes are allowed to recurse to
SRv6 TE Policies. If the color and next hop of a route are the same as the color
and endpoint of an SRv6 TE Policy, respectively, the route can successfully recurse
to the SRv6 TE Policy, and the traffic forwarded through the route can then be
steered into the SRv6 TE Policy.
e. Run commit
NOTE
EVPN VPWS and EVPN VPLS services do not support DSCP-based traffic steering.
a. Run system-view
c. Run mapping-policy color color-value
An SRv6 mapping policy is created, and the SRv6 mapping policy view is
displayed.
d. (Optional) Run description description-value
Description information is configured for the SRv6 mapping policy.
e. Run match-type srv6-te-policy dscp
The mapping type of the SRv6 mapping policy is set to DSCP.
f. Run color color-value match dscp { ipv4 | ipv6 } { { dscpBegin [ to
dscpEnd ] } &<1-10> | default }
The mapping between the color values of SRv6 TE Policies in an SRv6 TE
Policy group and the DSCP values of packets to be steered into the SRv6
TE Policies is configured.
In the SRv6 mapping policy view, a separate color-DSCP mapping can be
configured for each of the IPv4 and IPv6 address families. In the same
address family (IPv4 or IPv6), each DSCP value can be mapped to only
one color value. Furthermore, only the color value of an up SRv6 TE
Policy can be mapped to a DSCP value.

(2020-10-09)
During IPv4/IPv6 traffic forwarding, packets with DSCP values are

matched against SRv6 TE Policies in an SRv6 TE Policy group in the
following order:
1. The packets are first strictly matched against the SRv6 TE Policy
carrying the color value mapped to the DSCP value of these packets in
the corresponding address family.
Policy with the default priority in the corresponding address family.
corresponding address family.
Policy with the default priority in the other address family.
5. If the matching fails, the packets are directly steered into the SRv6 TE
other address family.
g. Run quit
Return to the SRv6 view.
h. Run quit
i. Run tunnel-policy policy-name
j. (Optional) Run description description-information
k. Run tunnel select-seq ipv6 srv6-te-policy-group load-balance-number
loadBalanceNumber
A tunnel selection policy is configured.
l. Run commit
Step 2 Configure a service to recurse to an SRv6 TE Policy.
● Configure a BGP L3VPN service to recurse to an SRv6 TE Policy.
a. Run system-view
c. Run ipv4-family
e. Run commit

(2020-10-09)
● Configure an EVPN service to recurse to an SRv6 TE Policy.

BD-EVPN Functions.
steps:
a. Run system-view
e. Run commit
a. Run system-view
d. Run commit
a. Run system-view
displayed.
mode.
d. Run commit
steps:
a. Run system-view

(2020-10-09)
The basic EVPN instance view is displayed.

d. Run commit
----End
2.2.6.8 Verifying the SRv6 TE Policy Configuration

After configuring SRv6 TE Policies, verify the configuration.
Prerequisites
SRv6 TE Policies have been configured.
Procedure
Step 1 Run the display srv6-te policy [ endpoint endpoint-ip color color-value | policy-
name name-value | binding-sid binding-sid ] command to check SRv6 TE Policy
details.
Step 2 Run the display srv6-te policy statistics command to check SRv6 TE Policy
statistics.
Step 3 Run the display srv6-te policy status { endpoint endpoint-ip color color-value |
policy-name name-value | binding-sid binding-sid } command to check SRv6 TE
Policy status to determine the reason why a specified SRv6 TE Policy cannot go up.
Step 4 Run the display srv6-te policy last-down-reason { endpoint endpoint-ip color
color-value | policy-name name-value | binding-sid binding-sid } command to
check records about events where SRv6 TE Policies or segment lists in SRv6 TE
Policies go down.
Step 5 Run the ping srv6-te policy { policy-name policyname | endpoint-ip
endpointipv6 color colorid | binding-sid bsid } [ end-op endop ] [ -a sourceaddr6
| -c count | -m interval | -s packetsize | -t timeout | -tc tc | -h hoplimit ] *
command with the policy-name policyname, endpoint-ip endpointipv6 color
colorid, or binding-sid bsid parameter configured to ping the specified SRv6 TE
Policy to check its connectivity.
Step 6 Run the display srv6-te policy group command to check SRv6 TE Policy group
details.
----End
2.2.7 Configuring SRv6 TE Policy-related Services

This section describes how to configure SRv6 TE Policy-related services.
2.2.7.1 Configuring L3VPNv4 over SRv6 TE Policy

This section describes how to configure L3VPNv4 over SRv6 TE Policy.

(2020-10-09)
Usage Scenario
L3VPNv4 over SRv6 TE Policy uses public SRv6 TE Policies to carry L3VPNv4 data.
The implementation of L3VPNv4 over SRv6 TE Policy involves establishing SRv6 TE
Policies, advertising VPN routes, and forwarding data.
network. The VPN is a traditional IPv4 network. SRv6 TE Policies can be deployed
on the IPv6 public network to carry L3VPNv4 services on the VPN.
Figure 2-89 L3VPNv4 over SRv6 TE Policy networking
Before configuring L3VPNv4 over SRv6 TE Policy, complete the following tasks:
Procedure
Step 1 Configure IPv6 IS-IS on each PE and P. For details, see Configuring Basic IPv6 IS-IS
Functions.
Step 2 Configure a VPN instance on each PE and enable the IPv4 address family for the
instance.
1. Run system-view
3. Run ipv4-family
extcommunity ]

(2020-10-09)
VPN targets are configured for the VPN instance IPv4 address family.
6. (Optional) Run default-color color-value
The default color value is specified for the L3VPNv4 service to recurse to an
SRv6 TE Policy.
If a remote VPN route without carrying the Color Extended Community is

leaked to a local VPN instance, the default color value is used for the
recursion.
7. Run commit

8. Run quit

9. Run quit

The view of the interface to which the VPN instance needs to be bound is
displayed.
The VPN instance is bound to the interface.
NOTE
Running the ip binding vpn-instance command deletes Layer 3 (including IPv4 and
IPv6) configurations, such as IP address and routing protocol configurations, on the
involved interface. If needed, reconfigure them after running the command.
An IP address is configured for the interface.
Some Layer 3 features such as route exchange between the PE and CE can be
configured only after an IP address is configured for the VPN interface on the
PE.
13. Run commit

14. Run quit
Step 3 Configure IPv4 route exchange between the PE and CE. For details, see
Configuring Route Exchange Between PEs and CEs.



(2020-10-09)

The device is enabled to exchange VPN-IPv4 routes with a specified peer.
The device is enabled to exchange IPv4 prefix SID information with a specified
IPv6 peer.
8. Run commit
9. Run quit
10. Run quit
Exit the BGP view.
Step 5 Configure the device to add SIDs to VPN routes.
name
configured. If you want to enable dynamic End.DT4 SID allocation using the
segment-routing ipv6 locator locator-name command, skip this step.
5. Run quit
6. Run quit
Exit the SRv6 view.

(2020-10-09)

The device is enabled to add SIDs to VPN routes.
If auto-sid-disable is not specified, dynamic SID allocation is supported. If
there are static SIDs in the range of the locator specified using locator-name,
the static SIDs are used. Otherwise, dynamically allocated SIDs are used.
If auto-sid-disable is specified, BGP does not dynamically allocate SIDs.
10. Run segment-routing ipv6 traffic-engineer [ best-effort ]
The device is enabled to perform VPN route recursion based on the SIDs
carried in the routes.
If an SRv6 BE path exists on the network, you can set the best-effort
parameter, allowing the SRv6 BE path to function as a best-effort path in the
case of an SRv6 TE Policy fault.
11. Run commit
12. Run quit
13. Run quit
Exit the BGP view.
Step 6 Configure an SRv6 TE Policy. For details, see 2.2.5 Configuring an SRv6 TE Policy
(Manual Configuration) or 2.2.6 Configuring an SRv6 TE Policy (Dynamic
Delivery by a Controller).
Step 7 Configure VPNv4 routes to recurse to the SRv6 TE Policy.
A route-policy node is created, and the route-policy view is displayed.
Clause.
4. Run quit
Exit the route-policy view.

(2020-10-09)
7. Run peer ipv6-address route-policy route-policy-name { import | export }

8. Run quit
9. Run quit
Exit the BGP view.
10. Run tunnel-policy policy-name
11. (Optional) Run description description-information
12. Run tunnel select-seq ipv6 srv6-te-policy load-balance-number load-
balance-number
The tunnel selection sequence and number of tunnels for load balancing are
configured.
13. Run quit
Exit the tunnel policy view.
15. Run ipv4-family
16. Run tnl-policy policy-name
17. Run commit
----End

After configuring L3VPNv4 over SRv6 TE Policy, verify the configuration.
● Run the display segment-routing ipv6 local-sid { end | end-x | end-dt4 }
[ sid ] forwarding command to check information about the SRv6 local SID
table.
● Run the display ip vpn-instance vpn-instance-name tunnel-info nexthop
nexthopIpv6Addr command to check information about the tunnel to which
the route with the specified next hop recurses in each address family of the
current VPN instance.
● Run the ping srv6-te policy { policy-name policyname | endpoint-ip
endpointipv6 color colorid | binding-sid bsid } [ end-op endop ] [ -a
sourceaddr6 | -c count | -m interval | -s packetsize | -t timeout | -tc tc | -h

(2020-10-09)
hoplimit ] * command with the policy-name policyname, endpoint-ip

endpointipv6 color colorid, or binding-sid bsid parameter to initiate a ping
operation on the specified SRv6 TE Policy for connectivity check.
● Run the ping command to check the connectivity between CEs.
2.2.7.2 Configuring EVPN L3VPNv4 over SRv6 TE Policy

This section describes how to configure EVPN L3VPNv4 over SRv6 TE Policy so that
EVPN L3VPNv4 services can be carried over SRv6 TE Policies.
Usage Scenario
EVPN L3VPNv4 over SRv6 TE Policy uses public SRv6 TE Policies to carry EVPN
L3VPNv4 services. As shown in Figure 2-90, PE1 and PE2 communicate through an
IPv6 public network. An SRv6 TE Policy is configured on the network to carry
EVPN L3VPNv4 services.
Figure 2-90 EVPN L3VPNv4 over SRv6 TE Policy networking
Before configuring EVPN L3VPNv4 over SRv6 TE Policy, complete the following
tasks:
● Configure an SRv6 TE Policy manually or use a controller to dynamically
deliver an SRv6 TE Policy.
You need to apply a tunnel policy to a specified EVPN L3VPNv4 instance when
configuring traffic steering.
Procedure
2. Run ipv4-family

(2020-10-09)

extcommunity ] evpn
5. (Optional) Run default-color color-value evpn
SRv6 TE Policy.
If a remote EVPN route without carrying the Color Extended Community is
recursion.
8. Run quit
9. Run quit
1. Run commit



An IPv4 address is configured for the interface.

4. Run quit

5. Run commit
Step 3 Configure BGP EVPN peer relationships.

(2020-10-09)
NOTE

number-dot }
A remote PE is configured as a peer.
NOTE
command is run on only one end, the BGP connection may fail to be established.

5. Run import-route { direct | isis process-id | static | ospf process-id | rip
process-id } [ med med | route-policy route-policy-name ] *
Routes of other protocols are imported to the BGP-VPN instance IPv4 address
family. To advertise host IP routes, configure import of direct routes. To
advertise routes on the network segment where the host resides, use a
dynamic routing protocol (such as OSPF) to advertise routes on the network
segment and then perform this step to import the routes of the dynamic
routing protocol.
host resides.

7. Run quit


The device is enabled to exchange EVPN routes with a specified peer or peer
group.

(2020-10-09)

11. Run quit
12. Run quit
Exit the BGP view.
13. Run commit
Step 4 On each PE, configure EVPN L3VPNv4 services to recurse to an SRv6 TE Policy.
A source address is specified for SRv6 VPN encapsulation.
name evpn
Alternatively, run the opcode func-opcode end-dx4 vpn-instance vpn-
instance-name evpn interface interface-type interface-number nexthop
nexthop-address command to configure a static SID opcode.
In EVPN scenarios, end-dx4 is used to allocate SIDs based on interfaces to
which VPN instances are bound, and end-dt4 is used to allocate SIDs based
on VPN instances.
End.DT4 and End.DX4 SIDs can be either dynamically allocated by BGP or
manually configured. If you want to enable dynamic End.DT4 and End.DX4
SID allocation using the segment-routing ipv6 locator locator-name
command, skip this step.
5. Run quit
6. Run quit
Exit the SRv6 view.
The device is enabled to add SIDs to VPN routes before sending the routes to
EVPN.

(2020-10-09)
10. Run segment-routing ipv6 traffic-engineer [ best-effort ] evpn
The function to recurse EVPN L3VPNv4 services to SRv6 TE Policies is enabled.
11. (Optional) Run segment-routing ipv6 apply-sid all-nexthop evpn
The device is configured to allocate SIDs to BGP VPN IPv4 routes based on all
next hops, thereby implementing SID-based load balancing.
To configure the device to allocate a SID to a BGP VPN IPv4 route with a
specified next hop, run the segment-routing ipv6 apply-sid specify-nexthop
evpn command. Then, run the nexthop nexthop-address interface
{ interface-name | interfaceType interfaceNum } command to specify a next
hop and an outbound interface.
12. Run commit
----End

After configuring EVPN L3VPNv4 over SRv6 TE Policy, verify the configuration.

length ] ] command to check BGP VPNv4 route information. The command
output shows that the value of Relay Tunnel Out-Interface is SRv6 TE
Policy.
● Run the display ip routing-table vpn-instance vpn-instance-name command
to check information about IPv4 VPN routes received from the remote end.
2.2.7.3 Configuring EVPN L3VPNv6 over SRv6 TE Policy

This section describes how to configure EVPN L3VPNv6 over SRv6 TE Policy so that
EVPN L3VPNv6 services can be carried over SRv6 TE Policies.
Usage Scenario
EVPN L3VPNv6 over SRv6 TE Policy uses public SRv6 TE Policies to carry EVPN
L3VPNv6 services. As shown in Figure 2-91, PE1 and PE2 communicate through an
IPv6 public network. An SRv6 TE Policy is configured on the network to carry
EVPN L3VPNv6 services.

(2020-10-09)
Before configuring EVPN L3VPNv6 over SRv6 TE Policy, complete the following
tasks:
You need to apply a tunnel policy to a specified EVPN L3VPNv6 instance when
configuring traffic steering.
Procedure
2. Run ipv6-family
A VPN instance IPv6 address family is enabled, and the view of this address
A route distinguisher (RD) is configured for the VPN instance IPv6 address
family.
extcommunity ] evpn
5. (Optional) Run default-color color-value evpn
SRv6 TE Policy.
recursion.

(2020-10-09)
8. Run quit
9. Run quit
1. Run commit



3. Run ipv6 enable

4. Run ipv6 address { ipv6-address prefix-length | ipv6-address/prefix-length }
An IPv6 address is configured for the interface.

5. Run quit

6. Run commit
Step 3 Configure BGP EVPN peers.

NOTE

number-dot }

(2020-10-09)

NOTE
command is run on one end only, the BGP connection may fail to be established.

5. Run import-route { direct | isis process-id | static | ospfv3 process-id | ripng
process-id } [ med med | route-policy route-policy-name ] *
Routes of other protocols are imported to the BGP-VPN instance IPv6 address
family. To advertise host IP routes, configure import of direct routes. To
advertise routes on the network segment where the host resides, use a
dynamic routing protocol (such as OSPFv3) to advertise routes on the
network segment and then perform this step to import the routes of the
dynamic routing protocol.
host resides.

7. Run quit


The device is enabled to exchange EVPN routes with the specified peer or
peer group.

attributes to the specified peer or peer group.
11. Run quit

12. Run quit
Exit the BGP view.

13. Run commit
Step 4 On each PE, configure EVPN L3VPNv6 services to recurse to an SRv6 TE Policy.

(2020-10-09)

name evpn
Alternatively, run the opcode func-opcode end-dx6 vpn-instance vpn-
instance-name evpn interface interface-type interface-number nexthop
nexthop-ipv6-address command to configure a static SID opcode.
In EVPN scenarios, end-dx6 is used to allocate SIDs based on interfaces to
which VPN instances are bound, and end-dt6 is used to allocate SIDs based
on VPN instances.
End.DT6 and End.DX6 SIDs can be either dynamically allocated by BGP or
manually configured. If you want to enable dynamic End.DT6 and End.DX6
SID allocation using the segment-routing ipv6 locator locator-name
command, skip this step.
5. Run quit
6. Run quit
Exit the SRv6 view.
The device is enabled to add SIDs to VPN routes when propagating the routes
to the EVPN peer.
10. Run segment-routing ipv6 traffic-engineer [ best-effort ] evpn
The device is enabled to recurse EVPN L3VPNv6 services to SRv6 TE Policies.
11. (Optional) Configure the device to allocate SIDs to BGP VPN IPv6 routes
based on next hops, thereby implementing SID-based load balancing.
– To configure the device to allocate SIDs to BGP VPN IPv6 routes based on
all next hops, run the segment-routing ipv6 apply-sid all-nexthop evpn
command.

(2020-10-09)
– To configure the device to allocate a SID to a BGP VPN IPv6 route with a
specified next hop, run the segment-routing ipv6 apply-sid specify-
nexthop evpn command. Then, run the nexthop nexthop-address
interface { interface-name | interfaceType interfaceNum } command to
specify a next hop and an outbound interface.
12. Run commit
----End

After configuring EVPN L3VPNv6 over SRv6 TE Policy, verify the configuration.
length ] ] command to check BGP VPNv6 route information. The command
output shows that the value of Relay Tunnel Out-Interface is SRv6 TE
Policy.
● Run the display ipv6 routing-table vpn-instance vpn-instance-name
command to check information about IPv6 VPN routes received from the
remote end.
2.2.7.4 Configuring EVPN VPWS over SRv6 TE Policy

This section describes how to configure EVPN virtual private wire service (VPWS)
over SRv6 TE Policy so that EVPN VPWSs can be carried over SRv6 TE Policies.
Usage Scenario
EVPN VPWS over SRv6 TE Policy uses public SRv6 TE Policies to carry EVPN
VPWSs. As shown in Figure 2-92, PE1 and PE2 communicate through an IPv6
public network. An SRv6 TE Policy is configured on the network to carry EVPN
VPWSs.

(2020-10-09)
Figure 2-92 EVPN VPWS over SRv6 TE Policy networking
Before configuring EVPN VPWS over SRv6 TE Policy, complete the following tasks:
You need to apply a tunnel policy to a specified EVPN instance that works in
EVPN VPWS mode when configuring traffic steering.
Procedure
Step 1 Configure EVPN and EVPL instances on each PE.
1. Run system-view
2. Run evpn source-address ip-address
In scenarios where a CE is dual-homed or multi-homed to PEs, you need to
configure an EVPN source address on each PE to generate route distinguishers
(RDs) for Ethernet segment routes and Ethernet auto-discovery per ES routes.
An EVPN instance that works in VPWS mode is created.
different EVPN instances on a PE must be different.
NOTE
After being configured, an RD cannot be modified but can be deleted. If the RD of an

EVPN instance is deleted, VPN targets configured for the EVPN instance are also
deleted.
extcommunity ]

(2020-10-09)
receiving and advertisement of EVPN routes. A maximum of eight VPN targets
can be configured using the vpn-target command. To configure more VPN
targets for an EVPN instance address family, run the vpn-target command
multiple times.
NOTE
An RT of an Ethernet segment route is generated using the middle six bytes of an ESI.
For example, if the ESI is 0011.1001.1001.1001.1002, the Ethernet segment route uses
11.1001.1001.10 as its RT.
The default color value is specified for the EVPN service to recurse to an SRv6
TE Policy.
leaked to a local EVPN instance, the default color value is used for the
recursion.
7. Run quit
An EVPL instance that works in SRv6 mode is created.
A specified EVPN instance that works in VPWS mode is bound to the current
EVPL instance.
10. Run local-service-id service-id remote-service-id service-id
remote service IDs.
11. (Optional) Run mtu-match ignore
The MTU matching check is ignored for the EVPL instance. In scenarios where
a Huawei device interworks with a non-Huawei device through an EVPN
VPWS, if the non-Huawei device does not support any MTU matching check
for an EVPL instance working in SRv6 mode, run the mtu-match ignore
command to ignore the MTU matching check.
12. (Optional) Run load-balancing ignore-esi
The device is disabled from checking ESI validity during EVPL instance load
balancing.
In an EVPN VPWS scenario where active-active protection is deployed, if each
access-side device is single-homed to an aggregation-side device and no ESI is
configured on the access interface, to implement active-active load balancing,
you can run this command on the aggregation-side device to enable the
device to ignore ESI validity check during EVPL instance load balancing.
13. Run quit
14. Run commit

(2020-10-09)
Step 2 Configure an AC interface.

1. Run interface interface-type interface-number.subnum mode l2
A Layer 2 sub-interface is created as an AC interface and the sub-interface
view is displayed.
NOTE
Before running this command, ensure that the Layer 2 interface on which a Layer 2
sub-interface is to be created does not have the port link-type dot1q-tunnel
command configuration. If this configuration exists, run the undo port link-type
command to delete the configuration.
In addition to a Layer 2 sub-interface, an Ethernet main interface, Layer 3 sub-
interface, or Eth-Trunk interface can also function as an AC interface.
2. Run evpl instance evpl-id
A specified EVPL instance is bound to the Layer 2 sub-interface.
3. (Optional) Run evpn-vpws ignore-ac-state
The interface is enabled to ignore the AC status.
On a network with primary and backup links, if CFM is associated with an AC
interface, run this command to ensure EVPN VPWS continuity. When the AC
status of the interface becomes down, a primary/backup link switchover is
triggered. As the interface has been enabled to ignore the AC status using this
command, the EVPN VPWS does not need to be re-established during the link
switchover.
4. Run quit
Exit the Layer 2 sub-interface view.
5. Run commit
An interface used to set up a TCP connection with the specified BGP peer is
specified.
7. Run peer ipv6-address advertise encap-type srv6

(2020-10-09)

attributes to the specified peer.
8. Run quit

9. Run quit
Exit the BGP view.

10. Run commit
Step 4 On each PE, configure EVPN VPWSs to recurse to an SRv6 TE Policy.



5. Run opcode func-opcode end-dx2 evpl-instance evpl-instance-id

6. Run quit

7. Run quit
Exit the SRv6 view.



length [ static static-length | args args-length ] * ].
10. Run quit

The view of an EVPL instance that works in SRv6 mode is displayed.

(2020-10-09)

If there are static SIDs in the range of the locator specified using locator-
name, use the static SIDs. Otherwise, use dynamically allocated SIDs.
13. Run quit
Exit the view of the EVPL instance that works in SRv6 mode.
The view of the EVPN instance that works in VPWS mode is displayed.
The device is enabled to recurse EVPN VPWSs to SRv6 TE Policies.
16. Run quit
17. Run commit
Step 5 (Optional) Verify EVPN VPWS connectivity.
1. Configure an End.OP SID on the remote PE.
b. Run locator locator-name
c. Run opcode func-opcode end-op
An End.OP SID opcode is configured.
d. Run commit
b. Run remote end-op op-sid prefix-length
A remote End.OP SID is configured.
c. Run commit
– Run ping evpn vpws local-ce-id remote-ce-id end-op endOp [ -a source-
ip | -c count | -exp exp-value | -m interval | -s packet-size | -t time-out | -r
reply-mode | -tc tc ] *
A ping operation is performed to check the EVPN VPWS status.

(2020-10-09)
– Run tracert evpn vpws local-ce-id remote-ce-id end-op endOp [ -a

source-ip | -exp exp-value | -s packet-size | -t timeout | -h max-ttl | -r
reply-mode | -tc tc ] * [ pipe | uniform ]
A tracert operation is performed to check the EVPN VPWS status.
----End

After configuring EVPN VPWS over SRv6 TE Policy, verify the configuration.
● Run the display bgp evpn evpl command to check all EVPL instance
information.
EVPN route information. The command output shows that the value of Relay
Tunnel Out-Interface is SRv6 TE Policy.
● Run the display evpn vpn-instance [ name vpn-instance-name ] tunnel-info
command to check information about the tunnel associated with a specified
EVPN instance.
● Run the display evpn vpn-instance name vpn-instance-name tunnel-info
nexthop nexthopIpv6Addr command to check information about the tunnel
that is associated with a specified EVPN instance and matches a specified next
hop.
2.2.7.5 Configuring EVPN VPLS over SRv6 TE Policy

This section describes how to configure EVPN VPLS over SRv6 TE Policy so that
EVPN VPLSs can be carried over SRv6 TE Policies.
Usage Scenario
EVPN VPLS uses the EVPN E-LAN model to carry MP2MP VPLSs. EVPN VPLS over
SRv6 TE Policy uses public SRv6 TE Policies to carry EVPN VPLSs. As shown in
Figure 2-93, PE1 and PE2 communicate through an IPv6 public network. An SRv6
TE Policy is configured on the network to carry EVPN VPLSs.
Figure 2-93 EVPN VPLS over SRv6 TE Policy networking

(2020-10-09)
Before configuring EVPN VPLS over SRv6 TE Policy, complete the following tasks:
You need to apply a tunnel policy to a specified EVPN instance that works in
BD mode when configuring traffic steering.
● Deploy BD-EVPN functions between PE1 and PE2.
Procedure
1. Run system-view
9. Run quit
10. Run quit
Exit the BGP view.
11. Run commit
Step 2 On each PE, configure EVPN VPLSs to recurse to an SRv6 TE Policy.

(2020-10-09)
5. (Optional) Run opcode func-opcode end-dt2m bridge-domain bd-id
A static End.DT2M SID operation code (opcode) is configured.
parameter. End.DT2M SIDs are used for BUM traffic forwarding through VPLS.
6. (Optional) Run opcode func-opcode { end-dt2u | end-dt2ul } bridge-domain
bd-id
Static End.DT2U and End.DT2UL SID opcodes are configured.
parameter. End.DT2U SIDs are used for the forwarding of known unicast
traffic through VPLS. In dual-homing scenarios, an End.DT2UL SID opcode
needs to be specified for the bypass path to prevent traffic loops between PEs.
7. Run quit
8. Run quit
Exit the SRv6 view.
length [ static static-length | args args-length ] * ]. If a separate locator is
configured for each of BUM traffic and known unicast traffic of EVPN VPLS
services, you need to run this command once for each locator for IS-IS to
advertise them both.
11. Run quit
The view of the EVPN instance that works in BD mode is displayed.
13. Run segment-routing ipv6 locator locator-name [ unicast-locator unicast-
locator-name ]

(2020-10-09)
In this command:
– locator-name must be set to an End.DT2M SID, with the args parameter
specified. unicast-locator-name must be set to an End.DT2U or
End.DT2UL SID, without having the args parameter specified. If the
locator-name and unicast-locator-name parameters are both required,
you need to run the locator locator-name [ ipv6-prefix ipv6-address
prefix-length [ static static-length | args args-length ] * ] command to
create two corresponding locators before setting the two parameters.
– In EVPN VPLS dual-homing scenarios, the args parameter is used to
splice ESI labels for End.DT2M SIDs only, which causes a waste of
End.DT2U SIDs. In this case, you can separately configure a locator for
End.DT2U SIDs and a locator for End.DT2M SIDs. The former locator does
not require the args parameter to be specified. The two locators can then
be bound to the same EVPN instance to conserve SIDs.
– If there are static SIDs in the range of the locator specified using locator-
name or unicast-locator-name, use the static SIDs. Otherwise, use
dynamically allocated SIDs.
The device is enabled to recurse EVPN VPLSs to SRv6 TE Policies.
The default color value is specified for the EVPN service to recurse to an SRv6
TE Policy.

leaked to a local EVPN instance, the default color value is used for the
recursion.
16. Run quit

17. Run commit
----End

After configuring EVPN VPLS over SRv6 TE Policy, verify the configuration.

EVPN route information. The command output shows that the value of Relay
Tunnel Out-Interface is SRv6 TE Policy.

(2020-10-09)
● Run the display evpn vpn-instance [ name vpn-instance-name ] tunnel-info

command to check information about the tunnel associated with a specified
EVPN instance.
● Run the display evpn vpn-instance name vpn-instance-name tunnel-info
nexthop nexthopIpv6Addr command to check information about the tunnel
that is associated with a specified EVPN instance and matches a specified next
hop.
2.2.7.6 Configuring L3VPNv4 HoVPN over SRv6 TE Policy

This section describes how to configure L3VPNv4 HoVPN over SRv6 TE Policy.
Usage Scenario
Currently, the typical structure of a MAN consists of three layers: core layer,
aggregation layer, and access layer. To implement VPN functions on a hierarchical
network for achieving end-to-end VPN data transmission and improving the
performance and scalability of the entire network, you need to deploy hierarchical
VPN solutions, among which the hierarchy of VPN (HoVPN) solution is commonly
used.
During network evolution, the core and aggregation layers may use different
forwarding modes, that is, SRv6 forwarding and MPLS forwarding. When the
HoVPN solution is used to implement hierarchical VPN deployment, the methods
used to forward L3VPNv4 data over a public network fall into three categories (as
shown in Figure 2-94): L3VPNv4 over MPLS plus SRv6, L3VPNv4 over SRv6 plus
MPLS, and L3VPNv4 over SRv6 plus SRv6.
Figure 2-94 HoVPN solution networking
This section uses L3VPNv4 over SRv6 TE Policy plus SRv6 TE Policy as an example.
As shown in Figure 2-95, L3VPNv4 HoVPN over SRv6 TE Policy allows SRv6 TE
Policies on a public network to carry L3VPNv4 data on condition that hierarchical
VPN deployment is implemented through the HoVPN solution.

(2020-10-09)
Figure 2-95 L3VPNv4 HoVPN over SRv6 TE Policy networking
Before configuring L3VPNv4 HoVPN over SRv6 TE Policy, complete the following
tasks:
Procedure
Step 1 Configure IPv6 IS-IS on the UPE, SPE, and NPE. For configuration details, see
Configuring Basic IPv6 IS-IS Functions.
Step 2 Configure IPv4 route exchange between the UPE and CE1 and between the NPE
and CE2. For configuration details, see Configuring Route Exchange Between PEs
and CEs.
Step 3 Establish an MP-IBGP peer relationship between the UPE and SPE and another one
between the NPE and SPE. Configure a VPN instance and enable the IPv4 address
family for the VPN instance on each of the three devices. In addition, enable the
devices to add SIDs to VPN routes. For configuration details, see 2.2.7.1
Configuring L3VPNv4 over SRv6 TE Policy.
Step 4 Configure an SRv6 TE Policy. For configuration details, see 2.2.5 Configuring an
SRv6 TE Policy (Manual Configuration) or 2.2.6 Configuring an SRv6 TE Policy
(Dynamic Delivery by a Controller).
Step 5 Configure VPNv4 route recursion to the SRv6 TE Policy. For configuration details,
see 2.2.7.1 Configuring L3VPNv4 over SRv6 TE Policy.
1. Run system-view
4. Run peer peerIpv6Addr upe

(2020-10-09)
The UPE is specified as the peer, and a default route is automatically

generated.
If the peer peerIpv6Addr upe command is not run to automatically generate

a default route, you can manually configure a static route as a default route,
with the next hop being the public or private network address of the NPE
rather than the SPE itself. Otherwise, a traffic black hole may occur when a
fault occurs on the link between the SPE and NPE. Then, run the ip route-
static recursive-lookup inherit-label-route segment-routing-ipv6 or ipv6
route-static recursive-lookup inherit-label-route segment-routing-ipv6
command to recurse the default route to an SRv6 route.
5. Run peer ipv6-address default-originate vpn-instance vpn-instance-name
The SPE is configured to advertise the default route to the UPE.

6. Run commit

7. Run quit
Exit the BGP-VPNv4 address family view.
Step 7 Enable route regeneration on the SPE and configure the SPE to advertise
regenerated routes to the NPE.

2. Run advertise best-route route-reoriginate
Route regeneration is enabled.

3. Run quit


5. Run peer ipv6-address advertise route-reoriginated vpnv4
The SPE is configured to advertise regenerated routes in the BGP-VPNv4

address family to the NPE.
6. Run commit
----End

After configuring L3VPNv4 HoVPN over SRv6 TE Policy, verify the configuration.
● Run the display bgp vpnv4 all routing-table command to check BGP VPNv4
● Run the display ip routing-table vpn-instance vpn-instance command to
check the routing tables of the NPE and UPE.

(2020-10-09)
2.2.7.7 Configuring a Device to Redirect IPv4 Public Network Traffic to an

SRv6 TE Policy Through Multi-Field Classification
The redirection function can be used to steer IPv4 public network traffic to an
SRv6 TE Policy.
Prerequisites
Before configuring a device to redirect IPv4 public network traffic to an SRv6 TE
Policy through multi-field classification, complete either of the following tasks:
● Configure an SRv6 TE Policy in controller-based dynamic delivery mode.
● Configure an SRv6 TE Policy in manual configuration mode.
Context
If some IPv4 public network traffic experiences congestion, QoS multi-field
classification can be used to identify and redirect the traffic to an SRv6 TE Policy,
resolving the congestion issue. The redirection involves three factors: endpoint,
color, and SID. If traffic fails to match a redirection rule or the SRv6 TE Policy fails,
multi-field classification also fails, meaning that the traffic is forwarded over
common IP.
Procedure
Step 2 Run traffic classifier classifier-name [ operator { and | or } ]
A traffic classifier is defined and its view is displayed.
Step 3 Configure if-match clauses to define matching conditions for IPv4 public network
traffic.
For details, see Defining a Traffic Classifier.
Step 4 Run quit
Exit the traffic classifier view.
Step 5 Run traffic behavior behavior–name
A traffic behavior is defined and its view is displayed.
Step 6 Run redirect srv6-te policy endpoint color { sid | vpnsid } sid-ip
The device is enabled to redirect IPv4 public network traffic to an SRv6 TE Policy.
You can specify sid and vpnsid to send IPv4 public network traffic to the IPv4
public network and VPN through SRv6 TE Policies, respectively.
sid-ip must be an End.DT4 SID, which is configured using the opcode func-opcode
end-dt4 [ vpn-instance vpn-instance-name ] command.
Step 7 Run quit
Exit the traffic behavior view.

(2020-10-09)
Step 8 Run traffic policy policy-name

A traffic policy is defined and its view is displayed.
Step 9 Run classifier classifier-name behavior behavior-name
The traffic behavior is specified for the traffic classifier in the traffic policy.
Step 10 Run quit
Exit the traffic policy view.
Step 11 Run interface interface-type interface-number [ .subinterface-number ]
Step 12 Run traffic-policy policy-name inbound
The traffic policy is applied to the interface.
Step 13 Run commit
----End

After configuring the device to redirect IPv4 public network traffic to an SRv6 TE
Policy through multi-field classification, perform the following operations to verify
the configuration:
● Run the display traffic classifier { system-defined | user-defined }
[ classifier-name ] command to check the traffic classifier configuration.
● Run the display traffic behavior user-defined [ behavior-name ] command
to check the traffic behavior configuration.
● Run the display traffic policy user-defined [ policy-name [ classifier
classifier-name ] ] command to check the associations between all traffic
classifiers and traffic behaviors or between specified ones in the traffic policy.
2.2.7.8 Configuring a Device to Redirect IPv6 Public Network Traffic to an

SRv6 TE Policy Through Multi-Field Classification
The redirection function can be used to steer IPv6 public network traffic to an
SRv6 TE Policy.
Prerequisites
Before configuring a device to redirect IPv6 public network traffic to an SRv6 TE
Policy through multi-field classification, complete either of the following tasks:
● Configure an SRv6 TE Policy in controller-based dynamic delivery mode.
● Configure an SRv6 TE Policy in manual configuration mode.
Context
If some IPv6 public network traffic experiences congestion, QoS multi-field
classification can be used to identify and redirect the traffic to an SRv6 TE Policy,

(2020-10-09)
resolving the congestion issue. The redirection involves three factors: endpoint,
color, and SID. If traffic fails to match a redirection rule or the SRv6 TE Policy fails,
multi-field classification also fails, meaning that the traffic is forwarded over
common IPv6.
Procedure
Step 2 Run traffic classifier classifier-name [ operator { and | or } ]
A traffic classifier is defined and its view is displayed.
Step 3 Configure if-match clauses to define matching conditions for IPv6 public network
traffic.
For details, see Defining a Traffic Classifier.
Step 4 Run quit
Step 5 Run traffic behavior behavior–name
Step 6 Run redirect srv6-te policy endpoint color { sid | vpnsid } sid-ip
The device is enabled to redirect IPv6 public network traffic to an SRv6 TE Policy.
You can specify sid and vpnsid to redirect IPv6 public network traffic to the IPv6
public network and VPN through SRv6 TE Policies, respectively.
sid-ip must be an End.DT6 SID, which is configured using the opcode func-opcode
end-dt6 [ vpn-instance vpn-instance-name evpn ] command.
Step 7 Run quit
Step 8 Run traffic policy policy-name
Step 9 Run classifier classifier-name behavior behavior-name
Step 10 Run quit
Step 11 Run interface interface-type interface-number [ .subinterface-number ]
Step 12 Run traffic-policy policy-name inbound

(2020-10-09)
Step 13 Run commit

----End

After configuring the device to redirect IPv6 public network traffic to an SRv6 TE
Policy through multi-field classification, perform the following operations to verify
the configuration:
● Run the display traffic classifier { system-defined | user-defined }
[ classifier-name ] command to check the traffic classifier configuration.
● Run the display traffic behavior user-defined [ behavior-name ] command
to check the traffic behavior configuration.
● Run the display traffic policy user-defined [ policy-name [ classifier
classifier-name ] ] command to check the associations between all traffic
classifiers and traffic behaviors or between specified ones in the traffic policy.
2.2.8 Redirecting a Public IPv4 BGP FlowSpec Route to an

SRv6 TE Policy
Redirecting a public IPv4 BGP FlowSpec route to an SRv6 TE Policy helps
implement more accurate traffic filtering.
Context
redirect a public IPv4 BGP FlowSpec route to an SRv6 TE Policy, a device can
to different SRv6 TE Policies.
2.2.8.1 Redirecting a Public IPv4 BGP FlowSpec Route to an SRv6 TE Policy

(Manual Configuration)
Manually generate a BGP FlowSpec route and configure redirection rules to
redirect the route to an SRv6 TE Policy.
Prerequisites
Before redirecting a public IPv4 BGP FlowSpec route to an SRv6 TE Policy in
manual configuration mode, complete the following tasks:
● Configure a BGP peer relationship.
● Configure an SRv6 TE Policy (in manual configuration mode).
Context
If no controller is deployed, perform the following operations to manually redirect
a public IPv4 BGP FlowSpec route to an SRv6 TE Policy:

(2020-10-09)
1. Manually configure an SRv6 TE Policy.

2. Manually configure a BGP FlowSpec route and define redirection rules. BGP
FlowSpec route redirection is based on <Redirection IP address, Color, Public
End.DT4 SID>. If the redirection IP address, color, and public End.DT4 SID
attributes of a BGP FlowSpec route match the endpoint, color, and public
End.DT4 SID attributes of an SRv6 TE Policy, the route can be successfully
redirected to the SRv6 TE Policy.
3. To enable the device to advertise the BGP FlowSpec route to another device,
establish a BGP peer relationship in the BGP-Flow address family.
Procedure
● Configure a public End.DT4 SID.
a. Run system-view
c. Run encapsulation source-address ipv6-address [ ip-ttl ttl-value ]
d. Run locator locator-name [ ipv6-prefix ipv6-address prefix-length
e. Run opcode func-opcode end-dt4
A public End.DT4 SID is configured.
f. Run quit
g. Run quit
Exit the SRv6 view.
h. Run commit
● Configure a BGP FlowSpec route.
a. Run flow-route flowroute-name
A static BGP FlowSpec route is created, and the Flow-Route view is
displayed.
b. (Optional) Configure if-match clauses. For details, see Configuring Static
BGP FlowSpec.
c. Run apply redirect ipv6 redirect-ipv6-rt color colorvalue prefix-sid
prefix-sid-value
The device is enabled to precisely redirect the traffic that matches the if-
match clauses to the SRv6 TE Policy.
d. Run quit
Exit the Flow-Route view.
e. Run commit

(2020-10-09)
● (Optional) Configure a BGP peer relationship in the BGP-Flow address family.
Establish a BGP FlowSpec peer relationship between the ingress of the SRv6
TE Policy and the device on which the BGP FlowSpec route is manually
generated. If the BGP FlowSpec route is manually generated on the ingress of
the SRv6 TE Policy, skip this step.
a. Run bgp as-number

b. Run ipv4-family flow


automatically imported to the BGP-Flow routing table and then sent to
each peer.
d. Run peer ipv4-address redirect tunnelv6
The device is enabled to process the redirection next-hop IPv6 address,

color, and prefix SID attributes carried in BGP FlowSpec routes received
from a peer.
e. Run redirect tunnelv6 tunnel-selector tunnel-selector-name
The device is enabled to recurse received routes with the redirection next-
hop IPv6 address, color, and prefix SID attributes to SRv6 TE Policies.
f. Run commit
----End


2.2.8.2 Redirecting a Public IPv4 BGP FlowSpec Route to an SRv6 TE Policy

(Dynamic Delivery by a Controller)
Use a controller to dynamically deliver a BGP FlowSpec route to a forwarder and
configure a redirection rule on the forwarder to redirect the route to a specified
SRv6 TE Policy.

(2020-10-09)
Prerequisites
Before redirecting a public IPv4 BGP FlowSpec route to an SRv6 TE Policy in
controller-based dynamic delivery mode, complete the following tasks:
● Configure a BGP peer relationship.
● Configure an SRv6 TE Policy (in controller-based dynamic delivery mode).
Context
If a controller is deployed, the controller can be used to configure a public IPv4
BGP FlowSpec route to be redirected to an SRv6 TE Policy. The configuration
1. Establish a BGP-LS peer relationship between the controller and forwarder,
enabling the controller to collect network information, such as topology and
label information, through BGP-LS.
2. Establish a BGP IPv6 SR-Policy peer relationship between the controller and
forwarder, enabling the controller to deliver a dynamically computed SRv6 TE
Policy to the ingress through the peer relationship. After receiving the SRv6 TE
Policy, the ingress generates corresponding entries.
3. Establish a BGP-Flow address family peer relationship between the controller
and forwarder, enabling the controller to dynamically deliver a BGP FlowSpec
route.
The following procedure focuses on forwarder configurations.
Procedure
Step 1 Establish BGP-LS and BGP IPv6 SR-Policy peer relationships. For details, see 2.2.6.4
Configuring BGP Peer Relationships Between the Controller and Forwarder.
Step 2 Establish a BGP-Flow address family peer relationship.
1. Run system-view
3. Run ipv4-family flow
automatically imported to the BGP-Flow routing table and then sent to each
peer.
5. Run peer ipv4-address redirect tunnelv6
The device is enabled to process the redirection next-hop IPv6 address, color,
and prefix SID attributes carried in BGP FlowSpec routes received from a peer.

(2020-10-09)
6. Run redirect tunnelv6 tunnel-selector tunnel-selector-name

The device is enabled to recurse received routes with the redirection next-hop
IPv6 address, color, and prefix SID attributes to SRv6 TE Policies.
7. Run commit
----End

2.2.9 Configuring a TTL Processing Mode for an SRv6 TE Policy

Configure an SRv6 TE Policy to process time to live (TTL) in pipe or uniform mode.
Context
In a scenario where a public IP route recurses to an SRv6 TE Policy, perform the
following operations at both ends of the policy to configure a TTL processing
mode for the policy.
Procedure
Step 3 Run ttl-mode { pipe | uniform }
A TTL processing mode is configured for the SRv6 TE Policy.
Step 4 Run commit
----End
2.2.10 Configuring Headend-based Fault Detection for SRv6

TE Policies
This section describes how to configure headend-based fault detection for SRv6 TE
Policies.

(2020-10-09)
Usage Scenario
An SRv6 TE Policy selects a forwarding path from the candidate paths that are
either delivered by a controller or manually configured. Currently, SBFD for SRv6
TE Policy is not allowed in some scenarios. As such, if the segment list of a
candidate path in an SRv6 TE Policy fails, the headend cannot quickly detect the
fault. The SRv6 TE Policy can be updated only after the controller detects a
topology change and re-converges the topology.
If the controller or the connection between the controller and headend fails, the
SRv6 TE Policy cannot detect the fault or perform a candidate path switchover.
This may cause traffic loss. To speed up traffic switching in the case of a fault,
headend-based fault detection is introduced. With this function, if a segment list
fails, the headend sets the segment list to down, triggering path or service
switching in the SRv6 TE Policy.
Before configuring headend-based fault detection for SRv6 TE Policies, complete
the following tasks:
● Configure SRv6 TE Policies.
● Run the segment-routing ipv6 locator locator-name command in the IS-IS
view to enable IS-IS SRv6.
Procedure
Step 3 Run srv6-te-policy path verification enable
Headend-based fault detection is enabled for all SRv6 TE Policies.
Step 4 (Optional) Run srv6-te-policy suppress-flapping disable
Flap suppression is disabled for all SRv6 TE Policies.
Enabling this function suppresses frequent SID status changes. If the SID status
becomes unreachable, the associated segment list goes down immediately.
However, if the SID status becomes reachable, the device needs to determine
whether flap suppression is required. If it is required, the device updates the SID
status to reachable after a delay and then updates the segment list status.
If flap suppression is not required, run the srv6-te-policy suppress-flapping
disable command to disable this function for all SRv6 TE Policies.
Step 5 Run srv6-te policy policy-name
The SRv6 TE Policy view is displayed.
Step 6 Run path verification { enable | disable }
Headend-based fault detection is configured for the SRv6 TE Policy.

(2020-10-09)
If an SRv6 TE Policy has both global configuration and single-policy configuration,

the single-policy configuration takes effect.
Step 7 Run commit
----End

After configuring headend-based fault detection for SRv6 TE Policies, verify the
configuration.
● Run the display srv6-te policy [ endpoint endpoint-ip color color-value |

policy-name name-value | binding-sid binding-sid ] command to check SRv6
TE Policy details.
● Run the display srv6-te policy source-sid [ sid-value | end | end-x ]
command to check details about the End and End.X SIDs collected from the
IS-IS LSDB, including the IS-IS process and level information about the SIDs.
● Run the display srv6-te policy sid statistics [ isis process process-id { level-1
| level-2 | level-1-2 } ] command to check the numbers of End and End.X SIDs
collected from the IS-IS LSDB.
● Run the display srv6-te policy last-down-reason { endpoint endpoint-ip
color color-value | policy-name name-value | binding-sid binding-sid }
command to check records about events where SRv6 TE Policies or segment
lists in SRv6 TE Policies go down.
2.2.11 Configuring SBFD for SRv6 TE Policy

This section describes how to configure seamless bidirectional forwarding
detection (SBFD) for SRv6 TE Policy.
Usage Scenario
SBFD for SRv6 TE Policy can quickly detect segment list faults. If all the segment
lists of a candidate path are faulty, SBFD triggers a candidate path switchover to
reduce impacts on services.
Before configuring SBFD for SRv6 TE Policy, complete the following tasks:
● Configure an SRv6 TE Policy.

● Run the te ipv6-router-id ipv6Addr command to configure a global TE IPv6
router ID.
Procedure
a. Run system-view

(2020-10-09)
b. Run bfd
the bfd command.
c. Run quit
d. Run sbfd
SBFD is enabled globally, and the SBFD view is displayed.
e. Run destination ipv6 Ipv6Address remote-discriminator
DiscriminatorValue
The mapping between the IPv6 address and discriminator of the SBFD
reflector is configured.
NOTE
The IPv6 address of the SBFD reflector must be the same as the endpoint of the
corresponding SRv6 TE Policy.
f. Run quit
g. Run segment-routing ipv6
h. Configure SBFD for SRv6 TE Policy.
SBFD for SRv6 TE Policy supports both global configuration and single-
policy configuration. You can select either of the two modes.
▪ Global configuration
1) Run srv6-te-policy seamless-bfd enable
SBFD is enabled for all SRv6 TE Policies.
2) (Optional) Run srv6-te-policy seamless-bfd { min-tx-interval
tx-value | detect-multiplier detectmulti-value } *
SBFD parameters are set for the SRv6 TE Policies.
▪ Single-policy configuration
1) Run srv6-te policy policy-name
2) Run seamless-bfd { enable | disable }
SBFD is enabled or disabled for the SRv6 TE Policy.
If an SRv6 TE Policy has both global configuration and single-policy
configuration, the single-policy configuration takes effect.
i. (Optional) Run srv6-te-policy switch-delay switchDelay delete-delay
deleteDelay
Segment list switching and deletion delays are configured for SRv6 TE
Policies.

(2020-10-09)
j. Run commit

● Configure an SBFD reflector.
a. Run system-view

b. Run bfd
the bfd command.
c. Run quit

d. Run sbfd
SBFD is enabled globally, and the SBFD view is displayed.

e. Run reflector discriminator unsigned-integer-value
NOTE
You can configure a 32-bit integer-type discriminator or an IP-address-type

discriminator. A device converts the discriminators into a uniform form for
management, ensuring that each discriminator is globally unique in a domain.
f. Run commit
----End

After configuring SBFD for SRv6 TE Policy, run the display srv6-te policy
[ endpoint ipv6-address colorcolor-value | policy-namename-value ] command to
check the SBFD status of the SRv6 TE Policy.
2.2.12 Configuring Hot Standby for SRv6 TE Policy

This section describes how to configure hot standby (HSB) for SRv6 TE Policy.
Usage Scenario
SBFD for SRv6 TE Policy can quickly detect segment list faults. If all the segment
lists of the primary path are faulty, SBFD triggers a candidate path HSB switchover
to reduce impacts on services.
Before configuring HSB for SRv6 TE Policy, configure one or more SRv6 TE Policies.

(2020-10-09)
Procedure
SRv6 is enabled globally and the SRv6 view is displayed.
Step 3 Enable HSB for SRv6 TE Policy.
HSB for SRv6 TE Policy supports both global configuration and individual
configuration. Select either of the following configuration modes as needed:
a. Run srv6-te-policy backup hot-standby enable
HSB is enabled for all SRv6 TE Policies.
a. Run srv6-te policy policy-name
b. Run backup hot-standby { enable | disable }
HSB is enabled or disabled for a single SRv6 TE Policy.
If an SRv6 TE Policy has both global configuration and individual configuration,

the individual configuration takes effect.
Step 4 Run commit
----End
2.2.13 Configuring IS-IS SRv6 TI-LFA FRR

IS-IS SRv6 topology-independent loop-free alternate (TI-LFA) fast reroute (FRR)
uses an explicit path to represent a backup path, which poses no topology
constraints and provides more reliable FRR.
Usage Scenario
In some LFA or RLFA scenarios, the P space and Q space do not intersect or have
direct neighbors. If a link or node fails, no backup path can be calculated, causing
traffic loss and resulting in a failure to meet reliability requirements. In this
situation, TI-LFA FRR can be used to resolve the issue.
SRv6 TI-LFA FRR provides link and node protection in SRv6 scenarios. If a link or
node fails, traffic is rapidly switched to a backup path, minimizing traffic loss.
SRv6 TI-LFA FRR applies to both SRv6 BE and SRv6 TE Policy scenarios. In normal
cases, SRv6 BE packets do not need to carry SRH information. However, in TI-LFA
FRR scenarios, to encapsulate repair list information, SRv6 BE packets are required
to carry SRH information.

(2020-10-09)
Before configuring IS-IS SRv6 TI-LFA FRR, enable IS-IS SRv6.
Procedure
An IS-IS process is created, and the IS-IS view is displayed.
Step 3 Run ipv6 enable topology ipv6
Step 4 Run ipv6 frr
The IPv6 IS-IS FRR view is displayed.
Step 5 Run loop-free-alternate [ level-1 | level-2 | level-1-2 ]
IPv6 IS-IS FRR is enabled, so that a loop-free backup link is generated using the
LFA algorithm.
Step 6 Run ti-lfa [ level-1 | level-2 | level-1-2 ]
IS-IS SRv6 TI-LFA is enabled.
Step 7 (Optional) Run tiebreaker { node-protecting | lowest-cost | non-ecmp | srlg-
disjoint | hold-max-cost } preference preference [ level-1 | level-2 | level-1-2 ]
An IS-IS SRv6 TI-LFA FRR backup path selection scheme is specified.
A larger value indicates a higher preference.
Before configuring the srlg-disjoint parameter, you need to run the isis srlg srlg-
value command in the IS-IS interface view to configure the IS-IS SRLG function.
Step 8 (Optional) After the preceding configurations are complete, IS-IS SRv6 TI-LFA is
enabled on all IPv6 IS-IS interfaces. If you do not want to enable IS-IS SRv6 TI-LFA
on some interfaces, perform the following steps:
1. Run quit
Exit the IS-IS FRR view.
2. Run quit
4. Run isis ipv6 ti-lfa disable [ level-1 | level-2 | level-1-2 ]
IPv6 IS-IS TI-LFA is disabled on the interface.

(2020-10-09)

1. Run quit
The IS-IS process is enabled, and the IS-IS view is displayed.
Local IS-IS anti-microloop is enabled.
delay
A delay in IS-IS route delivery is configured.
6. Run ipv6 avoid-microloop segment-routing
Remote IS-IS anti-microloop is enabled.
7. (Optional) Run ipv6 avoid-microloop segment-routing rib-update-delay
rib-update-delay
A delay in SRv6 IS-IS route delivery is configured.
Step 10 Run commit
----End

After configuring IS-IS SRv6 TI-LFA FRR, verify the configuration.
● Run the display isis [ process-id ] route ipv6 [ level-1 | level-2 ] [ verbose ]
command to check information about the primary and backup links after IS-IS
SRv6 TI-LFA FRR is enabled.
2.2.14 Configuring SRv6 Midpoint Protection

This section describes how to configure SRv6 midpoint protection to enhance SRv6
network reliability.
Before configuring SRv6 midpoint protection, complete the following tasks:
● Configure an IGP to implement network layer connectivity.
● Configure an SRv6 TE Policy. For details, see 2.2.5 Configuring an SRv6 TE
Policy (Manual Configuration) and 2.2.6 Configuring an SRv6 TE Policy
(Dynamic Delivery by a Controller).
Context
To resolve the TI-LFA FRR protection failure caused by strict node constraints in an
SRv6 TE Policy scenario, a proxy forwarding node (a node upstream to the faulty

(2020-10-09)
midpoint) takes over from the faulty midpoint to complete the forwarding.
Specifically, when the proxy forwarding node detects that the next-hop interface
of the packet is faulty, the next-hop address is the destination address of the
packet, and the SL value is greater than 0, the proxy forwarding node replaces the
midpoint to perform the End behavior. The behavior involves decrementing the SL
value by 1, copying the next SID to the DA field in the outer IPv6 header, and then
forwarding the packet according to the instruction bound to the SID. In this way,
the faulty midpoint is bypassed, achieving SRv6 midpoint protection.
As shown in Figure 2-96, SRv6 midpoint protection is implemented as follows:
1. Node A forwards a packet to destination node F, with an SRv6 SRH instructing
the packet to pass through the midpoint D.
2. If node D is faulty, node B detects that the next-hop interface of the received
packet is faulty. It also learns that the next-hop address is the current
destination address 4:: of the packet, and the SL value is greater than 0. In
this case, node B functions as a proxy forwarding node, decrementing the SL
value by 1 and copying the next SID 6:: to the DA field in the outer IPv6
header. Because the SL value is now 0, node B can remove the SRH and then
search the corresponding table to forward the packet based on the
destination address 6::.
3. The primary next hop to the destination address 6:: is still node E. Because the
SL value is 0 and node B is not the penultimate hop of the destination
address, node B can no longer perform proxy forwarding. Instead, it switches
the packet to a backup path according to the normal TI-LFA process, with the
repair segment list on the backup path as <3::5>. As such, node B executes the
H.Insert behavior, which involves encapsulating the segment list 3::5 into the
packet, adding an SRH, and then forwarding the packet to node F over the
backup path.
4. After node A detects that node D is faulty and that IGP convergence is
completed, it deletes the forwarding entry towards node D. Consequently,
when node A searches the corresponding table based on 4::, it cannot find any
matching route. In this case, node A needs to function as a proxy forwarding
node to perform proxy forwarding, so it decrements the SL value by 1, copies
the next SID 6:: to the outer IPv6 header, searches the corresponding table
based on the destination address 6::, and then forwards the packet to node B
accordingly. If node B has already completed convergence, it forwards the
packet to node F over the post-convergence shortest path; otherwise, it
forwards the packet to node F over the backup path according to the TI-LFA
process. In this way, the faulty node D is bypassed.

(2020-10-09)
Figure 2-96 SRv6 midpoint protection
NOTE
SRv6 midpoint protection uses the next SID to guide packet forwarding over the
bypass path, thereby bypassing the failure point. This mechanism is similar to MPLS TE
FRR that enables traffic to bypass the failure point using a bypass LSP. Therefore, SRv6
midpoint protection is also called SRv6 TE FRR.
Procedure
Step 3 Run sr-te frr enable
SRv6 midpoint protection is enabled.
On a network with complex services, midpoint nodes are not fixed. Therefore, to
improve network-wide reliability, you are advised to run the sr-te frr enable
command on all nodes. However, for a network with simple services, you can run
the sr-te frr enable command only on the upstream node of the protected node.
For example, in the DeviceA-to-DeviceF direction shown in the preceding figure, to
protect DeviceD, you can run the sr-te frr enable command on the upstream
nodes (DeviceA and DeviceB) of DeviceD to enable midpoint protection.
Step 4 Run commit
----End

(2020-10-09)
2.2.15 Configuring SRv6 Egress Protection

This section describes how to configure SRv6 egress protection to enhance SRv6
network reliability.
Before configuring SRv6 egress protection, configure an IGP to implement network
layer connectivity
Context
Services that recurse to an SRv6 TE Policy must be strictly forwarded through the
path defined using the segment lists in the SRv6 TE Policy. Considering that the
egress of the SRv6 TE Policy is also fixed, if a single point of failure occurs on the
egress, service forwarding may fail. To prevent this problem, configure egress
protection for the SRv6 TE Policy.
Figure 2-97 shows a typical SRv6 egress protection scenario where an SRv6 TE
Policy is deployed between PE3 and PE1. PE1 is the egress of the SRv6 TE Policy,
Figure 2-97 SRv6 egress protection
SRv6 egress protection is implemented as follows:

1. Locators A1::/64 and A2::/64 are configured on PE1 and PE2, respectively.

(2020-10-09)
2. An IPv6 VPNv4 peer relationship is established between PE3 and PE1 as well
as between PE2 and PE1. A VPN instance VPN1 and SRv6 VPN SIDs are
configured on both PE1 and PE2. In addition, IPv4 prefix SID advertisement is
enabled on the two PEs.
3. After receiving the VPN route advertised by CE2, PE1 encapsulates the route
as a VPNv4 route and sends it to PE3. The route carries the VPN SID, RT, RD,
and color information.
4. An End.M SID is configured on PE2 to protect PE1, generating an <End.M SID,
Locator> mapping entry (for example, <A2::100, A1::>).
5. PE2 propagates the End.M SID through an IGP and generates a local SID
entry. After receiving the End.M SID, P1 generates an FRR entry with the next-
hop address being PE2 and the action being Push End.M SID. In addition, P1
generates a low-priority route that cannot be recursed.
6. BGP subscribes to End.M SID configuration. After receiving the VPNv4 route
from PE1, PE2 leaks the route into the routing table of VPN1 based on the RT,
and matches the VPN SID carried by the route against the local <End.M SID,
Locator> table. If a matching locator is found according to the longest match
rule, PE2 generates a <Remote SRv6 VPN SID, VPN> entry.

1. In normal situations, PE3 forwards traffic to the private network through the
PE3-P1-PE1-CE2 path. If PE1 fails, P1 detects that the next hop PE1 is
unreachable and switches traffic to the FRR path.
2. P1 pushes the End.M SID into the packet header and forwards the packet to
PE2. After parsing the received packet, PE2 obtains the End.M SID, queries the
local SID table, and finds that the instruction specified by the End.M SID is to
query the remote SRv6 VPN SID table. As instructed, PE2 queries the remote
SRv6 VPN SID table based on the VPN SID in the packet and finds the
corresponding VPN instance. PE2 then searches the VPN routing table and
forwards the packet to CE2.
If PE1 fails, the peer relationship between PE2 and PE1 is also interrupted. As a
result, PE2 deletes the VPN route received from PE1, causing the <Remote SRv6
VPN SID, VPN> entry to be deleted on PE2. To prevent this, enable GR on PE2 and
PE1 to maintain routes or enable delayed deletion (enabled by default currently)
for the <Remote SRv6 VPN SID, VPN> entry on PE2.
Procedure
Step 1 Configure an SRv6 TE Policy along the PE3-P1-PE1 path.
For details about the configuration, see 2.2.5 Configuring an SRv6 TE Policy
(Manual Configuration) and 2.2.6 Configuring an SRv6 TE Policy (Dynamic
Delivery by a Controller).
Step 2 Configure services to recurse to the SRv6 TE Policy.
Supported service types are BGP L3VPN, EVPN L3VPN, EVPN VPWS, and EVPN
VPLS. For details about the configuration, see 2.2.7.3 Configuring EVPN L3VPNv6
over SRv6 TE Policy and 2.2.7.4 Configuring EVPN VPWS over SRv6 TE Policy.
Step 3 Configure protection on PE2.

(2020-10-09)
1. Run system-view


4. Run opcode func-opcode end-m mirror-locator ipv6-address prefix-length
An End.M SID opcode is configured, and the locator to be protected is

specified.
You need to configure opcode func-opcode within the local locator range and
use mirror-locator ipv6-address prefix-length to specify the locator to be
protected.
5. Run commit
Step 4 Configure IPv6 IS-IS FRR on each P.

1. Run system-view


3. Run ipv6 frr

4. Run loop-free-alternate [ level-1 | level-2 | level-1-2 ]
IPv6 IS-IS FRR is enabled, so that a loop-free backup link is generated using
the LFA algorithm.
5. Run commit
Step 5 Enable IPv6 IS-IS TI-LFA FRR and microloop avoidance on the PEs and Ps.

IS-IS local microloop avoidance is enabled.

delay
A delay in IS-IS route delivery is configured.
4. Run ipv6 avoid-microloop segment-routing
IS-IS remote microloop avoidance is enabled.

(2020-10-09)
5. (Optional) Run ipv6 avoid-microloop segment-routing rib-update-delay

rib-update-delay
A delay in SRv6 IS-IS route delivery is configured.
6. Run ipv6 frr

7. Run loop-free-alternate [ level-1 | level-2 | level-1-2 ]
IPv6 IS-IS FRR is enabled.

8. Run ti-lfa [ level-1 | level-2 | level-1-2 ]
IS-IS SRv6 TI-LFA is enabled.

9. Run commit
----End

After configuring SRv6 egress protection, verify the configuration.
● Run the display segment-routing ipv6 local-sid end-m [ sid-value ]

forwarding command to check information about local SIDs.
● Run the display ipv6 routing-table vpn-instance vpn-instance-name
command to check information about IPv6 VPN routes received from the
remote end.
● Run the display bgp remote prefix-sid command to check the mappings
between remote prefix SIDs, End.M locator routes, and local VPN instances.
2.2.16 Configuring an SRv6 Path MTU

Configure an SRv6 path MTU on the ingress of an SRv6 BE path or SRv6 TE Policy
to ensure successful packet forwarding through the path or policy.
Context
IPv6 packets cannot be fragmented on transit nodes for forwarding. If the size of
an IPv6 packet entering a transit node exceeds the IPv6 MTU of the specified
outbound interface, the node discards the packet. Conversely, if the size of an IPv6
packet is smaller than the MTU configured for an SRv6 BE path or an SRv6 TE
Policy, the bandwidth of the associated link is not fully utilized. Therefore, an
appropriate SRv6 path MTU needs to be configured to prevent packet loss and
maximize link bandwidth utilization.
In TI-LFA protection or binding SID scenarios, an SRH that has segment lists
associated with TI-LFA or the binding SID needs to be inserted into IPv6 packets.
This increases the packet size and must be taken into account when an SRv6 path
MTU is configured. To allow for this additional length, configure a reserved path
MTU value on the SRv6 ingress. The configured SRv6 path MTU minus the
reserved value is called the active path MTU. The smaller of either the active path
MTU or the IPv6 MTU of physical interfaces takes effect on SRv6 packets.

(2020-10-09)
SRv6 path MTU configuration takes effect for packets forwarded through either an
SRv6 BE path or an SRv6 TE Policy. You need to configure a proper SRv6 path MTU
according to the size of SRv6-encapsulated packets.
Both SRv6 TE Policies and SRv6 BE paths support the global configuration of an
SRv6 path MTU and reserved value. For example, if an SRv6 path MTU is set to
1600 bytes and the reserved value is set to 100 bytes globally, the active path
MTU is 1500 bytes. In this case, if the IPv6 MTU of physical interfaces is greater
than or equal to 1500 bytes, the MTU used by the SRv6 ingress is 1500 bytes.
However, if the IPv6 MTU of physical interfaces is less than 1500 bytes, the ingress
uses this IPv6 MTU.
SRv6 TE Policies also support the configuration of SRv6 path MTUs on a per
segment list basis. An SRv6 path MTU configured for a segment list overrides the
global SRv6 path MTU. For example, if an SRv6 path MTU is set to 1600 bytes
globally, the SRv6 path MTU of all segment lists is 1600 bytes by default. If an
SRv6 path MTU is set to a value other than 1600 bytes for a segment list, this
segment list uses the newly configured value. The SRv6 path MTU of the segment
list minus the globally configured reserved value is the active path MTU of the
segment list. This active path MTU is then compared with the IPv6 MTU of
physical interfaces. The smaller value between them is the MTU that the SRv6
ingress actually uses.
Procedure
● Configure a path MTU for an SRv6 BE path.
a. Run system-view
c. Run path-mtu mtu-value
A global path MTU is configured for an SRv6 BE path.
d. (Optional) Run path-mtu reserved reserved-value
A global path MTU reserved value is configured.
The active path MTU is calculated by deducting the reserved value from
the global path MTU. The active path MTU must be greater than or equal
to 1280. The ingress forwards SRv6 packets using the smaller of either
this active path MTU or the IPv6 MTU of physical interfaces.
e. Run commit
● Configure a path MTU for an SRv6 TE Policy.
a. Run system-view
c. Run path-mtu mtu-value

(2020-10-09)
A global path MTU is configured for an SRv6 TE Policy.

d. (Optional) Run path-mtu reserved reserved-value
A global path MTU reserved value is configured.
The active path MTU is calculated by deducting the reserved value from
the global path MTU. The active path MTU must be greater than or equal
to 1280. The ingress forwards SRv6 packets using the smaller of either
this active path MTU or the IPv6 MTU of physical interfaces.
e. (Optional) Configure a path MTU for a segment list.
An SRv6 path MTU configured for a segment list overrides the global
SRv6 path MTU.
i. Run srv6-te policy policy-name endpoint ipv6-address color color-
value
An SRv6 TE Policy is created, and the SRv6 TE Policy view is
displayed.
ii. Run candidate-path preference preference
The candidate path view of the SRv6 TE Policy is displayed.
iii. Run segment-list list-name path-mtu mtu-value
The path MTU of the segment list is configured.
f. Run commit
----End
2.2.17 Configuring BGP SRv6

A controller orchestrates IGP SIDs and BGP SRv6-allocated BGP peer SIDs to
implement inter-AS forwarding over the optimal path.
Context
BGP is a dynamic routing protocol used between ASs. BGP SRv6 is a BGP extension
for SR and is used for inter-AS source routing.
BGP SRv6 uses BGP egress peer engineering (EPE) to allocate Peer-Node and Peer-
Adj SIDs to peers. These SIDs can be reported to the controller through BGP-LS for
orchestrating E2E SRv6 TE Policy tunnels.
Procedure
● Configure BGP EPE.
a. Run system-view
SRv6 is enabled.
c. Run quit

(2020-10-09)
d. Run bgp { as-number-plain | as-number-dot }

e. Run peer ipv6-address as-number as-number-plain
f. Run peer ipv6-address egress-engineering srv6 [ locator locator-name |
static-sid { psp psp-sid | no-psp-usp no-psp-usp-sid }* ]
BGP EPE is enabled.
The peer ipv6-address egress-engineering srv6 command enables BGP
EPE only.
The peer ipv6-address egress-engineering srv6 locator locator-name
command enables BGP EPE and specifies a locator to be used for SID
allocation to a specific peer.
The peer ipv6-address egress-engineering srv6 static-sid { psp psp-sid |
no-psp-usp no-psp-usp-sid }* command enables BGP EPE and configures
static SIDs.
NOTE
If all of the preceding three commands are run, only the last command takes
effect.
Table 2-18 describes the effects of each format of the peer ipv6-address
egress-engineering srv6 [ locator locator-name | static-sid { psp psp-sid
| no-psp-usp no-psp-usp-sid }* ] command with the segment-routing
ipv6 egress-engineering locator command being executed or not. (The
left four column headings of the table indicate the functions
corresponding to the involved command formats.) The segment-routing
ipv6 egress-engineering locator locator-name command is used to
specify a locator to be used for SID allocation to all BGP EPE peers.

(2020-10-09)
Table 2-18 Effects of different command configuration combinations

Loca BGP EPE Locator for Static SID Effect
tor Enabling SID
for Allocation to
SID a Specific
Alloc BGP EPE Peer
atio
n to
All
BGP
EPE
Peer
s
Confi N/A Configured Not The locator

gure configured specified in
d the peer ipv6-
address
egress-
engineering
srv6 locator
locator-name
command
takes effect,
and the End.X
SID (PSP) and
End.X SID (no
PSP, no USP)
are
dynamically
allocated.
Confi N/A Not Configured SIDs from the

gure configured same locator
d are configured
for all BGP
EPE peers.
If either of the
static End.X
SID (PSP) and
End.X SID (no
PSP, no USP)
is specified,
the other type
of SID is
dynamically
allocated.

(2020-10-09)

tor Enabling SID
for Allocation to
SID a Specific
Alloc BGP EPE Peer
atio
n to
All
BGP
EPE
Peer
s
Confi Configured Not Not The locator

gure configured configured specified in
d the segment-
routing ipv6
egress-
engineering
locator
locator-name
command
takes effect,
and the End.X
SID (PSP) and
End.X SID (no
PSP, no USP)
are
dynamically
allocated.
Not N/A Configured Not The locator

confi configured specified in
gure the peer ipv6-
d address
egress-
engineering
srv6 locator
locator-name
command
takes effect,
and the End.X
SID (PSP) and
End.X SID (no
PSP, no USP)
are
dynamically
allocated.

(2020-10-09)

tor Enabling SID
for Allocation to
SID a Specific
Alloc BGP EPE Peer
atio
n to
All
BGP
EPE
Peer
s
Not N/A Not Configured SID

confi configured configuration
gure fails. To
d address this
issue, before
you configure
a static SID,
run the
segment-
routing ipv6
egress-
engineering
locator
locator-name
command.
Not Configured Not Not No SIDs are

confi configured configured allocated.
gure
d
g. Run commit
● Configure BGP-LS.
information collection simpler and more efficient. You must configure a BGP-
LS peer relationship between the controller and forwarder, so that topology
information can be properly reported from the forwarder to the controller.
This example provides the procedure for configuring BGP-LS on the forwarder.
The procedure on the controller is similar to that on the forwarder.
a. Run system-view
c. Run peer ipv6-address as-number as-number-plain

(2020-10-09)

d. Run link-state-family unicast
BGP-LS is enabled, and the BGP-LS address family view is displayed.
e. Run peer ipv6-address enable
The device is enabled to exchange BGP-LS routes with a specified peer.
f. Run commit
----End

After configuring BGP SRv6, verify the configuration.
Run the display bgp egress-engineering command to check BGP EPE
information. If SIDs are displayed in the SRv6 SID and SRv6 SID (PSP) fields, the
configuration succeeds.
2.2.18 Configuring OSPFv3 to Advertise a Locator Route

To guide traffic forwarding in SRv6 scenarios, OSPFv3 can be configured to
advertise a locator route.
Context
Currently, only IS-IS can be used to implement SRv6 BE. In scenarios that use
OSPFv3 on the public network (for example, an SRv6 BE scenario), OSPFv3 needs
to be configured to advertise a locator route. After this is configured, OSPFv3 can
advertise intra-area LSAs carrying information about the IPv6 prefix configured for
the locator, and deliver the route with this IPv6 prefix to the local routing table to
guide traffic forwarding.
Procedure
SRv6 is enabled.
Step 3 Run locator locator-name [ ipv6-prefix ipv6-address prefix-length [ static static-
length | args args-length ] * ]
Step 4 Run quit
Step 5 Run quit
Exit the SRv6 view.

(2020-10-09)
Step 6 Run ospfv3 [ process-id ]

The OSPFv3 process view is displayed.
Step 7 Run router-id router-id
This router ID must be unique in an AS. The common practice is to select the IP
address of an interface on the device as the router ID.
NOTE
The router ID for each OSPFv3 process must be unique across the whole network.
Otherwise, an OSPFv3 neighbor relationship cannot be established, and routing information
is incorrect. You are advised to set a network-wide unique router ID for each OSPFv3
process on an OSPFv3 device.
Step 8 Run segment-routing ipv6 locator locator-name auto-sid-disable

OSPFv3 is enabled to advertise the locator route.
Step 9 Run commit
----End

Run the display ospfv3 [ process-id ] routing verbose command in any view to
check information about an OSPFv3 routing table.
2.2.19 Configuring SRv6 SFC

traffic along a specified path. This mechanism can be used to instruct SFC traffic
to pass through specific service functions (SFs).
2.2.19.1 Configuring Basic SRv6 SFC Functions

This section describes how to configure basic Service Function Chaining (SFC)
functions based on SRv6 TE Policy.
Prerequisites
Before configuring basic SRv6 SFC functions, complete the following task:
● Configure IS-IS to ensure IPv6 connectivity between the SC, SFFs, and tail end.
● (Optional) Configure VPN instances for SRv6 nodes as needed.
● Configure basic SRv6 functions on the network, a static End SID for each SRv6
node, and End.DT4 SIDs for the IPv4 public network instances or VPN
instances on the SC and tail end.
Context
SFC logically connects services on network devices to provide an ordered service
set for the application layer. By adding service function path (SFP) information in

(2020-10-09)
original packets, SFC enables packets to pass through service functions (SFs) along
a specified path.
traffic along a specified path. This mechanism is suitable for implementing SFC.
Specifically, if a data packet is steered into an SRv6 TE Policy, the headend adds
the segment lists of the SRv6 TE Policy to the data packet, and other devices on
the network execute the instructions embedded in the segment lists.
On the network shown in Figure 2-98, SF1 and SF2 are SRv6-unaware SFs. To
implement SFC, SF proxy must be configured on SFF1 and SFF2, and SRv6 SIDs
must be allocated to SF1 and SF2 proxies. On the SC, the SF1 Proxy SID, SF2 Proxy
SID, and Tail End SID form a segment list of an SRv6 TE Policy. The SRv6 TE Policy
functions as an SFP.
Figure 2-98 SRv6 TE Policy-based SFC forwarding
Procedure
Step 1 Manually configure an SRv6 TE Policy on the SC or use a controller to deliver an
SRv6 TE Policy to the SC. The segment list of the SRv6 TE Policy consists of the
SF1 Proxy SID, SF2 Proxy SID, and Tail-End SID.
Step 2 Configure a traffic policy on the SC to redirect traffic to the SRv6 TE Policy.
1. Run system-view
2. Run traffic classifier classifier-name [ operator { and | or } ]
A traffic classifier is configured, and the traffic classifier view is displayed.
3. Run if-match
A match condition is specified for the traffic classifier.
Currently, SRv6 SFC supports only IPv4 services. Therefore, the match
condition must be set based on IPv4 packets.
4. Run quit

(2020-10-09)

5. Run traffic behavior behavior-name
6. Run redirect srv6-te policy endpoint color sid sid-ip
The function to redirect IPv4 packets to the SRv6 TE Policy is enabled.
7. Run quit
8. Run traffic policy policy-name
9. Run classifier classifier-name behavior behavior-name
10. Run quit
11. Run interface interface-type interface-number [ .subinterface-number ]
Currently, only VBDIF interfaces are supported.
12. Run traffic-policy policy-name inbound
13. Run commit
Step 3 Configure an SFF.
1. Run system-view
4. Run opcode func-opcode1 end-as
An operation code (opcode) is configured for static End.AS SIDs, and the
static SRv6 SFC proxy view is displayed.
5. Run inner-type ipv4
The type of the original packets to be sent from the SFF to an SF is
configured.
Currently, only IPv4 packets are supported by SRv6 SFC.
6. Run either of the following commands to configure the SFF-to-SF packet
forwarding mode:

(2020-10-09)
The following commands are mutually exclusive and cannot both be

configured. Select a proper packet forwarding mode and set proper
parameters based on the network environment of the target SF.
– To configure Layer 3 IP forwarding from the SFF to the SF, run the
encapsulation ipv4 nexthop nexthop-addr out-interface { outInfName |
outInfType outInfNumber } in-interface { inInfName | inInfType
inInfNumber } [ symmetric-index index-value ] command.
In the command, both out-interface and in-interface specify interfaces
on the SFF, where out-interface is used for sending traffic to the SF and
in-interface is used for receiving traffic from the SF. Currently, out-
interface and in-interface can only be VBDIF interfaces. VBDIF interfaces
usually need to be bound to VPN instances for service isolation.
– To configure Layer 2 forwarding from the SFF to the SF, run the
encapsulation eth out-interface { outIntfname | outInfType outInfNum }
[ out-vlan out-vlan-id [ ce-vid out-cevid ] ] in-interface { inIntfname |
inInfType inInfNum } [ in-vlan in-vlan-id [ ce-vid in-cevid ] ] [ dest-mac
destMac ] command.
In the command, both out-interface and in-interface specify interfaces
on the SFF, where out-interface is used for sending traffic to the SF and
in-interface is used for receiving traffic from the SF. Currently, out-
interface and in-interface can only be EVC sub-interfaces. The VLAN IDs,
including out-vlan-id and in-vlan-id must be the same as the VLAN IDs
configured using the encapsulation dot1q vid command on the EVC
sub-interfaces.
7. Run cache source-address ipv6-address
A source IPv6 address is configured for the SFF to re-encapsulate this address
into the SRv6 SFC packets returned from the SF.
8. Run cache list { ipv6-address } &<1-11>
An SRH is configured for the SFF to re-encapsulate this SRH into the SRv6 SFC
packets returned from the SF.
9. (Optional) Run diffserv-mode { pipe service-class color | uniform }
A DiffServ mode is configured for the SFC packets returned from the SF to the
SFF.
10. (Optional) Run ttl-mode { pipe ttl-value | uniform }
A TTL processing mode is configured for the SFC packets returned from the SF
to the SFF.
11. Run commit
Step 4 Configure the tail end.
1. Run system-view

(2020-10-09)

4. Run opcode func-opcode end-dt4 [ vpn-instance vpn-name ]
A static End.DT4 SID's operation code (Opcode) is configured.
If vpn-instance vpn-name is specified, the tail end forwards packets to the
specified VPN instance. If vpn-instance vpn-name is not specified, the tail end
searches the public IP routing table to forward the packets.
5. Run commit
----End

After completing the configuration, run the following commands to verify the
configuration:
● Run the display segment-routing ipv6 local-sid end-as [ sid-value ]
forwarding command to check the SRv6 local SID table containing End.AS
SIDs.
● Run the display segment-routing ipv6 local-sid end-dt4 [ sid-value | vpn-
instance vpn-name ] forwarding command to check the SRv6 local SID table
containing End.DT4 SIDs.
2.2.19.2 Configuring SRv6 SFC Reliability

This section describes how to configure SRv6 SFC reliability.
Prerequisites
Before configuring SRv6 SFC reliability, complete the following tasks:
● Configure basic SRv6 SFC functions.
Context
SFC services are forwarded in serial mode, meaning that a single link or node
failure causes SFC service interruptions. To improve service reliability, SRv6 SFC
provides backup link protection and bypass link protection.
● In backup link protection, an SF is dual-homed to two SFFs, with one as the
master, and the other as the backup. The backup SFF is used to protect the
primary SFF. If the primary SFF becomes unreachable, services are switched to
the backup SFF for processing.
● In bypass link protection, if an SF is unreachable, SFC traffic is switched to the
bypass service path, without being processed by the current SF. An SFF usually
discards SFC packets if an SF is unreachable. After bypass protection is
configured, SFC packets can continue to be forwarded as follows:
a. If no bypass SF is available for the current SF, SRv6 forwarding for SFC
packets is implemented.
b. If the current SF has a bypass SF to provide protection, SFC packets are
switched to the bypass SF for processing.

(2020-10-09)
These protection schemes can be selected according to specific SFC networking

scenarios. The following describes how to configure SRv6 SFC reliability, using the
network shown in Figure 2-99 as an example. In Figure 2-99, SF1 is dual-homed
to SFF1 and SFF2, and has a bypass SF – SF2.
Configuration roadmap:
1. Configure a backup path for protection. Because SF1 is dual-homed to SFF1
and SFF2, SFF1 and SFF2 can provide protection for each other. Specifically,
the same SF1 Proxy SID of the End.AS type needs to be configured on SFF1
and SFF2 to implement the anycast function. (For ease of description, the SF1
Proxy SID on SFF2 in Figure 2-99 is called SF1 Backup Proxy SID.) In addition,
SFF1 and SFF2 need to be configured as peers of each other. The peer SID of
SFF1 is the End SID of SFF2, and the peer SID of SFF2 is the End SID of SFF1.
2. Configure a bypass service path by using SF2 to protect SF1. Specifically,
configure a bypass protection SID for the SF1 Proxy SID, and configure the
SF2 Proxy SID on SFF3.
3. Configure one-arm BFD on SFF1 and SFF2 to detect SF1 reachability.
– If one-arm BFD on SFF1 detects that SF1 is unreachable, the SFC traffic is
switched to the backup service path. SFF1 replaces the original SRv6
segment list with the SF1 Proxy Backup SID and SFF2 End SID, and
forwards the SFC packet to SFF2. After receiving the packet, SFF2
identifies that both the SF1 Proxy Backup SID and SFF2 End SID are its
own SIDs. SFF2 then forwards the packet to SF1 based on the SF1 Proxy
Backup SID.
– SFC traffic is switched to SFF2 if one-arm BFD on SFF1 detects that SF1 is
unreachable. If one-arm BFD on SFF2 also detects that SF1 is
unreachable, the SFC traffic is switched to the bypass service path. SFF2
removes the SRH and searches the IPv6 routing table for packet
forwarding, using the SF2 Proxy SID as the destination IPv6 address. After
receiving the packet, SFF3 forwards the packet to SF2 based on the SF2
Proxy SID.

(2020-10-09)
Figure 2-99 SFC scenario with a dual-homed SF that has a bypass SF
Procedure
Step 1 Configure SFF backup link protection.
In this example, SF1 is dual-homed to SFF1 and SFF2, which can back up each
other. The configurations of SFF1 and SFF2 are symmetrical. In an SF single-
homing scenario, backup link protection cannot be implemented.
1. Run system-view


3. Run proxy peer-sid peersid
A peer End SID is configured on the SFF.
The peer SID on SFF1 is the End SID of SFF2, and the peer SID on SFF2 is the
End SID of SFF1.
static-length | args args-length ] * [ default ] ]
To implement anycast protection, the configuration must be the same on

SFF1 and SFF2.

(2020-10-09)

A static End.AS SID's operation code (opcode) is configured, and the static
SRv6 SFC proxy view is displayed.
To implement anycast protection, the configuration must be the same on
SFF1 and SFF2.
6. Run backup-opcode func-opcode
An opcode is configured for the static SRv6 SFC proxy backup SID.
This opcode and locator form a backup SID.
In the SF1 dual-homing scenario, the Backup SID on SFF1 is the SF1 Proxy SID
on SFF2, and the Backup SID on SFF2 is the SF1 Proxy SID on SFF1. To
implement anycast protection, the configuration must be the same on SFF1
and SFF2.
7. Run commit
Step 2 Configure SFF bypass protection.
1. Run system-view
static-length | args args-length ] * [ default ] ]
A static End.AS SID's opcode is configured, and the static SRv6 SFC proxy view
is displayed.
5. Run bypass [ sid ipv6-address ]
A bypass protection path is configured to protect traffic against SF service
failures.
When you configure a bypass protection path:
– If sid ipv6-address is not specified, traffic is forwarded without passing
through the faulty node. This means that no backup SF exists.
– If sid ipv6-address is specified, traffic is forwarded to the specified backup
SF. In this example, sid ipv6-address should be set to the SF2 Proxy SID of
SFF3.
6. Run commit
Step 3 Configure one-arm BFD.
In this example, one-arm BFD needs to be configured on SFF1 and SFF2. BFD can
detect only Layer 3 IP links. If Layer 2 forwarding is used from the SFFs to SFs, BFD
cannot be used.

(2020-10-09)
1. Run system-view

2. Run bfd
BFD is enabled.
3. Run quit
Exit the BFD view.

4. Run bfd sessname-value bind peer-ip ip-address [ vpn-instance vpn-
instance-name ] interface ifType ifNum [ source-ip ip-address ] one-arm-
echo destination-ip ip-address
A one-arm BFD session is created.
Pay attention to the following parameter values:
– When an SF is dual-homed to two SFFs that provide anycast protection,

the SF may return BFD packets to an unexpected SFF, causing BFD
detection to fail. To address this issue, destination-ip ip-address must be
set to the IP address of the target SFF's loopback interface on the public
network. The SF then returns BFD response packets to this IP address.
– If the SF is on a VPN, vpn-instance vpn-instance-name must be specified.
To ensure that the destination IP address specified using destination-ip
ip-address is reachable, the route to this destination IP address must be
configured in the VPN instance.
A local BFD session discriminator is configured. You only need to configure

the local discriminator because the BFD Echo function can be configured only
on the device supporting BFD.
6. Run process-pst
The BFD session is allowed to modify the port state table (PST) or link state
table when a fault is detected.
7. Run commit
----End

After completing the configuration, run the following command to verify the
configuration:
● Run the display bfd session { all | peer-ip peer-ip [ vpn-instance vpn-
name ] } [ verbose ] command to check the BFD session information.
2.2.20 Using Ping/Tracert to Test an SRv6 Network

Ping and tracert can be used to test and monitor a Segment Routing IPv6 (SRv6)
network.

(2020-10-09)
2.2.20.1 Using Ping to Test the Connectivity of an SRv6 Network

Ping can be used to test the connectivity of an SRv6 network.
Context
After SRv6 configurations are complete, you can perform the following operations
in any view of the client.
Procedure
● Specify SIDs to test the connectivity of an SRv6 network.
To test the connectivity of an SRv6 network, run the ping ipv6-sid [ -a

source-ipv6-address | -c echo-number | -m wait-time | -s packetsize | -t
timeout | -tc traffic-class-value ] * [ segment-by-segment ] sid & <1-11>
command on the ingress to specify SRv6 SIDs to initiate a ping test to the
egress.
<HUAWEI> ping ipv6-sid A2::C31 A4::C50 A4::C52
PING ipv6-sid A2::C31 A4::C50 A4::C52 : 56 data bytes, press CTRL_C to break
Reply from A4::C52
Reply from A4::C52
Reply from A4::C52
Reply from A4::C52
Reply from A4::C52
--- ipv6-sid ping statistics---

0.00% packet loss
● Test the connectivity of an SRv6 TE Policy.

a. (Optional) Configure an End.OP SID on the remote endpoint of the SRv6
TE Policy.
An End.OP SID is an OAM SID that specifies the punt behavior to be
implemented for an OAM packet in ping and tracert scenarios. If the
bottom SID in the SRv6 TE Policy's segment list is an End.X or binding
SID, you must manually specify an End.OP SID when initiating a ping
operation to the SRv6 TE Policy. Before specifying the end-op endop
parameter, you must configure the End.OP SID.
i. Run segment-routing ipv6
ii. Run locator locator-name
Ensure that the locator has been created and advertised through IS-
IS. The locator is also used by the created SRv6 TE Policy.
iii. Run opcode func-opcode end-op
An opcode is configured for an End.OP SID.

(2020-10-09)
iv. Run commit

b. On the ingress of the SRv6 TE Policy, run the ping srv6-te policy
{ policy-name policyname | endpoint-ip endpointipv6 color colorid |
binding-sid bsid } [ end-op endop ] [ -a sourceaddr6 | -c count | -m
interval | -s packetsize | -t timeout | -tc tc | -h hoplimit ] * command
with the policy-name policyname, endpoint-ip endpointipv6 color
colorid, or binding-sid bsid parameter to initiate a ping operation on the
specified SRv6 TE Policy for connectivity check.
<HUAWEI> ping srv6-te policy policy-name test end-op 2001:db8:2::1 -a 2001:db8:1::1 -c 5 -m
2000 -t 2000 -s 100 -tc 0 -h 255
PING srv6-te policy : 100 data bytes, press CTRL_C to break
srv6-te policy's segment list:
Preference: 200; Path Type: primary; Protocol-Origin: local; Originator: 0, 0.0.0.0; Discriminator: 200;
Segment-List ID: 1; Xcindex: 1; end-op: 2001:db8:2::1
Reply from 2001:db8:2::1
bytes=100 Sequence=1 time=8 ms
--- srv6 ping statistics ---
0.00% packet loss
----End
2.2.20.2 Using Tracert to Test the Path Information of an SRv6 Network

Tracert can be used to test the path information of an SRv6 network.
Context
After configuring SRv6, you can perform the following configurations in any view
of a client.
Procedure
● Specify SIDs to test the path information of an SRv6 network or locate the
fault point on the path.
To test the fault point on an SRv6 network, run the tracert ipv6-sid [ -f first-
hop-limit | -m max-hop-limit | -p port-number | -q probes | -w timeout | -s
packetsize | -a source-ipv6-address ] * [ overlay ] sid & <1-11> command on
the ingress to specify SRv6 SIDs to initiate a tracert test to the egress.
<HUAWEI> tracert ipv6-sid A2::C31 A4::C50 A4::C52
traceroute ipv6-sid A2::C31 A4::C50 A4::C52 30 hops max,60 bytes packet
1 2001:DB8:1:2::21[SRH: A4::C52, A4::C50, A2::C31, SL=2] 5 ms 3 ms 2 ms
2 2001:DB8:2:3::31[SRH: A4::C52, A4::C50, A2::C31, SL=1] 5 ms 2001:DB8:2:3::32[SRH: A4::C52, A4::OP,
A2::C31, SL=1] 2ms 2ms
3 A4::C52[SRH: A4::C52, A4::C50, A2::C31, SL=1] 5 ms 10 ms 0.759 ms
● Test the path over which an SRv6 TE Policy is established or locate the fault
point on the path.

(2020-10-09)
a. (Optional) Configure an End.OP SID on the remote endpoint of the SRv6

TE Policy.
An End.OP SID is an OAM SID that specifies the punt behavior to be
implemented for an OAM packet in ping and tracert scenarios. If the
bottom SID in the SRv6 TE Policy's segment list is an End.X or binding
SID, you must manually specify an End.OP SID when initiating a tracert
operation to the SRv6 TE Policy. Before specifying the end-op endop
parameter, you must configure the End.OP SID.
i. Run segment-routing ipv6
ii. Run locator locator-name
Ensure that the locator has been created and advertised through IS-
IS. The locator is also used by the created SRv6 TE Policy.
iii. Run opcode func-opcode end-op
An opcode is configured for an End.OP SID.
iv. Run commit
b. On the ingress of the SRv6 TE Policy, run the tracert srv6-te policy
{ policy-name policyname | endpoint-ip endpointipv6 color colorId |
binding-sid bsid } [ end-op endop ] [ -a sourceaddr6 | -f initHl | -m
maxHl | -s packetsize | -w timeout | -p destport | -tc tc ] * command with
the policy-name policyname, endpoint-ip endpointipv6 color colorId, or
binding-sid bsid to initiate tracert to the corresponding SRv6 TE Policy to
detect all intermediate nodes along the tunnel.
<HUAWEI> tracert srv6-te policy policy-name test end-op 2001:db8:2::1 -a 2001:db8:1::1 -p 5 -m
20 -tc 0
Trace Route srv6-te policy : 100 data bytes, press CTRL_C to break
srv6-te policy's segment list:
Preference: 200; Path Type: primary; Protocol-Origin: local; Originator: 0, 0.0.0.0; Discriminator: 200;
Segment-List ID: 1; Xcindex: 1; end-op: 2001:db8:2::1
TTL Replier Time Type SRH
0 Ingress [SRH: 2001:db8:1::F:1, 2001:db8:2::F:1, 2001:db8:2::1,
SL=2]
1 2001:db8:A::192:168:103:2 22 ms Transit [SRH: 2001:db8:1::F:1, 2001:db8:2::F:1,
2001:db8:2::1, SL=2]
2 2001:db8:A::192:168:106:2 10 ms Transit [SRH: 2001:db8:1::F:1, 2001:db8:2::F:1,
2001:db8:2::1, SL=1]
3 2001:db8:2::1 4 ms Egress
----End
2.2.21 Maintaining SRv6

This section describes SRv6 maintenance functions.
2.2.21.1 Configuring SRv6 TE Policy-related Alarm Thresholds

You can configure SRv6 TE Policy-related alarm thresholds, enabling the device to
generate an alarm when the number of SRv6 TE Policies, SRv6 TE Policy groups, or
segment lists reaches the specified threshold. This facilitates O&M.

(2020-10-09)
Context
If the number of SRv6 TE Policies, SRv6 TE Policy groups, or segment lists exceeds
the upper limit, adding new SRv6 TE Policies, SRv6 TE Policy groups, or segment
lists may affect existing services. To prevent this, you can configure alarm
thresholds for the numbers of SRv6 TE Policies, SRv6 TE Policy groups, and
segment lists. In this way, when the number of SRv6 TE Policies or segment lists
reaches the specified threshold, an alarm is generated to notify users to handle
the problem.
Procedure
Step 3 Run srv6-te-policy segment-list-number threshold-alarm upper-limit
upperLimitValue lower-limit lowerLimitValue
An alarm threshold is configured for the number of segment lists.
Step 4 Run srv6-te-policy policy-number threshold-alarm upper-limit upperLimitValue
An alarm threshold is configured for the number of SRv6 TE Policies.
Step 5 Run srv6-te-policy group-number threshold-alarm upper-limit upperLimitValue
An alarm threshold is configured for the number of SRv6 TE Policy groups.
Step 6 Run commit
----End
2.2.21.2 Configuring SRv6 TE Policy Traffic Statistics Collection

This section describes how to configure SRv6 TE Policy traffic statistics collection.
Context
SRv6 TE Policy traffic statistics collection enables you to collect statistics about the
traffic forwarded through a specified or all SRv6 TE Policies.
This function supports both global configuration and single-policy configuration. If
global configuration and single-policy configuration both exist, the single-policy
Procedure
Step 1 Global configuration

(2020-10-09)
1. Run system-view


3. Run srv6-te-policy traffic-statistics enable
Traffic statistics collection is enabled for all SRv6 TE Policies.

4. Run commit
Step 2 Single-policy configuration

1. Run system-view


3. Run srv6-te policy policy-name

4. Run traffic-statistics (SRv6 TE Policy view) { enable | disable }
Traffic statistics collection is enabled for a specified SRv6 TE Policy.

5. Run commit
----End

After configuring SRv6 TE Policy traffic statistics collection, run the display srv6-te
policy traffic-statistics [ endpoint ipv6-address color color-value | policy-name
name-value | binding-sid binding-sid ] command to check collected SRv6 TE
Policy traffic statistics.
Follow-up Procedure
To clear existing SRv6 TE Policy traffic statistics, run the reset srv6-te policy
traffic-statistics [ endpoint ipv6-address color color-value | policy-name name-
value | binding-sid binding-sid ] command.
2.2.22 Configuration Examples for SRv6 BE

This section provides SRv6 BE configuration examples.
2.2.22.1 Example for Configuring L3VPNv4 over SRv6 BE

This section provides an example for configuring SRv6 BE to carry L3VPNv4
services.

(2020-10-09)
● PE1, the P, and PE2 are in the same AS and run IS-IS to implement IPv6
network connectivity.
● PE1, the P, and PE2 are Level-1 devices that belong to IS-IS process 1.
It is required that a bidirectional SRv6 BE path be deployed between PE1 and PE2
to carry L3VPNv4 services.
Figure 2-100 L3VPNv4 over SRv6 BE networking

NOTE
1. Enable IPv6 forwarding and configure an IPv6 address for each interface on
PE1, the P, and PE2.
2. Enable IS-IS, configure an IS-IS level, and specify a network entity on PE1, the
P, and PE2.
3. Configure VPN instances on PE1 and PE2.
4. Establish an EBGP peer relationship between each PE and its connected CE.
5. Establish an MP-IBGP peer relationship between PEs.
6. Configure SRv6 on PE1 and PE2, and enable IS-IS SRv6.
Data Preparation
● IPv6 address of each interface on PE1, the P, and PE2
● IS-IS process ID of PE1, the P, and PE2
● IS-IS level of PE1, the P, and PE2
● VPN instance name, RD, and RT on PE1 and PE2

(2020-10-09)
Procedure
Step 1 Enable IPv6 forwarding and configure an IPv6 address for each interface. The
following example uses the configuration of PE1. The configurations of other
devices are similar to the configuration of PE1. For configuration details, see
[*HUAWEI] commit
[~PE1-GigabitEthernet1/0/0] ipv6 enable
[*PE1-GigabitEthernet1/0/0] ipv6 address 2001::1 96
[*PE1] interface LoopBack 1
[*PE1-LoopBack1] ipv6 enable
[*PE1-LoopBack1] ipv6 address 1::1 64
[*PE1] commit
Step 2 Configure IS-IS.

# Configure PE1.
[~PE1] isis 1
[*PE1-isis-1] ipv6 enable topology ipv6
[*PE1-isis-1] quit
[*PE1-GigabitEthernet1/0/0] isis ipv6 enable 1
[*PE1] interface loopback1
[*PE1-LoopBack1] isis ipv6 enable 1
# Configure the P.
[~P] isis 1
[*P-isis-1] ipv6 enable topology ipv6
[*P-isis-1] quit
[*P] interface gigabitethernet 1/0/0
[*P-GigabitEthernet1/0/0] isis ipv6 enable 1
[*P] interface loopback1
[*P-LoopBack1] isis ipv6 enable 1
[*P-LoopBack1] commit
[~P-LoopBack1] quit
# Configure PE2.
[~PE2] isis 1
[*PE2-isis-1] quit

(2020-10-09)

After the configuration is complete, perform the following operations to check

whether IS-IS is successfully configured:
# Display IS-IS neighbor information. The following example uses the command
output on PE1.

--------------------------------------------------------------------------------
0000.0000.0002 GE1/0/0 0000.0000.0002.01 Up 8s L1 64
Total Peer(s): 1
# Display IS-IS routing table information. The following example uses the
[~PE1] display isis route
-----------------------------

--------------------------------
IPV6 Dest. ExitInterface NextHop Cost Flags

--------------------------------------------------------------------------------
1::1/64 Loop1 Direct 0 D/-/L/-
2::2/64 GE1/0/0 FE80::3A92:6CFF:FE21:10 10 A/-/-/-
3::3/64 GE1/0/0 FE80::3A92:6CFF:FE21:10 20 A/-/-/-
2001::/96 GE1/0/0 Direct 10 D/-/L/-
2002::/96 GE1/0/0 FE80::3A92:6CFF:FE21:10 20 A/-/-/-
instance, and bind the interface that connects a PE to a CE to the VPN instance on
that PE.
# Configure PE1.
[*PE1] commit
# Configure PE2.

(2020-10-09)

[*PE2] commit
# Assign an IP address to each interface on CEs, as shown in Figure 2-100. For

NOTE
may fail.
# Configure CE1.
[*CE1] bgp 65410
[*CE1-bgp] network 11.11.11.11 32
[*CE1-bgp] quit
[*CE1] commit
# Configure PE1.
[~PE1] bgp 100
[*PE1-bgp] router-id 1.1.1.1
[*PE1-bgp-vpna] import-route direct
[~PE1-bgp] quit
# Configure CE2.
[*CE2] bgp 65420
[*CE2-bgp] network 22.22.22.22 32
[*CE2-bgp] quit
[*CE2] commit
# Configure PE2.
[~PE2] bgp 100
[~PE2-bgp] quit
command on the PEs and check whether BGP peer relationships have been

(2020-10-09)


10.1.1.2 4 65410 11 9 0 00:06:37 Established 1
# Configure PE1.
[~PE1] bgp 100
[~PE1-bgp] peer 3::3 as-number 100
[*PE1-bgp] peer 3::3 connect-interface loopback 1
[*PE1-bgp-af-vpnv4] peer 3::3 enable
[~PE1-bgp] quit
# Configure PE2.
[~PE2] bgp 100
[~PE2-bgp] quit
After the configuration is complete, run the display bgp vpnv4 all peer command
on the PEs and check whether BGP peer relationships have been established
BGP peer relationships have been established successfully. The following example
uses the command output on PE1.

Peer V AS MsgRcvd MsgSent OutQ Up/Down State

PrefRcv
3::3 4 100 10 11 0 00:05:15 Established 2
Peer of IPv4-family for vpn instance :

PrefRcv
10.1.1.2 4 65410 10 13 0 00:06:18 Established 1

(2020-10-09)
NOTE
An End.DT4 SID can be either dynamically allocated by BGP or manually configured. If a

dynamically allocated SID and a manually configured SID both exist, the manually
configured SID takes effect. If dynamic End.DT4 SID allocation by BGP has been enabled
using the segment-routing ipv6 locator locator-name command, you do not need to run
the opcode func-opcode end-dt4 vpn-instance vpn-instance-name command to configure
a static SID opcode.
In this example, SIDs are dynamically allocated by BGP.
# Configure PE1.
[~PE1] segment-routing ipv6
[*PE1-segment-routing-ipv6] encapsulation source-address 1::1
[*PE1-segment-routing-ipv6] locator as1 ipv6-prefix 10:: 64 static 32
[*PE1-segment-routing-ipv6-locator] quit
[*PE1-segment-routing-ipv6] quit
[*PE1] bgp 100
[*PE1-bgp-af-vpnv4] peer 3::3 prefix-sid
[*PE1-bgp-af-vpnv4] quit
[*PE1-bgp-vpna] segment-routing ipv6 best-effort
[*PE1-bgp-vpna] segment-routing ipv6 locator as1
[~PE1-bgp] quit
[~PE1] isis 1
[~PE1-isis-1] segment-routing ipv6 locator as1
[~PE1-isis-1] quit
# Configure PE2.
[*PE2] bgp 100
[~PE2-bgp] quit
[~PE2] isis 1
[~PE2-isis-1] quit

Run the display segment-routing ipv6 locator [ locator-name ] verbose
command to check SRv6 locator information. The following example uses the
[~PE1] display segment-routing ipv6 locator verbose
Locator Configuration Table
---------------------------
LocatorName : as1 LocatorID : 1

IPv6Prefix : 10:: PrefixLength: 64
StaticLength : 32 Reference : 2

(2020-10-09)
ArgsLength : 0
AutoSIDPoolID: 8193
AutoSIDBegin : 10::1:0:0
AutoSIDEnd : 10::FFFF:FFFF:FFFF:FFFF
Total Locator(s): 1
Run the display segment-routing ipv6 local-sid end-dt4 forwarding command

to check information about the SRv6 local SID table. The following example uses
the command output on PE1.
[~PE1] display segment-routing ipv6 local-sid end-dt4 forwarding
My Local-SID End.DT4 Forwarding Table
-------------------------------------
SID : 10::1:0:0/128 FuncType : End.DT4

VPN Name : vpna VPN ID : 3
LocatorName: as1 LocatorID: 1
Total SID(s): 1
Run the display bgp vpnv4 all routing-table command on each PE to check BGP
VPNv4 routing information. The following example uses the command output on
PE1.
[~PE1] display bgp vpnv4 all routing-table

RPKI validation codes: V - valid, I - invalid, N - not-found
Total number of routes from all PE: 6

Network NextHop MED LocPrf PrefVal Path/

Ogn
*> 10.1.1.0/24 0.0.0.0 0 0 ?

*> 10.1.1.1/32 0.0.0.0 0 0 ?
*> 11.11.11.11/32 10.1.1.2 0 0 65410i
*> 127.0.0.0/8 0.0.0.0 0 0 ?
Network NextHop MED LocPrf PrefVal Path/Ogn
*>i 10.2.1.0/24 3::3 0 100 0 ?

*>i 22.22.22.22/32 3::3 0 100 0 65420i

Network NextHop MED LocPrf PrefVal Path/
Ogn
*> 10.1.1.0/24 0.0.0.0 0 0 ?

*> 10.1.1.1/32 0.0.0.0 0 0 ?
*>i 10.2.1.0/24 3::3 0 100 0 ?
*> 11.11.11.11/32 10.1.1.2 0 0 65410i
*>i 22.22.22.22/32 3::3 0 100 0 65420i
*> 127.0.0.0/8 0.0.0.0 0 0 ?
Run the display ip routing-table vpn-instance vpna command on PEs to check

VPN routing table information. The following example uses the command output
on PE1.

(2020-10-09)

route
------------------------------------------------------------------------------

10.2.1.0/24 IBGP 255 0 RD 30::1:0:3C SRv6 BE
22.22.22.22/32 IBGP 255 0 RD 30::1:0:3C SRv6 BE
Run the display ip routing-table vpn-instance vpna ip-address verbose

command on PEs to check detailed VPN routing table information. The following
route
------------------------------------------------------------------------------
Summary Count : 1
NextHop: 30::1:0:3C Neighbour: 3::3
IndirectID: 0x1000133 Instance:
RelayNextHop: 30::1:0:3C Interface: SRv6 BE
Check that CEs belonging to the same VPN instance can ping each other. The
following example uses the command output on CE1.
[~CE1] ping -a 11.11.11.11 22.22.22.22

0.00% packet loss
----End
Configuration Files
#
sysname PE1
#
ipv4-family

(2020-10-09)

#
segment-routing ipv6
encapsulation source-address 1::1
locator as1 ipv6-prefix 10:: 64 static 32
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0001.00
#
ipv6 enable topology ipv6
segment-routing ipv6 locator as1
#
#
undo shutdown
ipv6 enable
ipv6 address 2001::1/96
isis ipv6 enable 1
#
undo shutdown
ip address 10.1.1.1 255.255.255.0
#
interface LoopBack1
ipv6 enable
isis ipv6 enable 1
#
bgp 100
router-id 1.1.1.1
peer 3::3 as-number 100
peer 3::3 connect-interface LoopBack1
#
ipv4-family unicast
#
ipv6-family unicast
#
ipv4-family vpnv4
policy vpn-target
peer 3::3 enable
peer 3::3 prefix-sid
#
import-route direct
segment-routing ipv6 best-effort
#
return
#
sysname P
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0002.00
#
#
#
undo shutdown

(2020-10-09)
ipv6 enable
isis ipv6 enable 1
#
undo shutdown
ipv6 enable
isis ipv6 enable 1
#
interface LoopBack1
ipv6 enable
isis ipv6 enable 1
#
return
#
sysname PE2
#
ipv4-family
#
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0003.00
#
#
#
undo shutdown
ipv6 enable
isis ipv6 enable 1
#
undo shutdown
ip address 10.2.1.1 255.255.255.0
#
interface LoopBack1
ipv6 enable
isis ipv6 enable 1
#
bgp 100
router-id 2.2.2.2
#
ipv4-family unicast
#
ipv6-family unicast
#
ipv4-family vpnv4
policy vpn-target
peer 1::1 enable

(2020-10-09)

#
import-route direct
#
return

#
sysname CE1
#
undo shutdown
ip address 10.1.1.2 255.255.255.0
#
interface LoopBack1
ip address 11.11.11.11 255.255.255.255
#
bgp 65410
#
ipv4-family unicast
network 11.11.11.11 255.255.255.255
#
return

#
sysname CE2
#
undo shutdown
ip address 10.2.1.2 255.255.255.0
#
interface LoopBack1
ip address 22.22.22.22 255.255.255.255
#
bgp 65420
#
ipv4-family unicast
network 22.22.22.22 255.255.255.255
#
return
2.2.22.2 Example for Configuring L3VPNv4 over SRv6 BE ECMP

This section provides an example for configuring L3VPNv4 over SRv6 BE ECMP.
Context
● PE1, PE2, P1, and P2 are in the same AS and run IS-IS to implement IPv6
● PE1, P1, P2, and PE2 are Level-2 devices that belong to IS-IS process 1.

(2020-10-09)
to carry L3VPNv4 services. In addition, to maximize network resource utilization, it
is required that ECMP be performed for L3VPNv4 services carried by the SRv6 BE
path between PE1 and PE2.
Figure 2-101 L3VPNv4 over SRv6 BE ECMP networking

NOTE
Precautions
When configuring L3VPNv4 over SRv6 BE ECMP, note the following:
● SRv6 BE ECMP depends on equal-cost routes on the network. To ensure

successful configuration, you need to properly plan IGP costs for links. In this
example, each link uses the default cost value 10.
PE1, P1, P2, and PE2.
2. Enable IS-IS, configure an IS-IS level, and specify a network entity on PE1, P1,
P2, and PE2. In addition, configure dynamic BFD for IPv6 IS-IS.
Data Preparation

(2020-10-09)
● IPv6 address of each interface on PE1, P1, P2, and PE2

● IS-IS process ID of PE1, P1, P2, and PE2
● IS-IS level of PE1, P1, P2, and PE2
Procedure
[*HUAWEI] commit
[*PE1-GigabitEthernet1/0/0] ipv6 address 2001:db8:1::1 96
[*PE1] commit

When configuring IS-IS, enable dynamic BFD to speed up IS-IS convergence in the
case of a link status change.
# Configure PE1.
[~PE1] bfd
[*PE1-bfd] quit
[*PE1] isis 1
[*PE1-isis-1] ipv6 bfd all-interfaces enable
[*PE1-isis-1] quit
# Configure P1.
[~P1] bfd
[*P1-bfd] quit
[*P1] isis 1
[*P1-isis-1] ipv6 enable topology ipv6

(2020-10-09)
[*P1-isis-1] ipv6 bfd all-interfaces enable

[*P1-isis-1] quit
[*P1-GigabitEthernet1/0/0] isis ipv6 enable 1
[*P1] interface loopback1
[*P1-LoopBack1] isis ipv6 enable 1
# Configure P2.
[~P2] bfd
[*P2-bfd] quit
[*P2] isis 1
[*P2-isis-1] quit
# Configure PE2.
[~PE2] bfd
[*PE2-bfd] quit
[*PE2] isis 1
[*PE2-isis-1] quit

output on PE1.

--------------------------------------------------------------------------------

(2020-10-09)
0000.0000.0004* GE2/0/0 0000.0000.0004.02 Up 7s L2 64

0000.0000.0002* GE1/0/0 0000.0000.0002.02 Up 9s L2 64
Total Peer(s): 2
-----------------------------

--------------------------------

--------------------------------------------------------------------------------
1::/64 Loop1 Direct 0 D/-/L/-
2::/64 GE1/0/0 FE80::3A92:6CFF:FE31:307 10 A/-/-/-
3::/64 GE1/0/0 FE80::3A92:6CFF:FE31:307 20 A/-/-/-
GE2/0/0 FE80::3A92:6CFF:FE41:305
4::/64 GE2/0/0 FE80::3A92:6CFF:FE41:305 10 A/-/-/-
2001:DB8:1::/96 GE1/0/0 Direct 10 D/-/L/-
2001:DB8:2::/96 GE1/0/0 FE80::3A92:6CFF:FE31:307 20 A/-/-/-
2001:DB8:3::/96 GE2/0/0 Direct 10 D/-/L/-
2001:DB8:4::/96 GE2/0/0 FE80::3A92:6CFF:FE41:305 20 A/-/-/-
that PE.
# Configure PE1.
[*PE1] commit
# Configure PE2.
[*PE2] commit


(2020-10-09)
NOTE
may fail.
# Configure CE1.
[*CE1] bgp 65410
[*CE1-bgp] network 11.11.11.11 32
[*CE1-bgp] quit
[*CE1] commit
# Configure PE1.
[~PE1] bgp 100
[~PE1-bgp] quit
# Configure CE2.
[*CE2] bgp 65420
[*CE2-bgp] network 22.22.22.22 32
[*CE2-bgp] quit
[*CE2] commit
# Configure PE2.
[~PE2] bgp 100
[~PE2-bgp] quit

(2020-10-09)

10.1.1.2 4 65410 11 9 0 00:06:37 Established 1

# Configure PE1.
[~PE1] bgp 100
[~PE1-bgp] quit
# Configure PE2.
[~PE2] bgp 100
[~PE2-bgp] quit
BGP peer relationships have been established successfully.
NOTE

# Configure PE1.
[*PE1] bgp 100
[~PE1-bgp] quit
[~PE1] isis 1
[~PE1-isis-1] quit

(2020-10-09)
# Configure PE2.
[*PE2] bgp 100
[~PE2-bgp] quit
[~PE2] isis 1
[~PE2-isis-1] quit

command to check VPN routing information. The following example uses the
[~PE1] display ip routing-table vpn-instance vpna 22.22.22.22 32 verbose
------------------------------------------------------------------------------
Summary Count : 1
NextHop: 30::1:0:20 Neighbour: 3::3
IndirectID: 0x10000C7 Instance:
RelayNextHop: 30::1:0:20 Interface: SRv6 BE
The preceding command output shows that the VPN route 22.22.22.22/32 has
recursed to an SRv6 BE path.
Display details about the IPv6 route using the next-hop address 30::1:0:20 as the
[~PE1] display ipv6 routing-table 30::1:0:20 verbose
------------------------------------------------------------------------------
Summary Count : 2
Destination : 30:: PrefixLength : 64

NextHop : FE80::3A92:6CFF:FE31:307 Preference : 15
Neighbour : :: ProcessID : 1
Label : NULL Protocol : ISIS-L2
State : Active Adv Cost : 20
Priority : medium Age : 132sec
IndirectID : 0x1000085 Instance :

(2020-10-09)

IndirectID : 0x1000087 Instance :
The preceding command output shows that the route 30::1:0:20 has two outbound
interfaces. The interfaces work in ECMP mode during packet forwarding.
[~CE1] ping -a 11.11.11.11 22.22.22.22

0.00% packet loss
----End
Configuration Files
#
sysname PE1
#
ipv4-family
#
bfd
#
#
isis 1
is-level level-2
cost-style wide
network-entity 10.0000.0000.0001.00
#
ipv6 bfd all-interfaces enable
#
#
undo shutdown
ipv6 enable
isis ipv6 enable 1

(2020-10-09)
#
undo shutdown
ipv6 enable
isis ipv6 enable 1
#
undo shutdown
ip address 10.1.1.1 255.255.255.0
#
interface LoopBack1
ipv6 enable
isis ipv6 enable 1
#
bgp 100
router-id 1.1.1.1
#
ipv4-family unicast
#
ipv6-family unicast
#
ipv4-family vpnv4
policy vpn-target
peer 3::3 enable
#
import-route direct
#
return
#
sysname P1
#
bfd
#
isis 1
is-level level-2
cost-style wide
network-entity 10.0000.0000.0002.00
#
#
#
undo shutdown
ipv6 enable
isis ipv6 enable 1
#
undo shutdown
ipv6 enable
isis ipv6 enable 1
#
interface LoopBack1
ipv6 enable

(2020-10-09)

isis ipv6 enable 1
#
return
#
sysname P2
#
bfd
#
isis 1
is-level level-2
cost-style wide
network-entity 10.0000.0000.0004.00
#
#
#
undo shutdown
ipv6 enable
isis ipv6 enable 1
#
undo shutdown
ipv6 enable
isis ipv6 enable 1
#
interface LoopBack1
ipv6 enable
isis ipv6 enable 1
#
return
#
sysname PE2
#
ipv4-family
#
bfd
#
#
isis 1
is-level level-2
cost-style wide
network-entity 10.0000.0000.0003.00
#
#
#
undo shutdown
ipv6 enable
isis ipv6 enable 1

(2020-10-09)
#
undo shutdown
ipv6 enable
isis ipv6 enable 1
#
undo shutdown
ip address 10.2.1.1 255.255.255.0
#
interface LoopBack1
ipv6 enable
isis ipv6 enable 1
#
bgp 100
router-id 2.2.2.2
#
ipv4-family unicast
#
ipv6-family unicast
#
ipv4-family vpnv4
policy vpn-target
peer 1::1 enable
#
import-route direct
#
return
#
sysname CE1
#
undo shutdown
ip address 10.1.1.2 255.255.255.0
#
interface LoopBack1
ip address 11.11.11.11 255.255.255.255
#
bgp 65410
#
ipv4-family unicast
network 11.11.11.11 255.255.255.255
#
return
#
sysname CE2
#
undo shutdown
ip address 10.2.1.2 255.255.255.0
#

(2020-10-09)
interface LoopBack1
ip address 22.22.22.22 255.255.255.255
#
bgp 65420
#
ipv4-family unicast
network 22.22.22.22 255.255.255.255
#
return
2.2.22.3 Example for Configuring VPN FRR for L3VPNv4 over SRv6 BE
This section provides an example for configuring VPN FRR for L3VPNv4 over SRv6
BE.
Context
● PE1, PE2, and PE3 are in the same AS and run IS-IS to implement IPv6
● The PEs are Level-2 devices that belong to IS-IS process 1.
as well as between PE1 and PE3 to carry L3VPNv4 services. In addition, VPN FRR
needs to be configured on PE1 to improve network reliability.
Figure 2-102 Networking of VPN FRR configuration for L3VPNv4 over SRv6 BE
NOTE
Precautions
When configuring VPN FRR for L3VPNv4 over SRv6 BE, note the following:

(2020-10-09)
● In a VPN FRR scenario, after the primary path recovers, traffic switches back
to this path. Because the order in which nodes undergo IGP convergence
differs, packet loss may occur during the switchback. To resolve this problem,
run the route-select delay delay-value command to configure a route
selection delay so that traffic is switched back only after forwarding entries on
the devices along the primary path are updated. The delay specified using
delay-value depends on various factors, such as the number of routes on the
devices. Set a proper delay as needed.
1. Enable IPv6 forwarding and configure an IPv6 address for each PE interface.
2. Enable IS-IS, configure an IS-IS level, and specify a network entity on each PE.
3. Configure a VPN instance on each PE.
6. Configure SRv6 on each PE, and enable IS-IS SRv6.
7. Enable VPN FRR on PE1 and configure BFD to detect locator route
reachability to speed up VPN FRR switching.
Data Preparation
● IPv6 address of each PE interface

● IS-IS process ID of each PE
● IS-IS level of each PE
● VPN instance name, RD, and RT on each PE
Procedure
[*HUAWEI] commit
[*PE1] commit

(2020-10-09)

# Configure PE1.
[~PE1] isis 1
[*PE1-isis-1] quit
# Configure PE2.
[~PE2] isis 1
[*PE2-isis-1] quit
# Configure PE3.
[~PE3] isis 1
[*PE3-isis-1] quit

output on PE1.

--------------------------------------------------------------------------------
0000.0000.0004* GE2/0/0 0000.0000.0004.02 Up 7s L2 64
0000.0000.0002* GE1/0/0 0000.0000.0002.02 Up 9s L2 64
Total Peer(s): 2

(2020-10-09)
-----------------------------

--------------------------------

--------------------------------------------------------------------------------
2::/64 GE1/0/0 FE80::3A92:6CFF:FE31:307 10 A/-/-/-
3::/64 GE2/0/0 FE80::3A92:6CFF:FE41:305 10 A/-/-/-
2001:DB8:1::/96 GE1/0/0 Direct 10 D/-/L/-
2001:DB8:3::/96 GE2/0/0 Direct 10 D/-/L/-
that PE.
# Configure PE1.
[*PE1] commit
# Configure PE2.
[*PE2] commit
# Configure PE3.
[*PE3] commit


(2020-10-09)

NOTE
may fail.
# Configure CE1.
[*CE1] bgp 65410
[*CE1-bgp] network 11.11.11.11 32
[*CE1-bgp] quit
[*CE1] commit
# Configure PE1.
[~PE1] bgp 100
[~PE1-bgp] quit
# Configure CE2.
[*CE2] bgp 65420
[*CE2-bgp] network 22.22.22.22 32
[*CE2-bgp] quit
[*CE2] commit
# Configure PE2.
[~PE2] bgp 100
[~PE2-bgp] quit
# Configure PE3.
[~PE3] bgp 100

(2020-10-09)
[~PE3-bgp] quit


10.1.1.2 4 65410 1695 1704 0 24:37:20 Established 1
# Configure PE1.
[~PE1] bgp 100
[*PE1-bgp] peer 3::3 as-number 100
[~PE1-bgp] quit
# Configure PE2.
[~PE2] bgp 100
[~PE2-bgp] quit
# Configure PE3.
[~PE3] bgp 100
[~PE3-bgp] quit

(2020-10-09)
NOTE

# Configure PE1.
[*PE1] bgp 100
[~PE1-bgp] quit
[~PE1] isis 1
[~PE1-isis-1] quit
# Configure PE2.
[*PE2] bgp 100
[~PE2-bgp] quit
[~PE2] isis 1
[~PE2-isis-1] quit
# Configure PE3.
[*PE3] bgp 100

(2020-10-09)

[~PE3-bgp] quit
[~PE3] isis 1
[~PE3-isis-1] quit
Step 7 Configure VPN FRR.

Configure VPN FRR and use BFD to detect locator route reachability. If the locator
route is unreachable, VPN FRR is performed, triggering traffic switching.
# Configure PE1.
[~PE1-vpn-instance-vpna] ipv4-family
[~PE1-vpn-instance-vpna-af-ipv4] vpn frr
[*PE1-vpn-instance-vpna-af-ipv4] commit
[~PE1-vpn-instance-vpna-af-ipv4] quit
[~PE1-vpn-instance-vpna] quit
[~PE1] bgp 100
[~PE1-bgp-vpna] route-select delay 300
[~PE1-bgp] quit
[~PE1] bfd
[*PE1-bfd] quit
[*PE1] bfd pe1tope2 bind peer-ipv6 20::
[*PE1-bfd-session-pe1tope2] discriminator local 100
[*PE1-bfd-session-pe1tope2] discriminator remote 200
[*PE1-bfd-session-pe1tope2] commit
[~PE1-bfd-session-pe1tope2] quit
# Configure PE2.
[~PE2] bfd
[*PE2-bfd] quit

[~PE1] display ip routing-table vpn-instance vpna 22.22.22.22 32 verbose
------------------------------------------------------------------------------
Summary Count : 1
NextHop: 20::1:0:1E Neighbour: 2::2
IndirectID: 0x10000CC Instance:
RelayNextHop: 20::1:0:1E Interface: SRv6 BE
BkNextHop: 20::1:0:1F BkInterface: SRv6 BE

(2020-10-09)
BkLabel: 3 SecTunnelID: 0x0

BkPETunnelID: 0x0 BkPESecTunnelID: 0x0
BkIndirectID: 0x10000D2
The preceding command output shows that the VPN route 22.22.22.22/32 has a
backup outbound interface and a VPN FRR routing entry has been generated.
[~CE1] ping -a 11.11.11.11 22.22.22.22

0.00% packet loss
----End
Configuration Files
#
sysname PE1
#
ipv4-family
vpn frr
#
bfd
#
#
isis 1
is-level level-2
cost-style wide
network-entity 10.0000.0000.0001.00
#
#
#
undo shutdown
ipv6 enable
isis ipv6 enable 1
#
undo shutdown
ipv6 enable
isis ipv6 enable 1
#
undo shutdown

(2020-10-09)

ip address 10.1.1.1 255.255.255.0
#
interface LoopBack1
ipv6 enable
isis ipv6 enable 1
#
bfd pe1tope2 bind peer-ipv6 20::
#
bgp 100
router-id 1.1.1.1
#
ipv4-family unicast
#
ipv6-family unicast
#
ipv4-family vpnv4
policy vpn-target
peer 2::2 enable
peer 3::3 enable
#
import-route direct
route-select delay 300
#
return

#
sysname PE2
#
ipv4-family
#
bfd
#
#
isis 1
is-level level-2
cost-style wide
network-entity 10.0000.0000.0002.00
#
#
#
undo shutdown
ipv6 enable

(2020-10-09)
isis ipv6 enable 1

#
undo shutdown
ip address 10.2.1.1 255.255.255.0
#
interface LoopBack1
ipv6 enable
isis ipv6 enable 1
#
#
bgp 100
router-id 2.2.2.2
#
ipv4-family unicast
#
ipv6-family unicast
#
ipv4-family vpnv4
policy vpn-target
peer 1::1 enable
#
import-route direct
#
return
#
sysname PE3
#
ipv4-family
#
#
isis 1
is-level level-2
cost-style wide
network-entity 10.0000.0000.0004.00
#
#
#
undo shutdown
ipv6 enable
isis ipv6 enable 1
#

(2020-10-09)
undo shutdown
ip address 10.3.1.1 255.255.255.0
#
interface LoopBack1
ipv6 enable
isis ipv6 enable 1
#
bgp 100
router-id 3.3.3.3
#
ipv4-family unicast
#
ipv6-family unicast
#
ipv4-family vpnv4
policy vpn-target
peer 1::1 enable
#
import-route direct
#
return
#
sysname CE1
#
undo shutdown
ip address 10.1.1.2 255.255.255.0
#
interface LoopBack1
ip address 11.11.11.11 255.255.255.255
#
bgp 65410
#
ipv4-family unicast
network 11.11.11.11 255.255.255.255
#
return
#
sysname CE2
#
undo shutdown
ip address 10.2.1.2 255.255.255.0
#
undo shutdown
ip address 10.3.1.2 255.255.255.0
#
interface LoopBack1
ip address 22.22.22.22 255.255.255.255
#
bgp 65420

(2020-10-09)

#
ipv4-family unicast
network 22.22.22.22 255.255.255.255
#
return
2.2.22.4 Example for Configuring EVPN L3VPNv4 over SRv6 BE

This section provides an example for configuring SRv6 BE to carry EVPN L3VPNv4
services.
Context
On the network shown in Figure 2-103, PE1, the P, and PE2 are in the same AS
and run IS-IS to implement IPv6 network connectivity. It is required that a
bidirectional SRv6 BE path be deployed between PE1 and PE2 to carry EVPN
L3VPNv4 services.
Figure 2-103 EVPN L3VPNv4 over SRv6 BE networking

NOTE

(2020-10-09)
P, and PE2.
3. Configure an IPv4 L3VPN instance on each PE and bind the IPv4 L3VPN
instance to an access-side interface.
5. Establish a BGP EVPN peer relationship between PEs.
6. Configure SRv6 BE on PEs, and enable IS-IS SRv6.
Data Preparation
● L3VPN instance name: vpn1
● RD and RT values of the L3VPN instance: 100:1 and 1:1
Procedure
[*HUAWEI] commit
[*PE1-LoopBack1] ipv6 address 2001:DB8:1::1 64
[*PE1] commit

# Configure PE1.
[~PE1] isis 1
[*PE1-isis-1] quit
[*PE1] commit
# Configure the P.
[~P] isis 1
[*P-isis-1] quit

(2020-10-09)

[*P-LoopBack1] quit
[*P] commit
# Configure PE2.
[~PE2] isis 1
[*PE2-isis-1] quit
[*PE2] commit

output on PE1.

--------------------------------------------------------------------------------
0000.0000.0002 GE1/0/0 0000.0000.0002.01 Up 8s L1 64
Total Peer(s): 1
Step 3 Configure an IPv4 L3VPN instance on each PE and bind the IPv4 L3VPN instance
to an access-side interface.
# Configure PE1.
[*PE1] bgp 100
[*PE1-bgp] quit
[*PE1] commit
# Configure PE2.

(2020-10-09)

[*PE2] bgp 100
[*PE2-bgp] quit
[*PE2] commit
# Configure CE1.
[*CE1] bgp 65410
[*CE1-bgp] network 11.11.11.11 32
[*CE1-bgp] quit
[*CE1] commit
# Configure PE1.
[~PE1] bgp 100
[~PE1-bgp] quit
# Configure CE2.
[*CE2] bgp 65420
[*CE2-bgp] network 22.22.22.22 32
[*CE2-bgp] quit
[*CE2] commit
# Configure PE2.
[~PE2] bgp 100
[~PE2-bgp] quit

(2020-10-09)
[~PE1] display bgp vpnv4 vpn-instance vpn1 peer

VPN-Instance vpn1, Router ID 1.1.1.1:


PrefRcv
10.1.1.2 4 65410 43 47 0 00:35:32 Established 1

# Configure PE1.
[~PE1] bgp 100
[~PE1-bgp] peer 2001:DB8:3::3 as-number 100
[*PE1-bgp] peer 2001:DB8:3::3 connect-interface loopback 1
[*PE1-bgp-af-evpn] peer 2001:DB8:3::3 enable
[*PE1-bgp] quit
[*PE1] commit
# Configure PE2.
[~PE2] bgp 100
[*PE2-bgp] quit
[*PE2] commit
the PEs to check whether BGP EVPN peer relationships have been established
BGP EVPN peer relationships have been established successfully.
# Configure PE1.
[*PE1-segment-routing-ipv6] encapsulation source-address 2001:DB8:1::1
[*PE1-segment-routing-ipv6] locator PE1 ipv6-prefix 2001:DB8:100:: 64 static 32
[*PE1-segment-routing-ipv6-locator] opcode ::100 end-dt4 vpn-instance vpn1 evpn
[*PE1] isis 1
[*PE1-isis-1] segment-routing ipv6 locator PE1
[*PE1-isis-1] quit
[*PE1] bgp 100
[*PE1-bgp-af-evpn] peer 2001:DB8:3::3 advertise encap-type srv6
[*PE1-bgp-vpn1] segment-routing ipv6 locator PE1 evpn
[*PE1-bgp-vpn1] segment-routing ipv6 best-effort evpn
[*PE1-bgp] quit
[*PE1] commit
# Configure PE2.

(2020-10-09)

[*PE2-segment-routing-ipv6-locator] opcode ::200 end-dt4 vpn-instance vpn1 evpn
[*PE2] isis 1
[*PE2-isis-1] quit
[*PE2] bgp 100
[*PE2-bgp-vpn1] segment-routing ipv6 locator PE2 evpn
[*PE2-bgp-vpn1] segment-routing ipv6 best-effort evpn
[*PE2-bgp] quit
[*PE2] commit

Run the display bgp evpn all routing-table prefix-route command on each PE.
The command output shows the IP prefix route sent from the peer end. The


*> 0:10.1.1.0:24 0.0.0.0
*> 0:11.11.11.11:32 10.1.1.2
*>i 0:10.2.1.0:24 2001:DB8:3::3
*>i 0:22.22.22.22:32 2001:DB8:3::3
Run the display ip routing-table vpn-instance vpn1 command on each PE. The
command output shows the VPN route sent from the peer end. The following
route
------------------------------------------------------------------------------

10.2.1.0/24 IBGP 255 0 RD 2001:DB8:130::200 SRv6 BE
22.22.22.22/32 IBGP 255 0 RD 2001:DB8:130::200 SRv6 BE

(2020-10-09)


-------------------------------------
SID : 2001:DB8:100::100/128 FuncType : End.DT4

VPN Name : vpn1 VPN ID : 4
LocatorName: PE1 LocatorID: 7
Total SID(s): 1
[~CE1] ping -a 11.11.11.11 22.22.22.22

0.00% packet loss
----End
Configuration Files
#
sysname PE1
#
ipv4-family
#
encapsulation source-address 2001:DB8:1::1
locator PE1 ipv6-prefix 2001:DB8:100:: 64 static 32
opcode ::100 end-dt4 vpn-instance vpn1 evpn
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0001.00
#
segment-routing ipv6 locator PE1
#
#
undo shutdown
ipv6 enable
isis ipv6 enable 1
#

(2020-10-09)
undo shutdown
ip address 10.1.1.1 255.255.255.0
#
interface LoopBack1
ipv6 enable
isis ipv6 enable 1
#
bgp 100
router-id 1.1.1.1
peer 2001:DB8:3::3 connect-interface LoopBack1
#
ipv4-family unicast
#
import-route direct
segment-routing ipv6 locator PE1 evpn
segment-routing ipv6 best-effort evpn
#
l2vpn-family evpn
undo policy vpn-target
peer 2001:DB8:3::3 advertise encap-type srv6
#
return
#
sysname P
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0002.00
#
#
undo shutdown
ipv6 enable
isis ipv6 enable 1
#
undo shutdown
ipv6 enable
isis ipv6 enable 1
#
interface LoopBack1
ipv6 enable
isis ipv6 enable 1
#
return
#
sysname PE2
#
ipv4-family

(2020-10-09)
#
opcode ::200 end-dt4 vpn-instance vpn1 evpn
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0003.00
#
#
#
undo shutdown
ipv6 enable
isis ipv6 enable 1
#
undo shutdown
ip address 10.2.1.1 255.255.255.0
#
interface LoopBack1
ipv6 enable
isis ipv6 enable 1
#
bgp 100
router-id 3.3.3.3
#
ipv4-family unicast
#
import-route direct
#
l2vpn-family evpn
#
return
#
sysname CE1
#
undo shutdown
ip address 10.1.1.2 255.255.255.0
#
interface LoopBack1
ip address 11.11.11.11 255.255.255.255
#
bgp 65410
#
ipv4-family unicast
network 11.11.11.11 255.255.255.255

(2020-10-09)

#
return

#
sysname CE2
#
undo shutdown
ip address 10.2.1.2 255.255.255.0
#
interface LoopBack1
ip address 22.22.22.22 255.255.255.255
#
bgp 65420
#
ipv4-family unicast
network 22.22.22.22 255.255.255.255
#
return
2.2.22.5 Example for Configuring EVPN L3VPNv6 over SRv6 BE

This section provides an example for configuring SRv6 BE to carry EVPN L3VPNv6
services.
Context
L3VPNv6 services.
Figure 2-104 EVPN L3VPNv6 over SRv6 BE networking

NOTE

(2020-10-09)
P, and PE2.
5. Configure SRv6 BE on PEs, and enable IS-IS SRv6.
Data Preparation
● L3VPN instance name: vpn1
● RD and RT values of the L3VPN instance: 100:1 and 1:1
Procedure
[*HUAWEI] commit

(2020-10-09)

[*PE1] commit

# Configure PE1.
[~PE1] isis 1
[*PE1-isis-1] quit
[*PE1] commit
# Configure the P.
[~P] isis 1
[*P-isis-1] quit
[*P-LoopBack1] quit
[*P] commit
# Configure PE2.
[~PE2] isis 1
[*PE2-isis-1] quit
[*PE2] commit

output on PE1.

(2020-10-09)
--------------------------------------------------------------------------------
0000.0000.0002 GE1/0/0 0000.0000.0002.01 Up 8s L1 64
Total Peer(s): 1
# Configure PE1.
[*PE1] bgp 100
[*PE1-bgp] quit
[*PE1] commit
# Configure PE2.
[*PE2] bgp 100
[*PE2-bgp] quit
[*PE2] commit
# Configure PE1.
[~PE1] bgp 100
[~PE1-bgp] router-id 1.1.1.1
[*PE1-bgp] peer 2001:DB8:3::3 as-number 100
[*PE1-bgp] quit
[*PE1] commit
# Configure PE2.
[~PE2] bgp 100

(2020-10-09)

[*PE2-bgp] quit
[*PE2] commit
the PEs and check whether BGP EVPN peer relationships have been established
# Configure PE1.
[*PE1] isis 1
[*PE1-isis-1] quit
[*PE1] bgp 100
[*PE1-bgp-6-vpn1] segment-routing ipv6 locator PE1 evpn
[*PE1-bgp-6-vpn1] segment-routing ipv6 best-effort evpn
[*PE1-bgp] quit
[*PE1] commit
# Configure PE2.
[*PE2] isis 1
[*PE2-isis-1] quit
[*PE2] bgp 100
[*PE2-bgp-6-vpn1] segment-routing ipv6 locator PE2 evpn
[*PE2-bgp-6-vpn1] segment-routing ipv6 best-effort evpn
[*PE2-bgp] quit
[*PE2] commit

Run the display bgp evpn all routing-table prefix-route command on each PE.
The command output shows the IP prefix route sent from the peer end. The


(2020-10-09)

*> 0:[2001:DB8:11::]:64 0.0.0.0
*>i 0:[2001:DB8:22::]:64 2001:DB8:3::3
Run the display ipv6 routing-table vpn-instance vpn1 command on each PE.
The command output shows the VPN route sent from the peer end. The following
[~PE1] display ipv6 routing-table vpn-instance vpn1



Interface : SRv6 BE Flags : RD

----End
Configuration Files
#
sysname PE1
#
ipv6-family
#
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0001.00
#

(2020-10-09)
#
#
undo shutdown
ipv6 enable
isis ipv6 enable 1
#
undo shutdown
ipv6 enable
#
interface LoopBack1
ipv6 enable
isis ipv6 enable 1
#
bgp 100
router-id 1.1.1.1
#
ipv4-family unicast
#
import-route direct
#
l2vpn-family evpn
#
return
#
sysname P
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0002.00
#
#
undo shutdown
ipv6 enable
isis ipv6 enable 1
#
undo shutdown
ipv6 enable
isis ipv6 enable 1
#
interface LoopBack1
ipv6 enable
isis ipv6 enable 1
#
return

(2020-10-09)

#
sysname PE2
#
ipv6-family
#
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0003.00
#
#
#
undo shutdown
ipv6 enable
isis ipv6 enable 1
#
undo shutdown
ipv6 enable
#
interface LoopBack1
ipv6 enable
isis ipv6 enable 1
#
bgp 100
router-id 3.3.3.3
#
ipv4-family unicast
#
import-route direct
#
l2vpn-family evpn
#
return
2.2.22.6 Example for Configuring EVPN L3VPNv6 over SRv6 BE ECMP

This section provides an example for configuring EVPN L3VPNv6 over SRv6 BE
ECMP.

(2020-10-09)
Context
● PE1, PE2, P1, and P2 are in the same AS and run IS-IS to implement IPv6
to carry EVPN L3VPNv6 services. In addition, to maximize network resource
utilization, it is required that ECMP be performed for EVPN L3VPNv6 services
carried by the SRv6 BE path between PE1 and PE2.
Figure 2-105 EVPN L3VPNv6 over SRv6 BE ECMP networking

NOTE
Precautions
When configuring EVPN L3VPNv6 over SRv6 BE ECMP, note the following:
● SRv6 BE ECMP depends on equal-cost routes on the network. To ensure

successful configuration, you need to properly plan IGP costs for links. In this
example, each link uses the default cost value 10.
P2, and PE2. In addition, configure dynamic BFD for IPv6 IS-IS.

(2020-10-09)
Data Preparation
Procedure
[*HUAWEI] commit
[*PE1] commit

When configuring IS-IS, enable dynamic BFD to speed up IS-IS convergence in the
case of a link status change.
# Configure PE1.
[~PE1] bfd
[*PE1-bfd] quit
[*PE1] isis 1
[*PE1-isis-1] quit

(2020-10-09)

# Configure P1.
[~P1] bfd
[*P1-bfd] quit
[*P1] isis 1
[*P1-isis-1] quit
# Configure P2.
[~P2] bfd
[*P2-bfd] quit
[*P2] isis 1
[*P2-isis-1] quit
# Configure PE2.
[~PE2] bfd
[*PE2-bfd] quit
[*PE2] isis 1
[*PE2-isis-1] quit

(2020-10-09)

output on PE1.

--------------------------------------------------------------------------------
0000.0000.0004* GE2/0/0 0000.0000.0004.02 Up 7s L2 64
0000.0000.0002* GE1/0/0 0000.0000.0002.02 Up 9s L2 64
Total Peer(s): 2
-----------------------------

--------------------------------

--------------------------------------------------------------------------------
2::/64 GE1/0/0 FE80::3A92:6CFF:FE31:307 10 A/-/-/-
3::/64 GE1/0/0 FE80::3A92:6CFF:FE31:307 20 A/-/-/-
GE2/0/0 FE80::3A92:6CFF:FE41:305
4::/64 GE2/0/0 FE80::3A92:6CFF:FE41:305 10 A/-/-/-
2001:DB8:1::/96 GE1/0/0 Direct 10 D/-/L/-
2001:DB8:2::/96 GE1/0/0 FE80::3A92:6CFF:FE31:307 20 A/-/-/-
2001:DB8:3::/96 GE2/0/0 Direct 10 D/-/L/-
2001:DB8:4::/96 GE2/0/0 FE80::3A92:6CFF:FE41:305 20 A/-/-/-
# Configure PE1.
[*PE1-vpn-instance-vpna-af-ipv6] vpn-target 111:1 evpn
[*PE1] bgp 100
[*PE1-bgp-6-vpna] import-route direct
[*PE1-bgp-6-vpna] advertise l2vpn evpn
[*PE1-bgp-6-vpna] quit
[*PE1-bgp] quit
[*PE1] commit
# Configure PE2.

(2020-10-09)

[*PE2] bgp 100
[*PE2-bgp] quit
[*PE2] commit
# Configure CE1.
[~CE1] interface LoopBack1
[*CE1-LoopBack1] ipv6 address 11::11 128
[*CE1] bgp 65410
[*CE1-bgp] peer 2001:DB8:11::1 as-number 100
[*CE1-bgp-af-ipv6] peer 2001:DB8:11::1 enable
[*CE1-bgp-af-ipv6] commit
[~CE1-bgp-af-ipv6] quit
[~CE1-bgp] quit
# Configure PE1.
[~PE1] bgp 100
[*PE1-bgp-6-vpna] peer 2001:DB8:11::2 as-number 65410
[~PE1-bgp] quit
# Configure CE2.
[*CE2] bgp 65420
[~CE2-bgp] quit
# Configure PE2.
[~PE2] bgp 100

(2020-10-09)

[~PE2-bgp] quit

2001:DB8:11::2 4 65410 98 103 0 01:22:02 Established 2

# Configure PE1.
[~PE1] bgp 100
[*PE1-bgp-af-evpn] peer 3::3 enable
[*PE1-bgp] quit
[*PE1] commit
# Configure PE2.
[~PE2] bgp 100
[*PE2-bgp] quit
[*PE2] commit
BGP EVPN peer relationships have been established successfully. The following


3::3 4 100 100 100 0 01:22:17 Established 2

# Configure PE1.

(2020-10-09)

[*PE1] isis 1
[*PE1-isis-1] segment-routing ipv6 locator as1
[*PE1-isis-1] quit
[*PE1] bgp 100
[*PE1-bgp-af-evpn] peer 3::3 advertise encap-type srv6
[*PE1-bgp-6-vpna] segment-routing ipv6 locator as1 evpn
[*PE1-bgp-6-vpna] segment-routing ipv6 best-effort evpn
[*PE1-bgp] quit
[*PE1] commit
# Configure PE2.
[*PE2] isis 1
[*PE2-isis-1] quit
[*PE2] bgp 100
[*PE2-bgp] quit
[*PE2] commit

Run the display ipv6 routing-table vpn-instance vpna ipv6-address verbose
[~PE1] display ipv6 routing-table vpn-instance vpna 22::22 verbose
------------------------------------------------------------------------------
Summary Count : 1
Destination : 22::22 PrefixLength : 128

NextHop : 30::1:0:20 Preference : 255
Neighbour : 3::3 ProcessID : 0
Label : NULL Protocol : IBGP
IndirectID : 0x100011B Instance :
RelayNextHop : 30::1:0:20 TunnelID : 0x0
The preceding command output shows that the VPN route 22::22/128 has recursed
to an SRv6 BE path.
Display details about the IPv6 route using the next-hop address 30::1:0:20 as the
[~PE1] display ipv6 routing-table 30::1:0:20 verbose

(2020-10-09)
------------------------------------------------------------------------------
Summary Count : 2

IndirectID : 0x100011B Instance :

IndirectID : 0x100011C Instance :
The preceding command output shows that the route 30::1:0:20 has two outbound
interfaces. The interfaces work in ECMP mode during packet forwarding.
[~CE1] ping ipv6 -a 11::11 22::22
PING 22::22 : 56 data bytes, press CTRL_C to break
Reply from 22::22
Reply from 22::22
Reply from 22::22
Reply from 22::22
Reply from 22::22
--- 22::22 ping statistics---

0.00% packet loss
----End
Configuration Files
#
sysname PE1
#
ipv6-family
#
bfd

(2020-10-09)
#
#
isis 1
is-level level-2
cost-style wide
network-entity 10.0000.0000.0001.00
#
#
#
undo shutdown
ipv6 enable
isis ipv6 enable 1
#
undo shutdown
ipv6 enable
isis ipv6 enable 1
#
undo shutdown
ipv6 enable
#
interface LoopBack1
ipv6 enable
isis ipv6 enable 1
#
bgp 100
router-id 1.1.1.1
#
ipv4-family unicast
#
ipv6-family unicast
#
import-route direct
segment-routing ipv6 locator as1 evpn
#
l2vpn-family evpn
peer 3::3 enable
peer 3::3 advertise encap-type srv6
#
return
#
sysname P1
#
bfd
#
isis 1

(2020-10-09)
is-level level-2
cost-style wide
network-entity 10.0000.0000.0002.00
#
#
#
undo shutdown
ipv6 enable
isis ipv6 enable 1
#
undo shutdown
ipv6 enable
isis ipv6 enable 1
#
interface LoopBack1
ipv6 enable
isis ipv6 enable 1
#
return
#
sysname P2
#
bfd
#
isis 1
is-level level-2
cost-style wide
network-entity 10.0000.0000.0004.00
#
#
#
undo shutdown
ipv6 enable
isis ipv6 enable 1
#
undo shutdown
ipv6 enable
isis ipv6 enable 1
#
interface LoopBack1
ipv6 enable
isis ipv6 enable 1
#
return
#
sysname PE2
#
ipv6-family

(2020-10-09)
#
bfd
#
#
isis 1
is-level level-2
cost-style wide
network-entity 10.0000.0000.0003.00
#
#
#
undo shutdown
ipv6 enable
isis ipv6 enable 1
#
undo shutdown
ipv6 enable
isis ipv6 enable 1
#
undo shutdown
ipv6 enable
#
interface LoopBack1
ipv6 enable
isis ipv6 enable 1
#
bgp 100
router-id 2.2.2.2
#
ipv4-family unicast
#
ipv6-family unicast
#
import-route direct
#
l2vpn-family evpn
peer 1::1 enable
#
return
#
sysname CE1
#

(2020-10-09)
undo shutdown
ipv6 enable
#
interface LoopBack1
ipv6 enable
#
bgp 65410
router-id 10.11.1.1
#
ipv4-family unicast
#
ipv6-family unicast
import-route direct
#
return

#
sysname CE2
#
undo shutdown
ipv6 enable
#
interface LoopBack1
ipv6 enable
#
bgp 65420
router-id 10.12.1.1
#
ipv4-family unicast
#
ipv6-family unicast
import-route direct
#
return
2.2.22.7 Example for Configuring VPN FRR for EVPN L3VPNv6 over SRv6 BE
This section provides an example for configuring VPN FRR for EVPN L3VPNv6 over
SRv6 BE.
Context
● PE1, PE2, and PE3 are in the same AS and run IS-IS to implement IPv6
● The PEs are Level-2 devices that belong to IS-IS process 1.

(2020-10-09)
as well as between PE1 and PE3 to carry EVPN L3VPNv6 services. In addition, VPN
FRR needs to be configured on PE1 to improve network reliability.
Figure 2-106 Networking of VPN FRR configuration for EVPN L3VPNv6 over SRv6
BE
NOTE
Precautions
When configuring VPN FRR for EVPN L3VPNv6 over SRv6 BE, note the following:
● In a VPN FRR scenario, after the primary path recovers, traffic switches back
to this path. Because the order in which nodes undergo IGP convergence
differs, packet loss may occur during the switchback. To resolve this problem,
run the route-select delay delay-value command to configure a route
selection delay so that traffic is switched back only after forwarding entries on
the devices along the primary path are updated. The delay specified using
delay-value depends on various factors, such as the number of routes on the
devices. Set a proper delay as needed.
3. Configure an IPv6 VPN instance on each PE, and connect each PE to a CE.
6. Configure SRv6 on each PE, and enable IS-IS SRv6.
7. Enable VPN FRR on PE1 and configure BFD to detect peer locator reachability
to speed up VPN FRR switching.

(2020-10-09)
Data Preparation
● IPv6 address of each PE interface
● IS-IS process ID of each PE
● IS-IS level of each PE
● VPN instance name, RD, and RT on each PE
Procedure
[*HUAWEI] commit
[*PE1] commit

# Configure PE1.
[~PE1] isis 1
[*PE1-isis-1] quit
# Configure PE2.
[~PE2] isis 1
[*PE2-isis-1] quit

(2020-10-09)

# Configure PE3.
[~PE3] isis 1
[*PE3-isis-1] quit

output on PE1.

--------------------------------------------------------------------------------
0000.0000.0004* GE2/0/0 0000.0000.0004.02 Up 7s L2 64
0000.0000.0002* GE1/0/0 0000.0000.0002.02 Up 9s L2 64
Total Peer(s): 2
-----------------------------

--------------------------------

--------------------------------------------------------------------------------
2::/64 GE1/0/0 FE80::3A92:6CFF:FE31:307 10 A/-/-/-
3::/64 GE2/0/0 FE80::3A92:6CFF:FE41:305 10 A/-/-/-
2001:DB8:1::/96 GE1/0/0 Direct 10 D/-/L/-
2001:DB8:3::/96 GE2/0/0 Direct 10 D/-/L/-
# Configure PE1.

(2020-10-09)
[*PE1] bgp 100
[*PE1-bgp] quit
[*PE1] commit
# Configure PE2.
[*PE2] bgp 100
[*PE2-bgp] quit
[*PE2] commit
# Configure PE3.
[*PE3] bgp 100
[*PE3-bgp] quit
[*PE3] commit
# Configure CE1.
[*CE1] bgp 65410

(2020-10-09)
[~CE1-bgp] quit
# Configure PE1.
[~PE1] bgp 100
[~PE1-bgp] quit
# Configure CE2.
[*CE2] bgp 65420
[~CE2-bgp] quit
# Configure PE2.
[~PE2] bgp 100
[~PE2-bgp] quit
# Configure PE3.
[~PE3] bgp 100
[~PE3-bgp] quit


(2020-10-09)

2001:DB8:11::2 4 65410 98 103 0 01:22:02 Established 2

# Configure PE1.
[~PE1] bgp 100
[*PE1-bgp] quit
[*PE1] commit
# Configure PE2.
[~PE2] bgp 100
[*PE2-bgp] quit
[*PE2] commit
# Configure PE3.
[~PE3] bgp 100
[*PE3-bgp] quit
[*PE3] commit


2::2 4 100 23 22 0 00:15:33 Established 3
3::3 4 100 23 23 0 00:15:35 Established 3

# Configure PE1.
[*PE1] isis 1

(2020-10-09)
[*PE1-isis-1] quit
[*PE1] bgp 100
[*PE1-bgp] quit
[*PE1] commit
# Configure PE2.
[*PE2] isis 1
[*PE2-isis-1] quit
[*PE2] bgp 100
[*PE2-bgp] quit
[*PE2] commit
# Configure PE3.
[*PE3] isis 1
[*PE3-isis-1] quit
[*PE3] bgp 100
[*PE3-bgp] quit
[*PE3] commit
Step 7 Configure VPN FRR.
Configure VPN FRR and use BFD to detect locator route reachability. If the locator
route is unreachable, VPN FRR is performed, triggering traffic switching.
# Configure PE1.
[~PE1-vpn-instance-vpna] ipv6-family
[~PE1-vpn-instance-vpna-af-ipv6] vpn frr
[~PE1] bgp 100

(2020-10-09)

[~PE1-bgp-6-vpna] route-select delay 300
[~PE1-bgp] quit
[~PE1] bfd
[*PE1-bfd] quit
# Configure PE2.
[~PE2] bfd
[*PE2-bfd] quit

Run the display ipv6 routing-table vpn-instance vpna ipv6-address verbose
[~PE1] display ipv6 routing-table vpn-instance vpna 22::22 128 verbose
------------------------------------------------------------------------------
Summary Count : 1
Destination : 22::22 PrefixLength : 128

NextHop : 20::1:0:3C Preference : 255
Neighbour : 2::2 ProcessID : 0
IndirectID : 0x100016E Instance :
RelayNextHop : 30::1:0:20 TunnelID : 0x0
BkNextHop : 30::1:0:21 BkInterface : SRv6 BE
BkLabel : NULL BkTunnelID : 0x0
BkPETunnelID : 0x0 BkIndirectID : 0x100016A
The preceding command output shows that the VPN route 22::22/128 has a
backup outbound interface and a VPN FRR routing entry has been generated.
[~CE1] ping ipv6 -a 11::11 22::22
PING 22::22 : 56 data bytes, press CTRL_C to break
Reply from 22::22
Reply from 22::22
Reply from 22::22
Reply from 22::22
Reply from 22::22

(2020-10-09)
--- 22::22 ping statistics---

0.00% packet loss
----End
Configuration Files
#
sysname PE1
#
ipv6-family
vpn frr
#
bfd
#
#
isis 1
is-level level-2
cost-style wide
network-entity 10.0000.0000.0001.00
#
#
#
undo shutdown
ipv6 enable
isis ipv6 enable 1
#
undo shutdown
ipv6 enable
isis ipv6 enable 1
#
undo shutdown
ipv6 enable
#
interface LoopBack1
ipv6 enable
isis ipv6 enable 1
#
#
bgp 100
router-id 1.1.1.1

(2020-10-09)

#
ipv4-family unicast
#
import-route direct
route-select delay 300
#
l2vpn-family evpn
peer 2::2 enable
peer 3::3 enable
#
return

#
sysname PE2
#
ipv6-family
#
bfd
#
#
isis 1
is-level level-2
cost-style wide
network-entity 10.0000.0000.0002.00
#
#
#
undo shutdown
ipv6 enable
isis ipv6 enable 1
#
undo shutdown
ipv6 enable
#
interface LoopBack1
ipv6 enable
isis ipv6 enable 1
#
#
bgp 100
router-id 2.2.2.2

(2020-10-09)

#
ipv4-family unicast
#
ipv6-family unicast
#
import-route direct
#
l2vpn-family evpn
peer 1::1 enable
#
return
#
sysname PE3
#
ipv6-family
#
#
isis 1
is-level level-2
cost-style wide
network-entity 10.0000.0000.0004.00
#
#
#
undo shutdown
ipv6 enable
isis ipv6 enable 1
#
undo shutdown
ipv6 enable
#
interface LoopBack1
ipv6 enable
isis ipv6 enable 1
#
bgp 100
router-id 3.3.3.3
#
ipv4-family unicast

(2020-10-09)
#
ipv6-family unicast
#
import-route direct
#
l2vpn-family evpn
peer 1::1 enable
#
return
#
sysname CE1
#
undo shutdown
ipv6 enable
#
interface LoopBack1
ipv6 enable
#
bgp 65410
router-id 10.11.1.1
#
ipv4-family unicast
#
ipv6-family unicast
import-route direct
#
return
#
sysname CE2
#
undo shutdown
ipv6 enable
#
undo shutdown
ipv6 enable
#
interface LoopBack1
ipv6 enable
#
bgp 65420
router-id 10.12.1.1
#
ipv4-family unicast

(2020-10-09)
#
ipv6-family unicast
import-route direct
#
return
2.2.22.8 Example for Configuring EVPN VPWS over SRv6 BE

This section provides an example for configuring SRv6 BE to carry EVPN VPWSs.
Context
VPWSs.
Figure 2-107 EVPN VPWS over SRv6 BE networking

NOTE
P, and PE2.
3. Configure EVPN VPWS and EVPL instances on each PE and bind the EVPL
instance to an access-side sub-interface.

(2020-10-09)

5. Configure SRv6 BE on PEs.
Data Preparation
● EVPN instance name: evrf1
● RD and RT values of the EVPN instance: 100:1 and 1:1
Procedure
[*HUAWEI] commit
[*PE1] commit
Configure an IPv4 address for the loopback interface because the EVPN source
address needs to be an IPv4 address. The following example uses the
configuration of PE1. The configurations of other devices are similar to the
configuration of PE1. For configuration details, see Configuration Files in this
section.
# Configure PE1.
[~PE1] isis 1
[*PE1-isis-1] quit
# Configure the P.
[~P] isis 1
[*P-isis-1] quit

(2020-10-09)

[~P-LoopBack1] quit
# Configure PE2.
[~PE2] isis 1
[*PE2-isis-1] quit

output on PE1.

--------------------------------------------------------------------------------
0000.0000.0002 GE1/0/0 0000.0000.0002.01 Up 8s L1 64
Total Peer(s): 1
-----------------------------

--------------------------------

--------------------------------------------------------------------------------
2001:DB8:1::/64 GE1/0/0 Direct 10 D/-/L/-
2001:DB8:2::2/128 GE1/0/0 FE80::3A5D:67FF:FE31:307 10 A/-/-/-
2001:DB8:3::3/128 GE1/0/0 FE80::3A5D:67FF:FE31:307 20 A/-/-/-
2001:DB8:10::/64 GE1/0/0 Direct 20 A/-/-/-
2001:DB8:20::/64 GE1/0/0 FE80::3A5D:67FF:FE31:307 20 A/-/-/-
Step 3 Configure EVPN and EVPL instances on each PE and bind the EVPL instance to an
access-side sub-interface.
# Configure PE1.
[*PE1] evpn vpn-instance evrf1 vpws

(2020-10-09)
[*PE1-vpws-evpn-instance-evrf1] route-distinguisher 100:1

[*PE1-vpws-evpn-instance-evrf1] vpn-target 1:1
[*PE1-vpws-evpn-instance-evrf1] quit
[*PE1] evpl instance 1 srv6-mode
[*PE1-evpl-srv6-1] evpn binding vpn-instance evrf1
[*PE1-evpl-srv6-1] local-service-id 100 remote-service-id 200
[*PE1-evpl-srv6-1] quit
[*PE1] interface gigabitethernet 2/0/0.1 mode l2
[*PE1-GigabitEthernet2/0/0.1] evpl instance 1
[*PE1] commit
# Configure PE2.
[*PE2] commit

# Configure PE1.
[~PE1] bgp 100
[*PE1-bgp] quit
[*PE1] commit
# Configure PE2.
[~PE2] bgp 100
[*PE2-bgp] quit
[*PE2] commit
# Configure PE1.

(2020-10-09)
[*PE1] isis 1
[*PE1-isis-1] quit
[*PE1] bgp 100
[*PE1-bgp] quit
[*PE1-evpl-srv6-1] segment-routing ipv6 locator PE1
[*PE1-vpws-evpn-instance-evrf1] segment-routing ipv6 best-effort
[*PE1] commit
# Configure PE2.
[*PE2] isis 1
[*PE2-isis-1] quit
[*PE2] bgp 100
[*PE2-bgp] quit
[*PE2] commit

Run the display bgp evpn evpl command on each PE. The command output
shows the EVPL status. The following example uses the command output on PE1.
[~PE1] display bgp evpn evpl
Total EVPLs: 1 1 Up 0 Down
EVPL ID : 1
State : up
EVPL Type : srv6-mode
Interface : GigabitEthernet2/0/0.1
Local MTU : 1500
Local Control Word : false
Local Redundancy Mode : all-active
Local DF State : primary
Local ESI : 0000.0000.0000.0000.0000
Remote Redundancy Mode : all-active
Remote Primary DF Number : 1
Remote Backup DF Number : 0
Remote None DF Number : 0
Peer IP : 2001:DB8:3::3
Origin Nexthop IP : 2001:DB8:3::3
DF State : primary
Remote MTU : 1500
Remote Control Word : false
Remote ESI : 0000.0000.0000.0000.0000
Tunnel info : 1 tunnels
NO.0 Tunnel Type : srv6-be, Tunnel ID :

(2020-10-09)
Last Interface UP Timestamp : 2020-02-12 7:37:20:398

Last Designated Primary Timestamp : --
Last Designated Backup Timestamp : --
Run the display bgp evpn all routing-table command on each PE. The command
output shows the EVPN route sent from the peer end. The following example uses


*> 0000.0000.0000.0000.0000:100 127.0.0.1
*>i 0000.0000.0000.0000.0000:200 2001:DB8:3::3
*> 0000.0000.0000.0000.0000:100 127.0.0.1
*>i 0000.0000.0000.0000.0000:200 2001:DB8:3::3
Run the display bgp evpn all routing-table ad-route command on PE1. The
command output shows the EVPN routes sent from the peer end.
[~PE1] display bgp evpn all routing-table ad-route 0000.0000.0000.0000.0000:200

BGP routing table entry information of 0000.0000.0000.0000.0000:200:
From: 2001:DB8:3::3 (3.3.3.3)
Relay IP Nexthop: FE80::3AC2:67FF:FE31:307
Original nexthop: 2001:DB8:3::3
Ext-Community: RT <1 : 1>, EVPN L2 Attributes <MTU:1500 C:0 P:1 B:0>
Prefix-sid: 2001:DB8:30::1:0:3C
AS-path Nil, origin incomplete, localpref 100, pref-val 0, valid, internal, best, select, pre 255, IGP cost
20
Route Type: 1 (Ethernet Auto-Discovery (A-D) route)
ESI: 0000.0000.0000.0000.0000, Ethernet Tag ID: 200
Remote-Cross route
From: 2001:DB8:3::3 (3.3.3.3)

(2020-10-09)

Prefix-sid: 2001:DB8:30::1:0:3C
20
----End
Configuration Files
#
sysname PE1
#
evpn vpn-instance evrf1 vpws
#
evpl instance 1 srv6-mode
local-service-id 100 remote-service-id 200
#
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0001.00
#
#
undo shutdown
ipv6 enable
isis ipv6 enable 1
#
evpl instance 1
#
interface LoopBack1
ipv6 enable
ip address 1.1.1.1 255.255.255.255
isis ipv6 enable 1
#
bgp 100
router-id 1.1.1.1
#
ipv4-family unicast
#
l2vpn-family evpn

(2020-10-09)

#
#
return
#
sysname P
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0002.00
#
#
undo shutdown
ipv6 enable
isis ipv6 enable 1
#
undo shutdown
ipv6 enable
isis ipv6 enable 1
#
interface LoopBack1
ipv6 enable
isis ipv6 enable 1
#
return
#
sysname PE2
#
#
#
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0003.00
#
#
undo shutdown
ipv6 enable
isis ipv6 enable 1
#

(2020-10-09)

evpl instance 1
#
interface LoopBack1
ipv6 enable
ip address 3.3.3.3 255.255.255.255
isis ipv6 enable 1
#
bgp 100
router-id 3.3.3.3
#
ipv4-family unicast
#
l2vpn-family evpn
#
#
return
2.2.22.9 Example for Configuring EVPN VPWS over SRv6 BE (CE Dual-
Homing in Active-Active Mode)
This section provides an example for configuring SRv6 BE to carry EVPN VPWS
services. In the example, a redundancy mode needs to be configured on a per
Ethernet segment identifier (ESI) basis.
On the network shown in Figure 2-108, CE2 is dual-homed to PE2 and PE3. It is
required that CE1-to-CE2 traffic be transmitted in load-balancing mode.
To meet this requirement, configure the all-active redundancy mode on a per ESI
basis for PE2 and PE3.
Figure 2-108 EVPN VPWS over SRv6 BE networking (CE dual-homing in active-
active mode)
NOTE

(2020-10-09)
3. Configure EVPN VPWS and EVPL instances on each PE.
4. Establish BGP EVPN peer relationships among the PEs.
5. Configure SRv6 BE on each PE.
6. Bind the EVPL instance on each PE to an access-side sub-interface.
7. Configure a redundancy mode on a per ESI basis on PE2 and PE3.
8. Configure CE access to the PEs.
Data Preparation
● RD and RT of the EVPN instance
● Locator names for PE1, PE2, and PE3: PE1, PE2, and PE3, respectively;
dynamically generated operation code (opcode)
Procedure
Step 1 Enable IPv6 forwarding and configure an IPv6 address for each interface.
[*HUAWEI] commit

(2020-10-09)

[*PE1] commit
address needs to be an IPv4 address. The preceding example uses the
section.
# Configure PE1.
[~PE1] isis 1
[*PE1-isis-1] quit
# Configure PE2.
[~PE2] isis 1
[*PE2-isis-1] quit
# Configure PE3.
[~PE3] isis 1
[*PE3-isis-1] quit

(2020-10-09)
After the configuration is complete, run the display isis peer and display isis
route commands to check whether IS-IS has been configured successfully. The

--------------------------------------------------------------------------------
0000.0000.0003* GE2/0/0 0000.0000.0003.02 Up 8s L1 64
0000.0000.0002* GE1/0/0 0000.0000.0002.02 Up 6s L1 64
Total Peer(s): 2
Step 3 Configure EVPN VPWS and EVPL instances on each PE.

# Configure PE1.
[*PE1] commit
# Configure PE2.
[*PE2] commit
# Configure PE3.
[*PE3] commit
Step 4 Establish BGP EVPN peer relationships among the PEs.

# Configure PE1.
[~PE1] bgp 100

(2020-10-09)

[*PE1-bgp] quit
[*PE1] commit
# Configure PE2.
[~PE2] bgp 100
[*PE2-bgp] quit
[*PE2] commit
# Configure PE3.
[~PE3] bgp 100
[*PE3-bgp] quit
[*PE3] commit
relationships have been established successfully.


PrefRcv
2001:DB8:2::2 4 100 113 111 0 01:32:39 Established 2
2001:DB8:3::3 4 100 125 122 0 01:43:29 Established 2
Step 5 Configure SRv6 BE on each PE.

# Configure PE1.

(2020-10-09)

[*PE1] isis 1
[*PE1-isis-1] quit
[*PE1] commit
# Configure PE2.
[*PE2] isis 1
[*PE2-isis-1] quit
[*PE2] commit
# Configure PE3.
[*PE3] isis 1
[*PE3-isis-1] quit
[*PE3] commit
After the configuration is complete, run the display segment-routing ipv6 local-
sid end-dx2 forwarding command on the PEs to check SRv6 BE local SID tables.
[~PE1] display segment-routing ipv6 local-sid end-dx2 forwarding
My Local-SID End.DX2 Forwarding Table
-------------------------------------
SID : 2001:DB8:11::1:0:20/128 FuncType : End.DX2

EVPL ID : 1
Total SID(s): 1
Step 6 Bind the EVPL instance on each PE to an access-side sub-interface.

# Configure PE1.
[~PE1] interface gigabitethernet 3/0/0.1 mode l2

(2020-10-09)

[*PE1] commit
# Configure PE2.
[~PE2] e-trunk 1
[*PE2-e-trunk-1] priority 10
[*PE2-e-trunk-1] peer-ipv6 2001:DB8:3::3 source-ipv6 2001:DB8:2::2
[*PE2-e-trunk-1] security-key cipher 00E0FC000000
[*PE2-e-trunk-1] quit
[*PE2] interface eth-trunk 10
[*PE2-Eth-Trunk10] e-trunk 1
[*PE2-Eth-Trunk10] quit
[*PE2] interface eth-trunk 10.1 mode l2
[*PE2-Eth-Trunk10.1] encapsulation dot1q vid 10
[*PE2-Eth-Trunk10.1] evpl instance 1
[*PE2-Eth-Trunk10.1] quit
[*PE2-GigabitEthernet3/0/0] eth-trunk 10
[*PE2] commit
# Configure PE3.
[~PE3] e-trunk 1
[*PE3] commit
Step 7 Configure a redundancy mode on a per ESI basis on PE2 and PE3.
# Configure PE2.
[~PE2] evpn
[*PE2-evpn] esi 0001.0002.0003.0004.0005
[*PE2-evpn-esi-0001.0002.0003.0004.0005] evpn redundancy-mode all-active
[*PE2-evpn-esi-0001.0002.0003.0004.0005] quit
[*PE2-evpn] quit
[*PE2] interface Eth-Trunk 10
[*PE2-Eth-Trunk10] esi 0001.0002.0003.0004.0005
[*PE2-Eth-Trunk10] e-trunk mode force-master
[*PE2] commit
# Configure PE3.
[~PE3] evpn
[*PE3-evpn] esi 0001.0002.0003.0004.0005
[*PE3-evpn-esi-0001.0002.0003.0004.0005] quit
[*PE3-evpn] quit
[*PE3-Eth-Trunk10] esi 0001.0002.0003.0004.0005
[*PE3] commit

(2020-10-09)
Step 8 Configure CE access to the PEs.

# Configure CE1.
<CE1> system-view
[~CE1] vlan 10
[*CE1-vlan10] quit
[*CE1] interface gigabitethernet 1/0/0
[*CE1-GigabitEthernet1/0/0] portswitch
[*CE1-GigabitEthernet1/0/0] undo shutdown
[*CE1-GigabitEthernet1/0/0] port link-type access
[*CE1-GigabitEthernet1/0/0] port default vlan 10
[*CE1-GigabitEthernet1/0/0] commit
[~CE1-GigabitEthernet1/0/0] quit
# Configure CE2.
<CE2> system-view
[~CE2] vlan 10
[*CE2-vlan10] quit
After the configuration is complete, the corresponding Eth-Trunk should be up.

Run the display eth-trunk command on PE2 and PE3 to check the Eth-Trunk
status.
Command output on PE2:
[~PE2] display eth-trunk 10
Eth-Trunk10's state information is:
WorkingMode: NORMAL Hash arithmetic: According to flow
Least Active-linknumber: 1 Max Bandwidth-affected-linknumber: 32
Operate status: up Number Of Up Ports In Trunk: 1
--------------------------------------------------------------------------------
PortName Status Weight
GigabitEthernet3/0/0 Up 1

--------------------------------------------------------------------------------
According to the status of Eth-Trunk 10 shown in the preceding command output,

PE2 and PE3 are both active.
output shows the EVPN routes sent from the peer end. The following example

(2020-10-09)


*> 0000.0000.0000.0000.0000:100 127.0.0.1
*>i 0001.0002.0003.0004.0005:200 2001:DB8:2::2
*>i 0001.0002.0003.0004.0005:200 2001:DB8:3::3
*>i 0001.0002.0003.0004.0005:4294967295 2001:DB8:2::2
*>i 0001.0002.0003.0004.0005:4294967295 2001:DB8:3::3
*> 0000.0000.0000.0000.0000:100 127.0.0.1
*>i 0001.0002.0003.0004.0005:200 2001:DB8:2::2
*i 2001:DB8:3::3
*>i 0001.0002.0003.0004.0005:4294967295 2001:DB8:2::2
*i 2001:DB8:3::3
command output shows the A-D EVPN routes sent from the peer end.
From: 2001:DB8:2::2 (2.2.2.2)
Prefix-sid: 2001:DB8:21::1:0:3E
10

From: 2001:DB8:3::3 (3.3.3.3)

(2020-10-09)

Prefix-sid: 2001:DB8:31::1:0:3E
10
Remote-Cross route
From: 2001:DB8:2::2 (2.2.2.2)
Prefix-sid: 2001:DB8:21::1:0:3E
10

Remote-Cross route
From: 2001:DB8:3::3 (3.3.3.3)
Prefix-sid: 2001:DB8:31::1:0:3E
AS-path Nil, origin incomplete, localpref 100, pref-val 0, valid, internal, select, pre 255, IGP cost 10, not
preferred for router ID
According to the preceding command output, the EVPN instance evrf1 has two
preferred routes 0001.0002.0003.0004.0005:200 with the next hops being PE2 and
PE3, respectively. This indicates that dual-homing active-active networking has
been configured properly.
----End
Configuration Files
#
sysname PE1
#

(2020-10-09)

#
#
encapsulation source-address 2001:db8:1::1
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0001.00
#
#
#
undo shutdown
ipv6 enable
isis ipv6 enable 1
#
undo shutdown
ipv6 enable
isis ipv6 enable 1
#
undo shutdown
#
evpl instance 1
#
interface LoopBack1
ipv6 enable
ip address 1.1.1.1 255.255.255.255
isis ipv6 enable 1
#
bgp 100
router-id 1.1.1.1
#
ipv4-family unicast
#
l2vpn-family evpn
policy vpn-target
#
#
return

(2020-10-09)
#
sysname PE2
#
evpn
#
mac-duplication
#
esi 0001.0002.0003.0004.0005
evpn redundancy-mode all-active
#
#
#
e-trunk 1
priority 10
peer-ipv6 2001:DB8:3::3 source-ipv6 2001:DB8:2::2
security-key cipher %^%#VQE;E!Dl&Rr]if$F>}w9uk5C>y-4|MS$unQ!#Mb#%^%#
#
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0002.00
#
#
#
interface Eth-Trunk10
e-trunk 1
e-trunk mode force-master
esi 0001.0002.0003.0004.0005
#
interface Eth-Trunk10.1 mode l2
evpl instance 1
#
undo shutdown
ipv6 enable
isis ipv6 enable 1
#
undo shutdown
ipv6 enable
isis ipv6 enable 1
#
undo shutdown
eth-trunk 10
#
interface LoopBack1
ipv6 enable
ip address 2.2.2.2 255.255.255.255
isis ipv6 enable 1

(2020-10-09)
#
bgp 100
router-id 2.2.2.2
#
ipv4-family unicast
#
l2vpn-family evpn
policy vpn-target
#
#
return
#
sysname PE3
#
evpn
#
mac-duplication
#
esi 0001.0002.0003.0004.0005
#
#
#
e-trunk 1
priority 10
security-key cipher %^%#!8C!"bAoc~O}UW2)%$HP4%.G9179.;&Yr[GmV.PN%^%#
#
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0003.00
#
#
#
e-trunk 1
esi 0001.0002.0003.0004.0005
#
evpl instance 1

(2020-10-09)
#
undo shutdown
ipv6 enable
isis ipv6 enable 1
#
undo shutdown
ipv6 enable
isis ipv6 enable 1
#
undo shutdown
eth-trunk 10
#
interface LoopBack1
ipv6 enable
ip address 3.3.3.3 255.255.255.255
isis ipv6 enable 1
#
bgp 100
router-id 3.3.3.3
#
ipv4-family unicast
#
l2vpn-family evpn
policy vpn-target
#
#
return

#
sysname CE1
#
vlan batch 10
#
portswitch
undo shutdown
port link-type access
port default vlan 10
#
return

#
sysname CE2
#
vlan batch 10
#
portswitch
undo shutdown
#

(2020-10-09)
portswitch
undo shutdown
#
return
2.2.22.10 Example for Configuring EVPN VPWS over SRv6 BE (CE Dual-
Homing in Single-Active Mode)
This section provides an example for configuring SRv6 BE to carry EVPN VPWS
On the network shown in Figure 2-109, CE2 is dual-homed to PE2 and PE3. It is
required that PE2 and PE3 operate in master/backup mode to transmit traffic from
CE1 to CE2.
To meet this requirement, configure the single-active redundancy mode on a per

ESI basis for PE2 and PE3.
Figure 2-109 EVPN VPWS over SRv6 BE networking (CE dual-homing in single-
active mode)
NOTE

(2020-10-09)
3. Configure EVPN VPWS and EVPL instances on each PE.
6. Bind the EVPL instance on each PE to an access-side sub-interface.
Data Preparation
● Locator names for PE1, PE2, and PE3: PE1, PE2, and PE3, respectively;
dynamically generated operation codes (opcodes)
Procedure
[*HUAWEI] commit
[*PE1] commit
section.
# Configure PE1.
[~PE1] isis 1
[*PE1-isis-1] quit

(2020-10-09)
# Configure PE2.
[~PE2] isis 1
[*PE2-isis-1] quit
# Configure PE3.
[~PE3] isis 1
[*PE3-isis-1] quit

--------------------------------------------------------------------------------
0000.0000.0003* GE2/0/0 0000.0000.0003.02 Up 8s L1 64
0000.0000.0002* GE1/0/0 0000.0000.0002.02 Up 6s L1 64
Total Peer(s): 2
Step 3 Configure EVPN VPWS and EVPL instances on each PE.

# Configure PE1.

(2020-10-09)

[*PE1] commit
# Configure PE2.
[*PE2] commit
# Configure PE3.
[*PE3] commit

# Configure PE1.
[~PE1] bgp 100
[*PE1-bgp] quit
[*PE1] commit
# Configure PE2.
[~PE2] bgp 100
[*PE2-bgp] quit
[*PE2] commit
# Configure PE3.
[~PE3] bgp 100

(2020-10-09)

[*PE3-bgp] quit
[*PE3] commit



PrefRcv
2001:DB8:2::2 4 100 113 111 0 01:32:39 Established 2
2001:DB8:3::3 4 100 125 122 0 01:43:29 Established 2
# Configure PE1.
[*PE1] isis 1
[*PE1-isis-1] quit
[*PE1] commit
# Configure PE2.
[*PE2] isis 1
[*PE2-isis-1] quit
[*PE2] commit

(2020-10-09)
# Configure PE3.
[*PE3] isis 1
[*PE3-isis-1] quit
[*PE3] commit
sid end-dx2 forwarding command on the PEs to check SRv6 BE local SID tables.
[~PE1] display segment-routing ipv6 local-sid end-dx2 forwarding
My Local-SID End.DX2 Forwarding Table
-------------------------------------
SID : 2001:DB8:11::1:0:20/128 FuncType : End.DX2

EVPL ID : 1
Total SID(s): 1
Step 6 Bind the EVPL instance on each PE to an access-side sub-interface.

# Configure PE1.
[*PE1] commit
# Configure PE2.
[~PE2] e-trunk 1
[*PE2] commit
# Configure PE3.
[~PE3] e-trunk 1

(2020-10-09)
[*PE3] commit
# Configure PE2.
[~PE2] evpn
[*PE2-evpn] esi 0001.0002.0003.0004.0005
[*PE2-evpn-esi-0001.0002.0003.0004.0005] evpn redundancy-mode single-active
[*PE2-evpn-esi-0001.0002.0003.0004.0005] quit
[*PE2-evpn] quit
[*PE2-Eth-Trunk10] esi 0001.0002.0003.0004.0005
[*PE2-Eth-Trunk10] e-trunk mode auto
[*PE2] commit
# Configure PE3.
[~PE3] evpn
[*PE3-evpn] esi 0001.0002.0003.0004.0005
[*PE3-evpn-esi-0001.0002.0003.0004.0005] quit
[*PE3-evpn] quit
[*PE3-Eth-Trunk10] esi 0001.0002.0003.0004.0005
[*PE3] commit

# Configure CE1.
<CE1> system-view
[~CE1] vlan 10
[*CE1-vlan10] quit
# Configure CE2.
<CE2> system-view
[~CE2] vlan 10
[*CE2-vlan10] quit

(2020-10-09)

status.
--------------------------------------------------------------------------------

Operate status: down Number Of Up Ports In Trunk: 0
--------------------------------------------------------------------------------
GigabitEthernet3/0/0 Down 1
According to the status of Eth-Trunk 10 shown in the preceding command output,

PE2 and PE3 are in master and backup states, respectively. That is, only PE2 is
active.


*> 0000.0000.0000.0000.0000:100 127.0.0.1
*>i 0001.0002.0003.0004.0005:200 2001:DB8:2::2
*>i 0001.0002.0003.0004.0005:200 2001:DB8:3::3
*>i 0001.0002.0003.0004.0005:4294967295 2001:DB8:2::2
*>i 0001.0002.0003.0004.0005:4294967295 2001:DB8:3::3

(2020-10-09)

*> 0000.0000.0000.0000.0000:100 127.0.0.1
*>i 0001.0002.0003.0004.0005:200 2001:DB8:2::2
*i 2001:DB8:3::3
*>i 0001.0002.0003.0004.0005:4294967295 2001:DB8:2::2
*i 2001:DB8:3::3

From: 2001:DB8:2::2 (2.2.2.2)
Prefix-sid: 2001:DB8:21::1:0:3E
10

From: 2001:DB8:3::3 (3.3.3.3)
Prefix-sid: 2001:DB8:31::1:0:3E
10
Remote-Cross route
From: 2001:DB8:2::2 (2.2.2.2)
Prefix-sid: 2001:DB8:21::1:0:3E
10

(2020-10-09)


Remote-Cross route
From: 2001:DB8:3::3 (3.3.3.3)
Prefix-sid: 2001:DB8:31::1:0:3E
AS-path Nil, origin incomplete, localpref 100, pref-val 0, valid, internal, pre 255, IGP cost 10, not preferred
for L2 ext-community
According to the preceding command output, the EVPN instance evrf1 has one
preferred route 0001.0002.0003.0004.0005:200 with the next hop being PE2.
Although an active route with the next hop being PE3 exists, it is not the preferred
route. This indicates that dual-homing single-active networking has been
configured properly.
----End
Configuration Files
#
sysname PE1
#
#
#
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0001.00
#
#
#
undo shutdown
ipv6 enable
isis ipv6 enable 1
#

(2020-10-09)
undo shutdown
ipv6 enable
isis ipv6 enable 1
#
undo shutdown
#
evpl instance 1
#
interface LoopBack1
ipv6 enable
ip address 1.1.1.1 255.255.255.255
isis ipv6 enable 1
#
bgp 100
router-id 1.1.1.1
#
ipv4-family unicast
#
l2vpn-family evpn
policy vpn-target
#
#
return

#
sysname PE2
#
evpn
#
mac-duplication
#
esi 0001.0002.0003.0004.0005
evpn redundancy-mode single-active
#
#
#
e-trunk 1
priority 10
#

(2020-10-09)
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0002.00
#
#
#
e-trunk 1
esi 0001.0002.0003.0004.0005
#
evpl instance 1
#
undo shutdown
ipv6 enable
isis ipv6 enable 1
#
undo shutdown
ipv6 enable
isis ipv6 enable 1
#
undo shutdown
eth-trunk 10
#
interface LoopBack1
ipv6 enable
ip address 2.2.2.2 255.255.255.255
isis ipv6 enable 1
#
bgp 100
router-id 2.2.2.2
#
ipv4-family unicast
#
l2vpn-family evpn
policy vpn-target
#
#
return
#
sysname PE3
#
evpn
#
mac-duplication
#
esi 0001.0002.0003.0004.0005

(2020-10-09)

#
#
#
e-trunk 1
priority 10
#
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0003.00
#
#
#
e-trunk 1
esi 0001.0002.0003.0004.0005
#
evpl instance 1
#
undo shutdown
ipv6 enable
isis ipv6 enable 1
#
undo shutdown
ipv6 enable
isis ipv6 enable 1
#
undo shutdown
eth-trunk 10
#
interface LoopBack1
ipv6 enable
ip address 3.3.3.3 255.255.255.255
isis ipv6 enable 1
#
bgp 100
router-id 3.3.3.3
#
ipv4-family unicast

(2020-10-09)
#
l2vpn-family evpn
policy vpn-target
#
#
return

#
sysname CE1
#
vlan batch 10
#
portswitch
undo shutdown
#
return

#
sysname CE2
#
vlan batch 10
#
portswitch
undo shutdown
#
portswitch
undo shutdown
#
return
2.2.22.11 Example for Configuring EVPN VPLS over SRv6 BE

This section provides an example for configuring SRv6 BE to carry EVPN E-LAN
services.
bidirectional SRv6 BE path be deployed between PE1 and PE2 to carry EVPN E-
LAN services.
Figure 2-110 EVPN VPLS over SRv6 BE networking

NOTE

(2020-10-09)
P, and PE2.
3. Configure an EVPN instance in BD mode on each PE and bind the EVPN
5. Configure SRv6 BE on PEs.
Data Preparation
● BD ID: 100
● Names of locators on PE1: PE1_ARG and PE1; names of locators on PE2:
PE2_ARG and PE2; dynamically generated opcodes
● Length of the locators PE1_ARG and PE2_ARG: 10 (as specified in the args
parameter)
Procedure
[*HUAWEI] commit

(2020-10-09)

[*PE1] commit
address needs to be an IPv4 address. The following example uses the
section.
# Configure PE1.
[~PE1] isis 1
[*PE1-isis-1] quit
# Configure the P.
[~P] isis 1
[*P-isis-1] quit
[~P-LoopBack1] quit
# Configure PE2.
[~PE2] isis 1
[*PE2-isis-1] quit


(2020-10-09)
output on PE1.

--------------------------------------------------------------------------------
0000.0000.0002 GE1/0/0 0000.0000.0002.01 Up 8s L1 64
Total Peer(s): 1
-----------------------------

--------------------------------

--------------------------------------------------------------------------------
2001:DB8:1::/64 GE1/0/0 Direct 10 D/-/L/-
2001:DB8:2::/64 GE1/0/0 FE80::3A5D:67FF:FE31:307 10 A/-/-/-
2001:DB8:3::/64 GE1/0/0 FE80::3A5D:67FF:FE31:307 20 A/-/-/-
2001:DB8:10::/64 GE1/0/0 Direct 20 D/-/L/-
2001:DB8:20::/64 GE1/0/0 FE80::3A5D:67FF:FE31:307 20 A/-/-/-
Step 3 Configure an EVPN instance in BD mode on each PE and bind the EVPN instance
to an access-side sub-interface.
# Configure PE1.
[*PE1-bd100] quit
[*PE1] commit
# Configure PE2.
[*PE2-bd100] quit
[*PE2] commit

(2020-10-09)

# Configure PE1.
[~PE1] bgp 100
[*PE1-bgp] quit
[*PE1] commit
# Configure PE2.
[~PE2] bgp 100
[*PE2-bgp] quit
[*PE2] commit
# Configure PE1.
[*PE1-segment-routing-ipv6] locator PE1 ipv6-prefix 2001:DB8:11:: 64
[*PE1-segment-routing-ipv6] locator PE1_ARG ipv6-prefix 2001:DB8:12:: 64 args 10
[*PE1] isis 1
[*PE1-isis-1] segment-routing ipv6 locator PE1_ARG auto-sid-disable
[*PE1-isis-1] quit
[*PE1-evpn-instance-evrf1] segment-routing ipv6 locator PE1_ARG unicast-locator PE1
[*PE1-evpn-instance-evrf1] segment-routing ipv6 best-effort
[*PE1] commit
# Configure PE2.
[*PE2-segment-routing-ipv6] locator PE2 ipv6-prefix 2001:DB8:21:: 64
[*PE2-segment-routing-ipv6] locator PE2_ARG ipv6-prefix 2001:DB8:22:: 64 args 10
[*PE2] isis 1
[*PE2-isis-1] quit

(2020-10-09)

[*PE2] commit

Run the display segment-routing ipv6 local-sid { end-dt2u | end-dt2ul | end-
dt2m } forwarding command on each PE to check information about the SRv6 BE
local SID table. The following example uses the command output on PE1.
[~PE1] display segment-routing ipv6 local-sid end-dt2m forwarding
My Local-SID End.DT2M Forwarding Table
--------------------------------------
SID : 2001:DB8:12::400/118 FuncType : End.DT2M
Bridge-domain ID: 100
LocatorName : PE1_ARG LocatorID: 5
Total SID(s): 1
[~PE1] display segment-routing ipv6 local-sid end-dt2u forwarding
My Local-SID End.DT2U Forwarding Table
--------------------------------------
SID : 2001:DB8:11::3D/128 FuncType : End.DT2U

LocatorName : PE1 LocatorID: 4
Total SID(s): 1
output shows the EVPN route sent from the peer end. The following example uses


*> 0:32:1.1.1.1 127.0.0.1
*>i 0:32:3.3.3.3 2001:DB8:3::3
*> 0:32:1.1.1.1 127.0.0.1
*>i 0:32:3.3.3.3 2001:DB8:3::3
----End
Configuration Files
#
sysname PE1
#
segment-routing ipv6 locator PE1_ARG unicast-locator PE1

(2020-10-09)

#
bridge-domain 100
#
locator PE1 ipv6-prefix 2001:DB8:11:: 64
locator PE1_ARG ipv6-prefix 2001:DB8:12:: 64 args 10
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0001.00
#
segment-routing ipv6 locator PE1_ARG auto-sid-disable
#
#
undo shutdown
ipv6 enable
isis ipv6 enable 1
#
undo shutdown
#
rewrite pop single
bridge-domain 100
#
interface LoopBack1
ipv6 enable
ip address 1.1.1.1 255.255.255.255
isis ipv6 enable 1
#
bgp 100
router-id 1.1.1.1
#
ipv4-family unicast
#
l2vpn-family evpn
policy vpn-target
#
#
return
#
sysname P
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0002.00
#
#
#

(2020-10-09)
undo shutdown
ipv6 enable
isis ipv6 enable 1
#
undo shutdown
ipv6 enable
isis ipv6 enable 1
#
interface LoopBack1
ipv6 enable
ip address 2.2.2.2 255.255.255.255
isis ipv6 enable 1
#
return
#
sysname PE2
#
#
bridge-domain 100
#
locator PE2 ipv6-prefix 2001:DB8:21:: 64
locator PE2_ARG ipv6-prefix 2001:DB8:22:: 64 args 10
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0003.00
#
#
#
undo shutdown
ipv6 enable
isis ipv6 enable 1
#
undo shutdown
#
rewrite pop single
bridge-domain 100
#
interface LoopBack1
ipv6 enable
ip address 3.3.3.3 255.255.255.255
isis ipv6 enable 1
#
bgp 100

(2020-10-09)
router-id 3.3.3.3
#
ipv4-family unicast
#
l2vpn-family evpn
policy vpn-target
#
#
return
2.2.22.12 Example for Configuring EVPN VPLS over SRv6 BE (CE Dual-
Homing)
This section provides an example for configuring SRv6 BE to carry EVPN VPLS
On the network shown in Figure 2-111, CE2 and CE3 are both dual-homed to PE2
and PE3. It is required that CE1-to-CE2 traffic be transmitted in load-balancing
mode, whereas CE1-to-CE3 traffic be transmitted in non-load-balancing mode.
To meet this requirement, configure the all-active redundancy mode on a per ESI
basis for CE2 access to PE2 and PE3 and the single-active redundancy mode on a
per ESI basis for CE3 access to PE2 and PE3.
Figure 2-111 EVPN VPLS over SRv6 BE (CE dual-homing) networking

NOTE
respectively.

(2020-10-09)
3. Configure a BD EVPN instance on each PE.
6. Bind the BD on each PE to an access-side sub-interface.
Data Preparation
● EVPN instance names: evrf1 and evrf2
● RDs and RTs of the EVPN instances
● BD IDs
● Locator names for PE1: PE1_BUM and PE1_UNICAST; locator names for PE2:
PE2_BUM and PE2_UNICAST; locator names for PE3: PE3_BUM and
PE3_UNICAST; dynamically generated operation code (opcode)
● Length of the Args field for locators PE1_BUM, PE2_BUM, and PE3_BUM: 10
bits
Procedure
[*HUAWEI] commit
[*PE1] commit
section.
# Configure PE1.

(2020-10-09)
[~PE1] isis 1
[*PE1-isis-1] quit
# Configure PE2.
[~PE2] isis 1
[*PE2-isis-1] quit
# Configure PE3.
[~PE3] isis 1
[*PE3-isis-1] quit

--------------------------------------------------------------------------------
0000.0000.0003* GE2/0/0 0000.0000.0003.02 Up 8s L1 64
0000.0000.0002* GE1/0/0 0000.0000.0002.02 Up 6s L1 64
Total Peer(s): 2

(2020-10-09)
Step 3 Configure a BD EVPN instance on each PE.

# Configure PE1.
[*PE1-bd10] quit
[*PE1-bd20] quit
[*PE1] commit
The preceding example uses the configuration of PE1. The configurations of other
# Configure PE1.
[~PE1] bgp 100
[*PE1-bgp] quit
[*PE1] commit
# Configure PE2.
[~PE2] bgp 100
[*PE2-bgp] quit
[*PE2] commit
# Configure PE3.
[~PE3] bgp 100

(2020-10-09)

[*PE3-bgp] quit
[*PE3] commit


PrefRcv
2001:DB8:2::2 4 100 120 125 0 01:05:04 Established 6
2001:DB8:3::3 4 100 27 27 0 00:12:15 Established 5

# Configure PE1.
[*PE1-segment-routing-ipv6] locator PE1_UNICAST ipv6-prefix 2001:DB8:11:: 64
[*PE1-segment-routing-ipv6] locator PE1_BUM ipv6-prefix 2001:DB8:12:: 64 args 10
[*PE1] isis 1
[*PE1-isis-1] segment-routing ipv6 locator PE1_UNICAST
[*PE1-isis-1] segment-routing ipv6 locator PE1_BUM auto-sid-disable
[*PE1-isis-1] quit
[*PE1-evpn-instance-evrf1] segment-routing ipv6 locator PE1_BUM unicast-locator PE1_UNICAST
[*PE1] commit
# Configure PE2.
[*PE2] isis 1
[*PE2-isis-1] quit

(2020-10-09)

[*PE2] commit
# Configure PE3.
[*PE3] isis 1
[*PE3-isis-1] quit
[*PE3] commit

dt2m } forwarding command on each PE to check information about the SRv6 BE
--------------------------------------
SID : 2001:DB8:12::400:0:7800/118 FuncType :

End.DT2M
LocatorName : PE1_BUM LocatorID: 2
SID : 2001:DB8:12::400:0:7C00/118 FuncType :

End.DT2M
LocatorName : PE1_BUM LocatorID: 2
Total SID(s): 2
--------------------------------------
SID : 2001:DB8:11::1:0:20/128 FuncType : End.DT2U

LocatorName : PE1_UNICAST LocatorID: 1
SID : 2001:DB8:11::1:0:22/128 FuncType : End.DT2U

LocatorName : PE1_UNICAST LocatorID: 1
Total SID(s): 2
Step 6 Bind the BD on each PE to an access-side sub-interface.

# Configure PE1.

(2020-10-09)
[*PE1] commit
# Configure PE2.
[~PE2] e-trunk 1
[*PE2] e-trunk 2
[*PE2-Eth-Trunk10.1] rewrite pop single
[*PE2-Eth-Trunk10.1] bridge-domain 10
[*PE2] commit
# Configure PE3.
[~PE3] e-trunk 1
[*PE3] e-trunk 2

(2020-10-09)

[*PE3] commit
# Configure PE2.
[~PE2] evpn
[*PE2-evpn] esi 0001.0002.0003.0004.0005
[*PE2-evpn-esi-0001.0002.0003.0004.0005] quit
[*PE2-evpn] esi 0005.0004.0003.0002.0001
[*PE2-evpn-esi-0005.0004.0003.0002.0001] quit
[*PE2-evpn] quit
[*PE2-Eth-Trunk10] esi 0001.0002.0003.0004.0005
[*PE2-Eth-Trunk20] esi 0005.0004.0003.0002.0001
[*PE2] commit
# Configure PE3.
[~PE3] evpn
[*PE3-evpn] esi 0001.0002.0003.0004.0005
[*PE3-evpn-esi-0001.0002.0003.0004.0005] quit
[*PE3-evpn] esi 0005.0004.0003.0002.0001
[*PE3-evpn-esi-0005.0004.0003.0002.0001] quit
[*PE3-evpn] quit
[*PE3-Eth-Trunk10] esi 0001.0002.0003.0004.0005
[*PE3-Eth-Trunk20] esi 0005.0004.0003.0002.0001
[*PE3] commit
# Configure CE1.
[~CE1] interface gigabitethernet 1/0/0
[~CE1-GigabitEthernet1/0/0] undo shutdown
[*CE1] interface gigabitethernet 1/0/0.1
[*CE1] interface gigabitethernet 1/0/0.2
[*CE1] commit

(2020-10-09)
# Configure CE2.
[~CE2] interface Eth-Trunk10
[*CE2-Eth-Trunk10] quit
[*CE2] interface Eth-Trunk10.1
[*CE2-Eth-Trunk10.1] vlan-type dot1q 10
[*CE2-Eth-Trunk10.1] ip address 10.1.1.2 255.255.255.0
[*CE2-Eth-Trunk10.1] quit
[*CE2-GigabitEthernet1/0/0] eth-trunk 10
[*CE2] commit
# Configure CE3.
[*CE3] interface Eth-Trunk20.1
[*CE3-Eth-Trunk20.1] vlan-type dot1q 20
[*CE3-Eth-Trunk20.1] ip address 10.2.1.2 255.255.255.0
[*CE3] commit

status.
--------------------------------------------------------------------------------

Operate status: down Number Of Up Ports In Trunk: 0
--------------------------------------------------------------------------------
GigabitEthernet4/0/0 Down 1

--------------------------------------------------------------------------------

(2020-10-09)

--------------------------------------------------------------------------------
According to the Eth-Trunk status shown in the preceding command output, for
Eth-Trunk 10, PE2 and PE3 are both active; for Eth-Trunk 20, PE2 and PE3 are in
backup and master states, respectively. That is, for Eth-Trunk 20, only PE3 is active.


*>i 0001.0002.0003.0004.0005:0 2001:DB8:2::2
*i 2001:DB8:3::3
*>i 0005.0004.0003.0002.0001:0 2001:DB8:2::2
*i 2001:DB8:3::3
*>i 0001.0002.0003.0004.0005:4294967295 2001:DB8:2::2
*>i 0001.0002.0003.0004.0005:4294967295 2001:DB8:3::3
*>i 0005.0004.0003.0002.0001:4294967295 2001:DB8:3::3
*>i 0001.0002.0003.0004.0005:0 2001:DB8:2::2
*i 2001:DB8:3::3
*>i 0001.0002.0003.0004.0005:4294967295 2001:DB8:2::2
*i 2001:DB8:3::3
*>i 0005.0004.0003.0002.0001:0 2001:DB8:3::3
i 2001:DB8:2::2
*>i 0005.0004.0003.0002.0001:4294967295 2001:DB8:3::3


(2020-10-09)

*>i 0:48:38c2-6721-0300:0:0.0.0.0 2001:DB8:2::2
*i 2001:DB8:3::3
*> 0:48:38c2-6721-0300:0:0.0.0.0 0.0.0.0
*> 0:48:38c2-6721-0300:0:0.0.0.0 0.0.0.0
*i 2001:DB8:2::2
*i 2001:DB8:3::3
*> 0:48:38c2-6721-0300:0:0.0.0.0 0.0.0.0

*> 0:32:1.1.1.1 127.0.0.1
*>i 0:32:2.2.2.2 2001:DB8:2::2
*>i 0:32:3.3.3.3 2001:DB8:3::3
*> 0:32:1.1.1.1 127.0.0.1
*>i 0:32:2.2.2.2 2001:DB8:2::2
*>i 0:32:3.3.3.3 2001:DB8:3::3
*> 0:32:1.1.1.1 127.0.0.1
*>i 0:32:2.2.2.2 2001:DB8:2::2
*>i 0:32:3.3.3.3 2001:DB8:3::3
*> 0:32:1.1.1.1 127.0.0.1
*>i 0:32:2.2.2.2 2001:DB8:2::2
*>i 0:32:3.3.3.3 2001:DB8:3::3
Check the route of the ESI 0001.0002.0003.0004.0005. According to the ESI Label
field, dual-homing active-active networking has been configured for the ESI.

Total routes of Route Distinguisher(2.2.2.2:0): 1
From: 2001:DB8:2::2 (2.2.2.2)

(2020-10-09)

Ext-Community: RT <1 : 1>, ESI Label<0 : 0 : 48066>
Prefix-sid: ::1
10

From: 2001:DB8:3::3 (3.3.3.3)
Prefix-sid: ::1
10
Remote-Cross route
From: 2001:DB8:2::2 (2.2.2.2)
Prefix-sid: ::1
10

Remote-Cross route
From: 2001:DB8:3::3 (3.3.3.3)
Prefix-sid: ::1
for router ID
Check the route of the ESI 0005.0004.0003.0002.0001. According to the ESI Label
field, dual-homing single-active networking has been configured for the ESI.

(2020-10-09)

From: 2001:DB8:3::3 (3.3.3.3)
Prefix-sid: ::2
10
Remote-Cross route
From: 2001:DB8:3::3 (3.3.3.3)
Prefix-sid: ::2
10
Check that CE1 can ping CE2 and CE3. For example:
[~CE1] ping 10.1.1.2

0.00% packet loss
[~CE1] ping 10.2.1.2


(2020-10-09)
0.00% packet loss

----End
Configuration Files
#
sysname PE1
#
segment-routing ipv6 locator PE1_BUM unicast-locator PE1_UNICAST
#
#
bridge-domain 10
#
bridge-domain 20
#
locator PE1_UNICAST ipv6-prefix 2001:DB8:11:: 64 static 32
locator PE1_BUM ipv6-prefix 2001:DB8:12:: 64 static 32 args 10
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0001.00
#
segment-routing ipv6 locator PE1_UNICAST
segment-routing ipv6 locator PE1_BUM auto-sid-disable
#
#
undo shutdown
ipv6 enable
isis ipv6 enable 1
#
undo shutdown
ipv6 enable
isis ipv6 enable 1
#
undo shutdown
#
rewrite pop single
bridge-domain 10
#

(2020-10-09)
rewrite pop single

bridge-domain 20
#
interface LoopBack1
ipv6 enable
ip address 1.1.1.1 255.255.255.255
isis ipv6 enable 1
#
bgp 100
router-id 1.1.1.1
#
ipv4-family unicast
#
l2vpn-family evpn
policy vpn-target
#
#
return

#
sysname PE2
#
evpn
#
mac-duplication
#
esi 0001.0002.0003.0004.0005
#
esi 0005.0004.0003.0002.0001
#
#
#
bridge-domain 10
#
bridge-domain 20
#
e-trunk 1
priority 10
#
e-trunk 2

(2020-10-09)
priority 10
security-key cipher %^%#F&zi0c6x_2+SrLT_nm4,vfS$SCd]G:r~A_T!C>A$%^%#
#
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0002.00
#
#
#
e-trunk 1
esi 0001.0002.0003.0004.0005
#
rewrite pop single
bridge-domain 10
#
e-trunk 2
esi 0005.0004.0003.0002.0001
#
rewrite pop single
bridge-domain 20
#
undo shutdown
ipv6 enable
isis ipv6 enable 1
#
undo shutdown
ipv6 enable
isis ipv6 enable 1
#
undo shutdown
eth-trunk 10
#
undo shutdown
eth-trunk 20
#
interface LoopBack1
ipv6 enable
ip address 2.2.2.2 255.255.255.255
isis ipv6 enable 1
#
bgp 100
router-id 2.2.2.2

(2020-10-09)

#
ipv4-family unicast
#
l2vpn-family evpn
policy vpn-target
#
#
return
#
sysname PE3
#
evpn
#
mac-duplication
#
esi 0001.0002.0003.0004.0005
#
esi 0005.0004.0003.0002.0001
#
#
#
bridge-domain 10
#
bridge-domain 20
#
e-trunk 1
priority 10
#
e-trunk 2
priority 10
security-key cipher %^%#GAG\Y-F%GY[GnwCkov7A<e(m/cl}m86`jd6z[79~%^%#
#
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0003.00
#

(2020-10-09)

#
#
e-trunk 1
esi 0001.0002.0003.0004.0005
#
rewrite pop single
bridge-domain 10
#
e-trunk 2
esi 0005.0004.0003.0002.0001
#
rewrite pop single
bridge-domain 20
#
undo shutdown
ipv6 enable
isis ipv6 enable 1
#
undo shutdown
ipv6 enable
isis ipv6 enable 1
#
undo shutdown
eth-trunk 20
#
undo shutdown
eth-trunk 10
#
interface LoopBack1
ipv6 enable
ip address 3.3.3.3 255.255.255.255
isis ipv6 enable 1
#
bgp 100
router-id 3.3.3.3
#
ipv4-family unicast
#
l2vpn-family evpn
policy vpn-target
#

(2020-10-09)
#
return

#
sysname CE1
#
undo shutdown
#
vlan-type dot1q 10
ip address 10.1.1.1 255.255.255.0
#
vlan-type dot1q 20
ip address 10.2.1.1 255.255.255.0
#
return

#
sysname CE2
#
#
interface Eth-Trunk10.1
vlan-type dot1q 10
ip address 10.1.1.2 255.255.255.0
#
undo shutdown
eth-trunk 10
#
undo shutdown
eth-trunk 10
#
return

#
sysname CE3
#
#
vlan-type dot1q 20
ip address 10.2.1.2 255.255.255.0
#
undo shutdown
eth-trunk 20
#
undo shutdown
eth-trunk 20
#
return
2.2.22.13 Example for Configuring Inter-AS L3VPNv4 over SRv6 BE

This section provides an example for configuring an inter-AS SRv6 BE path to carry
L3VPNv4 services.

(2020-10-09)
Context
● PE1 and ASBR1 belong to AS 100, and PE2 and ASBR2 belong to AS 200.
Intra-AS IPv6 connectivity needs to be achieved for AS 100 and AS 200
through IS-IS.
● PE1 and ASBR1 belong to IS-IS process 1, and PE2 and ASBR2 belong to IS-IS
process 10. PE1, ASBR1, PE2, and ASBR2 are all Level-1 devices.
It is required that a bidirectional inter-AS SRv6 BE path be deployed between PE1
and PE2 to carry L3VPNv4 services.
Figure 2-112 Inter-AS L3VPNv4 over SRv6 BE networking

NOTE
the PEs and ASBRs.
2. Enable IS-IS, configure an IS-IS level, and specify a network entity on each PE
and ASBR.
5. Enable IS-IS SRv6 on each PE and ASBR.
6. Configure locator route import between the ASBRs.
7. Establish an MP-EBGP peer relationship between the PEs.
8. Configure the PEs to exchange BGP VPNv4 routes carrying SIDs through this
peer relationship.
9. Configure SRv6 forwarding on the PEs.
Data Preparation

(2020-10-09)
● Interface IPv6 addresses on each device

● AS numbers of the PEs and ASBRs
● IS-IS process IDs, levels, and network entity names of the PEs and ASBRs
Procedure
[*HUAWEI] commit

# Configure PE1.
[~PE1] isis 1
[*PE1-isis-1] quit
# Configure ASBR1.
[~ASBR1] isis 1
[*ASBR1-isis-1] ipv6 enable topology ipv6
[*ASBR1] interface gigabitethernet 1/0/0
[*ASBR1-GigabitEthernet1/0/0] isis ipv6 enable 1
[*ASBR1] interface loopback1
[*ASBR1-LoopBack1] isis ipv6 enable 1
[*ASBR1-LoopBack1] commit
[~ASBR1-LoopBack1] quit
# Configure ASBR2.
[~ASBR2] isis 10

(2020-10-09)
# Configure PE2.
[~PE2] isis 10
[*PE2-isis-10] quit

output on PE1.

--------------------------------------------------------------------------------
0000.0000.0002 GE1/0/0 0000.0000.0002.01 Up 8s L1 64
Total Peer(s): 1
that PE.
# Configure PE1.
[*PE1] commit
# Configure PE2.

(2020-10-09)

[*PE2] commit
# Assign an IP address to each interface on the CEs, as shown in Figure 2-112. For

NOTE
# Configure CE1.
[*CE1] bgp 65410
[*CE1-bgp] network 11.11.11.11 32
[*CE1-bgp] quit
[*CE1] commit
# Configure PE1.
[~PE1] bgp 100
[~PE1-bgp] quit
# Configure CE2.
[*CE2] bgp 65420
[*CE2-bgp] network 22.22.22.22 32
[*CE2-bgp] quit
[*CE2] commit
# Configure PE2.
[~PE2] bgp 200
[~PE2-bgp] quit

(2020-10-09)



10.1.1.2 4 65410 11 9 0 00:06:37 Established 1
Step 5 Configure IS-IS on the PEs to advertise SRv6 locator routes.

# Configure PE1.
[*PE1] isis 1
[~PE1-isis-1] quit
# Configure PE2.
[*PE2] isis 10
[~PE2-isis-10] quit
Step 6 Configure locator route import.

Configure locator route import in the PE1 -> PE2 direction. Specifically, configure
BGP on ASBR1 to import the locator routes advertised by PE1 through IS-IS and
advertise the routes to ASBR2. In addition, configure IS-IS on ASBR2 to import BGP
routes, thereby also advertising the locator routes of PE1 to PE2 through IS-IS.
Then, configure locator route import in the PE2 -> PE1 direction in a similar way.
# Configure ASBR1.
[~ASBR1] bgp 100
[*ASBR1-bgp] router-id 2.2.2.2
[*ASBR1-bgp] peer 2020::2 as-number 200
[*ASBR1-bgp] peer 2020::2 ebgp-max-hop 255
[*ASBR1-bgp-af-ipv6] peer 2020::2 enable
[*ASBR1-bgp-af-ipv6] network 10:: 64
[*ASBR1-bgp-af-ipv6] quit
[*ASBR1-bgp] quit
[*ASBR1] ip ipv6-prefix p1 permit 40:: 64
[*ASBR1] route-policy rp1 permit node 10
[*ASBR1-route-policy] if-match ipv6 address prefix-list p1

(2020-10-09)
[*ASBR1-route-policy] quit
[*ASBR1] isis 1
[*ASBR1-isis-1] ipv6 import-route bgp route-policy rp1
[*ASBR1] commit
# Configure ASBR2.
[~ASBR2] bgp 200
[*ASBR2-bgp] quit
[*ASBR2] route-policy rp1 permit node 10
[*ASBR2-route-policy] if-match ipv6 address prefix-list p1
[*ASBR2] isis 10
[*ASBR2-isis-10] ipv6 import-route bgp route-policy rp1
[*ASBR2] commit
Step 7 Establish an MP-EBGP peer relationship between the PEs, configure the PEs to
exchange BGP VPNv4 routes carrying SIDs through this peer relationship, and
enable SRv6 BE forwarding on the PEs.
# Configure PE1.
[~PE1] bgp 100
[*PE1-bgp] peer 4::4 ebgp-max-hop 255
[~PE1-bgp] quit
# Configure PE2.
[~PE2] bgp 200
[~PE2-bgp] quit
on the PEs to check whether BGP peer relationships have been established

(2020-10-09)
BGP peer relationships have been established successfully. The following example

4::4 4 200 1512 1520 0 21:55:19 Established 2

PrefRcv
10.1.1.2 4 65410 1790 1812 0 0026h03m Established 1


---------------------------

ArgsLength : 0
AutoSIDPoolID: 8193
Total Locator(s): 1

-------------------------------------

VPN Name : vpna VPN ID : 3
Total SID(s): 1
Run the ping command on a CE. The command output shows that CEs belonging
to the same VPN can ping each other. For example:
[~CE1] ping -a 11.11.11.11 22.22.22.22


(2020-10-09)
0.00% packet loss

----End
Configuration Files
#
sysname PE1
#
ipv4-family
#
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0001.00
#
#
#
undo shutdown
ipv6 enable
isis ipv6 enable 1
#
undo shutdown
ip address 10.1.1.1 255.255.255.0
#
interface LoopBack1
ipv6 enable
isis ipv6 enable 1
#
bgp 100
router-id 1.1.1.1
peer 4::4 ebgp-max-hop 255
#
ipv4-family unicast
#
ipv6-family unicast
#
ipv4-family vpnv4
policy vpn-target
peer 4::4 enable
#
import-route direct

(2020-10-09)
#
return
#
sysname ASBR1
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0002.00
#
ipv6 mport-route bgp route-policy rp1
#
#
undo shutdown
ipv6 enable
isis ipv6 enable 1
#
undo shutdown
ipv6 enable
#
interface LoopBack1
ipv6 enable
isis ipv6 enable 1
#
bgp 100
router-id 2.2.2.2
#
ipv4-family unicast
#
ipv6-family unicast
network 10:: 64
network 1:: 64
peer 2020::2 enable
#
route-policy rp1 permit node 10
if-match ipv6 address prefix-list p1
#
ip ipv6-prefix p1 index 10 permit 40:: 64
#
return
#
sysname ASBR2
#
isis 10
is-level level-1
cost-style wide
network-entity 10.0000.0000.0003.00
#
ipv6 import-route bgp route-policy rp1
#
#
undo shutdown
ipv6 enable

(2020-10-09)

isis ipv6 enable 10
#
undo shutdown
ipv6 enable
#
interface LoopBack1
ipv6 enable
isis ipv6 enable 10
#
bgp 200
#
ipv4-family unicast
#
ipv6-family unicast
network 40:: 64
network 4:: 64
peer 2020::1 enable
#
route-policy rp1 permit node 10
if-match ipv6 address prefix-list p1
#
#
return
#
sysname PE2
#
ipv4-family
#
#
isis 10
is-level level-1
cost-style wide
network-entity 10.0000.0000.0004.00
#
#
#
undo shutdown
ipv6 enable
isis ipv6 enable 10
#
undo shutdown
ip address 10.2.1.1 255.255.255.0
#
interface LoopBack1
ipv6 enable

(2020-10-09)

isis ipv6 enable 10
#
bgp 200
router-id 4.4.4.4
#
ipv4-family unicast
#
ipv6-family unicast
#
ipv4-family vpnv4
policy vpn-target
peer 1::1 enable
#
import-route direct
#
return

#
sysname CE1
#
undo shutdown
ip address 10.1.1.2 255.255.255.0
#
interface LoopBack1
ip address 11.11.11.11 255.255.255.255
#
bgp 65410
#
ipv4-family unicast
network 11.11.11.11 255.255.255.255
#
return

#
sysname CE2
#
undo shutdown
ip address 10.2.1.2 255.255.255.0
#
interface LoopBack1
ip address 22.22.22.22 255.255.255.255
#
bgp 65420
#
ipv4-family unicast
network 22.22.22.22 255.255.255.255
#
return

(2020-10-09)
2.2.22.14 Example for Configuring L3VPNv4 HoVPN over SRv6 BE Plus SRv6
BE
This section provides an example for configuring L3VPNv4 HoVPN over SRv6 BE
plus SRv6 BE.
Context
● The UPE, SPE, and NPE all belong to AS 100. They need to run IS-IS to
implement IPv6 network connectivity.
● The UPE, SPE, and NPE all belong to IS-IS process 1.
It is required that bidirectional SRv6 BE paths be established between the UPE and
NPE to carry L3VPNv4 services.
Figure 2-113 L3VPNv4 HoVPN over SRv6 BE networking

NOTE
the UPE, SPE, and NPE.
2. Enable IS-IS, configure an IS-IS level, and specify a network entity on the UPE,
SPE, and NPE.
3. Establish an EBGP peer relationship between the UPE and CE1 and another
one between the NPE and CE2.
4. Establish an MP-IBGP peer relationship between the UPE and SPE and
another one between the NPE and SPE.
5. Configure SRv6 on the UPE, SPE, and NPE.
6. Specify the UPE as the peer of the SPE and configure the SPE to advertise the
7. Configure the SPE to advertise regenerated routes to the NPE.

(2020-10-09)
Data Preparation
● IPv6 address of each interface on the UPE, SPE, and NPE
● IS-IS process ID of the UPE, SPE, and NPE
● IS-IS level of the UPE, SPE, and NPE
● VPN instance name, RD, and RT on the SPE and NPE
Procedure
following example uses the configuration of the UPE. The configurations of other
devices are similar to the configuration of the UPE. For configuration details, see
[~HUAWEI] sysname UPE
[*HUAWEI] commit
[~UPE] interface GigabitEthernet 1/0/0
[~UPE-GigabitEthernet1/0/0] ipv6 enable
[*UPE-GigabitEthernet1/0/0] ipv6 address 2001:db:2001::1 96
[*UPE-GigabitEthernet1/0/0] quit
[*UPE] interface loopback1
[*UPE-LoopBack1] ipv6 enable
[*UPE-LoopBack1] ipv6 address 2001:db8:1::1/64
[*UPE-LoopBack1] commit
[~UPE-LoopBack1] quit

# Configure the UPE.
[~UPE] isis 1
[*UPE-isis-1] is-level level-1
[*UPE-isis-1] cost-style wide
[*UPE-isis-1] network-entity 10.0000.0000.0001.00
[*UPE-isis-1] ipv6 enable topology ipv6
[*UPE-isis-1] quit
[*UPE] interface GigabitEthernet 1/0/0
[*UPE-GigabitEthernet1/0/0] isis ipv6 enable 1
[*UPE-LoopBack1] isis ipv6 enable 1
# Configure the SPE.

[~SPE] isis 1
[*SPE-isis-1] is-level level-1
[*SPE-isis-1] cost-style wide
[*SPE-isis-1] network-entity 10.0000.0000.0002.00
[*SPE-isis-1] ipv6 enable topology ipv6
[*SPE-isis-1] quit
[*SPE] interface GigabitEthernet 1/0/0
[*SPE-GigabitEthernet1/0/0] isis ipv6 enable 1
[*SPE-GigabitEthernet1/0/0] quit
[*SPE] interface GigabitEthernet 2/0/0
[*SPE] interface loopback1
[*SPE-LoopBack1] isis ipv6 enable 1
[*SPE-LoopBack1] commit
[~SPE-LoopBack1] quit

(2020-10-09)
# Configure the NPE.

[~NPE] isis 1
[*NPE-isis-1] is-level level-1
[*NPE-isis-1] cost-style wide
[*NPE-isis-1] network-entity 10.0000.0000.0003.00
[*NPE-isis-1] ipv6 enable topology ipv6
[*NPE-isis-1] quit
[*NPE] interface GigabitEthernet 1/0/0
[*NPE-GigabitEthernet1/0/0] isis ipv6 enable 1
[*NPE-GigabitEthernet1/0/0] quit
[*NPE] interface loopback1
[*NPE-LoopBack1] isis ipv6 enable 1
[*NPE-LoopBack1] commit
[~NPE-LoopBack1] quit
Step 3 On the UPE, SPE, and NPE, configure a VPN instance, enable the IPv4 address
family for the instance, and bind the interface that connects the UPE to CE1 to the
VPN instance on the UPE as well as the interface that connects the NPE to CE2 to
the VPN instance on the NPE.

[~UPE] ip vpn-instance vpna
[*UPE-vpn-instance-vpna] ipv4-family
[*UPE-vpn-instance-vpna-af-ipv4] route-distinguisher 100:1
[*UPE-vpn-instance-vpna-af-ipv4] vpn-target 111:1 both
[*UPE-vpn-instance-vpna-af-ipv4] quit
[*UPE-vpn-instance-vpna] quit
[*UPE-GigabitEthernet2/0/0] ip binding vpn-instance vpna
[*UPE-GigabitEthernet2/0/0] ip address 10.1.1.1 24
[*UPE] commit

[~SPE] ip vpn-instance vpna
[*SPE-vpn-instance-vpna] ipv4-family
[*SPE-vpn-instance-vpna-af-ipv4] route-distinguisher 200:1
[*SPE-vpn-instance-vpna-af-ipv4] vpn-target 111:1 both
[*SPE-vpn-instance-vpna-af-ipv4] quit
[*SPE-vpn-instance-vpna] quit
[*SPE] commit

[~NPE] ip vpn-instance vpna
[*NPE-vpn-instance-vpna] ipv4-family
[*NPE-vpn-instance-vpna-af-ipv4] route-distinguisher 300:1
[*NPE-vpn-instance-vpna-af-ipv4] vpn-target 111:1 both
[*NPE-vpn-instance-vpna-af-ipv4] quit
[*NPE-vpn-instance-vpna] quit
[*NPE] interface GigabitEthernet 2/0/0
[*NPE-GigabitEthernet2/0/0] ip binding vpn-instance vpna
[*NPE-GigabitEthernet2/0/0] ip address 10.2.1.1 24
[*NPE] commit
Step 4 Establish an EBGP peer relationship between the UPE and CE1 and another one
between the NPE and CE2.
# Configure CE1.
[*CE1] bgp 65410
[*CE1-bgp] network 11.11.11.11 32
[*CE1-bgp] quit
[*CE1] commit

(2020-10-09)

[~UPE] bgp 100
[*UPE-bgp] router-id 1.1.1.1
[*UPE-bgp] ipv4-family vpn-instance vpna
[*UPE-bgp-vpna] peer 10.1.1.2 as-number 65410
[*UPE-bgp-vpna] import-route direct
[*UPE-bgp-vpna] commit
[~UPE-bgp-vpna] quit
[~UPE-bgp] quit
# Configure CE2.
[*CE2] bgp 65420
[*CE2-bgp] network 22.22.22.22 32
[*CE2-bgp] quit
[*CE2] commit

[~NPE] bgp 100
[*NPE-bgp] router-id 3.3.3.3
[*NPE-bgp] ipv4-family vpn-instance vpna
[*NPE-bgp-vpna] peer 10.2.1.2 as-number 65420
[*NPE-bgp-vpna] import-route direct
[*NPE-bgp-vpna] commit
[~NPE-bgp-vpna] quit
[~NPE-bgp] quit
between the SPE and NPE.
[~UPE] bgp 100
[~UPE-bgp] peer 2001:db8:2::2 as-number 100
[*UPE-bgp] peer 2001:db8:2::2 connect-interface loopback 1
[*UPE-bgp] ipv4-family vpnv4
[*UPE-bgp-af-vpnv4] peer 2001:db8:2::2 enable
[*UPE-bgp-af-vpnv4] commit
[~UPE-bgp-af-vpnv4] quit
[~UPE-bgp] quit

[~SPE] bgp 100
[*SPE-bgp] router-id 2.2.2.2
[*SPE-bgp] peer 2001:db8:1::1 as-number 100
[*SPE-bgp] peer 2001:db8:1::1 connect-interface loopback 1
[~SPE-bgp] peer 2001:db8:3::3 as-number 100
[*SPE-bgp] peer 2001:db8:3::3 connect-interface loopback 1
[*SPE-bgp] ipv4-family vpnv4
[*SPE-bgp-af-vpnv4] peer 2001:db8:1::1 enable
[*SPE-bgp-af-vpnv4] peer 2001:db8:3::3 enable
[*SPE-bgp-af-vpnv4] commit
[~SPE-bgp-af-vpnv4] quit
[~SPE-bgp] quit

[~NPE] bgp 100
[~NPE-bgp] peer 2001:db8:2::2 as-number 100
[*NPE-bgp] peer 2001:db8:2::2 connect-interface loopback 1
[*NPE-bgp] ipv4-family vpnv4
[*NPE-bgp-af-vpnv4] peer 2001:db8:2::2 enable
[*NPE-bgp-af-vpnv4] commit
[~NPE-bgp-af-vpnv4] quit
[~NPE-bgp] quit
Step 6 Establish an SRv6 BE path between the UPE and SPE and another one between
the SPE and NPE.

(2020-10-09)

[~UPE] segment-routing ipv6
[*UPE-segment-routing-ipv6] encapsulation source-address 2001:db8:1::1
[*UPE-segment-routing-ipv6] locator as1 ipv6-prefix 10:: 64 static 32
[*UPE-segment-routing-ipv6-locator] quit
[*UPE-segment-routing-ipv6] quit
[*UPE] bgp 100
[*UPE-bgp-af-vpnv4] peer 2001:db8:2::2 prefix-sid
[*UPE-bgp-af-vpnv4] quit
[*UPE-bgp-vpna] segment-routing ipv6 best-effort
[*UPE-bgp-vpna] segment-routing ipv6 locator as1
[~UPE-bgp] quit
[~UPE] isis 1
[~UPE-isis-1] segment-routing ipv6 locator as1
[*UPE-isis-1] commit
[~UPE-isis-1] quit

[~SPE] segment-routing ipv6
[*SPE-segment-routing-ipv6] encapsulation source-address 2001:db8:2::2
[*SPE-segment-routing-ipv6] locator as1 ipv6-prefix 20:: 64 static 32
[*SPE-segment-routing-ipv6-locator] quit
[*SPE-segment-routing-ipv6] quit
[*SPE] bgp 100
[*SPE-bgp-af-vpnv4] peer 2001:db8:1::1 prefix-sid
[*SPE-bgp-af-vpnv4] peer 2001:db8:3::3 prefix-sid
[*SPE-bgp] ipv4-family vpn-instance vpna
[*SPE-bgp-vpna] segment-routing ipv6 best-effort
[*SPE-bgp-vpna] segment-routing ipv6 locator as1
[*SPE-bgp-vpna] commit
[~SPE-bgp-vpna] quit
[~SPE-bgp] quit
[~SPE] isis 1
[~SPE-isis-1] segment-routing ipv6 locator as1
[*SPE-isis-1] commit
[~SPE-isis-1] quit

[~NPE] segment-routing ipv6
[*NPE-segment-routing-ipv6] encapsulation source-address 2001:db8:3::3
[*NPE-segment-routing-ipv6] locator as1 ipv6-prefix 30:: 64 static 32
[*NPE-segment-routing-ipv6-locator] quit
[*NPE-segment-routing-ipv6] quit
[*NPE] bgp 100
[*NPE-bgp-af-vpnv4] peer 2001:db8:2::2 prefix-sid
[*NPE-bgp-vpna] segment-routing ipv6 best-effort
[*NPE-bgp-vpna] segment-routing ipv6 locator as1
[~NPE-bgp] quit
[~NPE] isis 1
[~NPE-isis-1] segment-routing ipv6 locator as1
[*NPE-isis-1] commit
[~NPE-isis-1] quit
Step 7 Specify the UPE as the peer of the SPE, and configure the SPE to advertise the
default route to the UPE and regenerated routes to the NPE.

(2020-10-09)
[~SPE] bgp 100

[~SPE-bgp] ipv4-family vpnv4
[~SPE-bgp-af-vpnv4] peer 2001:db8:1::1 upe
[*SPE-bgp-af-vpnv4] peer 2001:db8:1::1 default-originate vpn-instance vpna
[*SPE-bgp-af-vpnv4] peer 2001:db8:3::3 advertise route-reoriginated vpnv4
[*SPE-bgp-af-vpnv4] quit
[*SPE-bgp-vpna] advertise best-route route-reoriginate
[~SPE-bgp] quit

command output on the UPE.
[~UPE] display segment-routing ipv6 locator verbose
---------------------------

ArgsLength : 0
AutoSIDPoolID: 8193
Total Locator(s): 1
[~CE1] ping -a 11.11.11.11 22.22.22.22

0.00% packet loss
----End
Configuration Files
#
sysname CE1
#
undo shutdown
ip address 10.1.1.2 255.255.255.0
#
interface loopback1
ip address 11.11.11.11 255.255.255.255
#
bgp 65410
#
ipv4-family unicast

(2020-10-09)
network 11.11.11.11 255.255.255.255

#
return

#
sysname CE2
#
undo shutdown
ip address 10.2.1.2 255.255.255.0
#
interface loopback1
ip address 22.22.22.22 255.255.255.255
#
bgp 65420
#
ipv4-family unicast
network 22.22.22.22 255.255.255.255
#
return
● UPE configuration file

#
sysname UPE
#
ipv4-family
#
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0001.00
#
#
#
undo shutdown
ipv6 enable
ipv6 address 2001:DB8:2001::1/96
isis ipv6 enable 1
undo dcn
#
undo shutdown
ip address 10.1.1.1 255.255.255.0
#
interface loopback1
ipv6 enable
isis ipv6 enable 1
#
bgp 100
router-id 1.1.1.1
peer 2001:DB8:2::2 connect-interface loopback1

(2020-10-09)
#
ipv4-family unicast
#
ipv4-family vpnv4
policy vpn-target
peer 2001:DB8:2::2 prefix-sid
#
import-route direct
#
return
● SPE configuration file

#
sysname SPE
#
ipv4-family
#
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0002.00
#
#
#
undo shutdown
ipv6 enable
ipv6 address 2001:DB:2001::2/96
isis ipv6 enable 1
undo dcn
#
undo shutdown
ipv6 enable
ipv6 address 2001:DB8:2002::1/96
isis ipv6 enable 1
dcn
#
undo shutdown
ip address 100.1.1.2 255.255.255.0
#
interface loopback1
ipv6 enable
isis ipv6 enable 1
#
bgp 100
router-id 2.2.2.2
peer 2001:db8:1::1 as-number 100
peer 2001:db8:1::1 connect-interface loopback1
peer 2001:db8:3::3 as-number 100
peer 2001:db8:3::3 connect-interface loopback1
#

(2020-10-09)
ipv4-family unicast
#
ipv4-family vpnv4
policy vpn-target
peer 2001:db8:1::1 enable
peer 2001:db8:1::1 upe
peer 2001:db8:1::1 default-originate vpn-instance vpna
peer 2001:db8:1::1 prefix-sid
peer 2001:db8:3::3 advertise route-reoriginated vpnv4
#
import-route direct
advertise best-route route-reoriginate
#
return
● NPE configuration file

#
sysname NPE
#
ipv4-family
#
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0003.00
#
#
#
undo shutdown
ipv6 enable
ipv6 address 2001:DB8:2002::2/96
isis ipv6 enable 1
dcn
#
undo shutdown
ip address 10.2.1.1 255.255.255.0
dcn
#
interface loopback1
ipv6 enable
isis ipv6 enable 1
#
bgp 100
router-id 3.3.3.3
peer 2001:DB8:2::2 connect-interface loopback1
#
ipv4-family unicast
#

(2020-10-09)
ipv4-family vpnv4
policy vpn-target
#
import-route direct
#
return
2.2.22.15 Example for Configuring Public IPv4 over SRv6 BE

This section provides an example for configuring SRv6 BE to carry public IPv4
services.
Context
On the network shown in Figure 2-114, PE1, the P, and PE2 are in the same AS.
They need to run IS-IS to implement IPv6 network connectivity. PE1, the P, and
PE2 are Level-1 devices that belong to IS-IS process 1. An IBGP peer relationship
needs to be established between PE1 and PE2, and EBGP peer relationships need
to be established between PE1 and DeviceA and between PE2 and DeviceB.
A bidirectional SRv6 BE path needs to be deployed between PE1 and PE2 to carry
public IPv4 services.

NOTE
P, and PE2.

(2020-10-09)
3. Establish an EBGP peer relationship between PE1 and DeviceA and another
one between PE2 and DeviceB.
Data Preparation
Procedure
[*HUAWEI] commit

# Configure PE1.
[~PE1] isis 1
[*PE1-isis-1] quit
# Configure the P.
[~P] isis 1
[*P-isis-1] quit

(2020-10-09)

[*P-GigabitEthernet2/0/0] commit
[~P-GigabitEthernet2/0/0] quit
# Configure PE2.
[~PE2] isis 1
[*PE2-isis-1] quit

output on PE1.

--------------------------------------------------------------------------------
0000.0000.0002 GE1/0/0 0000.0000.0002.01 Up 8s L1 64
Total Peer(s): 1
-----------------------------

--------------------------------

--------------------------------------------------------------------------------
2::2/64 GE1/0/0 FE80::3A92:6CFF:FE21:10 10 A/-/-/-
2001::/96 GE1/0/0 Direct 10 D/-/L/-
2002::/96 GE1/0/0 FE80::3A92:6CFF:FE21:10 20 A/-/-/-
# Configure DeviceA.
[~DeviceA] interface gigabitethernet 1/0/0
[~DeviceA-GigabitEthernet1/0/0] ip address 192.168.1.1 24
[*DeviceA] bgp 200
[*DeviceA-bgp] router-id 4.4.4.4
[*DeviceA-bgp] peer 192.168.1.2 as-number 100
[*DeviceA-bgp] quit
[*DeviceA] commit

(2020-10-09)
# Configure PE1.
[~PE1-GigabitEthernet2/0/0] ip address 192.168.1.2 24
[*PE1] bgp 100
[*PE1-bgp-af-ipv4] network 192.168.1.0 24
[~PE1-bgp] quit
# Configure DeviceB.
[~DeviceB] interface gigabitethernet 1/0/0
[~DeviceB-GigabitEthernet1/0/0] ip address 192.168.2.1 24
[*DeviceB] bgp 300
[*DeviceB-bgp] router-id 5.5.5.5
[*DeviceB-bgp] peer 192.168.2.2 as-number 100
[*DeviceB-bgp] quit
[*DeviceB] commit
# Configure PE2.
[~PE2-GigabitEthernet2/0/0] ip address 192.168.2.2 24
[*PE2] bgp 100
[*PE2-bgp-af-ipv4] network 192.168.2.0 24
[~PE2-bgp] quit
PEs to check whether the BGP peer relationships have been established. If the
Established state is displayed in the command output, the BGP peer relationships
have been established successfully.
relationship has been established between PE1 and DeviceA.

192.168.1.1 4 200 1624 1622 0 00:06:37 Established 1

# Configure PE1.
[~PE1] bgp 100
[*PE1-bgp] peer 2::2 connect-interface loopback1
[*PE1-bgp-af-ipv4] peer 2::2 enable

(2020-10-09)
[~PE1-bgp] quit
# Configure PE2.
[~PE2] bgp 100
[*PE2-bgp] peer 1::1 connect-interface loopback1
[*PE2-bgp-af-ipv4] peer 1::1 enable
[~PE2-bgp] quit
output on PE1.


PrefRcv
192.168.1.1 4 200 10 11 0 00:05:15 Established 2
2::2 4 100 10 11 0 00:05:15 Established 2

NOTE

the opcode func-opcode end-dt4 command to configure a static SID opcode.
# Configure PE1.
[*PE1-segment-routing-ipv6] locator aa ipv6-prefix 11:: 64 static 32
[*PE1] isis 1
[*PE1-isis-1] segment-routing ipv6 locator aa
[~PE1-isis-1] quit
[~PE1] bgp 100
[~PE1-bgp] ipv4-family unicast
[*PE1-bgp-af-ipv4] peer 2::2 prefix-sid
[*PE1-bgp-af-ipv4] segment-routing ipv6 best-effort
[*PE1-bgp-af-ipv4] segment-routing ipv6 locator aa
[~PE1-bgp] quit
# Configure PE2.

(2020-10-09)
[*PE2] isis 1
[~PE2-isis-1] quit
[~PE2] bgp 100
[*PE2-bgp-af-ipv4] peer 1::1 prefix-sid
[~PE2-bgp] quit
Run the display segment-routing ipv6 local-sid forwarding command to check

information about the SRv6 local SID table. The following example uses the
[~PE1] display segment-routing ipv6 local-sid forwarding
My Local-SID Forwarding Table
-------------------------------------

LocatorName: aa LocatorID: 1
Total SID(s): 1
Run the display bgp routing-table command to check information about the BGP
routing table. The following example uses the command output on PE2.
[~PE2] display bgp routing-table 192.168.1.0

Paths: 1 available, 1 best, 1 select, 0 best-external, 0 add-path
BGP routing table entry information of 192.168.1.0/24:
From: 1::1 (1.1.1.1)
Relay IP Nexthop: FE80::3ABD:6CFF:FE31:300
Original nexthop: 1::1
Prefix-sid: 11::1:0:1
AS-path Nil, origin igp, MED 0, localpref 100, pref-val 0, valid, internal, best, select, pre 255, IGP cost 20
192.168.2.1
Check that DeviceA and DeviceB can ping each other. The following example uses
the command output on DeviceA.
[~DeviceA] ping 192.168.2.1

0.00% packet loss
----End

(2020-10-09)
Configuration Files
#
sysname PE1
#
locator aa ipv6-prefix 11:: 64 static 32
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0001.00
#
segment-routing ipv6 locator aa
#
#
undo shutdown
ipv6 enable
isis ipv6 enable 1
#
undo shutdown
ip address 192.168.1.2 255.255.255.0
#
interface LoopBack1
ipv6 enable
isis ipv6 enable 1
#
bgp 100
router-id 1.1.1.1
#
ipv4-family unicast
network 192.168.1.0 255.255.255.0
peer 2::2 enable
#
return
#
sysname P
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0002.00
#
#
#
undo shutdown
ipv6 enable
isis ipv6 enable 1
#

(2020-10-09)
undo shutdown
ipv6 enable
isis ipv6 enable 1
#
return
#
sysname PE2
#
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0003.00
#
#
#
undo shutdown
ipv6 enable
isis ipv6 enable 1
#
undo shutdown
ip address 192.168.2.2 255.255.255.0
#
interface LoopBack1
ipv6 enable
isis ipv6 enable 1
#
bgp 100
router-id 2.2.2.2
#
ipv4-family unicast
network 192.168.2.0 255.255.255.0
peer 1::1 enable
#
return
● DeviceA configuration file
#
sysname DeviceA
#
undo shutdown
ip address 192.168.1.1 255.255.255.0
#
bgp 200
router-id 4.4.4.4
#
ipv4-family unicast

(2020-10-09)
#
return
● DeviceB configuration file

#
sysname DeviceB
#
undo shutdown
ip address 192.168.2.1 255.255.255.0
#
bgp 300
router-id 5.5.5.5
#
ipv4-family unicast
#
return
2.2.22.16 Example for Configuring Public IPv6 over SRv6 BE

This section provides an example for configuring SRv6 BE to carry public IPv6
services.
Context
On the network shown in Figure 2-115, PE1, the P, and PE2 are in the same AS.
They need to run IS-IS to implement IPv6 network connectivity. PE1, the P, and
PE2 are Level-1 devices that belong to IS-IS process 1. An IBGP peer relationship
needs to be established between PE1 and PE2, and EBGP peer relationships need
to be established between PE1 and DeviceA and between PE2 and DeviceB.
A bidirectional SRv6 BE path needs to be deployed between PE1 and PE2 to carry
public IPv6 services.

NOTE

(2020-10-09)
P, and PE2.
3. Establish an EBGP peer relationship between PE1 and DeviceA and another
one between PE2 and DeviceB.
5. Configure SRv6 and enable IS-IS SRv6 on PE1 and PE2. In addition, use BGP to
dynamically allocate End.DT6 SIDs.
Data Preparation
Procedure
[*HUAWEI] commit
[~PE1] interface loopback1

# Configure PE1.
[~PE1] isis 1
[*PE1-isis-1] quit

(2020-10-09)
# Configure the P.
[~P] isis 1
[*P-isis-1] quit
[*P-GigabitEthernet2/0/0] commit
[~P-GigabitEthernet2/0/0] quit
# Configure PE2.
[~PE2] isis 1
[*PE2-isis-1] quit

output on PE1.

--------------------------------------------------------------------------------
0000.0000.0002 GE1/0/0 0000.0000.0002.01 Up 8s L1 64
Total Peer(s): 1
-----------------------------

--------------------------------

------------------------------------------------------------------------------------------
2001:DB8:1::1/64 Loop1 Direct 0 D/-/L/-
2001:DB8:3::3/64 GigabitEthernet1/0/0 FE80::3ABD:6CFF:FE31:306 20 A/-/-/-
2001:DB8:10::/64 GigabitEthernet1/0/0 Direct 10 D/-/L/-

(2020-10-09)
2001:DB8:20::/64 GigabitEthernet1/0/0 FE80::3ABD:6CFF:FE31:306 20 A/-/-/-

# Configure DeviceA.
[~DeviceA] bgp 200
[*DeviceA-bgp] router-id 4.4.4.4
[*DeviceA-bgp] peer 2001:DB8:11::2 as-number 100
[*DeviceA-bgp] ipv6-family unicast
[*DeviceA-bgp-af-ipv6] peer 2001:DB8:11::2 enable
[*DeviceA-bgp-af-ipv6] commit
[~DeviceA-bgp-af-ipv6] quit
[~DeviceA-bgp] quit
# Configure PE1.
[~PE1] bgp 100
[*PE1-bgp-af-ipv6] peer 2001:DB8:11::1 enable
[*PE1-bgp-af-ipv6] network 2001:DB8:11::1 64
[~PE1-bgp] quit
# Configure DeviceB.
[~DeviceB] bgp 300
[*DeviceB-bgp] router-id 5.5.5.5
[*DeviceB-bgp] peer 2001:DB8:22::2 as-number 100
[*DeviceB-bgp] ipv6-family unicast
[*DeviceB-bgp-af-ipv6] peer 2001:DB8:22::2 enable
[*DeviceB-bgp-af-ipv6] commit
[~DeviceB-bgp-af-ipv6] quit
[~DeviceB-bgp] quit
# Configure PE2.
[~PE2] bgp 100
[*PE2-bgp-af-ipv6] network 2001:DB8:22::1 64
[~PE2-bgp] quit
the PEs to check whether the BGP peer relationships have been established. If the
Established state is displayed in the command output, the BGP peer relationships
have been established successfully.
relationship has been established between PE1 and DeviceA.

2001:DB8:11::1 4 200 1624 1622 0 00:06:37 Established 1

(2020-10-09)

# Configure PE1.
[~PE1] bgp 100
[*PE1-bgp] peer 2001:DB8:3::3 connect-interface loopback1
[~PE1-bgp] quit
# Configure PE2.
[~PE2] bgp 100
[*PE2-bgp] peer 2001:DB8:1::1 connect-interface loopback1
[~PE2-bgp] quit
the PEs to check whether the BGP peer relationship has been established. If the
output on PE1.


PrefRcv
2001:DB8:11::1 4 200 10 11 0 00:05:15 Established 2
2001:DB8:3::3 4 100 10 11 0 00:05:15 Established 2

NOTE

the opcode func-opcode end-dt6 command to configure a static SID opcode.
# Configure PE1.
[*PE1] isis 1
[~PE1-isis-1] quit
[~PE1] bgp 100
[*PE1-bgp-af-ipv6] peer 2001:DB8:3::3 prefix-sid

(2020-10-09)

[~PE1-bgp] quit
# Configure PE2.
[*PE2] isis 1
[~PE2-isis-1] quit
[~PE2] bgp 100
[*PE2-bgp-af-ipv6] peer 2001:DB8:1::1 prefix-sid
[~PE2-bgp] quit

Run the display segment-routing ipv6 local-sid forwarding command to check
information about the SRv6 local SID table. The following example uses the
[~PE1] display segment-routing ipv6 local-sid forwarding
My Local-SID Forwarding Table
-------------------------------------
SID : 10::1:0:0/128 FuncType : End


SID : 10::1:0:2/128 FuncType : End.X

SID : 10::1:0:3/128 FuncType : End.X

SID : 10::1:0:3C/128 FuncType : End.DT6

Run the display bgp ipv6 routing-table command to check information about
the BGP routing table. The following example uses the command output on PE2.
[~PE2] display bgp ipv6 routing-table 2001:DB8:11::1

Paths: 1 available, 1 best, 1 select, 0 best-external, 0 add-path
BGP routing table entry information of 1::/96:
From: 2001:DB8:1::1 (1.1.1.1)
Relay IP Nexthop: FE80::3ABD:6CFF:FE31:300
Prefix-sid: 10::1:0:3C
AS-path Nil, origin igp, MED 0, localpref 100, pref-val 0, valid, internal, best, select, pre 255, IGP cost 20
2001:DB8:22::1

(2020-10-09)
Check that DeviceA and DeviceB can ping each other. The following example uses
the command output on DeviceA.
[~DeviceA] ping ipv6 2001:DB8:22::1
PING 2001:DB8:22::1 : 56 data bytes, press CTRL_C to break

0.00% packet loss
----End
Configuration Files
#
sysname PE1
#
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0001.00
#
#
#
undo shutdown
ipv6 enable
isis ipv6 enable 1
#
undo shutdown
ipv6 enable
ip address 2001:DB8:11::2/64
#
interface LoopBack1
ipv6 enable
isis ipv6 enable 1
#
bgp 100
router-id 1.1.1.1
#
ipv6-family unicast
network 1:: 96

(2020-10-09)

#
return
#
sysname P
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0002.00
#
#
#
undo shutdown
ipv6 enable
isis ipv6 enable 1
#
undo shutdown
ipv6 enable
isis ipv6 enable 1
#
return
#
sysname PE2
#
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0003.00
#
#
#
undo shutdown
ipv6 enable
isis ipv6 enable 1
#
undo shutdown
ipv6 enable
#
interface LoopBack1
ipv6 enable
isis ipv6 enable 1
#
bgp 100
router-id 2.2.2.2

(2020-10-09)

#
ipv6-family unicast
network 2:: 96
#
return
● DeviceA configuration file
#
sysname DeviceA
#
undo shutdown
ipv6 enable
#
bgp 200
router-id 4.4.4.4
#
ipv6-family unicast
#
return
● DeviceB configuration file
#
sysname DeviceB
#
undo shutdown
ipv6 enable
#
bgp 300
router-id 5.5.5.5
#
ipv6-family unicast
#
return
2.2.23 Configuration Examples for SRv6 TE Policy

This section provides SRv6 TE Policy configuration examples.
2.2.23.1 Example for Configuring L3VPNv4 over SRv6 TE Policy (Manual

Configuration)
This section provides an example for configuring an SRv6 TE Policy to carry
L3VPNv4 services.

(2020-10-09)
It is required that a bidirectional SRv6 TE Policy be deployed between PE1 and PE2
Figure 2-116 L3VPNv4 over SRv6 TE Policy networking

NOTE
Precautions
1. End and End.X SIDs are mandatory for SRv6 TE Policies. The SIDs can either
be configured manually or generated dynamically using an IGP. In scenarios
where SRv6 TE Policies are configured manually, if dynamic SIDs are used for
the SRv6 TE Policies, the SIDs may change after an IGP restart. In this case,
you need to manually adjust the SRv6 TE Policies for them to remain up. This
complicates maintenance and therefore dynamic SIDs cannot be used on a
large scale. For this reason, you are advised to configure SIDs manually and
not to use dynamic SIDs.
2. To implement color-based traffic steering into SRv6 TE Policies, you need to
configure an import or export route-policy with the color attribute being
specified. Then, configure a tunnel policy to allow routes to recurse to SRv6
TE Policies.
After the preceding configurations are complete, if the color and next hop of
a route are the same as the color and endpoint of an SRv6 TE Policy,
respectively, the route can successfully recurse to the SRv6 TE Policy, and the
traffic forwarded through the route can then be steered into the SRv6 TE
Policy.
2. Enable IS-IS, configure an IS-IS level, and specify a network entity on PE1,
PE2, and the P.

(2020-10-09)

6. Configure SRv6 SIDs and enable IS-IS SRv6 on PE1, the P, and PE2. In addition,
configure PE1 and PE2 to advertise VPN routes carrying SIDs.
7. Configure an SRv6 TE Policy on PE1 and PE2.
8. Configure a tunnel policy on PE1 and PE2 to import VPN traffic.
Data Preparation
Procedure
# Configure PE1. The configurations of the P and PE2 are similar to the
section.
[*HUAWEI] commit
[*PE1] commit

# Configure PE1.
[~PE1] isis 1
[*PE1-isis-1] quit
# Configure the P.
[~P] isis 1

(2020-10-09)

[*P-isis-1] quit
[~P-LoopBack1] quit
# Configure PE2.
[~PE2] isis 1
[*PE2-isis-1] quit

output on PE1.

--------------------------------------------------------------------------------
0000.0000.0002 GE1/0/0 0000.0000.0002.01 Up 8s L1 64
Total Peer(s): 1
-----------------------------

--------------------------------

--------------------------------------------------------------------------------
2::2/64 GE1/0/0 FE80::3A92:6CFF:FE21:10 10 A/-/-/-
3::3/64 GE1/0/0 FE80::3A92:6CFF:FE21:10 20 A/-/-/-
2001::/96 GE1/0/0 Direct 10 D/-/L/-
2002::/96 GE1/0/0 FE80::3A92:6CFF:FE21:10 20 A/-/-/-

(2020-10-09)
that PE.
# Configure PE1.
[*PE1] commit
# Configure PE2.
[*PE2] commit

NOTE
may fail.
# Configure CE1.
[*CE1] bgp 65410
[*CE1-bgp] network 11.11.11.11 32
[*CE1-bgp] quit
[*CE1] commit
# Configure PE1.
[~PE1] bgp 100

(2020-10-09)
[~PE1-bgp] quit
# Configure CE2.
[*CE2] bgp 65420
[*CE2-bgp] network 22.22.22.22 32
[*CE2-bgp] quit
[*CE2] commit
# Configure PE2.
[~PE2] bgp 100
[~PE2-bgp] quit



10.1.1.2 4 65410 11 9 0 00:06:37 Established 1
# Configure PE1.
[~PE1] bgp 100
[~PE1-bgp] quit
# Configure PE2.
[~PE2] bgp 100
[~PE2-bgp] quit

(2020-10-09)


3::3 4 100 216 220 0 03:03:35 Established 2

10.1.1.2 4 65410 216 217 0 03:06:22 Established 1
Step 6 Configure SRv6 SIDs, and configure the PEs to add SIDs to VPN routes.
NOTE

# Configure PE1.
[*PE1-segment-routing-ipv6-locator] opcode ::111 end
[*PE1] bgp 100
[*PE1-bgp-vpna] segment-routing ipv6 traffic-engineer best-effort
[~PE1-bgp] quit
[~PE1] isis 1
[~PE1-isis-1] segment-routing ipv6 locator as1 auto-sid-disable
[~PE1-isis-1] quit
# Configure the P.
[~P] segment-routing ipv6
[*P-segment-routing-ipv6] encapsulation source-address 2::2
[*P-segment-routing-ipv6] locator as1 ipv6-prefix 20:: 64 static 32
[*P-segment-routing-ipv6-locator] opcode ::222 end
[*P-segment-routing-ipv6-locator] quit
[*P-segment-routing-ipv6] quit
[*P] isis 1
[*P-isis-1] segment-routing ipv6 locator as1 auto-sid-disable

(2020-10-09)
[*P-isis-1] commit
[~P-isis-1] quit
# Configure PE2.
[*PE2] bgp 100
[~PE2-bgp] quit
[~PE2] isis 1
[~PE2-isis-1] quit
After the configuration is complete, run the display segment-routing ipv6

locator [ locator-name ] verbose command to check SRv6 locator information.
---------------------------

ArgsLength : 0
AutoSIDPoolID: 8202
Total Locator(s): 1
Run the display segment-routing ipv6 local-sid end forwarding command to

check information about the SRv6 local SID table.
[~PE1] display segment-routing ipv6 local-sid end forwarding
My Local-SID End Forwarding Table
---------------------------------
SID : 10::111/128 FuncType : End

Flavor : PSP
Total SID(s): 1
---------------------------------

Flavor : PSP
Total SID(s): 1
[~P] display segment-routing ipv6 local-sid end forwarding
---------------------------------

(2020-10-09)

Flavor : PSP
Total SID(s): 1
# Configure PE1.
[~PE1-segment-routing-ipv6] segment-list list1
[*PE1-segment-routing-ipv6-segment-list-list1] index 5 sid ipv6 20::222
[*PE1-segment-routing-ipv6-segment-list-list1] commit
[~PE1-segment-routing-ipv6-segment-list-list1] quit
[~PE1-segment-routing-ipv6] srv6-te-policy locator as1
[*PE1-segment-routing-ipv6] srv6-te policy policy1 endpoint 3::3 color 101
[*PE1-segment-routing-ipv6-policy-policy1] binding-sid 10::100
[*PE1-segment-routing-ipv6-policy-policy1] candidate-path preference 100
[*PE1-segment-routing-ipv6-policy-policy1-path] segment-list list1
[*PE1-segment-routing-ipv6-policy-policy1-path] commit
[~PE1-segment-routing-ipv6-policy-policy1-path] quit
[~PE1-segment-routing-ipv6-policy-policy1] quit
[~PE1-segment-routing-ipv6] quit
# Configure PE2.
After the configuration is complete, run the display srv6-te policy command to
check SRv6 TE Policy information.

[~PE1] display srv6-te policy
Color : 101 Endpoint : 3::3
TunnelId :1 Binding SID : 10::100
TunnelType : SRv6-TE Policy DelayTimerRemain :-
Policy State : UP State Change Time : 2019-02-17 11:45:30
Backup Hot-Standby : Disable BFD : Disable
Candidate-path Preference : 100

Discriminator : 100 Binding SID : 10::100
Template ID :0 Path Verification : Disable
DelayTimerRemain :- Segment-List Count : 1
Segment-List : list1
Segment-List ID :1 XcIndex :1

(2020-10-09)
List State : UP DelayTimerRemain :-

Verification State : - SuppressTimeRemain : -
PMTU : 9600 Active PMTU : 9600
Weight :1 BFD State :-
SID :
20::222
30::333
Step 8 Configure a tunnel policy to import VPN traffic.

# Configure PE1.
[~PE1] route-policy p1 permit node 10
[*PE1] bgp 100
[*PE1-bgp-af-vpnv4] peer 3::3 route-policy p1 import
[*PE1-bgp] quit
[*PE1-tunnel-policy-p1] tunnel select-seq ipv6 srv6-te-policy load-balance-number 1
# Configure PE2.
[*PE2] bgp 100
[*PE2-bgp] quit
After the configuration is complete, run the display ip routing-table vpn-

instance vpna command to check the routing table of the VPN instance. The
command output shows that the VPN route has successfully recursed to the SRv6
TE Policy.
------------------------------------------------------------------------------

10.2.1.0/24 IBGP 255 0 RD 3::3 policy1

(2020-10-09)

22.22.22.22/32 IBGP 255 0 RD 3::3 policy1
------------------------------------------------------------------------------
Summary Count : 1
NextHop: 3::3 Neighbour: 3::3
IndirectID: 0x10000E0 Instance:
RelayNextHop: :: Interface: policy1

[~CE1] ping -a 11.11.11.11 22.22.22.22

0.00% packet loss
----End
Configuration Files
#
sysname PE1
#
ipv4-family
tnl-policy p1
#
opcode ::111 end
srv6-te-policy locator as1
segment-list list1
index 5 sid ipv6 20::222
srv6-te policy policy1 endpoint 3::3 color 101
binding-sid 10::100
segment-list list1
#

(2020-10-09)
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0001.00
#
segment-routing ipv6 locator as1 auto-sid-disable
#
#
undo shutdown
ip address 10.1.1.1 255.255.255.0
#
undo shutdown
ipv6 enable
isis ipv6 enable 1
#
interface LoopBack1
ipv6 enable
isis ipv6 enable 1
#
bgp 100
router-id 1.1.1.1
#
ipv4-family unicast
#
ipv6-family unicast
#
ipv4-family vpnv4
policy vpn-target
peer 3::3 enable
peer 3::3 route-policy p1 import
#
import-route direct
segment-routing ipv6 traffic-engineer best-effort
#
route-policy p1 permit node 10
#
tunnel-policy p1
tunnel select-seq ipv6 srv6-te-policy load-balance-number 1
#
return
#
sysname P
#
opcode ::222 end
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0002.00
#

(2020-10-09)

#
#
undo shutdown
ipv6 enable
isis ipv6 enable 1
#
undo shutdown
ipv6 enable
isis ipv6 enable 1
#
interface LoopBack1
ipv6 enable
isis ipv6 enable 1
#
return
#
sysname PE2
#
ipv4-family
tnl-policy p1
#
opcode ::333 end
segment-list list1
binding-sid 30::300
segment-list list1
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0003.00
#
#
#
undo shutdown
ipv6 enable
isis ipv6 enable 1
#
undo shutdown
ip address 10.2.1.1 255.255.255.0
#
interface LoopBack1
ipv6 enable

(2020-10-09)
isis ipv6 enable 1

#
bgp 100
router-id 2.2.2.2
#
ipv4-family unicast
#
ipv6-family unicast
#
ipv4-family vpnv4
policy vpn-target
peer 1::1 enable
#
import-route direct
#
#
tunnel-policy p1
#
return
#
sysname CE1
#
undo shutdown
ip address 10.1.1.2 255.255.255.0
#
interface LoopBack1
ip address 11.11.11.11 255.255.255.255
#
bgp 65410
#
ipv4-family unicast
network 11.11.11.11 255.255.255.255
#
return
#
sysname CE2
#
undo shutdown
ip address 10.2.1.2 255.255.255.0
#
interface LoopBack1
ip address 22.22.22.22 255.255.255.255
#
bgp 65420
#
ipv4-family unicast

(2020-10-09)
network 22.22.22.22 255.255.255.255

#
return
2.2.23.2 Example for Configuring L3VPNv4 over SRv6 TE Policy to Achieve

DSCP-based Traffic Steering (Manual Configuration)
This section provides an example for configuring L3VPNv4 over SRv6 TE Policy to
achieve DSCP-based traffic steering.
● PE1, P1, P2, and PE2 are in the same AS and run IS-IS to implement IPv6
Figure 2-117 Networking for configuring L3VPNv4 over SRv6 TE Policy to achieve
DSCP-based traffic steering
NOTE

(2020-10-09)
P2, and PE2.
6. Configure SRv6 SIDs and enable IS-IS SRv6 on PE1, P1, P2, and PE2. In
addition, configure PE1 and PE2 to advertise VPN routes carrying SIDs.
7. Deploy an SRv6 TE Policy between PE1 and PE2.
8. Configure an SRv6 mapping policy on PE1 and PE2.
9. Configure a tunnel policy on PE1 and PE2 to preferentially use an SRv6 TE
Policy group for VPN traffic import.
Data Preparation
Procedure
# Configure PE1. The configurations of P1, P2, and PE2 are similar to the
section.
[*HUAWEI] commit
[*PE1] commit

# Configure PE1.
[~PE1] isis 1

(2020-10-09)
[*PE1-isis-1] quit
# Configure P1.
[~P1] isis 1
[*P1-isis-1] quit
# Configure PE2.
[~PE2] isis 1
[*PE2-isis-1] quit
# Configure P2.
[~P2] isis 1
[*P2-isis-1] quit

(2020-10-09)

output on PE1.

--------------------------------------------------------------------------------
0000.0000.0002* GE1/0/0 0000.0000.0003.01 Up 9s L1 64
0000.0000.0004* GE3/0/0 0000.0000.0004.02 Up 7s L1 64
Total Peer(s): 2
instance, and bind the interface that connects each PE to a CE to the VPN instance
on that PE.
# Configure PE1.
[*PE1] commit
# Configure PE2.
[*PE2] commit

NOTE
may fail.

(2020-10-09)
# Configure CE1.
[*CE1] bgp 65410
[*CE1-bgp] network 11.11.11.11 32
[*CE1-bgp] quit
[*CE1] commit
# Configure PE1.
[~PE1] bgp 100
[~PE1-bgp] quit
# Configure CE2.
[*CE2] bgp 65420
[*CE2-bgp] network 22.22.22.22 32
[*CE2-bgp] quit
[*CE2] commit
# Configure PE2.
[~PE2] bgp 100
[~PE2-bgp] quit



PrefRcv
10.1.1.2 4 65410 88 89 0 01:12:27 Established 1
# Configure PE1.

(2020-10-09)
[~PE1] bgp 100

[~PE1-bgp] quit
# Configure PE2.
[~PE2] bgp 100
[~PE2-bgp] quit
on the PEs to check whether a BGP peer relationship has been established
BGP peer relationship has been established successfully.



PrefRcv
3::3 4 100 85 85 0 01:10:30 Established 2

PrefRcv
10.1.1.2 4 65410 88 89 0 01:12:58 Established 1
NOTE

# Configure PE1.
[*PE1-segment-routing-ipv6-locator] opcode ::200 end no-psp
[*PE1] bgp 100

(2020-10-09)

[~PE1-bgp] quit
[~PE1] isis 1
[~PE1-isis-1] quit
# Configure P1.
[~P1] segment-routing ipv6
[*P1-segment-routing-ipv6] encapsulation source-address 2::2
[*P1-segment-routing-ipv6] locator as1 ipv6-prefix 20:: 64 static 32
[*P1-segment-routing-ipv6-locator] opcode ::100 end
[*P1-segment-routing-ipv6-locator] opcode ::200 end no-psp
[*P1-segment-routing-ipv6-locator] quit
[*P1-segment-routing-ipv6] quit
[*P1] isis 1
[*P1-isis-1] segment-routing ipv6 locator as1 auto-sid-disable
[*P1-isis-1] commit
[~P1-isis-1] quit
# Configure PE2.
[*PE2-segment-routing-ipv6-locator] opcode ::200 end no-psp
[*PE2] bgp 100
[~PE2-bgp] quit
[~PE2] isis 1
[~PE2-isis-1] quit
# Configure P2.
[~P2] segment-routing ipv6
[*P2-segment-routing-ipv6] encapsulation source-address 4::4
[*P2-segment-routing-ipv6] locator as1 ipv6-prefix 40:: 64 static 32
[*P2-segment-routing-ipv6-locator] opcode ::100 end
[*P2-segment-routing-ipv6-locator] opcode ::200 end no-psp
[*P2-segment-routing-ipv6-locator] quit
[*P2-segment-routing-ipv6] quit
[*P2] isis 1
[*P2-isis-1] segment-routing ipv6 locator as1 auto-sid-disable
[*P2-isis-1] commit
[~P2-isis-1] quit


(2020-10-09)

---------------------------

ArgsLength : 0
AutoSIDPoolID: 8193
Total Locator(s): 1

---------------------------------

Flavor : PSP

Flavor : --
Total SID(s): 2
[~P1] display segment-routing ipv6 local-sid end forwarding
---------------------------------

Flavor : --

Flavor : PSP
Total SID(s): 2
---------------------------------

Flavor : --

Flavor : PSP
Total SID(s): 2
[~P2] display segment-routing ipv6 local-sid end forwarding
---------------------------------

Flavor : --

Flavor : PSP
Total SID(s): 2

(2020-10-09)

# Configure PE1.
[*PE1-segment-routing-ipv6-segment-list-list1] quit
[*PE1-segment-routing-ipv6] segment-list list2
[*PE1-segment-routing-ipv6] srv6-te-policy locator as1
[*PE1-segment-routing-ipv6-policy-policy1-path] quit
[*PE1-segment-routing-ipv6-policy-policy1] quit
# Configure PE2.
[*PE2-segment-routing-ipv6] srv6-te-policy locator as1
[*PE2-segment-routing-ipv6-policy-policy1-path] quit
[*PE2-segment-routing-ipv6-policy-policy1] quit
TunnelId : 8194 Binding SID : 10::900

(2020-10-09)
Candidate-path Count :1

SID :
20::100
30::100
TunnelId : 8195 Binding SID : 10::901

SID :
40::100
30::100
Step 8 Configure an SRv6 mapping policy.

After an SRv6 mapping policy is configured for a device, the device matches the
associated service route with the SRv6 mapping policy that has the same color
value as the route. If such a mapping policy is found, the device dynamically
generates an SRv6 TE Policy group that contains multiple SRv6 TE Policies with the
same endpoint but different color values.
In this example, traffic with DSCP values ranging from 1 to 20 is forwarded
through policy1, and other traffic is forwarded through policy2 by default.
# Configure PE1.
[~PE1-segment-routing-ipv6] mapping-policy color 101
[*PE1-segment-routing-ipv6-mapping-policy-101] match-type srv6-te-policy dscp
[*PE1-segment-routing-ipv6-mapping-policy-101] color 10 match dscp ipv4 1 to 20
[*PE1-segment-routing-ipv6-mapping-policy-101] color 20 match dscp ipv4 default
[*PE1-segment-routing-ipv6-mapping-policy-101] quit
[*PE1-segment-routing-ipv6] commit
# Configure PE2.

(2020-10-09)

[~PE2-segment-routing-ipv6] mapping-policy color 101
[*PE2-segment-routing-ipv6-mapping-policy-101] match-type srv6-te-policy dscp
[*PE2-segment-routing-ipv6-mapping-policy-101] color 10 match dscp ipv4 1 to 20
[*PE2-segment-routing-ipv6-mapping-policy-101] color 20 match dscp ipv4 default
[*PE2-segment-routing-ipv6-mapping-policy-101] quit
[*PE2-segment-routing-ipv6] commit
Step 9 Configure a tunnel policy for VPN traffic import.

# Configure PE1.
[*PE1] bgp 100
[*PE1-bgp] quit
[*PE1-tunnel-policy-p1] tunnel select-seq ipv6 srv6-te-policy-group load-balance-number 1
# Configure PE2.
[*PE2] bgp 100
[*PE2-bgp] quit
[*PE2-tunnel-policy-p1] tunnel select-seq ipv6 srv6-te-policy-group load-balance-number 1

TE Policy.
------------------------------------------------------------------------------


(2020-10-09)
10.2.1.0/24 IBGP 255 0 RD 3::3 SRv6-TE Policy Group

22.22.22.22/32 IBGP 255 0 RD 3::3 SRv6-TE Policy Group
route
------------------------------------------------------------------------------
Summary Count : 1
IndirectID: 0x10000DE Instance:
RelayNextHop: :: Interface: SRv6-TE Policy Group

[~CE1] ping -a 11.11.11.11 22.22.22.22

0.00% packet loss
----End
Configuration Files
#
sysname PE1
#
ipv4-family
tnl-policy p1
#
opcode ::100 end
opcode ::200 end no-psp
segment-list list1
segment-list list2

(2020-10-09)

binding-sid 10::900
segment-list list1
binding-sid 10::901
segment-list list2
mapping-policy color 101
match-type srv6-te-policy dscp
color 10 match dscp ipv4 1 to 20
color 20 match dscp ipv4 default
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0001.00
#
#
#
undo shutdown
ipv6 enable
isis ipv6 enable 1
#
undo shutdown
ip address 10.1.1.1 255.255.255.0
#
undo shutdown
ipv6 enable
isis ipv6 enable 1
#
interface LoopBack1
ipv6 enable
isis ipv6 enable 1
#
bgp 100
router-id 1.1.1.1
#
ipv4-family unicast
#
ipv6-family unicast
#
ipv4-family vpnv4
policy vpn-target
peer 3::3 enable
#
import-route direct
#

(2020-10-09)

#
tunnel-policy p1
tunnel select-seq ipv6 srv6-te-policy-group load-balance-number 1
#
return
#
sysname P1
#
opcode ::100 end
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0002.00
#
#
#
undo shutdown
ipv6 enable
isis ipv6 enable 1
#
undo shutdown
ipv6 enable
isis ipv6 enable 1
#
interface LoopBack1
ipv6 enable
isis ipv6 enable 1
#
return
#
sysname PE2
#
ipv4-family
tnl-policy p1
#
opcode ::100 end
segment-list list1
segment-list list2
binding-sid 30::900

(2020-10-09)

segment-list list1
binding-sid 30::901
segment-list list2
mapping-policy color 101
match-type srv6-te-policy dscp
color 10 match dscp ipv4 1 to 20
color 20 match dscp ipv4 default
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0003.00
#
#
#
undo shutdown
ipv6 enable
isis ipv6 enable 1
#
undo shutdown
ip address 10.2.1.1 255.255.255.0
#
undo shutdown
ipv6 enable
isis ipv6 enable 1
#
interface LoopBack1
ipv6 enable
isis ipv6 enable 1
#
bgp 100
router-id 2.2.2.2
#
ipv4-family unicast
#
ipv6-family unicast
#
ipv4-family vpnv4
policy vpn-target
peer 1::1 enable
#
import-route direct
#
#
tunnel-policy p1

(2020-10-09)
tunnel select-seq ipv6 srv6-te-policy-group load-balance-number 1

#
return
#
sysname P2
#
locator as1 ipv6-prefix 40::1 64 static 32
opcode ::100 end
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0004.00
#
#
#
undo shutdown
ipv6 enable
isis ipv6 enable 1
#
undo shutdown
ipv6 enable
isis ipv6 enable 1
#
interface LoopBack1
ipv6 enable
isis ipv6 enable 1
#
return
#
sysname CE1
#
undo shutdown
ip address 10.1.1.2 255.255.255.0
#
interface LoopBack1
ip address 11.11.11.11 255.255.255.255
#
bgp 65410
#
ipv4-family unicast
network 11.11.11.11 255.255.255.255
#
return
#
sysname CE2
#
undo shutdown
ip address 10.2.1.2 255.255.255.0

(2020-10-09)
#
interface LoopBack1
ip address 22.22.22.22 255.255.255.255
#
bgp 65420
#
ipv4-family unicast
network 22.22.22.22 255.255.255.255
#
return
2.2.23.3 Example for Configuring EVPN L3VPNv4 over SRv6 TE Policy

This section provides an example for configuring an SRv6 TE Policy to carry EVPN
L3VPNv4 services.
bidirectional SRv6 TE Policy be deployed between PE1 and PE2 to carry EVPN
L3VPNv4 services.

NOTE
Precautions

(2020-10-09)
TE Policies.
Policy.
PE2, and the P.
Data Preparation
Procedure
section.

(2020-10-09)
[*HUAWEI] commit
[*PE1] commit

# Configure PE1.
[~PE1] isis 1
[*PE1-isis-1] quit
[*PE1] commit
# Configure the P.
[~P] isis 1
[*P-isis-1] quit
[*P-LoopBack1] quit
[*P] commit
# Configure PE2.
[~PE2] isis 1
[*PE2-isis-1] quit
[*PE2] commit

output on PE1.

(2020-10-09)


--------------------------------------------------------------------------------
0000.0000.0002 GE1/0/0 0000.0000.0002.01 Up 8s L1 64
Total Peer(s): 1
# Configure PE1.
[*PE1] bgp 100
[*PE1-bgp-vpna] advertise l2vpn evpn
[*PE1-bgp] quit
[*PE1] commit
# Configure PE2.
[*PE2] bgp 100
[*PE2-bgp-vpna] advertise l2vpn evpn
[*PE2-bgp] quit
[*PE2] commit
# Configure CE1.
[*CE1] bgp 65410
[*CE1-bgp] quit
[*CE1] commit
# Configure PE1.
[~PE1] bgp 100

(2020-10-09)

[~PE1-bgp] quit
# Configure CE2.
[*CE2] bgp 65420
[*CE2-bgp] quit
[*CE2] commit
# Configure PE2.
[~PE2] bgp 100
[~PE2-bgp] quit


10.11.1.2 4 65410 48 51 0 00:39:40 Established 2

# Configure PE1.
[~PE1] bgp 100
[*PE1-bgp] quit
[*PE1] commit
# Configure PE2.
[~PE2] bgp 100

(2020-10-09)
[*PE2-bgp] quit
[*PE2] commit


2001:DB8:3::3 4 100 49 49 0 00:30:41 Established 2
# Configure PE1.
[*PE1] bgp 100
[*PE1-bgp-vpna] segment-routing ipv6 traffic-engineer best-effort evpn
[*PE1-bgp-vpna] segment-routing ipv6 locator PE1 evpn
[~PE1-bgp] quit
[~PE1] isis 1
[~PE1-isis-1] segment-routing ipv6 locator PE1 auto-sid-disable
[~PE1-isis-1] quit
# Configure the P.
[*P-segment-routing-ipv6] encapsulation source-address 2001:DB8:2::2
[*P-segment-routing-ipv6] locator P ipv6-prefix 2001:DB8:120:: 64 static 32
[*P] isis 1
[*P-isis-1] segment-routing ipv6 locator P auto-sid-disable
[*P-isis-1] commit
[~P-isis-1] quit
# Configure PE2.
[*PE2] bgp 100

(2020-10-09)
[*PE2-bgp-vpna] segment-routing ipv6 traffic-engineer best-effort evpn
[*PE2-bgp-vpna] segment-routing ipv6 locator PE2 evpn
[~PE2-bgp] quit
[~PE2] isis 1
[~PE2-isis-1] quit

---------------------------
LocatorName : PE1 LocatorID : 1

IPv6Prefix : 2001:DB8:100:: PrefixLength: 64
ArgsLength : 0
AutoSIDPoolID: -
AutoSIDBegin : 2001:DB8:100::1:0:0
AutoSIDEnd : 2001:DB8:100:0:FFFF:FFFF:FFFF:FFFF
Total Locator(s): 1

---------------------------------
SID : 2001:DB8:100::10/128 FuncType : End

Flavor : PSP
Total SID(s): 1
---------------------------------

Flavor : PSP
Total SID(s): 1
---------------------------------

Flavor : PSP
LocatorName: P LocatorID: 1
Total SID(s): 1

# Configure PE1.
[*PE1-segment-routing-ipv6-segment-list-list1] index 5 sid ipv6 2001:DB8:120::20

(2020-10-09)

[~PE1-segment-routing-ipv6] srv6-te-policy locator PE1
[*PE1-segment-routing-ipv6] srv6-te policy policy1 endpoint 2001:DB8:3::3 color 101
[*PE1-segment-routing-ipv6-policy-policy1] binding-sid 2001:DB8:100::450
# Configure PE2.

Color : 101 Endpoint : 2001:DB8:3::3
TunnelId :1 Binding SID : 2001:DB8:100::450

Discriminator : 100 Binding SID : 2001:DB8:100::450
SID :
2001:DB8:120::20
2001:DB8:130::30
# Configure PE1.

(2020-10-09)
[*PE1] bgp 100
[*PE1-bgp-af-evpn] peer 2001:DB8:3::3 route-policy p1 import
[*PE1-bgp] quit
[*PE1-vpn-instance-vpna-af-ipv4] tnl-policy p1 evpn
# Configure PE2.
[*PE2] bgp 100
[*PE2-bgp] quit

instance vpna command to check the IPv4 routing table of the VPN instance. The
TE Policy.
------------------------------------------------------------------------------

10.22.1.0/24 IBGP 255 0 RD 2001:DB8:3::3 policy1
22.2.2.2/32 IBGP 255 0 RD 2001:DB8:3::3 policy1
------------------------------------------------------------------------------
Summary Count : 1
NextHop: 2001:DB8:3::3 Neighbour: 2001:DB8:3::3

(2020-10-09)

Label: NULL QoSInfo: 0x0
IndirectID: 0x10000DF Instance:

[~CE1] ping -a 11.1.1.1 22.2.2.2

0.00% packet loss
----End
Configuration Files
#
sysname PE1
#
ipv4-family
tnl-policy p1 evpn
#
opcode ::10 end
srv6-te-policy locator PE1
segment-list list1
index 5 sid ipv6 2001:DB8:120::20
index 10 sid ipv6 2001:DB8:130::30
srv6-te policy policy1 endpoint 2001:DB8:3::3 color 101
binding-sid 2001:DB8:100::450
segment-list list1
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0001.00
#
segment-routing ipv6 locator PE1 auto-sid-disable
#
#
undo shutdown
ip address 10.11.1.1 255.255.255.0
#

(2020-10-09)
undo shutdown
ipv6 enable
isis ipv6 enable 1
#
interface LoopBack1
ipv6 enable
isis ipv6 enable 1
#
bgp 100
router-id 1.1.1.1
#
ipv4-family unicast
#
import-route direct
segment-routing ipv6 traffic-engineer best-effort evpn
#
l2vpn-family evpn
peer 2001:DB8:3::3 route-policy p1 import
#
#
tunnel-policy p1
#
return
#
sysname P
#
locator P ipv6-prefix 2001:DB8:120:: 64 static 32
opcode ::20 end
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0002.00
#
segment-routing ipv6 locator P auto-sid-disable
#
#
undo shutdown
ipv6 enable
isis ipv6 enable 1
#
undo shutdown
ipv6 enable
isis ipv6 enable 1
#

(2020-10-09)
interface LoopBack1
ipv6 enable
isis ipv6 enable 1
#
return
#
sysname PE2
#
ipv4-family
tnl-policy p1 evpn
#
opcode ::30 end
segment-list list1
index 5 sid ipv6 2001:DB8:120::20
index 10 sid ipv6 2001:DB8:100::10
segment-list list1
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0003.00
#
#
#
undo shutdown
ipv6 enable
isis ipv6 enable 1
#
undo shutdown
ip address 10.22.1.1 255.255.255.0
#
interface LoopBack1
ipv6 enable
isis ipv6 enable 1
#
bgp 100
router-id 3.3.3.3
#
ipv4-family unicast
#
import-route direct

(2020-10-09)
#
l2vpn-family evpn
#
#
tunnel-policy p1
#
return

#
sysname CE1
#
undo shutdown
ip address 10.11.1.2 255.255.255.0
#
interface LoopBack1
ip address 11.1.1.1 32
#
bgp 65410
router-id 11.1.1.1
#
ipv4-family unicast
import-route direct
#
return

#
sysname CE2
#
undo shutdown
ip address 10.22.1.2 255.255.255.0
#
interface LoopBack1
ip address 22.2.2.2 32
#
bgp 65420
router-id 22.2.2.2
#
ipv4-family unicast
import-route direct
#
return
2.2.23.4 Example for Configuring EVPN L3VPNv6 over SRv6 TE Policy

L3VPNv6 services.

(2020-10-09)
L3VPNv6 services.

NOTE
Precautions
TE Policies.
Policy.

(2020-10-09)
PE2, and the P.
3. Configure IS-IS SRv6 on PE1, PE2, and the P.
Data Preparation
Procedure
section.
[*HUAWEI] commit
[*PE1] commit

# Configure PE1.
[~PE1] isis 1

(2020-10-09)

[*PE1-isis-1] quit
[*PE1] commit
# Configure the P.
[~P] isis 1
[*P-isis-1] quit
[*P-LoopBack1] quit
[*P] commit
# Configure PE2.
[~PE2] isis 1
[*PE2-isis-1] quit
[*PE2] commit

output on PE1.

--------------------------------------------------------------------------------
0000.0000.0002 GE1/0/0 0000.0000.0002.01 Up 8s L1 64
Total Peer(s): 1
# Configure PE1.

(2020-10-09)
[*PE1] bgp 100
[*PE1-bgp] quit
[*PE1] commit
# Configure PE2.
[*PE2] bgp 100
[*PE2-bgp] quit
[*PE2] commit
# Configure CE1.
[*CE1] bgp 65410
[*CE1-bgp] quit
[*CE1] commit
# Configure PE1.
[~PE1] bgp 100
[~PE1-bgp] quit
# Configure CE2.

(2020-10-09)
[*CE2] bgp 65420
[*CE2-bgp] quit
[*CE2] commit
# Configure PE2.
[~PE2] bgp 100
[~PE2-bgp] quit

2001:DB8:11::2 4 65410 131 132 0 01:51:37 Established 2

# Configure PE1.
[~PE1] bgp 100
[*PE1-bgp] quit
[*PE1] commit
# Configure PE2.
[~PE2] bgp 100
[*PE2-bgp] quit
[*PE2] commit

(2020-10-09)



2001:DB8:3::3 4 100 40 40 0 00:30:41 Established 2
# Configure PE1.
[*PE1] bgp 100
[*PE1-bgp-6-vpna] segment-routing ipv6 traffic-engineer best-effort evpn
[*PE1-bgp-6-vpna] segment-routing ipv6 locator PE1 evpn
[~PE1-bgp] quit
[~PE1] isis 1
[~PE1-isis-1] quit
# Configure the P.
[*P] isis 1
[*P-isis-1] commit
[~P-isis-1] quit
# Configure PE2.
[*PE2] bgp 100
[*PE2-bgp-6-vpna] segment-routing ipv6 traffic-engineer best-effort evpn
[*PE2-bgp-6-vpna] segment-routing ipv6 locator PE2 evpn
[~PE2-bgp] quit
[~PE2] isis 1

(2020-10-09)
[~PE2-isis-1] quit

---------------------------

ArgsLength : 0
AutoSIDPoolID: -
Total Locator(s): 1

---------------------------------

Flavor : PSP
Total SID(s): 1
---------------------------------

Flavor : PSP
Total SID(s): 1
---------------------------------

Flavor : PSP
Total SID(s): 1

# Configure PE1.

(2020-10-09)
# Configure PE2.


SID :
2001:DB8:120::20
2001:DB8:130::30
# Configure PE1.
[*PE1] bgp 100
[*PE1-bgp] quit

(2020-10-09)
# Configure PE2.
[*PE2] bgp 100
[*PE2-bgp] quit
After the configuration is complete, run the display ipv6 routing-table vpn-
TE Policy.
[~PE1] display ipv6 routing-table vpn-instance vpna







(2020-10-09)

[~PE1] display ipv6 routing-table vpn-instance vpna 2001:DB8:222::222 verbose
------------------------------------------------------------------------------
Summary Count : 1

Neighbour : 2001:DB8:3::3 ProcessID : 0
IndirectID : 0x10000DC Instance :

[~CE1] ping ipv6 -a 2001:DB8:111::111 2001:DB8:222::222
PING 2001:DB8:222::222 : 56 data bytes, press CTRL_C to break
Reply from 2001:DB8:222::222
Reply from 2001:DB8:222::222
Reply from 2001:DB8:222::222
Reply from 2001:DB8:222::222
Reply from 2001:DB8:222::222

0.00% packet loss
----End
Configuration Files
#
sysname PE1
#
ipv6-family
tnl-policy p1 evpn
#
opcode ::10 end
segment-list list1
index 5 sid ipv6 2001:DB8:120::20
index 10 sid ipv6 2001:DB8:130::30

(2020-10-09)
segment-list list1
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0001.00
#
#
#
undo shutdown
ipv6 enable
#
undo shutdown
ipv6 enable
isis ipv6 enable 1
#
interface LoopBack1
ipv6 enable
isis ipv6 enable 1
#
bgp 100
router-id 1.1.1.1
#
ipv4-family unicast
#
import-route direct
#
l2vpn-family evpn
#
#
tunnel-policy p1
#
return
sysname P
#
opcode ::20 end
#
isis 1
is-level level-1
cost-style wide

(2020-10-09)
network-entity 10.0000.0000.0002.00
#
#
#
undo shutdown
ipv6 enable
isis ipv6 enable 1
#
undo shutdown
ipv6 enable
isis ipv6 enable 1
#
interface LoopBack1
ipv6 enable
isis ipv6 enable 1
#
return
#
sysname PE2
#
ipv6-family
tnl-policy p1 evpn
#
opcode ::30 end
segment-list list1
index 5 sid ipv6 2001:DB8:120::20
index 10 sid ipv6 2001:DB8:100::10
segment-list list1
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0003.00
#
#
#
undo shutdown
ipv6 enable
isis ipv6 enable 1
#
undo shutdown
ipv6 enable
#

(2020-10-09)
interface LoopBack1
ipv6 enable
isis ipv6 enable 1
#
bgp 100
router-id 3.3.3.3
#
ipv4-family unicast
#
import-route direct
#
l2vpn-family evpn
#
#
tunnel-policy p1
#
return
sysname CE1
#
undo shutdown
ipv6 enable
#
interface LoopBack1
ipv6 enable
ipv6 address 2001:DB8:111::111/128
#
bgp 65410
router-id 10.11.1.1
#
ipv4-family unicast
#
ipv6-family unicast
import-route direct
#
return
sysname CE2
#
undo shutdown
ipv6 enable
#
interface LoopBack1
ipv6 enable

(2020-10-09)
ipv6 address 2001:DB8:222::222/128

#
bgp 65420
router-id 10.22.2.2
#
ipv4-family unicast
#
ipv6-family unicast
import-route direct
#
return
2.2.23.5 Example for Configuring EVPN VPWS over SRv6 TE Policy (Manual
Configuration)
VPWSs.
VPWSs.
Figure 2-120 EVPN VPWS over SRv6 TE Policy networking

NOTE

(2020-10-09)
PE2, and the P.
Data Preparation
Procedure
section.
[*HUAWEI] commit
[*PE1] commit
address needs to be an IPv4 address.
# Configure PE1.
[~PE1] isis 1
[*PE1-isis-1] quit

(2020-10-09)

[*PE1] commit
# Configure the P.
[~P] isis 1
[*P-isis-1] quit
[*P-LoopBack1] quit
[*P] commit
# Configure PE2.
[~PE2] isis 1
[*PE2-isis-1] quit
[*PE2] commit

output on PE1.

--------------------------------------------------------------------------------
0000.0000.0002 GE1/0/0 0000.0000.0002.01 Up 8s L1 64
Total Peer(s): 1
Step 3 Configure EVPN VPWS and EVPL instances on each PE and bind the EVPL instance
to an access-side sub-interface. In addition, configure a VLAN on each CE.
# Configure PE1.

(2020-10-09)

[*PE1-GigabitEthernet 2/0/0.1] evpl instance 1
[*PE1] commit
# Configure PE2.
[*PE2] commit
# Configure CE1.
<CE1> system-view
[~CE1] vlan 1
[*CE1-vlan1] quit
# Configure CE2.
<CE2> system-view
[~CE2] vlan 1
[*CE2-vlan1] quit

# Configure PE1.
[~PE1] bgp 100
[*PE1-bgp] quit
[*PE1] commit
# Configure PE2.
[~PE2] bgp 100

(2020-10-09)

[*PE2-bgp] quit
[*PE2] commit


2001:DB8:3::3 4 100 40 40 0 00:30:41 Established 2
# Configure PE1.
[*PE1] bgp 100
[*PE1-bgp] quit
[*PE1-vpws-evpn-instance-evrf1] segment-routing ipv6 traffic-engineer best-effort
[*PE1] commit
[~PE1] isis 1
[~PE1-isis-1] quit
# Configure the P.
[~P] isis 1
[~P-isis-1] segment-routing ipv6 locator P auto-sid-disable
[*P-isis-1] commit
[~P-isis-1] quit
# Configure PE2.

(2020-10-09)

[*PE2] bgp 100
[*PE2-bgp] quit
[*PE2-vpws-evpn-instance-evrf1] segment-routing ipv6 traffic-engineer best-effort
[*PE2] commit
[~PE2] isis 1
[~PE2-isis-1] quit


---------------------------

ArgsLength : 0
AutoSIDPoolID: -
Total Locator(s): 1

---------------------------------

Flavor : PSP
Total SID(s): 1
---------------------------------

Flavor : PSP
Total SID(s): 1
---------------------------------

Flavor : PSP
Total SID(s): 1

(2020-10-09)

# Configure PE1.
# Configure PE2.

SID :
2001:DB8:120::20
2001:DB8:130::30

(2020-10-09)

# Configure PE1.
[*PE1] bgp 100
[*PE1-bgp] quit
[*PE1-vpws-evpn-instance-evrf] tnl-policy p1
[*PE1-vpws-evpn-instance-evrf] commit
[~PE1-vpws-evpn-instance-evrf] quit
# Configure PE2.
[*PE2] bgp 100
[*PE2-bgp] quit
[*PE2-vpws-evpn-instance-evrf] tnl-policy p1
[*PE2-vpws-evpn-instance-evrf] commit
[~PE2-vpws-evpn-instance-evrf] quit

Run the display bgp evpn evpl command on each PE. The command output
shows the EVPL status.
[~PE1] display bgp evpn evpl
Total EVPLs: 1 1 Up 0 Down
EVPL ID : 1
State : up
Evpl Type : srv6-mode
Interface : GigabitEthernet2/0/0.1
Local MTU : 1500
Local Control Word : false
Local Redundancy Mode : all-active
Local DF State : primary
Local ESI : 0000.0000.0000.0000.0000
Remote Redundancy Mode : all-active
Remote Primary DF Number : 1
Remote Backup DF Number : 0
Remote None DF Number : 0
Peer IP : 2001:DB8:3::3
Origin Nexthop IP : 2001:DB8:3::3
DF State : primary
Eline Role : primary
Remote MTU : 1500
Remote Control Word : false
Remote ESI : 0000.0000.0000.0000.0000

(2020-10-09)
Tunnel info : 1 tunnels

NO.0 Tunnel Type : srv6te-policy, Tunnel ID : 0x000000003400000001
Last Interface UP Timestamp : 2019-8-14 3:21:34:196
Last Designated Primary Timestamp : 2019-8-14 3:23:45:839
Last Designated Backup Timestamp : --
output shows the EVPN route sent from the peer end.



*> 0000.0000.0000.0000.0000:100 127.0.0.1
*>i 0000.0000.0000.0000.0000:200 2001:DB8:3::3
*> 0000.0000.0000.0000.0000:100 127.0.0.1
*>i 0000.0000.0000.0000.0000:200 2001:DB8:3::3
command output shows the EVPN routes sent from the peer end.

From: 2001:DB8:3::3 (3.3.3.3)
Ext-Community: RT <1 : 1>, Color <0 : 101>, EVPN L2 Attributes <MTU:1500 C:0 P:1 B:
0>
Prefix-sid: 2001:DB8:130::1:0:5A
20
Remote-Cross route

(2020-10-09)

From: 2001:DB8:3::3 (3.3.3.3)
Relay Tunnel Out-Interface: policy1(srv6tepolicy)
Ext-Community: RT <1 : 1>, Color <0 : 101>, EVPN L2 Attributes <MTU:1500 C:0 P:1 B:
0>
Prefix-sid: 2001:DB8:130::1:0:5A
AS-path Nil, origin incomplete, localpref 100, pref-val 0, valid, internal, best, select, pre
255
----End
Configuration Files
sysname PE1
#
tnl-policy p1
#
#
opcode ::10 end
segment-list list1
index 5 sid ipv6 2001:DB8:120::20
index 10 sid ipv6 2001:DB8:130::30
segment-list list1
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0001.00
#
#
#
undo shutdown
#
evpl instance 1
#
undo shutdown
ipv6 enable
isis ipv6 enable 1

(2020-10-09)
#
interface LoopBack1
ipv6 enable
ip address 1.1.1.1 255.255.255.255
isis ipv6 enable 1
#
bgp 100
router-id 1.1.1.1
#
ipv4-family unicast
#
l2vpn-family evpn
#
#
tunnel-policy p1
#
#
return
sysname P
#
opcode ::20 end
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0002.00
#
#
#
undo shutdown
ipv6 enable
isis ipv6 enable 1
#
undo shutdown
ipv6 enable
isis ipv6 enable 1
#
interface LoopBack1
ipv6 enable
isis ipv6 enable 1
#
return
sysname PE2
#

(2020-10-09)

tnl-policy p1
#
#
opcode ::30 end
segment-list list1
index 5 sid ipv6 2001:DB8:120::20
index 10 sid ipv6 2001:DB8:100::10
segment-list list1
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0003.00
#
#
#
undo shutdown
#
evpl instance 1
#
undo shutdown
ipv6 enable
isis ipv6 enable 1
#
interface LoopBack1
ipv6 enable
ip address 3.3.3.3 255.255.255.255
isis ipv6 enable 1
#
bgp 100
router-id 3.3.3.3
#
ipv4-family unicast
#
l2vpn-family evpn
#

(2020-10-09)
#
tunnel-policy p1
#
#
return

sysname CE1
#
vlan batch 1
#
portswitch
undo shutdown
port default vlan 1
#
return

sysname CE2
#
vlan batch 1
#
portswitch
undo shutdown
port default vlan 1
#
return
2.2.23.6 Example for Configuring EVPN VPLS over SRv6 TE Policy (Manual
Configuration)
E-LAN services.
Context
bidirectional SRv6 TE Policy be deployed between PE1 and PE2 to carry EVPN E-
LAN services.
Figure 2-121 EVPN VPLS over SRv6 TE Policy networking

NOTE
Interface 1, interface 2, sub-interface 1.1, and sub-interface 2.1 in this example represent GE
1/0/0, GE 2/0/0, GE 1/0/0.1, and GE 2/0/0.1, respectively.

(2020-10-09)
PE2, and the P.
3. Configure an EVPN instance in BD mode on each PE and bind the EVPN
Data Preparation

● BD ID: 100
● Names of locators on PE1: PE1_ARG and PE1; names of locators on PE2:
PE2_ARG and PE2; dynamically generated opcodes for End.DT2U and
End.DT2M SIDs
● Length of the locators PE1_ARG and PE2_ARG: 10 (as specified in the args
parameter)
Procedure
section.

(2020-10-09)
[*HUAWEI] commit
[*PE1] commit
address needs to be an IPv4 address.
# Configure PE1.
[~PE1] isis 1
[*PE1-isis-1] quit
# Configure the P.
[~P] isis 1
[*P-isis-1] quit
[~P-LoopBack1] quit
# Configure PE2.
[~PE2] isis 1
[*PE2-isis-1] quit

(2020-10-09)

output on PE1.

--------------------------------------------------------------------------------
0000.0000.0002 GE1/0/0 0000.0000.0002.01 Up 8s L1 64
Total Peer(s): 1
-----------------------------

--------------------------------

--------------------------------------------------------------------------------
2001:DB8:1::/64 GE1/0/0 Direct 10 D/-/L/-
2001:DB8:2::/64 GE1/0/0 FE80::3A5D:67FF:FE31:307 10 A/-/-/-
2001:DB8:3::/64 GE1/0/0 FE80::3A5D:67FF:FE31:307 20 A/-/-/-
2001:DB8:10::/64 GE1/0/0 Direct 20 D/-/L/-
2001:DB8:20::/64 GE1/0/0 FE80::3A5D:67FF:FE31:307 20 A/-/-/-
Step 3 Configure an EVPN instance in BD mode on each PE and bind the EVPN instance
# Configure PE1.
[*PE1-bd100] quit
[*PE1] commit
# Configure PE2.
[*PE2-bd100] quit

(2020-10-09)

[*PE2] commit
# Configure PE1.
[~PE1] bgp 100
[*PE1-bgp] quit
[*PE1] commit
# Configure PE2.
[~PE2] bgp 100
[*PE2-bgp] quit
[*PE2] commit


PrefRcv
2001:DB8:3::3 4 100 31 34 0 00:18:39 Established 1
# Configure PE1.
[*PE1-segment-routing-ipv6] locator PE1_ARG ipv6-prefix 2001:DB8:12:: 64 static 32 args 10
[*PE1] isis 1
[*PE1-isis-1] segment-routing ipv6 locator PE1 auto-sid-disable
[*PE1-isis-1] quit
[*PE1-evpn-instance-evrf1] segment-routing ipv6 traffic-engineer best-effort

(2020-10-09)
[*PE1] commit
# Configure the P.
[*P] isis 1
[*P-isis-1] commit
[~P-isis-1] quit
# Configure PE2.
[*PE2-segment-routing-ipv6] locator PE2_ARG ipv6-prefix 2001:DB8:22:: 64 static 32 args 10
[*PE2] isis 1
[*PE2-isis-1] segment-routing ipv6 locator PE2 auto-sid-disable
[*PE2-isis-1] quit
[*PE2-evpn-instance-evrf1] segment-routing ipv6 traffic-engineer best-effort
[*PE2] commit

---------------------------

ArgsLength : 0
AutoSIDPoolID: 8195
LocatorName : PE1_ARG LocatorID : 6

ArgsLength : 10
AutoSIDPoolID: 8196
AutoSIDEnd : 2001:DB8:12:0:FFFF:FFFF:FFFF:FC00
Total Locator(s): 2

---------------------------------

(2020-10-09)

Flavor : PSP
Total SID(s): 1
---------------------------------

Flavor : PSP
Total SID(s): 1
---------------------------------

Flavor : PSP
Total SID(s): 1

# Configure PE1.
# Configure PE2.

(2020-10-09)

TunnelId : 8193 Binding SID : 2001:DB8:11::450

Template ID :0
Segment-List : list1 Path Verification : Disable
SID :
2001:DB8:120::10
2001:DB8:21::10

# Configure PE1.
[*PE1] bgp 100
[*PE1-bgp] quit
[*PE1-evpn-instance-evrf] tnl-policy p1
[*PE1-evpn-instance-evrf] commit
[~PE1-evpn-instance-evrf] quit
# Configure PE2.
[*PE2] bgp 100
[*PE2-bgp] quit
[*PE2-evpn-instance-evrf] tnl-policy p1
[*PE2-evpn-instance-evrf] commit
[~PE2-evpn-instance-evrf] quit
Step 8 Configure CEs to access PEs.

# Configure CE1.

(2020-10-09)
[*CE1] interface gigabitethernet1/0/0.1

[*CE1] commit
# Configure CE2.
[*CE2] interface gigabitethernet1/0/0.1
[*CE2] commit

dt2m } forwarding command on each PE to check information about the SRv6

--------------------------------------
SID : 2001:DB8:12::400:0:0/118 FuncType : End.DT2M

LocatorName : PE1_ARG LocatorID: 6
Total SID(s): 1

--------------------------------------
SID : 2001:DB8:11::1:0:5C/128 FuncType : End.DT2U

LocatorName : PE1 LocatorID: 5
Total SID(s): 1


*>i 0:48:38c2-6721-0300:0:0.0.0.0 2001:DB8:3::3
*> 0:48:38c2-6761-0300:0:0.0.0.0 0.0.0.0
*> 0:48:38c2-6721-0300:0:0.0.0.0 0.0.0.0

(2020-10-09)
*i 2001:DB8:3::3
*> 0:48:38c2-6761-0300:0:0.0.0.0 0.0.0.0

*> 0:32:1.1.1.1 127.0.0.1
*>i 0:32:3.3.3.3 2001:DB8:3::3
*> 0:32:1.1.1.1 127.0.0.1
*>i 0:32:3.3.3.3 2001:DB8:3::3
[~PE1] display bgp evpn all routing-table inclusive-route 0:32:3.3.3.3

BGP routing table entry information of 0:32:3.3.3.3:
From: 2001:DB8:3::3 (3.3.3.3)
Prefix-sid: 2001:DB8:22::400:0:7800
10
PMSI: Flags 0, Ingress Replication, Label 0:0:0(3), Tunnel Identifier:3.3.3.3
Route Type: 3 (Inclusive Multicast Route)
Ethernet Tag ID: 0, Originator IP:3.3.3.3/32
BGP routing table entry information of 0:32:3.3.3.3:
Remote-Cross route
From: 2001:DB8:3::3 (3.3.3.3)
Relay Tunnel Out-Interface: policy1(srv6tepolicy)
Prefix-sid: 2001:DB8:22::400:0:7800
AS-path Nil, origin incomplete, localpref 100, pref-val 0, valid, internal, best, select, pre
255
PMSI: Flags 0, Ingress Replication, Label 0:0:0(3), Tunnel Identifier:3.3.3.3
Route Type: 3 (Inclusive Multicast Route)
Ethernet Tag ID: 0, Originator IP:3.3.3.3/32
Run the ping command on the CEs. The command output shows that the CEs
belonging to the same VPN instance can ping each other. For example:
[~CE1] ping 10.1.1.2

(2020-10-09)


0.00% packet loss
----End
Configuration Files
#
sysname CE1
#
undo shutdown
#
undo shutdown
vlan-type dot1q 1
ip address 10.1.1.1 255.255.255.0
#
return

#
sysname PE1
#
tnl-policy p1
#
bridge-domain 100
#
opcode ::10 end
locator PE1_ARG ipv6-prefix 2001:DB8:12:: 64 static 32 args 10
segment-list list1
index 5 sid ipv6 2001:DB8:120::10
index 10 sid ipv6 2001:DB8:21::10
segment-list list1
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0001.00
#
#
#
undo shutdown

(2020-10-09)
ipv6 enable
isis ipv6 enable 1
#
undo shutdown
#
rewrite pop single
bridge-domain 100
#
interface LoopBack1
ipv6 enable
ip address 1.1.1.1 255.255.255.255
isis ipv6 enable 1
#
bgp 100
router-id 1.1.1.1
#
ipv4-family unicast
#
l2vpn-family evpn
policy vpn-target
#
#
tunnel-policy p1
#
#
return
#
sysname P
#
opcode ::10 end
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0002.00
#
#
#
undo shutdown
ipv6 enable
isis ipv6 enable 1
#
undo shutdown
ipv6 enable

(2020-10-09)
isis ipv6 enable 1

#
interface LoopBack1
ipv6 enable
ip address 2.2.2.2 255.255.255.255
isis ipv6 enable 1
#
return
#
sysname PE2
#
tnl-policy p1
#
bridge-domain 100
#
opcode ::10 end
locator PE2_ARG ipv6-prefix 2001:DB8:22:: 64 static 32 args 10
segment-list list1
index 5 sid ipv6 2001:DB8:120::10
index 10 sid ipv6 2001:DB8:11::10
segment-list list1
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0003.00
#
#
#
undo shutdown
ipv6 enable
isis ipv6 enable 1
#
undo shutdown
#
rewrite pop single
bridge-domain 100
#
interface LoopBack1
ipv6 enable
ip address 3.3.3.3 255.255.255.255
isis ipv6 enable 1
#
bgp 100

(2020-10-09)
router-id 3.3.3.3
#
ipv4-family unicast
#
l2vpn-family evpn
policy vpn-target
#
#
tunnel-policy p1
#
#
return

#
sysname CE2
#
undo shutdown
#
undo shutdown
vlan-type dot1q 1
ip address 10.1.1.2 255.255.255.0
#
return
2.2.23.7 Example for Configuring L3VPNv4 over SRv6 TE Policy Egress

Protection
This section provides an example for configuring egress protection when an SRv6
TE Policy is used to carry L3VPNv4 services.
to carry L3VPNv4 services. In this example, PE2 is the egress of the SRv6 TE Policy,
Figure 2-122 Networking for L3VPNv4 over SRv6 TE Policy egress protection
NOTE

(2020-10-09)
PE1, the P, PE2, and PE3.
PE2, PE3, and the P.
6. Enable IS-IS SRv6 on PE1, the P, PE2, and PE3, and configure static End SIDs
for SRv6 TE Policy configuration.
9. Configure egress protection on PE3.
10. Configure SRv6 TI-LFA FRR and microloop avoidance on the PEs and P.
Data Preparation
● IPv6 address of each interface on PE1, the P, PE2, and PE3

● IS-IS process ID of PE1, the P, PE2, and PE3
● IS-IS level of PE1, the P, PE2, and PE3
● VPN instance name, RD, and RT on PE1, PE2, and PE3
Procedure

(2020-10-09)
# Configure PE1. The configurations of the P, PE2, and PE3 are similar to the
section.
[*HUAWEI] commit
[*PE1] commit

# Configure PE1.
[~PE1] isis 1
[*PE1-isis-1] quit
# Configure the P.
[~P] isis 1
[*P-isis-1] quit
[~P-LoopBack1] quit
# Configure PE2.
[~PE2] isis 1
[*PE2-isis-1] quit

(2020-10-09)

# Configure PE3.
[~PE3] isis 1
[*PE3-isis-1] quit

output on PE1.

--------------------------------------------------------------------------------
0000.0000.0002* GE1/0/0 0000.0000.0004.01 Up 7s L1 64
Total Peer(s): 1
-----------------------------

--------------------------------

--------------------------------------------------------------------------------
2::/64 GE1/0/0 FE80::3AC2:67FF:FE31:300 10 A/-/-/-
3::/64 GE1/0/0 FE80::3AC2:67FF:FE41:307 10 A/-/-/-
4::/64 GE1/0/0 FE80::3AC2:67FF:FE61:302 10 A/-/-/-
2001::/96 GE1/0/0 Direct 10 D/-/L/-
2002::/96 GE1/0/0 FE80::3AC2:67FF:FE31:300 20 A/-/-/-
2003::/96 GE1/0/0 FE80::3AC2:67FF:FE31:300 20 A/-/-/-
2004::/96 GE1/0/0 FE80::3AC2:67FF:FE41:307 20 A/-/-/-
that PE.
# Configure PE1.

(2020-10-09)

[*PE1] commit
# Configure PE2.
[*PE2] commit
# Configure PE3.
[*PE3] commit


NOTE
may fail.
# Configure CE1.
[*CE1] bgp 65410
[*CE1-bgp] network 11.11.11.11 32
[*CE1-bgp] quit
[*CE1] commit

(2020-10-09)
# Configure PE1.
[~PE1] bgp 100
[~PE1-bgp] quit
# Configure CE2.
[*CE2] bgp 65420
[*CE2-bgp] network 22.22.22.22 32
[*CE2-bgp] quit
[*CE2] commit
# Configure PE2.
[~PE2] bgp 100
[~PE2-bgp] quit
# Configure PE3.
[~PE3] bgp 100
[~PE3-bgp] quit



10.1.1.2 4 65410 463 481 0 06:43:32 Established 2

# Configure PE1.
[~PE1] bgp 100

(2020-10-09)

[~PE1-bgp] quit
# Configure PE2.
[~PE2] bgp 100
[~PE2-bgp] quit
# Configure PE3.
[~PE3] bgp 100
[~PE3-bgp] quit


3::3 4 100 466 459 0 06:36:07 Established 3
4::4 4 100 421 419 0 05:59:33 Established 3

10.1.1.2 4 65410 469 487 0 06:48:40 Established 2
# Configure PE1.

(2020-10-09)

[*PE1] bgp 100
[~PE1-bgp] quit
[~PE1] isis 1
[~PE1-isis-1] quit
# Configure the P.
[*P-segment-routing-ipv6] encapsulation source-address 2::2
[*P-segment-routing-ipv6] locator as1 ipv6-prefix 20:: 64 static 32
[*P] isis 1
[*P-isis-1] segment-routing ipv6 locator as1 auto-sid-disable
[*P-isis-1] commit
[~P-isis-1] quit
# Configure PE2.
[*PE2] bgp 100
[~PE2-bgp] quit
[~PE2] isis 1
[~PE2-isis-1] quit
# Configure PE3.
[*PE3] bgp 100

(2020-10-09)

[~PE3-bgp] quit
[~PE3] isis 1
[~PE3-isis-1] quit

---------------------------

ArgsLength : 0
AutoSIDPoolID: 8200
Total Locator(s): 1

---------------------------------

Flavor : PSP
Total SID(s): 1
---------------------------------

Flavor : PSP
Total SID(s): 1
---------------------------------

Flavor : PSP
Total SID(s): 1

# Configure PE1.

(2020-10-09)
# Configure PE2.


SID :
20::1
30::1
# Configure PE1.
[*PE1] bgp 100

(2020-10-09)

[*PE1-bgp] quit
# Configure PE2.
[*PE2] bgp 100
[*PE2-bgp] quit

TE Policy.
------------------------------------------------------------------------------

10.2.1.0/24 IBGP 255 0 RD 3::3 policy1
10.3.1.0/24 IBGP 255 0 RD 40::1:0:0 SRv6 BE
22.22.22.22/32 IBGP 255 0 RD 3::3 policy1
------------------------------------------------------------------------------
Summary Count : 1

(2020-10-09)

Step 9 Configure egress protection on PE3.

# Configure PE3.
[~PE3-segment-routing-ipv6] locator as1 ipv6-prefix 40:: 64 static 32
[*PE3-segment-routing-ipv6-locator] opcode ::999 end-m mirror-locator 30:: 64
[*PE3] commit
# Configure the P.
[~P] isis 1
[~P-isis-1] ipv6 frr
[*P-isis-1-ipv6-frr] loop-free-alternate level-1
[*P-isis-1-ipv6-frr] quit
[*P-isis-1] quit
[*P] commit
sid end-m forwarding command to check SRv6 local SID table information.
[~PE3] display segment-routing ipv6 local-sid end-m forwarding
My Local-SID End.M Forwarding Table

---------------------------------
SID : 40::999/128 FuncType : End.M

Flavor : --
MirrorLocatorNumber: 1
MirrorLocator: 30::1/64
Total SID(s): 1
# Display mirror FRR entries on the P.

[~P] display isis route ipv6 30:: 64 verbose
-----------------------------
--------------------------------
IPV6 Dest : 30::/64 Cost : 10 Flags: A/-/-/-

Admin Tag : - Src Count : 2 Priority: Low
FE80::3A92:6CFF:FE41:300 GE2/0/0 0x00000007
SRv6 MIRROR FRR:
Interface : GE3/0/0
NextHop : FE80::3A92:6CFF:FE61:302 IID : 0x0100009c
Backup Sid Stack(Top->Bottom): {40::999}
Step 10 Configure SRv6 TI-LFA FRR and microloop avoidance on the PEs and P.
# Configure PE1.
[~PE1] isis 1
[~PE1-isis-1] avoid-microloop frr-protected
[*PE1-isis-1] ipv6 avoid-microloop segment-routing
[*PE1-isis-1] ipv6 frr

(2020-10-09)
[*PE1-isis-1-ipv6-frr] loop-free-alternate level-1

[*PE1-isis-1-ipv6-frr] ti-lfa level-1
[*PE1-isis-1-ipv6-frr] quit
[*PE1-isis-1] quit
[*PE1] commit
# Configure PE2.
[~PE2] isis 1
[*PE2-isis-1] quit
[*PE2] commit
# Configure PE3.
[~PE3] isis 1
[*PE3-isis-1] quit
[*PE3] commit
# Configure the P.
[~P] isis 1
[~P-isis-1] avoid-microloop frr-protected
[*P-isis-1] ipv6 avoid-microloop segment-routing
[*P-isis-1] ipv6 frr
[*P-isis-1-ipv6-frr] ti-lfa level-1
[*P-isis-1-ipv6-frr] quit
[*P-isis-1] quit
[*P] commit

[~CE1] ping -a 11.11.11.11 22.22.22.22

0.00% packet loss
Disable an interface on PE2 to simulate a link fault.

[~PE2-GigabitEthernet1/0/0] shutdown
Run the ping command again. The command output shows that CEs belonging to
the same VPN can still ping each other. For example:

(2020-10-09)
[~CE1] ping -a 11.11.11.11 22.22.22.22


0.00% packet loss
The preceding verification results indicate that PE3 can provide egress protection
for the SRv6 TE Policy between PE1 and PE2.
----End
Configuration Files
#
sysname PE1
#
ipv4-family
tnl-policy p1
#
opcode ::1 end
segment-list list1
binding-sid 10::100
segment-list list1
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0001.00
#
ipv6 avoid-microloop segment-routing
ipv6 frr
ti-lfa level-1
#
#
undo shutdown
ip address 10.1.1.1 255.255.255.0
#
undo shutdown
ipv6 enable

(2020-10-09)
isis ipv6 enable 1

#
interface LoopBack1
ipv6 enable
isis ipv6 enable 1
#
bgp 100
router-id 1.1.1.1
#
ipv4-family unicast
#
ipv6-family unicast
#
ipv4-family vpnv4
policy vpn-target
peer 3::3 enable
peer 4::4 enable
#
import-route direct
#
#
tunnel-policy p1
#
return
#
sysname P
#
opcode ::1 end
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0002.00
#
ipv6 frr
ti-lfa level-1
#
#
undo shutdown
ipv6 enable
isis ipv6 enable 1

(2020-10-09)
#
undo shutdown
ipv6 enable
isis ipv6 enable 1
#
undo shutdown
ipv6 enable
isis ipv6 enable 1
#
interface LoopBack1
ipv6 enable
isis ipv6 enable 1
#
return
#
sysname PE2
#
ipv4-family
tnl-policy p1
#
opcode ::1 end
segment-list list1
binding-sid 30::300
segment-list list1
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0003.00
#
ipv6 frr
ti-lfa level-1
#
#
undo shutdown
ipv6 enable
isis ipv6 enable 1
#
undo shutdown
ip address 10.2.1.1 255.255.255.0
#

(2020-10-09)
undo shutdown
ipv6 enable
isis ipv6 enable 1
#
interface LoopBack1
ipv6 enable
isis ipv6 enable 1
#
bgp 100
router-id 2.2.2.2
#
ipv4-family unicast
#
ipv6-family unicast
#
ipv4-family vpnv4
policy vpn-target
peer 1::1 enable
peer 4::4 enable
#
import-route direct
#
#
tunnel-policy p1
#
return

#
sysname PE3
#
ipv4-family
#
opcode ::1 end
opcode ::999 end-m mirror-locator 30:: 64
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0004.00
#

(2020-10-09)
ipv6 frr
ti-lfa level-1
#
#
undo shutdown
ipv6 enable
isis ipv6 enable 1
#
undo shutdown
ip address 10.3.1.1 255.255.255.0
#
undo shutdown
ipv6 enable
isis ipv6 enable 1
#
interface LoopBack1
ipv6 enable
isis ipv6 enable 1
#
bgp 100
router-id 3.3.3.3
#
ipv4-family unicast
#
ipv6-family unicast
#
ipv4-family vpnv4
policy vpn-target
peer 1::1 enable
peer 3::3 enable
#
import-route direct
#
return
#
sysname CE1
#
undo shutdown
ip address 10.1.1.2 255.255.255.0
#
interface LoopBack1
ip address 11.11.11.11 255.255.255.255
#
bgp 65410
#
ipv4-family unicast

(2020-10-09)
network 11.11.11.11 255.255.255.255

#
return

#
sysname CE2
#
undo shutdown
ip address 10.2.1.2 255.255.255.0
#
undo shutdown
ip address 10.3.1.2 255.255.255.0
#
interface LoopBack1
ip address 22.22.22.22 255.255.255.255
#
bgp 65420
#
ipv4-family unicast
network 22.22.22.22 255.255.255.255
#
return
2.2.23.8 Example for Configuring Inter-AS L3VPNv4 over SRv6 TE Policy

This section provides an example for configuring an inter-AS SRv6 TE Policy to
carry L3VPNv4 services.
Context
● PE1 and ASBR1 belong to AS 100, and PE2 and ASBR2 belong to AS 200.
Intra-AS IPv6 connectivity needs to be achieved for AS 100 and AS 200
through IS-IS.
● PE1 and ASBR1 belong to IS-IS process 1, and PE2 and ASBR2 belong to IS-IS
process 10. PE1, ASBR1, PE2, and ASBR2 are all Level-1 devices.
It is required that a bidirectional inter-AS SRv6 TE Policy be deployed between PE1
and PE2 to carry L3VPNv4 services.
Figure 2-123 Inter-AS L3VPNv4 over SRv6 TE Policy networking

NOTE

(2020-10-09)
PE1, PE2, ASBR1, and ASBR2.
PE2, ASBR1, and ASBR2.
5. Configure IS-IS to advertise SRv6 locator routes on the PEs and allocate intra-
AS static End.X SIDs to the PEs.
6. Configure BGP EPEv6 on ASBR1 and ASBR2 and allocate inter-AS static End.X
SIDs.
7. Establish an MP-EBGP peer relationship between the PEs, and configure the
PEs to exchange BGP VPNv4 routes carrying SIDs through this peer
relationship.
8. Deploy an SRv6 TE Policy between PE1 and PE2.
Precautions
When configuring inter-AS L3VPNv4 over SRv6 TE Policy, note the following:
● When configuring BGP EPEv6, you need to enable the BGP-LS address family
peer relationship so that BGP EPEv6 can take effect.
Data Preparation
● AS numbers of the PEs and ASBRs

(2020-10-09)
● IS-IS process IDs, levels, and network entity names of the PEs and ASBRs
Procedure
# Configure PE1. The configurations of PE2, ASBR1, and ASBR2 are similar to the
section.
[*HUAWEI] commit
[*PE1] commit

# Configure PE1.
[~PE1] isis 1
[*PE1-isis-1] quit
# Configure ASBR1.
[~ASBR1] isis 1
# Configure ASBR2.
[~ASBR2] isis 10

(2020-10-09)

# Configure PE2.
[~PE2] isis 10
[*PE2-isis-10] quit

output on PE1.

--------------------------------------------------------------------------------
0000.0000.0002 GE1/0/0 0000.0000.0002.01 Up 8s L1 64
Total Peer(s): 1
that PE.
# Configure PE1.
[*PE1] commit
# Configure PE2.

(2020-10-09)
[*PE2] commit
NOTE
# Configure CE1.
[*CE1] bgp 65410
[*CE1-bgp] network 11.11.11.11 32
[*CE1-bgp] quit
[*CE1] commit
# Configure PE1.
[~PE1] bgp 100
[~PE1-bgp] quit
# Configure CE2.
[*CE2] bgp 65420
[*CE2-bgp] network 22.22.22.22 32
[*CE2-bgp] quit
[*CE2] commit
# Configure PE2.
[~PE2] bgp 200
[~PE2-bgp] quit

(2020-10-09)


10.1.1.2 4 65410 11 9 0 00:06:37 Established 1
Step 5 Configure IS-IS to advertise SRv6 locator routes on the PEs and allocate intra-AS
static End.X SIDs to the PEs.
# Configure PE1.
[*PE1-segment-routing-ipv6-locator] opcode ::100 end-x interface GigabitEthernet1/0/0 nexthop 2001::2
no-psp
[*PE1] isis 1
[*PE1-isis-1] segment-routing ipv6 locator as1 auto-sid-disable
[~PE1-isis-1] quit
# Configure PE2.
[*PE2-segment-routing-ipv6-locator] opcode ::200 end-x interface GigabitEthernet1/0/0 nexthop 2002::1
no-psp
[*PE2] isis 10
[*PE2-isis-10] segment-routing ipv6 locator as1 auto-sid-disable
[~PE2-isis-10] quit

---------------------------

ArgsLength : 0
AutoSIDPoolID: 8202
Total Locator(s): 1
Run the display segment-routing ipv6 local-sid end-x forwarding command to

check information about the SRv6 local SID table. The following example uses the

(2020-10-09)
[~PE1] display segment-routing ipv6 local-sid end-x forwarding
My Local-SID End.X Forwarding Table

-----------------------------------
SID : 10::100/128 FuncType : End.X

Flavor : --
NextHop : Interface : ExitIndex:
2001::2 GigabitEthernet1/0/0 0x0000000e
Total SID(s): 1
Step 6 Configure BGP EPEv6 on ASBR1 and ASBR2 and allocate inter-AS static End.X SIDs.
NOTICE
When configuring BGP EPEv6, you need to enable the BGP-LS address family peer
relationship so that BGP EPEv6 can take effect.
# Configure ASBR1.
[~ASBR1] segment-routing ipv6
[*ASBR1-segment-routing-ipv6] encapsulation source-address 2::2
[*ASBR1-segment-routing-ipv6] locator as1 ipv6-prefix 20:: 64 static 32
[*ASBR1-segment-routing-ipv6-locator] opcode ::200 end-x interface GigabitEthernet1/0/0 nexthop
2001::1 no-psp
[*ASBR1-segment-routing-ipv6-locator] quit
[*ASBR1-segment-routing-ipv6] quit
[*ASBR1] isis 1
[*ASBR1-isis-1] segment-routing ipv6 locator as1 auto-sid-disable
[*ASBR1-isis-1] ipv6 import-route bgp
[*ASBR1-isis-1] commit
[~ASBR1-isis-1] quit
[~ASBR1] bgp 100
[*ASBR1-bgp] segment-routing ipv6 egress-engineering locator as1
[*ASBR1-bgp] peer 2020::2 egress-engineering srv6 static-sid no-psp-usp 20::100
[*ASBR1-bgp-af-ipv6] import-route direct
[*ASBR1-bgp-af-ls] peer 2020::2 enable
[*ASBR1-bgp] quit
[*ASBR1] commit
# Configure ASBR2.
[~ASBR2] segment-routing ipv6
[*ASBR2-segment-routing-ipv6] encapsulation source-address 3::3
[*ASBR2-segment-routing-ipv6] locator as1 ipv6-prefix 30:: 64 static 32
[*ASBR2-segment-routing-ipv6-locator] opcode ::100 end-x interface GigabitEthernet1/0/0 nexthop
2002::2 no-psp
[*ASBR2-segment-routing-ipv6-locator] quit
[*ASBR2-segment-routing-ipv6] quit
[*ASBR2] isis 10
[*ASBR2-isis-10] segment-routing ipv6 locator as1 auto-sid-disable
[*ASBR2-isis-10] ipv6 import-route bgp
[*ASBR2-isis-10] commit
[~ASBR2-isis-10] quit
[~ASBR2] bgp 200

(2020-10-09)

[*ASBR2-bgp] segment-routing ipv6 egress-engineering locator as1
[*ASBR2-bgp] peer 2020::1 egress-engineering srv6 static-sid no-psp-usp 30::200
[*ASBR2-bgp-af-ipv6] import-route direct
[*ASBR2-bgp-af-ls] peer 2020::1 enable
[*ASBR2-bgp] quit
[*ASBR2] commit
After the configuration is complete, run the display bgp egress-engineering

command on each ASBR to check BGP EPE information. The command output
shows SRv6 SID information. The following example uses the command output on
ASBR1.
Peer Node : 2020::2

Peer Adj Num :0
Local ASN : 100
Remote ASN : 200
Local Interface Address : 2020::1
Remote Interface Address : 2020::2
SRv6 SID : 20::100
SRv6 SID (PSP) : 20::1:0:1E
Nexthop : 2020::2
Step 7 Establish an MP-EBGP peer relationship between the PEs, and configure the PEs to
exchange BGP VPNv4 routes carrying SIDs through this peer relationship.
# Configure PE1.
[~PE1] bgp 100
[*PE1-bgp-vpna] segment-routing ipv6 traffic-engineer
[~PE1-bgp] quit
# Configure PE2.
[~PE2] bgp 200
[*PE2-bgp-vpna] segment-routing ipv6 traffic-engineer

(2020-10-09)
[~PE2-bgp] quit
on the PEs to check whether a BGP peer relationship has been established
BGP peer relationship has been established successfully. The following example


PrefRcv
4::4 4 200 1032 1037 0 14:58:13 Established 2

PrefRcv
10.1.1.2 4 65410 1313 1330 0 19:06:22 Established 1

# Configure PE1.
# Configure PE2.

(2020-10-09)


SID :
10::100
20::100
30::100
# Configure PE1.
[*PE1] bgp 100
[*PE1-bgp] quit
# Configure PE2.
[*PE2] bgp 200
[*PE2-bgp] quit

(2020-10-09)

TE Policy.
route
------------------------------------------------------------------------------

10.2.1.0/24 EBGP 255 0 RD 4::4 policy1
22.22.22.22/32 EBGP 255 0 RD 4::4 policy1
route
------------------------------------------------------------------------------
Summary Count : 1
Protocol: EBGP Process ID: 0

Run the ping command on a CE. The command output shows that CEs belonging
to the same VPN can ping each other. For example:
[~CE1] ping -a 11.11.11.11 22.22.22.22

0.00% packet loss
----End

(2020-10-09)
Configuration Files
#
sysname PE1
#
ipv4-family
tnl-policy p1
#
opcode ::100 end-x interface GigabitEthernet1/0/0 nexthop 2001::2 no-psp usp
segment-list list1
binding-sid 10::1000
segment-list list1
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0001.00
#
#
#
undo shutdown
ipv6 enable
isis ipv6 enable 1
#
undo shutdown
ip address 10.1.1.1 255.255.255.0
#
interface LoopBack1
ipv6 enable
isis ipv6 enable 1
#
bgp 100
router-id 1.1.1.1
#
ipv4-family unicast
#
ipv6-family unicast
#
ipv4-family vpnv4
policy vpn-target
peer 4::4 enable

(2020-10-09)
#
import-route direct
segment-routing ipv6 traffic-engineer
#
#
tunnel-policy p1
#
return
#
sysname ASBR1
#
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0002.00
#
ipv6 import-route bgp
#
#
undo shutdown
ipv6 enable
isis ipv6 enable 1
#
undo shutdown
ipv6 enable
#
interface LoopBack1
ipv6 enable
isis ipv6 enable 1
#
bgp 100
router-id 2.2.2.2
segment-routing ipv6 egress-engineering locator as1
peer 2020::2 egress-engineering srv6 static-sid no-psp-usp 20::100
#
ipv4-family unicast
#
peer 2020::2 enable
#
ipv6-family unicast
network 1:: 64
import-route direct
peer 2020::2 enable
#
return

(2020-10-09)

#
sysname ASBR2
#
#
isis 10
is-level level-1
cost-style wide
network-entity 10.0000.0000.0003.00
#
ipv6 import-route bgp
#
#
undo shutdown
ipv6 enable
isis ipv6 enable 10
#
undo shutdown
ipv6 enable
#
interface LoopBack1
ipv6 enable
isis ipv6 enable 10
#
bgp 200
router-id 3.3.3.3
segment-routing ipv6 egress-engineering locator as1
peer 2020::1 egress-engineering srv6 static-sid no-psp-usp 30::200
#
ipv4-family unicast
#
peer 2020::1 enable
#
ipv6-family unicast
network 4:: 64
import-route direct
peer 2020::1 enable
#
return

#
sysname PE2
#
ipv4-family
tnl-policy p1
#

(2020-10-09)

segment-list list1
binding-sid 40::1000
segment-list list1
#
isis 10
is-level level-1
cost-style wide
network-entity 10.0000.0000.0004.00
#
#
#
undo shutdown
ipv6 enable
isis ipv6 enable 10
#
undo shutdown
ip address 10.2.1.1 255.255.255.0
#
interface LoopBack1
ipv6 enable
isis ipv6 enable 10
#
bgp 200
router-id 4.4.4.4
#
ipv4-family unicast
#
ipv6-family unicast
#
ipv4-family vpnv4
policy vpn-target
peer 1::1 enable
#
import-route direct
segment-routing ipv6 traffic-engineer
#
#
tunnel-policy p1
#
return

(2020-10-09)
#
sysname CE1
#
undo shutdown
ip address 10.1.1.2 255.255.255.0
#
interface LoopBack1
ip address 11.11.11.11 255.255.255.255
#
bgp 65410
#
ipv4-family unicast
network 11.11.11.11 255.255.255.255
#
return

#
sysname CE2
#
undo shutdown
ip address 10.2.1.2 255.255.255.0
#
interface LoopBack1
ip address 22.22.22.22 255.255.255.255
#
bgp 65420
#
ipv4-family unicast
network 22.22.22.22 255.255.255.255
#
return
2.2.23.9 Example for Configuring an SRv6 SFC to Carry IPv4 Services (SFF-to-
SF Packets Are Forwarded at Layer 3)
This section provides an example for configuring an SRv6 TE Policy to carry IPv4
services in an SRv6 SFC scenario (SFF-to-SF packets are forwarded at Layer 3).
In Figure 2-124, SF1 is dual-homed to SFF1 and SFF2, and has a bypass SF – SF2.
For the IPv4 service flow direction from the SC to the tail end, it is required that
the SRv6 SFC function be configured on the network, and IPv4 service reliability be
ensured.
Figure 2-124 Configuring an SRv6 SFC to carry IPv4 services (SFF-to-SF packets
are forwarded at Layer 3)
NOTE
Interfaces 1 through 4 in this example represent GE 1/0/1, GE 1/0/2, GE 1/0/3, and GE

1/0/4, respectively.

(2020-10-09)
Precautions
Before configuring an SRv6 SFC to carry IPv4 services (SFF-to-SF packets are
forwarded at Layer 3), note the following:
1. The configuration in this example focuses on the SC, SFFs, and tail end. The
configuration on the SFs is not mentioned.
2. Two locators are configured on SFF1, and on SFF2. Different locators are used
to implement backup protection between SFF2 and SFF1, whereas the same
locators are used to provide the anycast SID function on SFF1 and SFF2. The
locator routes need to be advertised using IS-IS.
3. SF1 is dual-homed to SFF1 and SFF2. To implement dual-homing protection,
the same End.AS SID must be configured on SFF1 and SFF2.
1. Enable IPv6 forwarding and configure an IPv6 address for each interface.
2. Enable IS-IS, configure an IS-IS level, and specify a network entity on each
device.
3. Configure basic SRv6 functions on each device.
4. Configure SF access on SFFs.
5. Configure SFC on SFFs.
6. Configure an SRv6 TE Policy on the SC.
7. Configure a traffic policy on the SC to redirect traffic to the SRv6 TE Policy.
8. Configure backup link protection and bypass protection on SFF1 and SFF2.

(2020-10-09)
9. Configure one-arm BFD on SFF1 and SFF2 to detect SF1 reachability.
Data Preparation
● IS-IS process ID of each device
● IS-IS level of each device
● Locators of each device
Procedure
# Configure SFF1. The configurations of other devices are similar to the
configuration of SFF1. For configuration details, see Configuration Files in this
section.
[~HUAWEI] sysname SFF1
[*HUAWEI] commit
[~SFF1] interface gigabitethernet 1/0/1
[~SFF1-GigabitEthernet1/0/1] ipv6 enable
[*SFF1-GigabitEthernet1/0/1] ipv6 address 2001:db8:1::2 96
[*SFF1-GigabitEthernet1/0/1] quit
[*SFF1] interface gigabitethernet 1/0/2
[*SFF1-GigabitEthernet1/0/2] ipv6 enable
[*SFF1] interface loopback1
[*SFF1-LoopBack1] ipv6 enable
[*SFF1-LoopBack1] ipv6 address 2::2 128
[*SFF1-LoopBack1] commit
[~SFF1-LoopBack1] quit

section.
[~SFF1] isis 1
[*SFF1-isis-1] is-level level-1
[*SFF1-isis-1] cost-style wide
[*SFF1-isis-1] network-entity 10.0000.0000.0002.00
[*SFF1-isis-1] ipv6 enable topology ipv6
[*SFF1-isis-1] quit
[*SFF1-GigabitEthernet1/0/1] isis ipv6 enable 1
[*SFF1-LoopBack1] isis ipv6 enable 1

(2020-10-09)
Step 3 Configure SRv6 SIDs and enable IS-IS SRv6.

# Configure the SC.
[~SC] ip vpn-instance vpna
[*SC-vpn-instance-vpna] ipv4-family
[*SC-vpn-instance-vpna-af-ipv4] route-distinguisher 100:1
[*SC-vpn-instance-vpna-af-ipv4] vpn-target 111:1 both
[*SC-vpn-instance-vpna-af-ipv4] quit
[*SC-vpn-instance-vpna] quit
[*SC] segment-routing ipv6
[*SC-segment-routing-ipv6] encapsulation source-address 1::1
[*SC-segment-routing-ipv6] locator as1 ipv6-prefix 2001:db8:11:: 64 static 32
[*SC-segment-routing-ipv6-locator] opcode ::1 end
[*SC-segment-routing-ipv6-locator] opcode ::100 end-dt4 vpn-instance vpna
[*SC-segment-routing-ipv6-locator] quit
[*SC-segment-routing-ipv6] quit
[*SC] isis 1
[*SC-isis-1] segment-routing ipv6 locator as1 auto-sid-disable
[*SC-isis-1] commit
[~SC-isis-1] quit
# Configure SFF1.
[~SFF1] ip vpn-instance vpna
[*SFF1-vpn-instance-vpna] ipv4-family
[*SFF1-vpn-instance-vpna-af-ipv4] route-distinguisher 200:1
[*SFF1-vpn-instance-vpna-af-ipv4] vpn-target 111:1 both
[*SFF1-vpn-instance-vpna-af-ipv4] quit
[*SFF1-vpn-instance-vpna] quit
[*SFF1] segment-routing ipv6
[*SFF1-segment-routing-ipv6] encapsulation source-address 2::2
[*SFF1-segment-routing-ipv6] locator as1 ipv6-prefix 2001:db8:12:: 64 static 32
[*SFF1-segment-routing-ipv6-locator] opcode ::1 end
[*SFF1-segment-routing-ipv6-locator] quit
[*SFF1-segment-routing-ipv6] quit
[*SFF1] isis 1
[*SFF1-isis-1] segment-routing ipv6 locator as1 auto-sid-disable
[*SFF1-isis-1] commit
[~SFF1-isis-1] quit
# Configure SFF2.
[*SFF2] isis 1
[~SFF2-isis-1] quit
# Configure SFF3.

(2020-10-09)
[*SFF3] isis 1
[~SFF3-isis-1] quit
# Configure the tail end.

[~Tail] ip vpn-instance vpna
[*Tail-vpn-instance-vpna] ipv4-family
[*Tail-vpn-instance-vpna-af-ipv4] route-distinguisher 500:1
[*Tail-vpn-instance-vpna-af-ipv4] vpn-target 111:1 both
[*Tail-vpn-instance-vpna-af-ipv4] quit
[*Tail-vpn-instance-vpna] quit
[*Tail] interface gigabitethernet 1/0/2
[*Tail-GigabitEthernet1/0/2] ip binding vpn-instance vpna
[*Tail-GigabitEthernet1/0/2] ip address 10.1.5.2 30
[*Tail-GigabitEthernet1/0/2] quit
[*Tail] segment-routing ipv6
[*Tail-segment-routing-ipv6] encapsulation source-address 5::5
[*Tail-segment-routing-ipv6] locator as1 ipv6-prefix 2001:db8:15:: 64 static 32
[*Tail-segment-routing-ipv6-locator] opcode ::1 end
[*Tail-segment-routing-ipv6-locator] opcode ::100 end-dt4 vpn-instance vpna
[*Tail-segment-routing-ipv6-locator] quit
[*Tail-segment-routing-ipv6] quit
[*Tail] isis 1
[*Tail-isis-1] segment-routing ipv6 locator as1 auto-sid-disable
[*Tail-isis-1] commit
[~Tail-isis-1] quit

Step 4 Configure SF access on SFFs.
# Configure SFF1.
[~SFF1] bridge-domain 1
[*SFF1-bd1] quit
[*SFF1] interface gigabitethernet 1/0/3.1 mode l2
[*SFF1-GigabitEthernet1/0/3.1] encapsulation dot1q vid 1
[*SFF1-GigabitEthernet1/0/3.1] rewrite pop single
[*SFF1-GigabitEthernet1/0/3.1] bridge-domain 1
[*SFF1-GigabitEthernet1/0/3.1] quit
[*SFF1] interface Vbdif1
[*SFF1-Vbdif1] ip binding vpn-instance vpna
[*SFF1-Vbdif1] ip address 10.1.1.2 30
[*SFF1-Vbdif1] commit
[~SFF1-Vbdif1] quit
# Configure SFF2.
[*SFF2-bd1] quit
[~SFF2-Vbdif1] quit

(2020-10-09)
# Configure SFF3.
[*SFF3-bd1] quit
[~SFF3-Vbdif1] quit
Step 5 Configure basic SFC functions on SFFs.

# Configure SFF1.
[~SFF1] segment-routing ipv6
[~SFF1-segment-routing-ipv6] locator as2 ipv6-prefix 2001:db8:9999:: 64 static 32
[*SFF1-segment-routing-ipv6-locator] opcode ::1 end-as
[*SFF1-segment-routing-ipv6-locator-endas-::1] inner-type ipv4
[*SFF1-segment-routing-ipv6-locator-endas-::1] encapsulation ipv4 nexthop 10.1.1.1 out-interface Vbdif1
in-interface Vbdif1
[*SFF1-segment-routing-ipv6-locator-endas-::1] cache source-address 1::1
[*SFF1-segment-routing-ipv6-locator-endas-::1] cache list 2001:db8:15::100 2001:db8:15::1
2001:db8:9999::1
[*SFF1-segment-routing-ipv6-locator-endas-::1] quit
[*SFF1] isis 1
[~SFF1-isis-1] quit
# Configure SFF2.
in-interface Vbdif1
2001:db8:9999::1
[*SFF2] isis 1
[~SFF2-isis-1] quit
# Configure SFF3.
in-interface Vbdif1
[*SFF3-segment-routing-ipv6-locator-endas-::1] cache list 2001:db8:15::100 2001:db8:15::1 2001:db8:24::1
[*SFF3] isis 1

(2020-10-09)
[~SFF3-isis-1] quit
Step 6 Configure an SRv6 TE Policy on the SC.

# Configure the SC.
[~SC] segment-routing ipv6
[~SC-segment-routing-ipv6] segment-list list1
[*SC-segment-routing-ipv6-segment-list-list1] index 5 sid ipv6 2001:db8:9999::1
[*SC-segment-routing-ipv6-segment-list-list1] commit
[~SC-segment-routing-ipv6-segment-list-list1] quit
[~SC-segment-routing-ipv6] srv6-te-policy locator as1
[*SC-segment-routing-ipv6] srv6-te policy policy1 endpoint 2001:db8:15::1 color 101
[*SC-segment-routing-ipv6-policy-policy1] binding-sid 2001:db8:11::11
[*SC-segment-routing-ipv6-policy-policy1] candidate-path preference 100
[*SC-segment-routing-ipv6-policy-policy1-path] segment-list list1
[*SC-segment-routing-ipv6-policy-policy1-path] commit
[~SC-segment-routing-ipv6-policy-policy1-path] quit
[~SC-segment-routing-ipv6-policy-policy1] quit
[~SC-segment-routing-ipv6] quit
# Configure the SC.
[~SC] traffic classifier c1
[*SC-classifier-c1] if-match any
[*SC-classifier-c1] commit
[~SC-classifier-c1] quit
[~SC] traffic behavior b1
[*SC-behavior-b1] redirect srv6-te policy 2001:db8:15::1 101 vpnsid 2001:db8:15::100
[*SC-behavior-b1] commit
[~SC-behavior-b1] quit
[~SC] traffic policy p1
[*SC-trafficpolicy-p1] classifier c1 behavior b1
[*SC-trafficpolicy-p1] statistic enable
[*SC-trafficpolicy-p1] commit
[~SC-trafficpolicy-p1] quit
[~SC] bridge-domain 1
[*SC-bd1] quit
[*SC] interface gigabitethernet 1/0/1.1 mode l2
[*SC-GigabitEthernet1/0/1.1] encapsulation dot1q vid 1
[*SC-GigabitEthernet1/0/1.1] rewrite pop single
[*SC-GigabitEthernet1/0/1.1] bridge-domain 1
[*SC-GigabitEthernet1/0/1.1] quit
[*SC] interface Vbdif1
[*SC-Vbdif1] ip binding vpn-instance vpna
[*SC-Vbdif1] ip address 10.0.0.1 30
[*SC-Vbdif1] traffic-policy p1 inbound
[*SC-Vbdif1] commit
[~SC-Vbdif1] quit
Step 8 Configure backup link protection and bypass protection on SFF1 and SFF2.
# Configure SFF1.
[~SFF1-segment-routing-ipv6] proxy peer-sid 2001:db8:13::1
[*SFF1-segment-routing-ipv6] locator as2
[*SFF1-segment-routing-ipv6-locator-endas-::1] backup-opcode ::2
[*SFF1-segment-routing-ipv6-locator-endas-::1] bypass sid 2001:db8:24::1

(2020-10-09)
[*SFF1] commit
# Configure SFF2.
[~SFF2-segment-routing-ipv6] proxy peer-sid 2001:db8:12::1
[*SFF2-segment-routing-ipv6-locator-endas-::1] backup-opcode ::2
[*SFF2-segment-routing-ipv6-locator-endas-::1] bypass sid 2001:db8:24::1
[*SFF2] commit
Step 9 Configure one-arm BFD on SFF1 and SFF2.

# Configure SFF1.
[~SFF1] bfd
[*SFF1-bfd] quit
[*SFF1] bfd tosf1 bind peer-ip 10.1.1.1 vpn-instance vpna interface Vbdif1 one-arm-echo destination-
ip 2.2.2.9
[*SFF1-bfd-session-tosf1] discriminator local 10
[*SFF1-bfd-session-tosf1] process-pst
[*SFF1-bfd-session-tosf1] commit
[~SFF1-bfd-session-tosf1] quit
# Configure SFF2.
[~SFF2] bfd
[*SFF2-bfd] quit
[*SFF2] bfd tosf1 bind peer-ip 10.1.1.1 vpn-instance vpna interface Vbdif1 one-arm-echo destination-
ip 3.3.3.9
[*SFF2-bfd-session-tosf1] discriminator local 10
[*SFF2-bfd-session-tosf1] process-pst
[*SFF2-bfd-session-tosf1] commit
[~SFF2-bfd-session-tosf1] quit
----End
Configuration Files
● SC configuration file
#
sysname SC
#
ipv4-family
#
locator as1 ipv6-prefix 2001:db8:11:: 64 static 32
opcode ::1 end
opcode ::100 end-dt4 vpn-instance vpna
segment-list list1
index 5 sid ipv6 2001:db8:9999::1
index 10 sid ipv6 2001:db8:15::1
srv6-te policy policy1 endpoint 2001:db8:15::1 color 101
binding-sid 2001:db8:11::111
segment-list list1
#

(2020-10-09)
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0001.00
#
#
#
bridge-domain 1
#
traffic classifier c1
if-match any
#
traffic behavior b1
redirect srv6-te policy 2001:db8:15::1 101 vpnsid 2001:db8:15::100
#
traffic policy p1
classifier c1 behavior b1
statistic enable
#
interface Vbdif1
ip address 10.0.0.1 255.255.255.252
traffic-policy p1 inbound
#
undo shutdown
#
rewrite pop single
bridge-domain 1
#
undo shutdown
ipv6 enable
ipv6 address 2001:db8:1::1/96
isis ipv6 enable 1
#
undo shutdown
ipv6 enable
isis ipv6 enable 1
#
interface LoopBack1
ipv6 enable
isis ipv6 enable 1
#
return
● SFF1 configuration file
#
sysname SFF1
#
bfd
#
bfd tosf1 bind peer-ip 10.1.1.1 vpn-instance vpna interface Vbdif1 one-arm-echo destination-ip 2.2.2.9
process-pst
#
ipv4-family
#

(2020-10-09)

proxy peer-sid 2001:db8:13::1
opcode ::1 end
opcode ::1 end-as
inner-type ipv4
encapsulation ipv4 nexthop 10.1.1.1 out-interface Vbdif1 in-interface Vbdif1
cache source-address 1::1
cache list 2001:db8:15::100 2001:db8:15::1 2001:db8:9999::1
backup-opcode ::2
bypass sid 2001:db8:24::1
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0002.00
#
#
#
bridge-domain 1
#
interface Vbdif1
ip address 10.1.1.2 255.255.255.252
#
undo shutdown
ipv6 enable
isis ipv6 enable 1
#
undo shutdown
ipv6 enable
isis ipv6 enable 1
#
undo shutdown
#
rewrite pop single
bridge-domain 1
#
undo shutdown
ipv6 enable
isis ipv6 enable 1
#
interface LoopBack1
ipv6 enable
isis ipv6 enable 1
#
return
#
sysname SFF2
#
bfd
#
bfd tosf1 bind peer-ip 10.1.1.1 vpn-instance vpna interface Vbdif1 one-arm-echo destination-ip 3.3.3.9

(2020-10-09)
process-pst
#
ipv4-family
#
proxy peer-sid 2001:db8:12::1
opcode ::1 end
opcode ::1 end-as
inner-type ipv4
backup-opcode ::2
bypass sid 2001:db8:24::1
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0003.00
#
#
#
bridge-domain 1
#
interface Vbdif1
ip address 10.1.1.2 255.255.255.252
#
undo shutdown
ipv6 enable
isis ipv6 enable 1
#
undo shutdown
ipv6 enable
isis ipv6 enable 1
#
undo shutdown
#
rewrite pop single
bridge-domain 1
#
undo shutdown
ipv6 enable
isis ipv6 enable 1
#
interface LoopBack1
ipv6 enable
isis ipv6 enable 1

(2020-10-09)
#
return
#
sysname SFF3
#
ipv4-family
#
opcode ::1 end
opcode ::1 end-as
inner-type ipv4
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0004.00
#
#
#
bridge-domain 1
#
interface Vbdif1
ip address 10.2.1.2 255.255.255.252
#
undo shutdown
ipv6 enable
isis ipv6 enable 1
#
undo shutdown
ipv6 enable
isis ipv6 enable 1
#
undo shutdown
#
rewrite pop single
bridge-domain 1
#
undo shutdown
ipv6 enable
isis ipv6 enable 1
#
interface LoopBack1
ipv6 enable
isis ipv6 enable 1

(2020-10-09)
#
return
● Tail end configuration file

#
sysname Tail
#
ipv4-family
#
opcode ::1 end
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0005.00
#
#
#
undo shutdown
ipv6 enable
isis ipv6 enable 1
#
undo shutdown
ip address 10.5.1.2 255.255.255.252
#
interface LoopBack1
ipv6 enable
isis ipv6 enable 1
#
return
2.2.23.10 Example for Configuring an SRv6 SFC to Carry IPv4 Services (SFF-
to-SF Packets Are Forwarded at Layer 2)
This section provides an example for configuring an SRv6 TE Policy to carry IPv4
services in an SRv6 SFC scenario (SFF-to-SF packets are forwarded at Layer 2).
As shown in Figure 2-125, SF1 and SF2 are connected to SFF1 and SFF2,
respectively. SF1 and SF2 provide different SFC functions. For the service flow
direction from the SC to the tail end, it is required that the SFC function be
configured on the network to ensure that IPv4 service packets are processed by
SF1 and SF2 in sequence.

(2020-10-09)
Figure 2-125 Configuring an SRv6 SFC to carry IPv4 services (SFF-to-SF packets
are forwarded at Layer 2)
NOTE
Precautions
Before configuring an SRv6 SFC to carry IPv4 services (SFF-to-SF packets are
forwarded at Layer 2), note the following:
● The configuration in this example focuses on the SC, SFFs, and tail end. The
configuration on the SFs is not mentioned.
1. Enable IPv6 forwarding and configure an IPv6 address for each interface.
device.
3. Configure basic SRv6 functions on each device.
4. Configure SF access on SFFs.
5. Configure SFC on SFFs.
6. Configure an SRv6 TE Policy on the SC.
7. Configure a traffic policy on the SC to redirect traffic to the SRv6 TE Policy.
Data Preparation

(2020-10-09)
● IS-IS process ID of each device

● IS-IS level of each device
● Locators of each device
Procedure
section.
[~HUAWEI] sysname SFF1
[*HUAWEI] commit
[~SFF1] interface gigabitethernet 1/0/0
[~SFF1-GigabitEthernet1/0/0] ipv6 enable
[*SFF1-LoopBack1] ipv6 enable
[*SFF1-LoopBack1] ipv6 address 2::2 128

section.
[~SFF1] isis 1
[*SFF1-isis-1] is-level level-1
[*SFF1-isis-1] cost-style wide
[*SFF1-isis-1] network-entity 10.0000.0000.0002.00
[*SFF1-isis-1] ipv6 enable topology ipv6
[*SFF1-isis-1] quit
[*SFF1-LoopBack1] isis ipv6 enable 1
Step 3 Configure SRv6 SIDs and enable IS-IS SRv6.

# Configure the SC.
[*SC-segment-routing-ipv6] encapsulation source-address 1::1
[*SC-segment-routing-ipv6] locator as1 ipv6-prefix 2001:db8:11:: 64 static 32
[*SC-segment-routing-ipv6-locator] opcode ::1 end
[*SC-segment-routing-ipv6-locator] quit
[*SC-segment-routing-ipv6] quit
[*SC] isis 1
[*SC-isis-1] segment-routing ipv6 locator as1 auto-sid-disable
[*SC-isis-1] commit
[~SC-isis-1] quit

(2020-10-09)
# Configure SFF1.
[*SFF1] isis 1
[~SFF1-isis-1] quit
# Configure SFF2.
[*SFF2] isis 1
[~SFF2-isis-1] quit
# Configure the tail end.

[~Tail] ip vpn-instance vpna
[*Tail-vpn-instance-vpna] ipv4-family
[*Tail-vpn-instance-vpna-af-ipv4] route-distinguisher 500:1
[*Tail-vpn-instance-vpna-af-ipv4] vpn-target 111:1 both
[*Tail-vpn-instance-vpna-af-ipv4] quit
[*Tail-vpn-instance-vpna] quit
[*Tail] segment-routing ipv6
[*Tail-segment-routing-ipv6] encapsulation source-address 5::5
[*Tail-segment-routing-ipv6] locator as1 ipv6-prefix 2001:db8:15:: 64 static 32
[*Tail-segment-routing-ipv6-locator] opcode ::1 end
[*Tail-segment-routing-ipv6-locator] opcode ::100 end-dt4 vpn-instance vpna
[*Tail-segment-routing-ipv6-locator] quit
[*Tail-segment-routing-ipv6] quit
[*Tail] isis 1
[*Tail-isis-1] segment-routing ipv6 locator as1 auto-sid-disable
[*Tail-isis-1] commit
[~Tail-isis-1] quit

Step 4 Configure SF access on SFFs.
# Configure SFF1.
[~SFF1] interface gigabitethernet 3/0/0.1 mode l2
[*SFF1] commit
# Configure SFF2.
[~SFF2] interface gigabitethernet 3/0/0.1 mode l2
[*SFF2] commit
Step 5 Configure basic SFC functions on SFFs.
# Configure SFF1.

(2020-10-09)

[*SFF1-segment-routing-ipv6-locator-endas-::100] encapsulation eth out-interface gigabitethernet
3/0/0.1 out-vlan 1 in-interface gigabitethernet 3/0/0.1 in-vlan 1
2001:db8:12::100
[*SFF1] commit
# Configure SFF2.
[*SFF2-segment-routing-ipv6-locator-endas-::100] encapsulation eth out-interface gigabitethernet
3/0/0.1 out-vlan 1 in-interface gigabitethernet 3/0/0.1 in-vlan 1
2001:db8:13::100
[*SFF2] commit
Step 6 Configure an SRv6 TE Policy on the SC.

# Configure the SC.
[~SC-segment-routing-ipv6] segment-list list1
[*SC-segment-routing-ipv6-segment-list-list1] commit
[~SC-segment-routing-ipv6-segment-list-list1] quit
[~SC-segment-routing-ipv6] srv6-te-policy locator as1
[*SC-segment-routing-ipv6] srv6-te policy policy1 endpoint 2001:db8:15::1 color 101
[*SC-segment-routing-ipv6-policy-policy1] binding-sid 2001:db8:11::11
[*SC-segment-routing-ipv6-policy-policy1] candidate-path preference 100
[*SC-segment-routing-ipv6-policy-policy1-path] segment-list list1
[*SC-segment-routing-ipv6-policy-policy1-path] commit
[~SC-segment-routing-ipv6-policy-policy1-path] quit
[~SC-segment-routing-ipv6-policy-policy1] quit
[~SC-segment-routing-ipv6] quit
# Configure the SC.
[~SC] traffic classifier c1
[*SC-classifier-c1] if-match any
[*SC-classifier-c1] commit
[~SC-classifier-c1] quit
[~SC] traffic behavior b1
[*SC-behavior-b1] redirect srv6-te policy 2001:db8:15::1 101 vpnsid 2001:db8:15::100
[*SC-behavior-b1] commit
[~SC-behavior-b1] quit
[~SC] traffic policy p1
[*SC-trafficpolicy-p1] classifier c1 behavior b1
[*SC-trafficpolicy-p1] statistic enable

(2020-10-09)
[*SC-trafficpolicy-p1] commit
[~SC-trafficpolicy-p1] quit
[~SC] bridge-domain 1
[*SC-bd1] quit
[*SC] interface gigabitethernet 1/0/0.1 mode l2
[*SC-GigabitEthernet1/0/0.1] encapsulation dot1q vid 1
[*SC-GigabitEthernet1/0/0.1] rewrite pop single
[*SC-GigabitEthernet1/0/0.1] bridge-domain 1
[*SC-GigabitEthernet1/0/0.1] quit
[*SC] interface Vbdif1
[*SC-Vbdif1] ip binding vpn-instance vpna
[*SC-Vbdif1] ip address 10.0.0.1 30
[*SC-Vbdif1] traffic-policy p1 inbound
[*SC-Vbdif1] commit
[~SC-Vbdif1] quit
----End
Configuration Files
● SC configuration file
#
sysname SC
#
ipv4-family
#
opcode ::1 end
segment-list list1
index 5 sid ipv6 2001:db8:12::100
index 10 sid ipv6 2001:db8:13::100
index 15 sid ipv6 2001:db8:15::1
srv6-te policy policy1 endpoint 2001:db8:15::1 color 101
binding-sid 2001:db8:11::111
segment-list list1
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0001.00
#
#
#
bridge-domain 1
#
traffic classifier c1
if-match any
#
traffic behavior b1
redirect srv6-te policy 2001:db8:15::1 101 vpnsid 2001:db8:15::100
#
traffic policy p1
classifier c1 behavior b1
statistic enable
#
interface Vbdif1
ip address 10.0.0.1 255.255.255.252

(2020-10-09)
traffic-policy p1 inbound
#
undo shutdown
#
rewrite pop single
bridge-domain 1
#
undo shutdown
ipv6 enable
isis ipv6 enable 1
#
interface LoopBack1
ipv6 enable
isis ipv6 enable 1
#
return

#
sysname SFF1
#
opcode ::1 end
opcode ::100 end-as
inner-type ipv4
encapsulation eth out-interface GigabitEthernet3/0/0.1 out-vlan 1 in-interface
GigabitEthernet3/0/0.1 in-vlan 1
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0002.00
#
#
#
undo shutdown
ipv6 enable
isis ipv6 enable 1
#
undo shutdown
ipv6 enable
isis ipv6 enable 1
#
undo shutdown
#
#
interface LoopBack1
ipv6 enable
isis ipv6 enable 1

(2020-10-09)
#
return
#
sysname SFF2
#
opcode ::1 end
opcode ::100 end-as
inner-type ipv4
encapsulation eth out-interface GigabitEthernet3/0/0.1 out-vlan 1 in-interface
GigabitEthernet3/0/0.1 in-vlan 1
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0003.00
#
#
#
undo shutdown
ipv6 enable
isis ipv6 enable 1
#
undo shutdown
ipv6 enable
isis ipv6 enable 1
#
undo shutdown
#
#
interface LoopBack1
ipv6 enable
isis ipv6 enable 1
#
return
● Tail end configuration file
#
sysname Tail
#
ipv4-family
#
opcode ::1 end
#
isis 1
is-level level-1

(2020-10-09)
cost-style wide
network-entity 10.0000.0000.0004.00
#
#
#
undo shutdown
ipv6 enable
isis ipv6 enable 1
#
undo shutdown
ip address 10.5.1.2 255.255.255.252
#
interface LoopBack1
ipv6 enable
isis ipv6 enable 1
#
return
2.2.23.11 Example for Configuring L3VPNv4 HoVPN over MPLS Plus SRv6 TE
Policy
This section provides an example for configuring L3VPNv4 HoVPN over MPLS plus
SRv6 TE Policy.
● The UPE, SPE, and NPE all belong to AS 100. They need to run IS-IS to
implement IPv6 network connectivity.
● The UPE, SPE, and NPE all belong to IS-IS process 1.
It is required that a bidirectional MPLS LDP tunnel be established between the
UPE and SPE and a bidirectional SRv6 TE Policy be established between the SPE
and NPE to carry L3VPNv4 services.
Figure 2-126 L3VPNv4 HoVPN over MPLS plus SRv6 TE Policy networking
NOTE

(2020-10-09)
1. Enable IPv6 forwarding and configure an IPv6/IPv4 address for each interface
on the UPE, NPE, and SPE.
device.
3. Configure basic MPLS functions and MPLS LDP on the UPE and SPE, and
establish MPLS LDP LSPs between the two devices.
4. Configure VPN instances on the UPE, NPE, and SPE, and enable the IPv4
address family for the instances.
5. Establish an EBGP peer relationship between the UPE and CE1 and another
one between the NPE and CE2.
6. Establish an MP-IBGP peer relationship between the UPE and SPE and
another one between the SPE and NPE.
7. Configure SRv6 SIDs on the NPE and SPE, and enable the devices to advertise
VPN routes carrying SIDs.
8. Deploy an SRv6 TE Policy between the SPE and NPE.
9. Configure a tunnel policy on the SPE and NPE to import traffic.
10. Specify the UPE as the peer of the SPE and configure the SPE to advertise the
11. Configure the SPE to advertise regenerated routes to the NPE.
Data Preparation
● IPv6 address of each interface on the UPE, SPE, and NPE
● IS-IS process ID of the UPE, SPE, and NPE
● IS-IS level of the UPE, SPE, and NPE
● VPN instance name, RD, and RT on the SPE and NPE
Procedure
Step 1 Configure an IP address and enable IPv6 forwarding for each interface.
# Configure the NPE. The configurations of the SPE and UPE are similar to the
configuration of the NPE. For configuration details, see Configuration Files in this
section.
[~HUAWEI] sysname NPE
[~HUAWEI] commit
[~NPE] interface gigabitethernet 1/0/0
[~NPE-GigabitEthernet1/0/0] ipv6 enable
[*NPE-GigabitEthernet1/0/0] ipv6 address 2001:db8:2001::2 96
[*NPE] interface LoopBack 1
[*NPE-LoopBack1] ip address 3.3.3.3 32
[*NPE-LoopBack1] ipv6 enable
[*NPE-LoopBack1] ipv6 address 2001:DB8:2::2 64
[*NPE-LoopBack1] quit
[*NPE] commit

(2020-10-09)

[~UPE] isis 1
[*UPE-isis-1] is-level level-1
[*UPE-isis-1] cost-style wide
[*UPE-isis-1] network-entity 10.0000.0000.0001.00
[*UPE-isis-1] quit
[*UPE] interface gigabitethernet 1/0/0
[*UPE-GigabitEthernet1/0/0] isis enable 1
[*UPE-LoopBack1] isis enable 1

[~SPE] isis 1
[*SPE-isis-1] is-level level-1
[*SPE-isis-1] cost-style wide
[*SPE-isis-1] network-entity 10.0000.0000.0002.00
[*SPE-isis-1] ipv6 enable topology ipv6
[*SPE-isis-1] quit
[*SPE] interface gigabitethernet 1/0/0
[*SPE-GigabitEthernet1/0/0] isis enable 1
[*SPE] interface loopback1
[*SPE-LoopBack1] isis ipv6 enable 1
[*SPE-LoopBack1] isis enable 1
[*SPE-LoopBack1] commit
[~SPE-LoopBack1] quit

[~NPE] isis 1
[*NPE-isis-1] is-level level-1
[*NPE-isis-1] cost-style wide
[*NPE-isis-1] network-entity 10.0000.0000.0003.00
[*NPE-isis-1] ipv6 enable topology ipv6
[*NPE-isis-1] quit
[*NPE] interface gigabitethernet 1/0/0
[*NPE-GigabitEthernet1/0/0] isis ipv6 enable 1
[*NPE] interface loopback1
[*NPE-LoopBack1] isis ipv6 enable 1
[*NPE-LoopBack1] commit
[~NPE-LoopBack1] quit

output on the UPE.
[~UPE] display isis peer

--------------------------------------------------------------------------------
0000.0000.0002 GE1/0/0 0000.0000.0002.01 Up 8s L1 64
Total Peer(s): 1

(2020-10-09)
command output on the NPE.
[~NPE] display isis route
-----------------------------

--------------------------------

--------------------------------------------------------------------------------
2001:DB8:1::1/64 GE1/0/0 FE80::3A92:6CFF:FE21:10 10 A/-/-/-
2001:DB8:2::2/64 Loop1 Direct 0 D/-/L/-
2001:DB8:2001::/96 GE1/0/0 Direct 10 D/-/L/-
Step 3 Configure basic MPLS functions and MPLS LDP on the UPE and SPE, and establish
MPLS LDP LSPs between the two devices.
[~UPE] mpls lsr-id 1.1.1.1
[*UPE] mpls
[*UPE-mpls] commit
[~UPE-mpls] quit
[~UPE] mpls ldp
[*UPE-mpls-ldp] quit
[*UPE-GigabitEthernet1/0/0] mpls
[*UPE-GigabitEthernet1/0/0] mpls ldp
[*UPE-GigabitEthernet1/0/0] commit
[~UPE-GigabitEthernet1/0/0] quit

[~SPE] mpls lsr-id 2.2.2.2
[*SPE] mpls
[*SPE-mpls] commit
[~SPE-mpls] quit
[~SPE] mpls ldp
[*SPE-mpls-ldp] quit
[*SPE-GigabitEthernet1/0/0] mpls
[*SPE-GigabitEthernet1/0/0] mpls ldp
[*SPE-GigabitEthernet1/0/0] commit
[~SPE-GigabitEthernet1/0/0] quit
After the configuration is complete, run the display mpls ldp session command. If
Status is displayed as Operational in the command output, LDP sessions have
been successfully established between the UPE and SPE. Then, run the display
mpls ldp lsp command to check whether LDP LSPs have been successfully
established.
The following example uses the command output on the UPE.
[~UPE] display mpls ldp session
Codes: LAM(Label Advertisement Mode), SsnAge Unit(DDD:HH:MM)
-------------------------------------------------------------------------
Peer-ID Status LAM SsnRole SsnAge KA-Sent/Rcv
-------------------------------------------------------------------------
-------------------------------------------------------------------------
TOTAL: 1 session(s) Found.
LAM : Label Advertisement Mode SsnAge Unit : DDD:HH:MM
[~UPE] display mpls ldp lsp
LDP LSP Information

(2020-10-09)
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
DestAddress/Mask In/OutLabel UpstreamPeer NextHop OutInterface
-------------------------------------------------------------------------------
1.1.1.1/32 3/NULL 2.2.2.2 127.0.0.1 Loop1
*1.1.1.1/32 Liberal/1024 DS/2.2.2.2
2.2.2.2/32 NULL/3 - 10.1.2.2 GE1/0/0
2.2.2.2/32 1024/3 2.2.2.2 10.1.2.2 GE1/0/0
-------------------------------------------------------------------------------
TOTAL: 3 Normal LSP(s) Found.
TOTAL: 1 Liberal LSP(s) Found.
TOTAL: 0 FRR LSP(s) Found.
An asterisk (*) before an LSP means the LSP is not established
An asterisk (*) before a Label means the USCB or DSCB is stale
An asterisk (*) before an UpstreamPeer means the session is stale
An asterisk (*) before a DS means the session is stale
An asterisk (*) before a NextHop means the LSP is FRR LSP
Step 4 On the UPE, NPE, and SPE, configure a VPN instance and enable the IPv4 address
family for the instance.

[~UPE] ip vpn-instance vpna
[*UPE-vpn-instance-vpna] ipv4-family
[*UPE-vpn-instance-vpna-af-ipv4] route-distinguisher 100:1
[*UPE-vpn-instance-vpna-af-ipv4] vpn-target 111:1 both
[*UPE-vpn-instance-vpna-af-ipv4] quit
[*UPE-vpn-instance-vpna] quit
[*UPE-GigabitEthernet2/0/0] ip binding vpn-instance vpna
[*UPE-GigabitEthernet2/0/0] ip address 10.1.1.1 24
[*UPE] commit

[~SPE] ip vpn-instance vpna
[*SPE-vpn-instance-vpna-af-ipv4] route-distinguisher 200:1
[*SPE-vpn-instance-vpna-af-ipv4] vpn-target 111:1 both
[*SPE-vpn-instance-vpna-af-ipv4] quit
[*SPE-vpn-instance-vpna] quit
[*SPE] commit

[~NPE] ip vpn-instance vpna
[*NPE-vpn-instance-vpna-af-ipv4] route-distinguisher 300:1
[*NPE-vpn-instance-vpna-af-ipv4] vpn-target 111:1 both
[*NPE-vpn-instance-vpna-af-ipv4] quit
[*NPE-vpn-instance-vpna] quit
[*NPE] interface gigabitethernet 2/0/0
[*NPE-GigabitEthernet2/0/0] ip binding vpn-instance vpna
[*NPE-GigabitEthernet2/0/0] ip address 10.2.1.1 24
[*NPE] commit

command on the UPE and NPE to check VPN instance configurations.
NOTE
If the UPE and NPE have multiple interfaces bound to the same VPN instance, use the -a
source-ip-address parameter to specify a source IP address when running the ping -vpn-
instance vpn-instance-name -a source-ip-address dest-ip-address command to ping the
peer CE. If the source IP address is not specified, the ping operation may fail.

(2020-10-09)
Step 5 Establish an EBGP peer relationship between the UPE and CE1 and another one
between the NPE and CE2.
# Configure CE1.
[*CE1] bgp 65410
[*CE1-bgp] network 11.11.11.11 32
[*CE1-bgp] quit
[*CE1] commit

[~UPE] bgp 100
[*UPE-bgp] router-id 1.1.1.1
[*UPE-bgp-vpna] peer 10.1.1.2 as-number 65410
[*UPE-bgp-vpna] import-route direct
[~UPE-bgp] quit
# Configure CE2.
[*CE2] bgp 65420
[*CE2-bgp] network 22.22.22.22 32
[*CE2-bgp] quit
[*CE2] commit

[~NPE] bgp 100
[*NPE-bgp] router-id 3.3.3.3
[*NPE-bgp-vpna] peer 10.2.1.2 as-number 65420
[*NPE-bgp-vpna] import-route direct
[~NPE-bgp] quit
command on the UPE and NPE to check whether BGP peer relationships have
been established. If the Established state is displayed in the command output, the
The following example uses the command output on the UPE to show that a BGP
peer relationship has been established between the UPE and CE1.
[~UPE] display bgp vpnv4 vpn-instance vpna peer


10.1.1.2 4 65410 11 9 0 00:06:37 Established 1
[~UPE] bgp 100
[~UPE-bgp] peer 2.2.2.2 as-number 100
[*UPE-bgp] peer 2.2.2.2 connect-interface loopback 1

(2020-10-09)

[*UPE-bgp-af-vpnv4] peer 2.2.2.2 enable
[*UPE-bgp-af-vpnv4] commit
[~UPE-bgp-af-vpnv4] quit
[~UPE-bgp] quit

[~SPE] bgp 100
[~SPE-bgp] peer 1.1.1.1 as-number 100
[*SPE-bgp] peer 1.1.1.1 connect-interface loopback 1
[*SPE-bgp] peer 2001:DB8:2::2 as-number 100
[*SPE-bgp] peer 2001:DB8:2::2 connect-interface loopback 1
[*SPE-bgp-af-vpnv4] peer 1.1.1.1 enable
[*SPE-bgp-af-vpnv4] peer 2001:DB8:2::2 enable
[~SPE-bgp] quit

[~NPE] bgp 100
[~NPE-bgp] peer 2001:DB8:1::1 as-number 100
[*NPE-bgp] peer 2001:DB8:1::1 connect-interface loopback 1
[*NPE-bgp-af-vpnv4] peer 2001:DB8:1::1 enable
[*NPE-bgp-af-vpnv4] commit
[~NPE-bgp] quit
on the UPE and NPE to check whether BGP peer relationships have been
established. If the Established state is displayed in the command output, the BGP
peer relationships have been established successfully.
The following example uses the command output on the UPE.
[~UPE] display bgp vpnv4 all peer


2.2.2.2 4 100 216 220 0 03:03:35 Established 2

10.1.1.2 4 65410 216 217 0 03:06:22 Established 1
Step 7 Configure SRv6 SIDs on the NPE and SPE and enable the devices to add SIDs to
VPN routes.
[*SPE-segment-routing-ipv6] encapsulation source-address 2001:DB8:1::1
[*SPE-segment-routing-ipv6] locator as1 ipv6-prefix 10:: 64 static 32
[*SPE-segment-routing-ipv6-locator] quit
[*SPE-segment-routing-ipv6] quit
[*SPE] bgp 100
[*SPE-bgp-af-vpnv4] peer 2001:DB8:2::2 prefix-sid
[*SPE-bgp-vpna] segment-routing ipv6 traffic-engineer best-effort
[*SPE-bgp-vpna] segment-routing ipv6 locator as1

(2020-10-09)
[~SPE-bgp] quit
[~SPE] isis 1
[~SPE-isis-1] segment-routing ipv6 locator as1
[*SPE-isis-1] commit
[~SPE-isis-1] quit

[*NPE-segment-routing-ipv6] encapsulation source-address 2001:DB8:2::2
[*NPE-segment-routing-ipv6] locator as1 ipv6-prefix 20:: 64 static 32
[*NPE-segment-routing-ipv6-locator] quit
[*NPE-segment-routing-ipv6] quit
[*NPE] bgp 100
[*NPE-bgp-af-vpnv4] peer 2001:DB8:1::1 prefix-sid
[*NPE-bgp-af-vpnv4] quit
[*NPE-bgp-vpna] segment-routing ipv6 traffic-engineer best-effort
[*NPE-bgp-vpna] segment-routing ipv6 locator as1
[~NPE-bgp] quit
[~NPE] isis 1
[~NPE-isis-1] segment-routing ipv6 locator as1
[*NPE-isis-1] commit
[~NPE-isis-1] quit

The following example uses the command output on the SPE.
[~SPE] display segment-routing ipv6 locator verbose
---------------------------

ArgsLength : 0
AutoSIDPoolID: 8200
Total Locator(s): 1

[~SPE] display segment-routing ipv6 local-sid end forwarding
---------------------------------

Flavor : --

Flavor : PSP
Total SID(s): 2
[~NPE] display segment-routing ipv6 local-sid end forwarding
---------------------------------

Flavor : --

(2020-10-09)
Flavor : PSP
Total SID(s): 2

[~SPE-segment-routing-ipv6] segment-list list1
[*SPE-segment-routing-ipv6-segment-list-list1] index 10 sid ipv6 20::1:0:0
[*SPE-segment-routing-ipv6-segment-list-list1] commit
[~SPE-segment-routing-ipv6-segment-list-list1] quit
[~SPE-segment-routing-ipv6] srv6-te-policy locator as1
[*SPE-segment-routing-ipv6] srv6-te policy policy1 endpoint 2001:DB8:2::2 color 101
[*SPE-segment-routing-ipv6-policy-policy1] binding-sid 10::100
[*SPE-segment-routing-ipv6-policy-policy1] candidate-path preference 100
[*SPE-segment-routing-ipv6-policy-policy1-path] segment-list list1
[*SPE-segment-routing-ipv6-policy-policy1-path] commit
[~SPE-segment-routing-ipv6-policy-policy1-path] quit
[~SPE-segment-routing-ipv6-policy-policy1] quit
[~SPE-segment-routing-ipv6] quit

[~NPE-segment-routing-ipv6] segment-list list1
[*NPE-segment-routing-ipv6-segment-list-list1] index 10 sid ipv6 10::1:0:0
[*NPE-segment-routing-ipv6-segment-list-list1] commit
[~NPE-segment-routing-ipv6-segment-list-list1] quit
[~NPE-segment-routing-ipv6] srv6-te-policy locator as1
[*NPE-segment-routing-ipv6] srv6-te policy policy1 endpoint 2001:DB8:1::1 color 101
[*NPE-segment-routing-ipv6-policy-policy1] binding-sid 20::200
[*NPE-segment-routing-ipv6-policy-policy1] candidate-path preference 100
[*NPE-segment-routing-ipv6-policy-policy1-path] segment-list list1
[*NPE-segment-routing-ipv6-policy-policy1-path] commit
[~NPE-segment-routing-ipv6-policy-policy1-path] quit
[~NPE-segment-routing-ipv6-policy-policy1] quit
[~NPE-segment-routing-ipv6] quit
The following example uses the command output on the SPE.

[~SPE] display srv6-te policy

SID :
20::1:0:0

(2020-10-09)
Step 9 Configure a tunnel policy to import traffic.

[~SPE] route-policy p1 permit node 10
[*SPE-route-policy] apply extcommunity color 0:101
[*SPE-route-policy] quit
[*SPE] bgp 100
[*SPE-bgp-af-vpnv4] peer 2001:DB8:2::2 route-policy p1 import
[*SPE-bgp] quit
[*SPE] tunnel-policy p1
[*SPE-tunnel-policy-p1] tunnel select-seq ipv6 srv6-te-policy load-balance-number 1
[*SPE-tunnel-policy-p1] quit
[*SPE] ip vpn-instance vpna
[*SPE-vpn-instance-vpna-af-ipv4] tnl-policy p1
[*SPE-vpn-instance-vpna-af-ipv4] commit
[~SPE-vpn-instance-vpna-af-ipv4] quit
[~SPE-vpn-instance-vpna] quit

[~NPE] route-policy p1 permit node 10
[*NPE-route-policy] apply extcommunity color 0:101
[*NPE-route-policy] quit
[*NPE] bgp 100
[*NPE-bgp-af-vpnv4] peer 2001:DB8:1::1 route-policy p1 import
[*NPE-bgp] quit
[*NPE] tunnel-policy p1
[*NPE-tunnel-policy-p1] tunnel select-seq ipv6 srv6-te-policy load-balance-number 1
[*NPE-tunnel-policy-p1] quit
[*NPE] ip vpn-instance vpna
[*NPE-vpn-instance-vpna-af-ipv4] tnl-policy p1
[*NPE-vpn-instance-vpna-af-ipv4] commit
[~NPE-vpn-instance-vpna-af-ipv4] quit
[~NPE-vpn-instance-vpna] quit

command output shows that the corresponding route has successfully recursed to
the SRv6 TE Policy.
The following example uses the command output on the SPE and NPE.
[~SPE] display ip routing-table vpn-instance vpna
------------------------------------------------------------------------------

10.2.1.0/24 IBGP 255 0 RD 2001:DB8:2::2 policy1
22.22.22.22/32 IBGP 255 0 RD 2001:DB8:2::2 policy1
[~NPE] display ip routing-table vpn-instance vpna 22.22.22.22 verbose
------------------------------------------------------------------------------
Summary Count : 1

(2020-10-09)
NextHop: 2001:DB8:2::2 Neighbour: 2001:DB8:2::2
RelayNextHop: 2001:DB8:2::2 Interface: policy1
[~SPE] bgp 100
[*SPE-bgp-af-vpnv4] peer 1.1.1.1 upe
[*SPE-bgp-af-vpnv4] peer 1.1.1.1 default-originate vpn-instance vpna
[~SPE-bgp] quit
Step 11 Configure the SPE to advertise regenerated routes to the NPE.

[~SPE] bgp 100
[~SPE-bgp] ipv4-family vpn-instance vpna
[*SPE-bgp-vpna] advertise best-route route-reoriginate
[*SPE-bgp-af-vpnv4] peer 2001:DB8:2::2 advertise route-reoriginated vpnv4
[~SPE-bgp] quit
# Check the routing tables of the SPE and NPE.

[~SPE] display bgp vpnv4 all routing-table 10.1.1.2

From: 1.1.1.1 (10.1.1.2)
cost 10

From: 1.1.1.1 (10.1.1.2)
AS-path Nil, origin incomplete, MED 0, localpref 100, pref-val 0, valid, internal, best, select, pre 255,
reoriginated, IGP cost 10
2001:DB8:2::2

(2020-10-09)
VPN-Instance 1, Router ID 2.2.2.2:

Remote-Cross route
From: 1.1.1.1 (10.1.1.2)
cost 10
[~UPE] display ip routing-table vpn-instance vpna
------------------------------------------------------------------------------

# Check that CE1 can ping CE2 successfully.

[~CE1] ping -a 11.11.11.11 22.22.22.22

0.00% packet loss
----End
Configuration Files
#
sysname UPE
#
ipv4-family
#
mpls lsr-id 1.1.1.1
#
mpls
#
mpls ldp
#
ipv4-family

(2020-10-09)
#
isis 1
is-level level-1
cost-style wide
mpls ldp auto-config
network-entity 10.0000.0000.0001.00
#
#
undo shutdown
ip address 10.1.2.1 255.255.255.0
isis enable 1
mpls
mpls ldp
dcn
#
undo shutdown
ip address 10.1.1.1 255.255.255.0
#
interface LoopBack1
ip address 1.1.1.1 255.255.255.255
isis enable 1
#
bgp 100
router-id 1.1.1.1
#
ipv4-family unicast
peer 2.2.2.2 enable
#
ipv4-family vpnv4
policy vpn-target
peer 2.2.2.2 enable
#
import-route direct
#
return

#
sysname SPE
#
ipv4-family
tnl-policy p1
#
mpls lsr-id 2.2.2.2
#
mpls
#
mpls ldp
#
ipv4-family
#
locator asl ipv6-prefix 10:: 64 static 32
srv6-te-policy locator asl
segment-list list1
index 10 sid ipv6 20::1:0:0

(2020-10-09)
binding-sid 10::100
segment-list list1
#
isis 1
is-level level-1
cost-style wide
mpls ldp auto-config
network-entity 10.0000.0000.0002.00
#
segment-routing ipv6 locator asl
#
#
undo shutdown
ip address 10.1.2.2 255.255.255.0
isis enable 1
mpls
mpls ldp
#
undo shutdown
ipv6 enable
ipv6 address 2001:DB8:2001::1/96
isis ipv6 enable 1
#
interface LoopBack1
ipv6 enable
ip address 2.2.2.2 255.255.255.255
isis enable 1
isis ipv6 enable 1
#
bgp 100
#
ipv4-family unicast
peer 1.1.1.1 enable
#
ipv4-family vpnv4
policy vpn-target
peer 1.1.1.1 enable
peer 1.1.1.1 upe
peer 1.1.1.1 default-originate vpn-instance vpna
peer 2001:DB8:2::2 advertise route-reoriginated vpnv4
#
advertise best-route route-reoriginate
segment-routing ipv6 locator asl
#
#
tunnel-policy p1
#
return

#
sysname NPE

(2020-10-09)
#
ipv4-family
tnl-policy p1
#
segment-list list1
index 10 sid ipv6 10::1:0:0
binding-sid 20::200
segment-list list1
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0003.00
#
#
#
undo shutdown
ipv6 enable
ipv6 address 2001:db8:2001::2/96
isis ipv6 enable 1
#
undo shutdown
ip address 10.2.1.1 255.255.255.0
#
interface LoopBack1
ipv6 enable
ip address 3.3.3.3/32
isis ipv6 enable 1
#
bgp 100
router-id 3.3.3.3
#
ipv4-family unicast
#
ipv6-family unicast
#
ipv4-family vpnv4
policy vpn-target
#
import-route direct
#

(2020-10-09)

#
tunnel-policy p1
#
return

#
sysname CE1
#
undo shutdown
ip address 10.1.1.2 255.255.255.0
#
interface LoopBack1
ip address 11.11.11.11 255.255.255.255
#
bgp 65410
#
ipv4-family unicast
network 11.11.11.11 255.255.255.255
#
return

#
sysname CE2
#
undo shutdown
ip address 10.2.1.2 255.255.255.0
#
interface LoopBack1
ip address 22.22.22.22 255.255.255.255
#
bgp 65420
#
ipv4-family unicast
network 22.22.22.22 255.255.255.255
#
return

(2020-10-09)
New IP Technologies 3 EVPN
3 EVPN
3.1 EVPN Description
3.1.1 Overview of EVPN
Definition
Ethernet virtual private network (EVPN) is used for Layer 2 internetworking. EVPN
is similar to BGP/MPLS IP VPN. Using extended BGP reachability information,
EVPN implements MAC address learning and advertisement between Layer 2
networks at different sites on the control plane instead of on the data plane.
Purpose
As services grow rapidly, different sites have an increasingly strong need for Layer
2 interworking. VPLS, which is generally used for such a purpose, has the following
shortcomings:
● Lack of support for load balancing: VPLS does not support traffic load
balancing in multi-homing networking scenarios.
● High network resource usage: Interworking between sites requires all PEs
serving these sites on the ISP backbone network to be fully meshed, with PWs
established between any two PEs. If a large number of PEs exist, PW
establishment will consume a significant amount of network resources. In
addition, a large number of ARP messages must be transmitted for MAC
address learning. These ARP messages not only consume network bandwidth
but may also consume CPU resources on remote sites that do not need to
learn the MAC addresses carried in them.
EVPN solves the preceding problems with the following characteristics:

● EVPN uses extended BGP to implement MAC address learning and
advertisement on the control plane instead of on the data plane. This function
allows a device to manage MAC addresses in the same way as it manages
routes, implementing load balancing between EVPN routes with the same
destination MAC address but different next hops.

(2020-10-09)
● EVPN does not require PEs on the ISP backbone network to be fully meshed.
PEs on an EVPN use BGP to communicate, and BGP provides the route
reflection function. PEs can establish BGP peer relationships only with RRs
deployed on the ISP backbone network, with RRs reflecting EVPN routes. This
implementation significantly reduces network complexity and minimizes the
number of network signaling messages.
● EVPN enables PEs to use ARP to learn the local MAC addresses and use
MAC/IP address advertisement routes to learn remote MAC addresses and IP
addresses corresponding to these MAC addresses, and store them locally.
After receiving another ARP request, a PE searches the locally cached MAC
address and IP address based on the destination IP address in the ARP
request. If the corresponding information is found, the PE returns an ARP
reply packet. This prevents ARP request packets from being broadcast to other
PEs, therefore reducing network resource consumption.
Benefits
EVPN offers the following benefits:
● Improved link usage and transmission efficiency: EVPN supports load
balancing, fully utilizing network resources and reducing network congestion.
● Reduced network resource consumption: By deploying RRs on the public
network, EVPN decreases the number of logical connections required between
PEs on the public network.
● Reduces network resource consumption caused by ARP broadcast traffic: PEs
can respond to ARP requests from local sites based on locally cached MAC
addresses, preventing large-scale ARP request broadcast.
3.1.2 EVPN Fundamentals
Typical EVPN Networking

As shown in Figure 3-1, an EVPN has a similar network structure to a BGP/MPLS
IP VPN. In EVPN networking, to implement interconnection between sites, PEs
have an EVPN instance created on a carrier backbone network, connect to CEs at
different sites, and establish EVPN BGP peer relationships and MPLS/SR tunnels
with each other. Different from a BGP/MPLS IP VPN, an EVPN uses Layer 2
networks within sites. As such, a PE learns MAC addresses rather than IP routes
from the CEs at a site, and then advertises these MAC addresses to the other sites
within the same EVPN instance using EVPN-specific routes.
In EVPN networking, a CE can be single-homed to one PE or multi-homed to

several PEs. As shown in Figure 3-1, CE1, CE2, and CE4 are single-homed to PE1,
while CE3 is multi-homed to PE2 and PE3. Load balancing is supported in CE
multi-homing networking.
EVPN technology defines a unique Ethernet Segment Identifier (ESI) on PEs to

identify connections to the same CE. The PE interfaces must use the same ESI to
connect to a CE and different ESIs to different CEs. During route advertisement
between PEs, a PE can be aware of the other PEs connecting to the same CE after
receiving routes that carry the same ESI.

(2020-10-09)
Figure 3-1 EVPN networking
NOTE
A PE can use both IPv4 and IPv6 addresses to establish EVPN peer relationships with the
other PEs. MPLS/VXLAN/SR tunnels can be deployed between IPv4 EVPN peers to carry
services, and SRv6 tunnels need to be deployed between IPv6 EVPN peers to carry services.
A PE sends the EVPN routes that carry SIDs only to IPv6 EVPN peers and the EVPN routes
that do not carry SIDs only to IPv4 EVPN peers.
EVPN Routes
To enable sites to learn MAC addresses from each other, EVPN defines a new type
of BGP network layer reachability information (NLRI), also known as the EVPN
NLRI. An EVPN NLRI can be one of the following EVPN routes:
● Ethernet auto-discovery route: also known as the Ethernet A-D route. PEs
advertise Ethernet auto-discovery routes after establishing an EVPN BGP peer
relationship. A local PE advertises such routes to other PEs to notify the
reachability of MAC addresses of sites connected to the local PE. Ethernet A-D
routes are classified into per-ES routes and per-EVI routes. Ethernet A-D per-
ES routes are used for fast convergence, redundancy mode, and split horizon.
Ethernet A-D per-EVI (EVPN Instance) routes are used for aliasing. Figure 3-2
shows the NLRI of an Ethernet A-D route.

(2020-10-09)
Figure 3-2 NLRI of an Ethernet A-D route
The description of each field is as follows:

– Route Distinguisher: In an Ethernet A-D per-ES route, this field contains
the source IP address set on a PE, for example, X.X.X.X:0. In an Ethernet
A-D per-EVI route, this field is the RD of an EVPN instance.
– Ethernet Segment Identifier: uniquely identifies connections between PEs
and a CE.
– Ethernet Tag ID: The value of the field is all Fs in Ethernet A-D per-ES
routes. In an Ethernet A-D per-EVI route, this field identifies a sub-
broadcast domain in an ES. If this field is set to all 0s, the EVI contains
only one broadcast domain.
– MPLS Label: The value is all 0s for Ethernet A-D per-ES routes, in
compliance with the standard. The value of this field for Ethernet A-D
per-EVI routes is the MPLS label used to forward unicast traffic in load
balancing mode.
NOTE
Although the MPLS Label field of a per-ES route is all 0s according to the
standard, by default, a device sets the MPLS Label field to an ESI label value.
After the peer esad-route-compatible enable command is run on a device, the
device advertises the Ethernet A-D per-ES routes with the MPLS Label field
changed to all 0s.
● MAC/IP advertisement route: also known as the MAC/IP route. A MAC/IP
advertisement route can carry the RD and ESI of an EVPN instance configured
on the local PE and the VPN label assigned to the EVPN instance. Figure 3-3
shows the NLRI of a MAC/IP advertisement route. The MAC/IP advertisement
route contains information, such as the RTs and next hop of the EVPN
instance, in addition to the NLRI. This type of route can be used for the local
PE to advertise unicast MAC/IP address reachability to the other PEs. For
details, see Unicast MAC Address Transmission.

(2020-10-09)
Figure 3-3 NLRI of a MAC/IP advertisement route

– Route Distinguisher: RD of an EVPN instance.
and a CE.
– Ethernet Tag ID: The value is all 0s in regular scenarios, the same as the
local service ID in an EVPN VPWS scenario, or the same as the BD tag
value in VLAN-aware BD EVPN access scenarios.
– MAC Address Length: length of a MAC address advertised in the route.
– MAC Address: MAC address advertised in the route.
– IP Address Length: mask length of a host IP address advertised in the
route.
– IP Address: host IP address advertised in the route.
– MPLS Label1: label used for Layer 2 service traffic forwarding.
– MPLS Label2: label used for Layer 3 service traffic forwarding.
The functions of MAC/IP advertisement routes on the control plane are as
follows:
– Host MAC address advertisement
To implement Layer 2 service exchanges between hosts connected to two
PEs, the two PEs need to learn host MAC addresses from each other. After
a BGP EVPN peer relationship is established between the PEs, they
exchange MAC/IP advertisement routes to advertise host IPv4 addresses
to each other. The MAC Address Length and MAC Address fields identify a
host MAC address.
– Host ARP advertisement
A MAC/IP advertisement route carries both the MAC address and IP
address of a host. Therefore, this route can be used to transmit host ARP
entries between PEs. The MAC Address and MAC Address Length fields
identify a host MAC address, and the IP Address and IP Address Length
fields identify a host IP address. In this case, MAC/IP advertisement routes
are also called ARP routes.

(2020-10-09)
– Host IP route advertisement

To implement Layer 3 service exchanges between IPv4 hosts connected to
two PEs, the two PEs need to learn host IPv4 routes from each other.
After a BGP EVPN peer relationship is established between the PEs, they
to each other. The IP Address Length and IP Address fields carried in a
MAC/IP advertisement route identify a host destination address, and the
MPLS Label2 field must carry a label used for Layer 3 service forwarding.
In such a scenario, MAC/IP advertisement routes are also called Integrate
Routing and Bridge (IRB) routes.
NOTE
An ARP route carries the following valid information: host MAC address, host IP
address, and Layer 2 traffic forwarding label. IRB routes carry the following valid
information: host MAC address, host IP address, Layer 2 traffic forwarding label,
and Layer 3 traffic forwarding label. As a result, IRB routes include ARP routes
and can be used to advertise both the host IP routes and host ARP entries.
– Host ND information advertisement
A MAC/IP advertisement route can carry both a host MAC address and a
host IPv6 address. Such routes can be used to transmit and advertise host
ND entries between PEs. The MAC Address and MAC Address Length
fields identify a host MAC address, and the IP Address and IP Address
Length fields identify a host IPv6 address. In such a scenario, MAC/IP
advertisement routes are also called ND routes.
– Host IPv6 route advertisement
To implement Layer 3 service exchanges between IPv6 hosts connected to
two PEs, the two PEs need to learn host IPv6 routes from each other.
After a BGP EVPN peer relationship is established between the PEs, they
to each other. The IP Address Length and IP Address fields carried in the
MAC/IP advertisement route identify a host IPv6 destination address, and
the MPLS Label2 field must carry a label used for Layer 3 service traffic
forwarding. In such a scenario, MAC/IP advertisement routes are also
called IRBv6 routes.
NOTE
An ND route carries the following valid information: host MAC address, host IPv6
address, and L2VNI. An IRBv6 route carries the following valid information: host
MAC address, host IPv6 address, L2VNI, and L3VNI. As such, IRBv6 routes include
ND routes and can be used to advertise both a host IPv6 route and ND entry.
● Inclusive multicast Ethernet tag route: also known as the IMET route. After a
BGP peer relationship is established between PEs, the PEs exchange inclusive
multicast routes. An inclusive multicast route carries the RD and route target
(RT) of the EVPN instance on the local PE, source IP address (loopback
address of the local PE) and provider multicast service interface (PMSI)
information. The PMSI tunnel is used to carry the tunnel type (ingress
replication or mLDP) and tunnel label used to transmit multicast packets. The
PMSI and RT values are carried in routes as attributes, and the RD and source
IP address are contained in NLRI information. Figure 3-4 shows the NLRI of
an inclusive multicast route. BUM traffic includes broadcast, multicast, and
unknown unicast traffic. Upon receipt of BUM traffic, a PE forwards it to the

(2020-10-09)
other PEs in P2MP mode. The PEs use the inclusive multicast routes to
establish tunnels. For details, see BUM Packet Transmission.
Figure 3-4 NLRI of an inclusive multicast route

– Ethernet Tag ID: The value is all 0s in regular scenarios, the same as the
local service ID in an EVPN VPWS scenario , or the same as the BD tag
value in VLAN-aware BD EVPN access scenarios.
– IP Address Length: length of a source IP address configured on the local
PE.
– Originating Router's IP Address: source IP address configured on the local
PE.
● Ethernet segment route: carries the ESI, source IP address, and RD (source IP
address:0) of the local PE. PEs connecting to the same CE use Ethernet
segment routes to discover each other. This type of route is used in
designated forwarder (DF) election. Figure 3-5 shows the NLRI of an Ethernet
segment route.
Figure 3-5 NLRI of an Ethernet segment route

– Route Distinguisher: in the format of X.X.X.X:0. X.X.X.X indicates the EVPN
source IP address configured on the local PE.
and a CE.
PE.
PE.

(2020-10-09)
● IP prefix route: used to advertise a host IP address received from an access

network or the network segment where the host IP address resides. Figure
3-6 shows the NLRI of an IP prefix route.
Figure 3-6 NLRI of an IP prefix route

and a CE.
– Ethernet Tag ID: Currently, this field can only be set to 0.
– IP Prefix Length: mask length of an IP prefix carried in the route.
– IP Prefix: IP prefix address.
– GW IP Address: default gateway IP address.
– MPLS Label: label used for Layer 3 service traffic forwarding.
Unicast MAC Address Advertisement

As shown in Figure 3-7, the process of advertising a unicast MAC address is as
follows:
1. Site 1 sends an ARP Request message or a gratuitous ARP message to
advertise its MAC address (MAC A) and IP address to site 2. After the message
arrives at PE1, PE1 generates a MAC/IP advertisement route for MAC A.Site
2. Site 2 responds to site 1 with an ARP Response message or a gratuitous ARP
message carrying site 2's MAC address (MAC B) and IP address. After the
message arrives at PE2, PE2 generates a MAC/IP advertisement route for
MAC B.
3. PE1 and PE2 exchange MAC/IP advertisement routes that carry MAC
addresses, next hops, and EVPN instance-based extended community
attributes (such as RTs).
4. After PE1 and PE2 receive MAC/IP advertisement routes from each other,
PE1 and PE2 find the corresponding EVPN instances based on the RT values
carried in the routes. Then, PE1 and PE2 generate traffic forwarding entries in
the EVPN instances based on the NLRIs carried in the routes for traffic
transmission.

(2020-10-09)
Figure 3-7 Unicast MAC address advertisement
Unicast packet transmission

As shown in Figure 3-8, after a local PE learns a MAC address from another site
and successfully establishes a tunnel to the site over the public network, the local
PE can transmit unicast packets to the site. The detailed transmission process is as
follows:
1. CE2 forwards unicast packets to PE2 at Layer 2.
2. Upon receipt of the unicast packets, PE2 encapsulates an EVPN label, a
public-network LDP LSP label, PE2's MAC address, and PE1's MAC address in
the order into the unicast packets. PE2 then forwards the encapsulated
unicast packets to PE1.
3. After receiving the unicast packet after encapsulation, PE1 decapsulates the
packet, locates the EVPN instance based on the EVPN label, searches the MAC
table of the EVPN instance for an outbound interface mapped to the
destination MAC address in the original packet, and forwards the unicast
packet to the corresponding CE through the outbound interface.
Figure 3-8 Unicast packet transmission

(2020-10-09)
BUM Packet Transmission

After two PEs establish an EVPN BGP peer relationship, they exchange inclusive
multicast routes. A PE can discover PEs that belong to the same EVPN instance as
itself after matching RTs in the received inclusive multicast routes against the
local EVPN instance, which enables the PE to obtain information about
reachability to these PEs. This PE then automatically establishes MPLS tunnels
with these PEs to carry BUM packets. On the network shown in Figure 3-9, BUM
packets are transmitted as follows:
1. CE1 sends BUM packets to PE1.
2. Upon receipt of the BUM packets, PE1 forwards them to PE2 and PE3 that
belong to the same EVPN instance. Specifically, PE1 replicates each BUM
packet and encapsulates an EVPN BUM label, public network tunnel label,
PE1's MAC address, and P's MAC address into each packet, and sends the
packets to the remote PE.
3. Upon receipt of the BUM packets, PE2 and PE3 decapsulate the BUM packets
and send the BUM packets to the sites of the EVPN identified by the EVPN
BUM label carried in the packets.
Figure 3-9 BUM packet transmission networking
In the case where a CE is dual-homed to two PEs, based on the split horizon
mechanism, an EVPN ESI label will be encapsulated into the BUM packets
exchanged between the two PEs to prevent loops. As shown in Figure 3-10, CE1 is
dual-homed to PE1 and PE2. After receiving a BUM packet from CE1, PE1
encapsulates the packet with an ESI and forwards the packet to PE2. When PE2
receives the BUM packet and finds that the ESI carried in the BUM packet is the
same as the local ESI, PE2 discards the BUM packet to prevent a loop.

(2020-10-09)
Figure 3-10 Using an ESI to prevent loops
3.1.3 EVPN-MPLS
3.1.3.1 EVPN Multi-Homing
Related Concepts
Interface-based and VLAN-based DF election
As shown in Figure 3-11, CE1 is dual-homed to PE1 and PE2. CE2 sends BUM
traffic to PE1 and PE2. To prevent CE1 from receiving duplicate traffic from both
PE1 and PE2, the EVPN DF election mechanism is introduced to specify either PE1
or PE2 to forward BUM traffic to CE1. If PE1 is elected, it becomes the primary DF,
with PE2 functioning as the backup DF. The primary DF forwards BUM traffic from
CE2 to CE1.
If a PE interface connecting to a CE goes down, the PE becomes a backup DF. If a

PE interface connecting to a CE goes up, the PE and other PEs with up interfaces
elect a primary DF. The DF election process is as follows:
1. The PEs establish EVPN BGP peer relationships with each other and then
exchange Ethernet segment routes.
2. Upon receipt of the Ethernet segment routes, each PE generates a multi-
homing PE list based on the ESIs carried in the routes. Each multi-homing PE
list contains information about all PEs connecting to the same CE.
3. Each PE then sequences the PEs in each multi-homing PE list based on the
source IP addresses carried in Ethernet segment routes. The PEs are
numbered in ascending order from 0.
4. If interface-based DF election is enabled, the PE with the smallest source IP
address is elected to be the primary DF. If VLAN-based DF election is enabled,
the PE with a specific sequence number is elected to be the primary DF. The
sequence number is calculated using the following expression formula: (V
mod N) = i, in which i indicates a PE's sequence number, N indicates the
number of PEs to which a CE is multi-homed, and V indicates the VLAN ID
over an Ethernet segment.

(2020-10-09)
NOTE
If an Ethernet segment has multiple VLANs bound to, the smallest VLAN ID is used as
the value for V.
Figure 3-11 DF election diagram
ESI-based DF priority election

On the network shown in Figure 3-12, CE1 and CE2 are each dual-homed to PE1
and PE2. The PE interfaces that connect to CE1 have ESI 1 (shown in green), and
the PE interfaces that connect to CE2 have ESI 2 (shown in blue). If you want CE3-
to-CE1 BUM traffic and CE3-to-CE2 BUM traffic to be transmitted in load
balancing and non-load balancing mode, respectively, you can set a redundancy
mode per ESI instance. Specifically, you can set the redundancy mode of the ESI 1
instance to all-active and that of the ESI 2 instance to single-active.
If you want CE3-to-CE2 BUM traffic to be forwarded by PE1, configure ESI-based
DF priority election on PE1 and PE2 and specify PE1 as the primary DF.
Figure 3-12 ESI-based DF priority election diagram
AC interface influenced DF election

In CE dual-homing networking, an AC interface's sub-interfaces on the access side
are bound to an EVPN instance. If an ESI is set on the interface and one of the

(2020-10-09)
sub-interfaces goes down due to a fault or some other reason, the ESI remains
valid because the other sub-interfaces bound to the EVPN instance remain up. As
a result, the PE does not regenerate ES routes to trigger DF election, which may
prevent the BUM traffic from being forwarded.
To resolve this issue, enable the function that the AC interface status influences DF
election. This configuration helps check whether the PE has received the auto
discovery (AD) routes from all PEs during DF election to determine whether these
PEs are qualified for DF election. If a PE has not received the AD routes from a
peer PE, the peer PE cannot participate in DF election.
Split horizon
On the network shown in Figure 3-13, CE1 is dual-homed to PE1 and PE2 and has
load balancing enabled. If PE1 and PE2 have established an EVPN BGP peer
relationship, after PE1 receives BUM traffic from CE1, it forwards the BUM traffic
to PE2. To prevent this problem, EVPN uses split horizon. After PE1 forwards the
BUM traffic to PE2, PE2 checks the EVPN ESI label carried in the traffic. If the ESI
carried in the label equals the ESI for the link between PE2 and CE1, PE2 does not
forward the traffic to CE1, preventing a loop.
Figure 3-13 Split horizon diagram
Redundancy mode and aliasing
If a CE is multi-homed to several PEs, a redundancy mode can be set to all-active

or single-active for PEs connecting to the same CE. The redundancy mode
determines whether load balancing is implemented for unicast traffic in CE multi-
homing scenarios. If PE1 and PE2 are configured to work in all-active mode, after
PE1 and PE2 send Ethernet A-D routes carrying the redundancy mode
information to PE3, PE3 sends unicast traffic destined for CE1 to both PE1 and PE2
in load balancing mode.
EVPN also supports aliasing. When a CE is multi-homed to several PEs that work
in all-active mode, some PEs may fail to learn the MAC addresses on the CE side.
Aliasing enables remote PEs to learn the reachability to CE-side MAC addresses
based on the ESIs carried in Ethernet A-D routes received from the multi-homing
PEs. On the network shown in Figure 3-14, only PE1 sends MAC/IP
advertisement routes carrying CE1-side MAC addresses to PE3. However, PE3 can

(2020-10-09)
use Ethernet A-D routes to detect that PE2 can also reach CE1, implementing
load balancing.
Figure 3-14 Redundancy mode and aliasing
Rapid convergence
On the network shown in Figure 3-15, if the link between CE1 and PE1 fails, PE1
advertises an Ethernet A-D route to PE3 to inform that PE1 has become
unreachable to site 1. Upon receipt of the route, PE3 withdraws the corresponding
route and sends traffic to site 1 only through PE2, implementing rapid route
convergence.
Figure 3-15 Rapid route convergence
3.1.3.2 Fundamentals of EVPN Seamless MPLS

EVPN seamless MPLS establishes a BGP LSP across the access, aggregation, and
core layers and transmits services along this BGP LSP in E2E mode. Service traffic
can be transmitted between any two points over the LSP. The EVPN seamless
MPLS network architecture maximizes service scalability using the following
functions:
● Allows access nodes to signal all services to an LSP.

(2020-10-09)
● Uses the same transport layer convergence technology to converge services in

case of any network-side faults, without affecting service transmission.
Background
The popularity of EVPN MPLS networks poses increasing requirements for the
service scalability of the network architecture. The different metro networks of a
service provider or the collaborative backbone networks of different service
providers often span multiple ASs. In this case, EVPN seamless MPLS can be used
to establish an inter-AS E2E BGP LSP to carry EVPN services.
Implementation
On a seamless MPLS network, the EVPN services to be transmitted need to be
encapsulated using signaling only at service access points. In addition, if a
network-side fault triggers EVPN service convergence, the same transport layer
convergence technology is used to converge the services, without the service layer
being aware of the fault.
Application Scenarios
EVPN seamless MPLS supports the following networking solutions:
● EVPN intra-AS seamless MPLS: The access, aggregation, and core layers are
deployed within a single AS. This solution mainly applies to mobile transport
networks.
● EVPN inter-AS seamless MPLS: The access and aggregation layers are
deployed in a single AS, whereas the core layer is deployed in a different AS.
This solution mainly applies to enterprise networks.

(2020-10-09)
EVPN Intra-AS Seamless MPLS
Table 3-1 EVPN intra-AS seamless MPLS networking

Network Description
Deployment
Deployin In Figure 3-16, routing protocol deployment on devices

g routing is as follows:
protocols ● An IGP (IS-IS or OSPF) is enabled on devices at each
of the access, aggregation, and core layers to
implement intra-AS network connectivity.
● An IBGP peer relationship is established between
each of the following pairs of devices:
– CSG and AGG
– AGG and core ABR
– Core ABR and MASG
The AGGs and core ABRs are configured as RRs to
reflect routes to CSGs and MASGs, respectively, so
that the CSGs and MASGs can obtain the route to
each other's loopback address.
● The AGGs and core ABRs set the next-hop IP
Control
addresses in BGP routes to their own addresses to
plane
prevent the public routes of other IGP areas from
being advertised.
Figure 3-16 Deploying routing protocols for the EVPN

intra-AS seamless MPLS networking

(2020-10-09)
Network Description
Deployment
BGP As shown in Figure 3-16, AGGs and core ABRs function

EVPN as RRs. BGP EVPN peer relationships need to be
peer established between CSGs and AGGs, between MASGs
relationsh and core ABRs, and between AGGs and core ABRs. Then,
ip EVPN MAC/IP routes (Type 2) and IP prefix routes (Type
establish 5) need to be transmitted between the peers to
ment and transmit MAC and IP routing information.
route
advertise
ment
Deployin On the network shown in Figure 3-17, tunnels are

g tunnels deployed as follows:
● A public network tunnel is established using LDP, TE,
or LDP over TE in each IGP area.
● An IBGP peer relationship is established between
each of the following pairs of devices:
– CSG and AGG
– AGG and core ABR
– Core ABR and MASG
These devices are enabled to advertise labeled routes
and assign labels to BGP routes that match a
specified route-policy. After the devices exchange
labeled BGP routes, an E2E BGP LSP is established
between each pair of a CSG and MASG.
Figure 3-17 Deploying tunnels for the EVPN intra-AS

seamless MPLS networking

(2020-10-09)
Network Description
Deployment
Figure 3-18 illustrates the forwarding plane of EVPN

intra-AS seamless MPLS networking. Seamless MPLS is
mainly used to transmit EVPN packets. The following
example demonstrates how EVPN packets, including
labels and packet content, are transmitted from a CSG
to an MASG along the path CSG1->AGG1->core ABR1-
>MASG1.
1. The CSG pushes a BGP LSP label and an MPLS tunnel
label in sequence into each EVPN packet and
forwards the packets to the AGG.
2. Upon receipt, the AGG removes the access-layer
MPLS tunnel labels from the packets and swaps the
existing BGP LSP labels for new labels. The AGG then
pushes an aggregation-layer MPLS tunnel label into
each packet and proceeds to forward the packets to
the core ABR. If the penultimate hop popping (PHP)
Forwarding plane
function is enabled on the AGG, the CSG has
removed the MPLS tunnel labels from the packets,
and therefore, the AGG receives packets without
MPLS tunnel labels.
3. Upon receipt, the core ABR removes aggregation-
layer MPLS tunnel labels from the EVPN packets and
swaps the existing BGP LSP labels for new labels. The
core ABR pushes a core-layer MPLS tunnel label to
each packet and forwards the packets to the MASG.
4. The MASG removes MPLS tunnel labels and BGP LSP
labels from the EVPN packets. If the PHP function is
enabled on the MASG, the core ABR has removed the
core-layer MPLS tunnel labels from the packets, and
therefore, the MASG receives packets without MPLS
tunnel labels. The EVPN packet transmission along
the intra-AS seamless MPLS LSP is complete.

(2020-10-09)
Network Description
Deployment
Figure 3-18 Forwarding plane for the EVPN intra-AS


(2020-10-09)
EVPN Inter-AS Seamless MPLS
Table 3-2 EVPN inter-AS seamless MPLS networking

Network Description
Deployment
Deployin In Figure 3-19, routing protocol deployment on devices

g routing is as follows:
protocols ● An IGP (IS-IS or OSPF) is enabled on devices at each
of access, aggregation, and core layers to implement
intra-AS network connectivity.
● A BGP peer relationship is established between each
of the following pairs of devices:
– CSG and AGG
– AGG and AGG ASBR
– AGG ASBR and core ASBR
– Core ASBR and MASG
An EBGP peer relationship is established between the
AGG ASBR and core ASBR, and IBGP peer
relationships are established between the other pairs
of devices.
● The AGGs are configured as RRs to reflect routes so
that IBGP peers can exchange BGP routes, and the
Control CSGs and MASGs can obtain BGP routes destined for
plane each other's loopback addresses.
● If the AGG ASBR and core ASBR are connected
indirectly, an IGP neighbor relationship between them
must be established to implement inter-area
connectivity.
Figure 3-19 Deploying routing protocols for the EVPN

inter-AS seamless MPLS networking

(2020-10-09)
Network Description
Deployment
BGP On the network shown in Figure 3-19, BGP EVPN peer

EVPN relationships need to be established between the
peer following pairs of devices:
relations ● CSG and AGG
hip
establish ● AGG and AGG ASBR
ment ● AGG ASBR and core ASBR
and ● Core ASBR and MASG
route
advertise The peers exchange MAC/IP routes (Type 2) and IP
ment prefix routes (Type 5) to advertise MAC and IP routing
information.

(2020-10-09)
Network Description
Deployment
Deployin On the network shown in Figure 3-20, tunnels are

g tunnels deployed as follows:
● A public network tunnel is established using LDP, TE,
or LDP over TE in each IGP area. An LDP LSP or a TE
LSP must be established if more than one hop exists
between each pair of an AGG ASBR and core ASBR.
● The CSGs, AGGs, AGG ASBRs, and core ASBRs are
enabled to advertise labeled routes and assign labels
to BGP routes that match a specified route-policy.
After the devices exchange labeled BGP routes, a BGP
LSP is established between each pair of a CSG and
core ASBR.
● Either of the following tunnel deployment methods
can be used in the core area:
– A BGP LSP between a core ASBR and MASG is
combined with the BGP LSP between the CSG and
core ASBR to form an E2E BGP LSP. The route to
the MASG's loopback address is installed into the
BGP routing table and advertised to the core ASBR
using the IBGP peer relationship. The core ASBR
assigns a label to the route and advertises the
labeled route to the AGG ASBR.
– No BGP LSP is established between the core ASBR
and MASG. The core ASBR runs an IGP to learn
the route destined for the MASG's loopback
address and installs the route to the routing table.
The core ASBR assigns a BGP label to the route
and associates the route with an intra-AS MPLS
tunnel. The BGP LSP between the CSG and core
ASBR and the MPLS tunnel in the core area are
combined into an E2E tunnel.
Figure 3-20 Deploying tunnels for the EVPN inter-AS


(2020-10-09)
Network Description
Deployment
Figure 3-21 illustrates the forwarding plane of the EVPN

inter-AS seamless MPLS networking with a core-layer
BGP LSP established. EVPN seamless MPLS is mainly
used to transmit EVPN packets. The following example
demonstrates how EVPN packets, including VPN labels
and packet data, are transmitted from a CSG to an
MASG along the path CSG1->AGG1->AGG ASBR1->core
ASBR1->MASG1.
1. The CSG pushes a BGP LSP label and an MPLS tunnel
label in sequence into each EVPN packet and
forwards the packets to the AGG.
2. Upon receipt, the AGG removes the access-layer
MPLS tunnel labels from the packets and swaps the
existing BGP LSP labels for new labels. The AGG then
pushes an aggregation-layer MPLS tunnel label into
each packet and proceeds to forward the packets to
the AGG ASBR. If the PHP function is enabled on the
AGG, the CSG has removed the MPLS tunnel labels
from the packets, and therefore, the AGG receives
packets without MPLS tunnel labels.
Forwarding plane
3. Upon receipt, the AGG ASBR removes the MPLS
tunnel labels from the EVPN packets and swaps the
existing BGP LSP label for a new label in each packet.
It then forwards the packets to the core ASBR. If the
PHP function is enabled on the AGG ASBR, the AGG
has removed the MPLS tunnel labels from the
packets, and therefore, the AGG ASBR receives
packets without MPLS tunnel labels.
4. Upon receipt, the core ASBR swaps a BGP LSP label
for a new label and pushes a core-layer MPLS tunnel
label into each packet. It then forwards the packets
to the MASG.
5. Upon receipt, the MASG removes MPLS tunnel labels,
BGP LSP labels, and VPN labels from the packets. If
the PHP function is enabled on the MASG, the core
ASBR has removed the MPLS tunnel labels from the
packets, and therefore, the MASG receives packets
without MPLS tunnel labels. The EVPN packet
transmission along the inter-AS seamless MPLS LSP is
complete.

(2020-10-09)
Network Description
Deployment
Figure 3-21 Forwarding plane for the EVPN inter-AS

seamless MPLS networking with a core-layer BGP LSP
established
Figure 3-22 illustrates the forwarding plane for the

EVPN inter-AS seamless MPLS networking without a
BGP LSP established in the core area. The process of
transmitting EVPN packets on this network is similar to
that on a network with a BGP LSP established in the
core area. The difference is that without a BGP LSP in
the core area, the core ASBR removes (rather than
swaps) BGP labels from packets and pushes MPLS
tunnel labels into these packets.
Figure 3-22 Forwarding plane for the EVPN inter-AS

seamless MPLS networking without a BGP LSP
established in the core area

(2020-10-09)
Reliability
EVPN seamless MPLS network reliability can be improved using a variety of
functions. If a network fault occurs, devices with reliability functions enabled
immediately detect the fault and switch traffic from the active link to the standby
link.
The following examples demonstrate the reliability functions used on an EVPN
inter-AS seamless MPLS network.
● A fault occurs on a link between a CSG and an AGG.
On the EVPN inter-AS seamless MPLS network shown in Figure 3-23, the
active link along the primary path between CSG1 and AGG1 fails. After BFD
for LDP LSP or BFD for CR-LSP detects the fault, the BFD module uses LDP
FRR, TE hot standby, or BGP FRR to switch traffic from the primary path to
the backup path.
Figure 3-23 Traffic protection triggered by a fault of the CSG-AGG link on the
EVPN inter-AS seamless MPLS network
● A fault occurs on an AGG.

On the EVPN inter-AS seamless MPLS network shown in Figure 3-24, BGP
Auto FRR is configured on CSGs and AGG ASBRs to protect traffic on the BGP
LSP between CSG1 and MASG1. If BFD for LDP or BFD for TE detects an AGG1
fault, the BFD module switches traffic from the primary path to the backup
path.
Figure 3-24 Traffic protection triggered by an AGG fault on the EVPN inter-AS
seamless MPLS network

(2020-10-09)
● A fault occurs on the link between an AGG and an AGG ASBR.

On the EVPN inter-AS seamless MPLS network shown in Figure 3-25, a fault
occurs on the link between AGG1 and AGG ASBR1. After BFD for LDP LSP or
BFD for CR-LSP detects the fault, the BFD module instructs LDP FRR, TE hot
standby, or BGP FRR to switch traffic from the primary path to the backup
path.
Figure 3-25 Traffic protection triggered by a fault of the link between an AGG
and an AGG ASBR on the inter-AS seamless MPLS network
● A fault occurs on an AGG ASBR.

As shown in Figure 3-26, BFD for LDP or BFD for TE is configured on AGG1,
and BFD for interface is configured on core ASBR1. If AGG ASBR1 fails, the
BFD modules on AGG1 and core ASBR1 detect the fault and trigger the BGP
Auto FRR function. BGP Auto FRR switches both upstream and downstream
traffic from the primary path to backup paths.
Figure 3-26 Traffic protection triggered by a fault of an AGG ASBR on the

● A fault occurs on the link between an AGG ASBR and a core ASBR.
As shown in Figure 3-27, BFD for interface is configured on AGG ASBR1 and
core ASBR1. If the BFD module detects a fault of the link between AGG
ASBR1 and core ASBR1, the BFD module triggers the BGP Auto FRR function.
BGP Auto FRR switches both upstream and downstream traffic from the
primary path to backup paths.

(2020-10-09)
Figure 3-27 Traffic protection triggered by a fault of the link between an AGG
ASBR and a core ASBR on the EVPN inter-AS seamless MPLS network
● A fault occurs on a core ASBR.

On the EVPN inter-AS seamless MPLS network shown in Figure 3-28, BFD for
interface and BGP Auto FRR are configured on AGG ASBR1. BGP Auto FRR
and BFD for LDP (or for TE) are configured on MASGs to protect traffic on the
BGP LSP between CSG1 and MASG1. If the BFD module detects a fault on
core ASBR1, it switches both upstream and downstream traffic from the
primary path to backup paths.
Figure 3-28 Traffic protection triggered by a fault of a core ASBR on the

● A link fault occurs in the core area.

On the EVPN inter-AS seamless MPLS network shown in Figure 3-29, BFD for
LDP or BFD for TE is configured on core ASBR1. If the BFD module detects a
fault on the link between core ASBR1 and MASG1, it instructs the LDP FRR, TE
hot standby, or BGP FRR function to switch both upstream and downstream
traffic from the primary path to the backup paths.

(2020-10-09)
Figure 3-29 Traffic protection from a link fault in the core area on the EVPN
inter-AS seamless MPLS network
● A fault occurs on an MASG.

As shown in Figure 3-30, BFD for BGP tunnel is configured on CSG1. BFD for
BGP tunnel is implemented in compliance with a standard titled "Bidirectional
Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs)." BFD for
BGP tunnel monitors E2E BGP LSPs, including a BGP LSP stitched with an LDP
LSP. If MASG1 that functions as a remote PE fails, BFD for BGP LSP can rapidly
detect the fault and trigger VPN FRR switching. The BFD module then
switches both upstream and downstream traffic from the primary path to the
backup path.
Figure 3-30 Traffic protection triggered by a fault of an MASG on the EVPN

inter-AS seamless MPLS network
● A fault occurs on an access-side link.

On the inter-AS seamless MPLS network shown in Figure 3-31, if an E-Trunk
in single-active mode detects a link failure, the E-Trunk switches traffic from
the primary path to the backup path and PE2's interface connected to CE1 is
unblocked. Then upstream traffic on CE1 is switched to PE2. For BUM traffic
on the network side, PE1 sends a per-ES A-D route withdraw message to PE2,
and PE2 is elected as the DF to forward BUM traffic. After receiving the MAC
route advertised by PE2, PE3 switches unicast traffic to PE2.
If an E-Trunk in active-active mode detects a link failure, PE1 sends a per-ES
A-D route withdraw message to PE3, and PE3 switches unicast traffic to PE2.

(2020-10-09)
Figure 3-31 Traffic protection triggered by an access-side link fault on the

● A PE on the access side fails.

If PE1 fails, the original EVPN detection mechanism is triggered, which is
similar to that triggered when an access-side link fails. Other PEs switch
traffic after detecting PE1's down state rather than receiving a route withdraw
request.
3.1.3.3 EVPN's Service Modes

Multiple Ethernet VPN instances (EVIs) can be configured on PEs at the edge of an
EVPN. Each EVI connects to one or more user networks. EVIs access user networks
in various service modes, see the following table:
Table 3-3 EVPN's Service Modes
Service Mode Usage Scenario
Port Based The physical interface connected to a user

network is directly bound to a common EVI. This
service mode is used only to carry Layer 2
services.
VLAN Based The physical interfaces connected to user

networks each have different sub-interfaces
created. Each sub-interface is associated with a
unique VLAN and added to a specific bridge
domain (BD). Each BD is bound to a specific EVI.
An EVI is required per user. This service mode is
used to carry Layer 2 or Layer 3 services.
VLAN Bundle An EVI connects to multiple users, who are

divided by VLAN, and the EVI is bound to a BD.
This service mode is used to carry Layer 2 or
Layer 3 services.

(2020-10-09)
Service Mode Usage Scenario
VLAN-Aware Bundle An EVI connects to multiple users, who are

divided by VLAN. Additionally, the EVI can be
bound to multiple BDs. This service mode is used
to carry Layer 2 or Layer 3 services.
Port-based Mode
In port-based mode, an interface is used to access a user service. Specifically, the
physical interface connected to a user network is directly bound to a common EVI
(neither an EVI in BD mode nor an EVI in VPWS mode) and has no sub-interfaces
created. This service mode is used only to carry Layer 2 services.
VLAN-based Mode
On the network shown in Figure 3-32, in VLAN-based mode, the physical
interfaces connected to user networks each have different sub-interfaces created.
Each sub-interface is associated with a unique VLAN and added to a specific
bridge domain (BD). Each BD is bound to a specific EVI. In this service mode, the
sub-interface, VLAN, BD, and EVI are exclusive for a user to access a network, and
a separate MAC forwarding table is used on the forwarding plane for each user.
Therefore, this mode effectively ensures service isolation. However, an EVI is
required per user, consuming numerous EVI resources. This service mode is used to
carry Layer 2 or Layer 3 services.
Figure 3-32 VLAN-based mode
VLAN Bundle
On the network shown in Figure 3-33, in VLAN bundle mode, an EVI connects to
multiple users, who are divided by VLAN, and the EVI is bound to a BD. In this
service mode, the users connected to the same EVI share a MAC forwarding table,
requiring each user on the network to have a unique MAC address. This service
mode is used to carry Layer 2 or Layer 3 services.
NOTE
In a VLAN bundle scenario, only termination EVC sub-interfaces support both Layer 2 and
Layer 3 interfaces. Non-termination EVC sub-interfaces support only Layer 2 services.

(2020-10-09)
Figure 3-33 VLAN-bundle mode
VLAN-Aware Bundle
On the network shown in Figure 3-34, in VLAN-aware bundle mode, an EVI
connects to multiple users, who are divided by VLAN. Additionally, the EVI can be
bound to multiple BDs, in which case, the EVI must have different BD tags
configured. When EVPN peers send routes to each other, a BD tag is encapsulated
into the Ethernet Tag ID field of an Ethernet auto-discovery route, MAC/IP
advertisement route, and inclusive multicast route. In this service mode, users
connected to the same EVI use separate forwarding entries. During traffic
forwarding, the system uses the BD tag carried in user packets to locate the
corresponding MAC forwarding table and searches the table for a forwarding entry
based on a MAC address.
Figure 3-34 VLAN-aware bundle mode
Unlike the other service mode, in VLAN-aware bundle mode, load balancing,
designated forwarder (DF), host migration, and route re-origination are
implemented based on a BD:
● Load balancing: In VLAN-aware bundle mode, load balancing can be
implemented only if a MAC/IP advertisement route and Ethernet auto-
discovery route have the same Ethernet segment identifier (ESI) and the same
BD tag. If the BD tags are inconsistent, the routes belong to different BDs,
preventing load balancing from being implemented.
● DF election:
– For interface-based DF election, the system chooses the first interface to
go Up in a BD for DF election.
– During DF election after an AC interface is enabled to influence DF
election, a PE cannot participate in DF election if the system does not
receive the Ethernet auto-discovery route advertised by the PE. If the
VLAN-aware bundle mode is enabled in this scenario, an Ethernet auto-
discovery route is generated for each BD tag. The PE can participate in DF

(2020-10-09)
election only if the system receives Ethernet auto-discovery routes in all

BDs bound to a specified EVI.
● Host migration: When the system generates a local MAC/IP advertisement
route, the system checks whether it has received a MAC/IP advertisement
route from the remote end. If the system has received such a route, the MAC
address transfer attribute is added to the locally generated route, or the value
of the sequence field in the MAC address transfer attribute is incremented by
1. In VLAN-aware bundle mode, a BD tag is the prefix key of a MAC/IP
advertisement route. The system compares the BD tags carried in the received
MAC/IP advertisement route and the locally generated one, preventing MAC
address conflict between different BDs from causing a host migration failure.
● Route re-origination: In the Data Center Interconnect (DCI) solution, a DCI-PE
re-originates a MAC/IP advertisement route received from a peer device and
then sends the new route to the peer device. When the VLAN-aware bundle
mode is enabled on the DCI-PE, a MAC/IP advertisement route can be re-
originated only if its Ethernet tag ID is consistent with the BD tag.
3.1.4 EVPN-VXLAN
3.1.4.1 EVPN VXLAN Fundamentals
Introduction
Ethernet virtual private network (EVPN) is a VPN technology used for Layer 2
internetworking. EVPN is similar to BGP/MPLS IP VPN. EVPN defines a new type of
BGP network layer reachability information (NLRI), called the EVPN NLRI. The
EVPN NLRI defines new BGP EVPN routes to implement MAC address learning and
advertisement between Layer 2 networks at different sites.
VXLAN does not provide a control plane, and VTEP discovery and host information
(IP and MAC addresses, VNIs, and gateway VTEP IP address) learning are
implemented by traffic flooding on the data plane, resulting in high traffic
volumes on DC networks. To address this problem, VXLAN uses EVPN as the
control plane. EVPN allows VTEPs to exchange BGP EVPN routes to implement
automatic VTEP discovery and host information advertisement, preventing
unnecessary traffic flooding.
In summary, EVPN introduces several new types of BGP EVPN routes through BGP
extension to advertise VTEP addresses and host information. In this way, EVPN
applied to VXLAN networks enables VTEP discovery and host information learning
on the control plane instead of on the data plane.
BGP EVPN Routes

EVPN NLRI defines the following BGP EVPN route types applicable to the VXLAN
control plane:
Type 2 Route: MAC/IP Route
Figure 3-35 shows the format of a MAC/IP route.

(2020-10-09)
Figure 3-35 Format of a MAC/IP route
Table 3-4 describes the meaning of each field.
Table 3-4 Fields of a MAC/IP route
Field Description
Route RD value set in an EVI

Distingui
sher
Ethernet Unique ID for defining the connection between local and remote
Segment devices
Identifier
Ethernet VLAN ID configured on the device

Tag ID
MAC Length of the host MAC address carried in the route

Address
Length
MAC Host MAC address carried in the route

Address
IP Length of the host IP address carried in the route

Address
Length
IP Host IP address carried in the route

Address
MPLS L2VNI carried in the route

Label1

Label2
MAC/IP routes function as follows on the VXLAN control plane:
● MAC address advertisement

(2020-10-09)
To implement Layer 2 communication between intra-subnet hosts, the source

and remote VTEPs must learn the MAC addresses of the hosts. The VTEPs
function as BGP EVPN peers to exchange MAC/IP routes so that they can
obtain the host MAC addresses. The MAC Address field identifies the MAC
address of a host.
● ARP advertisement
A MAC/IP route can carry both the MAC and IP addresses of a host, and
therefore can be used to advertise ARP entries between VTEPs. The MAC
Address field identifies the MAC address of the host, whereas the IP Address
field identifies the IP address of the host. This type of MAC/IP route is called
the ARP route.
● IP route advertisement
In distributed VXLAN gateway scenarios, to implement Layer 3
communication between inter-subnet hosts, the source and remote VTEPs
that function as Layer 3 gateways must learn the host IP routes. The VTEPs
function as BGP EVPN peers to exchange MAC/IP routes so that they can
obtain the host IP routes. The IP Address field identifies the destination
address of the IP route. In addition, the MPLS Label2 field must carry the
L3VNI. This type of MAC/IP route is called the integrated routing and bridging
(IRB) route.
NOTE
An ARP route carries host MAC and IP addresses and an L2VNI. An IRB route carries
host MAC and IP addresses, an L2VNI, and an L3VNI. Therefore, IRB routes carry ARP
routes and can be used to advertise IP routes as well as ARP entries.
● Host IPv6 route advertisement
In a distributed gateway scenario, to implement Layer 3 communication
between hosts on different subnets, the VTEPs (functioning as Layer 3
gateways) must learn host IPv6 routes from each other. To achieve this, VTEPs
functioning as BGP EVPN peers exchange MAC/IP routes to advertise host
IPv6 routes to each other. The IP Address field carried in the MAC/IP routes
indicates the destination addresses of host IPv6 routes, and the MPLS Label2
field must carry an L3VNI. MAC/IP routes in this case are also called IRBv6
routes.
NOTE
An ND route carries host MAC and IPv6 addresses and an L2VNI. An IRBv6 route
carries host MAC and IPv6 addresses, an L2VNI, and an L3VNI. Therefore, IRBv6 routes
carry ND routes and can be used to advertise both host IPv6 routes and ND entries.
Type 3 Route: Inclusive Multicast Route

An inclusive multicast route comprises a prefix and a PMSI attribute. Figure 3-36
shows the format of an inclusive multicast route.

(2020-10-09)
Figure 3-36 Format of an inclusive multicast route
Table 3-5 Fields of an inclusive multicast route

Field Description
Route RD value set in an EVI.

Distingui
sher
Ethernet VLAN ID, which is all 0s in this type of route.

Tag ID
IP Length of the local VTEP's IP address carried in the route.

Address
Length
Originati Local VTEP's IP address carried in the route.

ng
Router's
IP
Address
Flags Flags indicating whether leaf node information is required for the
tunnel.
This field is inapplicable in VXLAN scenarios.
Tunnel Tunnel type carried in the route.

Type The value can only be 6, representing Ingress Replication in VXLAN
scenarios. It is used for BUM packet forwarding.
MPLS L2VNI carried in the route.

Label

(2020-10-09)
Field Description
Tunnel Tunnel identifier carried in the route.

Identifier This field is the local VTEP's IP address in VXLAN scenarios.
Inclusive multicast routes are used on the VXLAN control plane for automatic
VTEP discovery and dynamic VXLAN tunnel establishment. VTEPs that function as
BGP EVPN peers transmit L2VNIs and VTEPs' IP addresses through inclusive
multicast routes. The originating router's IP Address field identifies the local
VTEP's IP address; the MPLS Label field identifies an L2VNI. If the remote VTEP's IP
address is reachable at Layer 3, a VXLAN tunnel to the remote VTEP is established.
In addition, the local end creates a VNI-based ingress replication list and adds the
peer VTEP IP address to the list for subsequent BUM packet forwarding.
Type 5 Route: IP Prefix Route
Figure 3-37 shows the format of an IP prefix route.
Figure 3-37 Format of an IP prefix route
Table 3-6 Fields of an IP prefix route
Field Description
Route RD value set in a VPN instance.

Distingui
sher
Ethernet Unique ID for defining the connection between local and remote
Segment devices
Identifier
Ethernet VLAN ID configured on the device

Tag ID
IP Prefix Length of the IP prefix carried in the route

Length
IP Prefix IP prefix carried in the route

(2020-10-09)
Field Description
GW IP Default gateway address

Address

Label
An IP prefix route can carry either a host IP address or a network segment

address.
● When carrying a host IP address, the route is used for IP route advertisement
in distributed VXLAN gateway scenarios, which functions the same as an IRB
route on the VXLAN control plane.
● When carrying a network segment address, the route can be advertised to
allow hosts on a VXLAN network to access the specified network segment or
external network.
3.1.5 EVPN VPWS
3.1.5.1 EVPN VPWS Fundamentals
Introduction
The EVPN virtual private wire service (VPWS) solution provides a P2P L2VPN
service based on the EVPN service architecture. This solution reuses and simplifies
the original EVPN technology, uses the MPLS tunnel technology to traverse the
backbone network, and provides a Layer 2 packet forwarding mode for
connections between access circuits (ACs) without searching for MAC forwarding
entries.
As shown in Figure 3-38, the basic EVPN VPWS architecture consists of the
following parts:
● AC: an independent link or circuit that connects a CE to a PE. An AC interface
can be a physical or virtual interface. The AC attributes include the
encapsulation type, maximum transmission unit (MTU), and interface
parameters of the specified link type.
● EVPL instance: An EVPL instance corresponds to an AC. Each EVPL instance
has a service ID. An EVPL instance on the local PE corresponds to an EVPL
instance on the remote PE. PEs exchange EVPN routes carrying a service ID to
construct forwarding entries that are used to forward or receive service traffic
from different ESs, achieving P2P interworking.
● EVPN VPWS instance: An EVPN VPWS instance is deployed on an edge PE and
contains services that have the same access-side or network-side attributes.
Routes are transmitted based on the RD and RT configured in each EVPN
VPWS instance in a BGP EVPN address family.
● Tunnel: network-side MPLS tunnel or SR tunnel.

(2020-10-09)
Compared with the conventional L2VPN VPWS solution, the EVPN VPWS solution
simplifies the control and data models and uses BGP as the control plane where
BGP route selection and the BGP next hop recursion are used to select traffic
paths over backbone networks. This eliminates the need of specifying PWs.
Figure 3-38 EVPN VPWS networking
Routes Used in EVPN VPWS

On the basis of BGP, EVPN defines a new type of NLRI, which is called the EVPN
NLRI. EVPN VPWS supports the following types of EVPN NLRI:
● Ethernet auto-discovery route: also known as the Ethernet A-D route.
Ethernet A-D routes are classified into per-ES routes and per-EVI routes.
– Ethernet auto-discovery per-ES routes: are sent by PEs on an EVPN VPWS
network to notify the peer device of whether the local redundancy mode
is single-active or all-active.
– Ethernet auto-discovery per-EVI routes: are exchanged between PEs on an
EVPN VPWS network to guide through Layer 2 traffic forwarding. Figure
3-39 shows the NLRI format of Ethernet A-D per-EVI routes.
Figure 3-39 NLRI of an Ethernet A-D route
▪ Route Distinguisher: can be either the RD value of an EVPN instance

or a combination of the source IP address configured on a PE and :0,
such as X.X.X.X:0.
▪ Ethernet Segment Identifier: uniquely identifies connections between

PEs and a CE.
▪ Ethernet Tag ID: local service ID of the EVPL instance on the local PE.

(2020-10-09)
▪ MPLS Label: For a non-SRv6 tunnel, this field is the EVPL label
assigned based on each Ethernet A-D per-EVI route. For an SRv6
tunnel, this field is the SRv6 SID of this tunnel.
In addition to the NLRI, Ethernet A-D per-EVI routes also carry carries the
Layer 2 extended community attribute that includes the following control
fields:
▪ C: a control word identifier. If this field is set to 1, packets sent by the

local PE must carry control information.
▪ P: indicates whether the local PE is the master PE. In all-active

scenarios, this control field must be set to 1.
▪ B: indicates whether a PE is a backup PE in dual-homing single-active

scenarios.
● Ethernet Segment (ES) route: carries the RD, ESI, and source IP address of the
local PE to implement automatic discovery and DF election between PEs
connecting to the same CE. Figure 3-40 shows the NLRI of an Ethernet
segment route.
Figure 3-40 NLRI of an Ethernet segment route

– Route Distinguisher: in the format of X.X.X.X:0. X.X.X.X indicates the EVPN
source IP address configured on the local PE.
and a CE.
PE.
PE.
Protocol Packet Exchange Process in the Single-Homing Scenario

Figure 3-38 shows the protocol packet exchange process in the EVPN VPWS
single-homing scenario.
1. PE1 and PE2 are each configured with an EVPL instance and an EVPN VPWS
instance. The EVPL instance must be bound to an AC interface and an EVPN
VPWS instance, and each EVPL instance must be assigned a local service ID
and a remote service ID. After the configuration, the local PE generates a
forwarding entry indicating the association between the AC interface and
EVPL instance.

(2020-10-09)
2. PE1 and PE2 each send Ethernet A-D per-EVI routes to each other. An
Ethernet A-D per-EVI route carries the RD, RTs, next-hop information, local
service ID, and EVPL label or SRv6 SID.
3. PE1 and PE2 receive the Ethernet A-D per-EVI routes from each other, match
the RTs of the routes, and import the routes to the corresponding EVPN VPWS
instances. The routes then recure to an MPLS or SRv4 tunnel based on next
hop information or to SRv6 tunnels based on SRv6 SIDs. If the service ID in
the received routes is the same as the remote service ID configured for the
local EVPL instance, a forwarding entry indicating the association between the
MPLS or SRv4/v6 tunnel and local EVPL instance is generated.
Packet Exchange Process in Dual-Homing Single-Active Scenarios (with an

E-Trunk Deployed)
On the network shown in Figure 3-41, a CE is dual-homed to PE1 and PE2. PE1
and PE2 work in single-active mode and are configured with an E-Trunk. In this
case, DF election is not triggered, and the master/backup relationship between
PE1 and PE2 is determined by the E-Trunk configured between PE1 and PE2. The
protocol packet exchange process in this scenario is as follows:
1. Each PE is configured with an EVPL instance and an EVPN VPWS instance. The
EVPL instance must be bound to an AC interface and an EVPN VPWS instance,
and each EVPL instance must be assigned a local service ID and a remote
service ID. After the configuration, the local PE generates a forwarding entry
indicating the association between the AC interface and EVPL instance. The
access-side interfaces on PE1 and PE2 must be configured with the same ESI.
2. PE1 and PE2 exchange ES routes that carry RDs, RTs, ESIs, and source IP
addresses. After receiving the ES routes, PE1 and PE2 do not trigger DF
election. The active/standby status of PE1 and PE2 is determined by the E-
Trunk configured between PE1 and PE2. In this example, PE1 is the active
device, and PE2 is the standby device.
3. PE1 and PE2 send PE3 the Ethernet A-D per-ES routes that carry the RD, RTs,
next-hop information, and single-active mode information.
4. The PEs send each other the Ethernet A-D per-EVI routes that carry the RD,
RTs, next-hop information, local service ID, EVPL label or SRv6 SID, and active/
standby role.
5. Upon receipt of Ethernet A-D per-EVI routes from PE3, PE1 and PE2 match
RTs of the corresponding EVPN VPWS instance and select an MPLS or SRv4
tunnel to perform traffic recursion based on the next-hop information or
select an SRv6 tunnel to perform traffic recursion based on SRv6 SIDs. If the
service ID in the received routes is the same as the remote service ID
configured for the local EVPL instance, a forwarding entry indicating the
association between the MPLS or SRv4/v6 tunnel and local EVPL instance is
generated.
6. Upon receipt of EVI Ethernet AD routes from PE1 and PE2, PE3 matches RTs
of the corresponding EVPN VPWS instance and select an MPLS or SRv4 tunnel
to perform traffic recursion based on the next-hop information or select an
SRv6 tunnel to perform traffic recursion based on SRv6 SIDs. If the service ID
in the received routes is the same as the remote service ID configured for the
local EVPL instance, an FRR entry indicating the association between the
MPLS or SRv4/v6 tunnel and local EVPL instance is generated. The entry

(2020-10-09)
pointing to PE1 is the master entry, and the entry pointing to PE2 is the
backup entry.
7. PE1 and PE2 each receive EVI Ethernet AD routes from each other and match
the RTs of the corresponding EVPN VPWS instance. PE1 and PE1 then select
an MPLS or SRv4 tunnel to perform traffic recursion based on the next-hop
information or select an SRv6 tunnel to perform traffic recursion based on
SRv6 SIDs. If the service ID in the received routes is the same as the remote
service ID configured for the local EVPL instance, a bypass entry indicating the
generated.
Figure 3-41 EVPN VPWS dual-homing single-active networking (with an E-Trunk

deployed)
Protocol Packet Exchange Process in Dual-Homing All-Active Scenarios

On the network shown in Figure 3-42, a CE is dual-homed to PE1 and PE2. PE1
and PE2 work in active-active mode. The protocol packet exchange process in this
scenario is as follows:
1. Each PE is configured with an EVPL instance and an EVPN VPWS instance. The
EVPL instance must be bound to an AC interface and an EVPN VPWS instance,
and each EVPL instance must be assigned a local service ID and a remote
service ID. After the configuration, the local PE generates a forwarding entry
indicating the association between the AC interface and EVPL instance. PE1
and PE2 are configured to work in all-active mode and the access-side
interfaces of PE1 and PEs are assigned the same ESI.
2. PE1 and PE2 exchange ES routes that carry RDs, RTs, ESIs, and source IP
addresses. PE1 and PE2 send ES routes that carry the RD, RT, ESI, and source
IP address. Upon receipt of ES routes, PE1 and PE2 do not trigger DF election.
Both PE1 and PE2 are in the master DF state.
3. PE1 and PE2 send PE3 the Ethernet A-D per-ES routes that carry the RD, RTs,
next-hop information, and all-active mode information.
4. PEs send Ethernet A-D per-EVI routes to each other. An Ethernet A-D per-EVI
route carries the RD, RTs, next hop, local service ID, EVPL label or SRv6 SID,
and active/standby role.
5. Upon receipt of Ethernet A-D per-EVI routes from PE3, PE1 and PE2 match
RTs of the corresponding EVPN VPWS instance and select an MPLS or SRv4

(2020-10-09)
tunnel to perform traffic recursion based on the next-hop information or

select an SRv6 tunnel to perform traffic recursion based on SRv6 SIDs. If the
service ID in the received routes is the same as the remote service ID
configured for the local EVPL instance, a forwarding entry indicating the
generated.
6. PE3 receives the Ethernet A-D per-EVI routes from PE1 and PE2, matches the
RTs of the routes with the corresponding EVPN VPWS instances, and recurses
the routes to MPLS or SRv4 tunnels based on next hop information or to SRv6
tunnels based on SRv6 SIDs. If the service ID of the received route is the same
as the remote service ID configured for the local EVPL instance, load
balancing entries are generated for the MPLS or SRv4/v6 tunnel and the local
EVPL instance.
7. PE1 and PE2 receive Ethernet A-D per-EVI routes from each other, match the
RTs of the routes, and import the routes to the corresponding EVPN VPWS
instances. Then the routes recurse to MPLS or SRv4 tunnels based on next hop
information or to SRv6 tunnels based on SRv6 SIDs. If the service ID of the
received route is the same as the remote service ID and ESI configured for the
local EVPL instance, a bypass entry is generated, indicating the association
between the MPLS or SRv4/v6 tunnel and the local EVPL instance.
Figure 3-42 EVPN VPWS dual-homing active-active networking
The data packets sent from AC-side interfaces are forwarded to the peer PE over
the corresponding MPLS tunnel based on the forwarding entries indicating the
association between tunnels and EVPL instances. Upon receipt of packets, the peer
PE searches for the association entries based on the label encapsulated in the
packets and the forwards the packets to the corresponding AC interface based on
the association entries.
3.1.6 PBB-EVPN
3.1.6.1 PBB-EVPN Fundamentals
PBB-EVPN Networking
PBB-EVPN is an L2VPN technology implemented based on MPLS and Ethernet
technologies. PBB-EVPN uses BGP to exchange MAC address information between
PEs on the control plane and controls the exchange of data packets among
different sites across the MPLS network.

(2020-10-09)
As shown in Figure 3-43, a PBB-EVPN has similar architecture as an EVPN.

Compared with EVPN, PBB-EVPN introduces the following concepts:
● PBB: a technique defined in IEEE 802.1ah. PBB precedes C-MAC addresses with
B-MAC addresses in a packet to completely separate the user network from
the carrier network. This implementation enhances network stability and
eases the pressure on the capacity of PEs' MAC forwarding tables.
● I-EVPN: accesses the user network by being bound to a PE interface
connecting to a CE. After an I-EVPN instance receives a data packet from the
user network, the I-EVPN instance encapsulates a PBB header into the packet.
● B-EVPN: accesses the backbone network. A B-EVPN instance manages EVPN
routes received from other PEs.
● I-SID: uniquely identifies a broadcast domain. One I-EVPN instance
corresponds to one I-SID. If two PEs share the same I-SID, the two PEs belong
to the same BUM group.
Figure 3-43 PBB-EVPN networking
Table 3-7 describes the key points in PBB-EVPN implementation.

(2020-10-09)
Table 3-7 Key points in PBB-EVPN implementation

Plane Key Points in Related Concepts
Implementation
Control PEs use BGP to exchange Related PBB-EVPN routes:

plane PBB-EVPN routes and use ● MAC advertisement route
the B-MAC addresses
learned from these routes ● Inclusive multicast route
for later data packet Unicast MAC address
transmission. advertisement
BUM packet transmission
PBB-EVPN supports fast Fast convergence

convergence.
On a multi-homing Ethernet segment routeDF election

network, PBB-EVPN uses
DF election to prevent
bandwidth waste.
PBB-EVPN uses split Split horizon

horizon to prevent routing
loops.
On a multi-homing Redundancy mode

network, PBB-EVPN
supports per-flow load
balancing, but does not
support per-ISID load
balancing.
Data PBB-EVPN supports the Unicast packet transmission

plane transmission of unicast and
BUM packets. BUM packet transmission
PBB-EVPN Routes
On a PBB-EVPN, PEs exchange the following types of routes:
● MAC advertisement route: carries B-EVPN instance RD, B-MAC address, and
VPN label information on the local PE. Figure 3-44 shows the prefix format of
a MAC advertisement route packet. A PE uses MAC advertisement routes to
advertise B-MAC address reachability information to other PEs. When network
topology changes due to a CE node failure or CE-PE link failure, the
corresponding PE sends MAC advertisement routes to instruct other PEs to
refresh C-MAC addresses corresponding to the specified B-MAC address,
thereby achieving fast convergence.

(2020-10-09)
Figure 3-44 Prefix format of a MAC advertisement route packet

– Route Distinguisher: a field representing the RD of an EVPN instance.
– Ethernet Segment Identifier: a field of all 0s or Fs. In a dual-homing
single-active scenario, the value is all 0s. In a dual-homing active-active
scenario, the value is all Fs.
– Ethernet Tag ID: a field of all 0s for MAC advertisement routes.
– MAC Address Length: a field representing the length of the MAC address
advertised by the route.
– MAC Address: a field representing the MAC address advertised by the
route.
– IP Address Length: a reserved field.
– IP Address: a reserved field.
– MPLS Label1: a field that carries the ESI label.
– MPLS Label2: a reserved field.
● Inclusive multicast route: carries the EVPN instance RD and I-SID information
and source IP address (loopback interface address) on the local PE. PEs
exchange inclusive multicast routes after establishing an EVPN BGP peer
relationship. Figure 3-45 shows the prefix format of an inclusive multicast
route packet. PBB-EVPN involves BUM traffic. A PE forwards the BUM traffic
that it receives to other PEs in P2MP mode. BUM traffic can be transmitted
over MP2P or P2P tunnels established over inclusive multicast routes.
Figure 3-45 Prefix format of an inclusive multicast route packet

(2020-10-09)

– Route Distinguisher: a field representing the RD of an EVPN instance.
– Ethernet Tag ID: a field representing the I-SID.
– IP Address Length: a field representing the length of the source IP address
configured on the local PE.
– Originating Router's IP Address: a field representing the source IP address
● Ethernet segment route: carries the EVPN instance RD and ESI information
and source IP address on the local PE. PEs connecting to the same CE use
Ethernet segment routes to discover each other. Ethernet segment routes are
used in DF election. Figure 3-46 shows the prefix format of an Ethernet
segment route packet.
Figure 3-46 Prefix format of an Ethernet segment route packet

– Route Distinguisher: a field representing a combination of the source IP
address on the local PE and :0, such as X.X.X.X:0.
– Ethernet Segment Identifier: a field that uniquely identifies links between
PEs and CEs.
– IP Address Length: a field representing the length of the source IP address
– Originating Router's IP Address: a field representing the source IP address
Other Concepts
● Fast convergence
On the network shown in Figure 3-47, if the link between CE1 and PE1 fails,
PE1 will send a MAC advertisement route that carries the MAC mobility
extended community attribute to PE3, notifying PE3 that C-MAC addresses at
Site1 are unreachable. Upon receipt of the route, PE3 sends traffic to Site1
only through PE2, implementing fast convergence.

(2020-10-09)
Figure 3-47 Fast convergence networking
● DF election
On the network shown in Figure 3-48, CE1 is dual-homed to PE1 and PE2,
and CE2 sends BUM traffic to PE1 and PE2. In this scenario, CE1 receives the
same copy of traffic from both PE1 and PE2, wasting network resources. To
solve this problem, EVPN elects one PE as the DF to forward BUM traffic. If
PE1 is elected, it becomes the primary DF, with PE2 functioning as the backup
DF. The primary DF forwards BUM traffic from CE2 to CE1.
If a PE interface connecting to a CE goes Down, the PE functions as a backup
DF. If a PE interface connecting to a CE goes Up, the PE and other PEs with Up
interfaces elect a primary DF using the following procedure:
a. The PEs establish EVPN BGP peer relationships with each other and then
exchange Ethernet segment routes.
b. Upon receipt of the Ethernet segment routes, each PE generates a
multi-homing PE list based on the ESIs carried in Ethernet segment
routes. Each multi-homing PE list contains information about all PEs
connecting to the same CE.
c. Each PE then sequences the PEs in each multi-homing PE list based on
the source IP addresses carried in Ethernet segment routes. The PEs are
numbered from 0.
d. The primary DF is elected based on I-SIDs. Specifically, PBB-EVPN uses
the formula of "I-SID modulo Number of PEs in the PE list corresponding
to the I-SID" to calculate a number and then elects the PE with the same
number as the calculated one as the primary DF.

(2020-10-09)
Figure 3-48 DF election networking
● Split horizon
On the network shown in Figure 3-49, CE1 is dual-homed to PE1 and PE2. If
PE1 and PE2 have established an EVPN BGP peer relationship with each other,
after PE1 receives BUM traffic from CE1, it forwards the BUM traffic to PE2. If
PE2 forwards BUM traffic to CE1, a loop will occur. To prevent this problem,
EVPN uses split horizon. After PE1 forwards the BUM traffic to PE2, PE2
checks the B-SMAC address carried in the traffic. If the B-SMAC address
equals the B-MAC address configured on PE2, PE2 drops the traffic,
preventing a routing loop.
Figure 3-49 Split horizon networking
● Redundancy mode
If a CE is multi-homed to several PEs, a redundancy mode can be configured
to specify the redundancy mode of PEs connecting to the same CE. The
redundancy mode determines whether load balancing is implemented for
unicast traffic in CE multi-homing scenarios. On the network shown in Figure
3-50, if PE1 and PE2 are both configured to work in All-Active mode, after
PE1 and PE2 send MAC advertisement routes carrying the same B-MAC

(2020-10-09)
address to PE3, PE3 sends unicast traffic destined for CE1 to both PE1 and PE2
in load balancing mode.
Figure 3-50 Redundancy mode networking
Unicast MAC Address Advertisement

On the network shown in Figure 3-51, unicast MAC addresses are advertised as
follows:
1. Site1 sends an ARP request or gratuitous packet that carries Site1's C-MAC
address C-MAC A and the corresponding IP address to Site2.
2. Upon receipt of the packet, Site2 returns an ARP reply or gratuitous packet
that carries Site2's C-MAC address C-MAC B and the corresponding IP address
to Site1.
3. PE1 and PE2 exchange MAC advertisement routes that carry B-MAC
addresses, next hops, and EVPN instance extended community attributes
(such as RTs).
4. PE1 and PE2 construct B-EVPN instance forwarding entries based on the RTs
carried in received MAC advertisement routes.
Figure 3-51 Unicast MAC address advertisement networking

(2020-10-09)
BUM Packet Transmission

After two PEs establish an EVPN BGP peer relationship, they exchange inclusive
multicast routes. PEs then form redundancy groups based on I-SIDs carried in
received inclusive multicast routes, with PEs having the same I-SID belonging to
the same redundancy group. On the network shown in Figure 3-52, BUM packets
are transmitted as follows:
1. CE1 sends BUM packets to PE1.
2. Upon receipt of the packets, PE1 searches its C-MAC address table for the C-
DMAC address carried in packets. If the C-DMAC address cannot be found,
PE1 sends the BUM packets to all other PEs in the same redundancy group.
Specifically, PE1 replicates a copy of received BUM packets, encapsulates the
PBB header, public tunnel label, and VPN label into each copy, and sends the
two copies of traffic to PE2 and PE3, respectively. The B-DMAC address carried
in the PBB header is a broadcast MAC address.
3. Upon receipt of the BUM packets, PE2 and PE3 decapsulate the BUM packets
and send the BUM packets to the sites identified by the EVPN label carried in
the packets.
NOTE
Use the network shown in Figure 3-50 as an example. If PE1 and PE2 both work in Single-
Active mode, the bidirectional BUM traffic between CE2 and CE1 will be dropped by the
backup DF. If PE1 and PE2 both work in All-Active mode, only the BUM traffic from CE2 to
CE1 will be dropped by the backup DF.
Figure 3-52 BUM packet transmission networking

(2020-10-09)
Unicast packet transmission

On the network shown in Figure 3-53, unicast packets are transmitted as follows:
1. CE1 forwards unicast packets that carry the source C-MAC (C-SMAC) and
destination C-MAC (C-DMAC) addresses to PE1 at Layer 2.
2. Upon receipt of the packets, the I-EVPN instance on PE1 searches its C-MAC
address table for a matching forwarding entry. After finding such an entry,
PE1 encapsulates a PBB header, a tunnel label, and a VPN label into these
packets and forwards these packets to PE2. The PBB header carries the I-SID
and B-SMAC address configured in the I-EVPN instance and the B-DMAC
address obtained from the C-DMAC address table.
3. Upon receipt of these packets, PE2 removes the tunnel label and PBB header,
searches the local C-MAC address table for a matching forwarding entry, and
forwards these packets to an outbound interface.
Figure 3-53 Unicast packet transmission networking

(2020-10-09)
3.1.6.2 Migration from an HVPLS Network to a PBB-EVPN

On the network shown in Figure 3-54, VPLS is deployed to allow services of the
same private network to access VSIs over different PEs. To avoid establishment of
full-mesh PWs, SPEs are deployed on the network to form an HVPLS.
After devices have PBB-EVPN enabled, the HVPLS network can migrate to a PBB-
EVPN. Because this network has large numbers of devices, migration needs to be
performed step by step and HVPLS and PBB-EVPN will temporarily coexist. The
implementation process is as follows:
1. Configure a B-EVPN instance on the SPE and specify a unique B-MAC address
for the B-EVPN instance.
2. Change the existing VSI on the SPE to be an MP2MP I-VSI and bind the I-VSI
to the B-EVPN instance previously configured. The I-tag for the I-VSI must be
the same as the I-tag for the B-EVPN instance. Otherwise, services cannot be
forwarded.
3. Specify each UPE as an EVPN BGP peer for the SPE.
4. Configure a B-EVPN instance on each UPE and specify the SPE as an EVPN
BGP peer for each UPE. Then, UPEs will learn B-MAC addresses from their
EVPN BGP peers and the SPE will learn the B-MAC addresses of the entire
network.
5. Change the existing VSI on each UPE to be an I-EVPN instance, bind the I-
EVPN instance to the previously configured B-EVPN instance, and bind the AC
interface on each UPE to the I-EVPN instance on that UPE. After all
configurations are complete, the network becomes a PBB-EVPN.
Figure 3-54 Typical networking
3.1.7 EVPN E-Tree

Background
As the number of services carried on an EVPN increases, the number of user MAC
addresses managed by the EVPN is also increasing. The user MAC addresses are

(2020-10-09)
flooded on the network through EVPN routes. As a result, all interfaces in the
same broadcast domain can communicate with each other at Layer 2. However,
broadcast, unknown unicast, multicast (BUM), and unicast traffic cannot be
isolated for users who do not need to communicate with each other. To isolate
interfaces that do not need to communicate with each other in the same
broadcast domain, you can deploy the EVPN E-Tree function on the network.
Fundamentals
EVPN E-Tree implements the E-Tree model defined by the Metro Ethernet Forum
(MEF) by setting the root or leaf attribute for AC interfaces.
● A leaf AC interface and a root AC interface can send traffic to each other.
However, flows between leaf AC interfaces are isolated from each other.
● A root AC interface can communicate with the other root AC interfaces and
with leaf AC interfaces.
To implement the preceding functions, an E-Tree extended community attribute is
defined in a standard protocol. Figure 3-55 shows the format of a packet with the
E-Tree extended community attribute. The packet includes the Leaf Label field and
the Flags field. The Flags field contains 8 bits, in which the first 7 bits are all zeros
and the last identifies whether an EVPN MAC route is from a leaf AC interface.
Value 1 indicates that the MAC route comes from this interface. The extended
community attribute can be advertised through Ethernet A-D per-ES routes and
MAC routes on an EVPN, so that known unicast traffic and BUM traffic on leaf AC
interfaces are isolated from each other.
Figure 3-55 Format of a packet with the EVPN E-Tree extended community
attribute
Take the network shown in Figure 3-56 deployed as an example. Known unicast
traffic is isolated through the following process:
1. PE1 and PE2 transmit AC-side MAC addresses to each other through MAC
routes. Take the MAC address (MAC1) of the AC interface on CE2 as an
example. Because the AC interface has the leaf attribute, a MAC route
carrying the MAC1 address also carries the extended community attribute of
EVPN E-Tree. All bits in the Leaf Label field of the attribute are set to 0, and
the L bit in the Flags field is set to 1. PE1 then sends this MAC route to PE2.
2. Upon receipt, PE2 checks the L bit in the Flags field. Because this bit is set to
1, PE2 marks the entry corresponding to MAC1 in the local MAC table.
3. When PE2 receives traffic destined for CE2 from its own leaf AC interface, PE2
determines that the traffic needs to be sent to the remote leaf AC interface
based on the flag in the local MAC routing table and discards the traffic. In
this way, known unicast traffic is isolated between leaf AC interfaces.
In the preceding example, BUM traffic is isolated through the following process:

(2020-10-09)
1. After EVPN E-Tree is configured on the network, PE1 and PE2 send a special
Ethernet A-D per ES route to each other. After EVPN E-Tree is configured on
the network, PE1 and PE2 send a special Ethernet A-D per ES route to each
other. A regular Ethernet A-D per-ES route carries the ESI attribute. However,
the ESI field in the Ethernet A-D per-ES route used by EVPN E-Tree is set to all
zeros, and the route carries the extended community attribute of EVPN E-Tree.
The Leaf Label field of this attribute uses a label value, and the L bit in the
Flags field is set to 0.
2. After PE1 receives the Ethernet A-D per ES route, it determines that the route
is used to transmit the leaf label because the ESI field value is all zeros. PE1
then saves the label.
3. When PE1 needs to send BUM traffic from its leaf AC interface to PE2, PE1
encapsulates the saved leaf label into the BUM packets and then sends them
to PE2.
4. Upon receipt, PE2 finds the locally allocated leaf label in the BUM packets.
Therefore, PE2 does not send the traffic to CE4 or CE5. Instead, PE2 sends the
traffic only to CE3, implementing BUM traffic isolation between leaf AC
interfaces.
Figure 3-56 Network with EVPN E-Tree deployed
NOTE
EVPN E-Tree supports the following types of AC interfaces: main interfaces bound to
common EVPN instances, EVC Layer 2 sub-interfaces associated with BDs, and VLAN sub-
interfaces.
In a CE dual-homing scenario, ensure that the same root or leaf attribute is set for the
same VLAN sub-interface in the same broadcast domain on two PEs. If the leaf attribute is
set on both PEs, the Leaf label can replace the ESI label to implement split horizon.
Different root or leaf attributes can be set for a PE's interfaces or sub-interfaces that
connect to different CEs.
Currently, EVPN E-Tree can be used in two scenarios: EVPN E-Tree over MPLS and
EVPN E-Tree over SRv6. The differences between the two modes are as follows:

(2020-10-09)
Table 3-8 Implementation differences between EVPN E-Tree over MPLS and EVPN
E-Tree over SRv6
Application Public Network BUM Traffic Forwarding
Scenarios Tunnel
EVPN E-Tree MPLS LDP/MPLS TE When a PE sends BUM traffic from

over MPLS a leaf interface to the peer PE, the
PE encapsulates the leaf label value
in the traffic. After receiving BUM
traffic, the peer PE finds the leaf
label allocated by itself and does
not forward the traffic to the
interface with the leaf attribute.
EVPN E-Tree SRv6 BE/SRv6 TE Policy When a PE sends BUM traffic from
over SRv6 a leaf interface to the peer PE, the
PE encapsulates the Arguments
value (a field in a prefix SID) sent
by the peer PE into the traffic. After
receiving BUM traffic, the remote
PE parses the valid Arguments
value and does not forward the
traffic to the interface with the
Leaf attribute.
3.1.8 MAC Duplication Suppression for EVPN

On an EVPN E-LAN, two PEs may be interconnected both through network-side
and access-side links. If this is the case, a BUM traffic loop and MAC route
flapping both occur, preventing devices from working properly. MAC duplication
suppression for EVPN can resolve this problem.

(2020-10-09)
Figure 3-57 BUM traffic loop over an EVPN
On the network shown in Figure 3-57, EVPN runs between PE1 and PE2. CE1 and
CE2 access PE1 and PE2 respectively in one of the following ways: VLAN, QinQ,
static or dynamic PW, or static VXLAN. PE1 and PE2 can communicate with each
other both through network-side and access-side links, which induces a BUM
traffic loop:
1. After PE1 receives BUM traffic from CE1, PE1 first replicates it, and then
forwards it to both the network-side and access-side links (traffic 1 in Figure
3-57).
2. PE2 forwards the BUM traffic received from PE1 through the network-side link
to the access-side link (traffic 2 in Figure 3-57). Equally, PE2 forwards the
BUM traffic received from the access side to the network side (traffic 3 in
Figure 3-57).
3. PE1 forwards the BUM traffic received from PE2 through the network-side link
to the access-side link (traffic 4 in Figure 3-57). Equally, PE1 forwards the
BUM traffic received from the access side to the network side (traffic 5 in
Figure 3-57).
4. As steps 2 and 3 are repeated, BUM traffic is continuously transmitted
between PE1 and PE2.

(2020-10-09)
Figure 3-58 Route flapping over the EVPN
On the network shown in Figure 3-58, in addition to a BUM traffic loop, route
flapping also occurs:
1. After PE1 receives BUM traffic from CE1, PE1 learns CE1's MAC address (M1)
from the source MAC address of the traffic. PE1 sends a MAC route with a
destination address of M1 to PE2 by means of EVPN.
2. Upon receipt, PE2 matches the RT of the MAC route, imports the MAC route
into a matching EVPN instance, generates a MAC entry, and iterates the MAC
route to the network-side VXLAN or MPLS tunnel to PE1.
3. PE2 can also receive BUM traffic from PE1 through the direct access-side link
between them. Upon receipt, PE2 also generates a MAC route to M1 based on
the source MAC address of the traffic. In this case, PE2 considers M1 to have
moved to its own access network. PE2 preferentially selects the MAC address
received from the local access side. PE2 therefore sends the MAC route
destined for M1 to PE1. This route carries the MAC mobility extended
community attribute. The mobility sequence number is Seq0+1.
4. Upon receipt, PE1 matches the RT of the MAC route, and imports the MAC
route into a matching EVPN instance. PE1 preferentially selects the MAC route
received from PE2 because this route has a larger mobility sequence number.
PE1 then generates a MAC entry and iterates the MAC route to the network-
side VXLAN or MPLS tunnel to PE2. PE1 then sends a MAC Withdraw message
to PE2.
5. After PE1 receives BUM traffic again from the access-side link, PE1 generates
another MAC route to M1 and considers M1 to have moved to its own access
network. PE1 preferentially selects the local MAC route to M1 and sends it to
PE2. This route carries the MAC Mobility extended community attribute. The
mobility sequence number is Seq0+2.
6. Upon receipt, PE2 matches the RT of the MAC route and imports the MAC
route into a matching EVPN instance. PE2 preferentially selects the MAC route
received from PE1 because this route has a larger mobility sequence number.

(2020-10-09)
PE2 then generates a MAC entry and iterates the MAC route to the network-
side VXLAN or MPLS tunnel to PE1. PE2 then sends a MAC Withdraw message
to PE1.
7. After PE2 receives BUM traffic again from PE1 through the direct access-side
link between them, PE2 generates another MAC route to M1 and considers
M1 to have moved to its own access network. PE2 preferentially selects the
local MAC route and sends the MAC route destined for M1 to PE1. This route
carries the MAC mobility extended community attribute. The mobility
sequence number is Seq0+3.
8. As steps 3 to 7 are repeated, the mobility sequence number of the MAC route
is incremented by 1 continuously, causing route flapping on the network.
To prevent traffic loops and route flapping, the system starts the process of MAC
duplication suppression. The system checks the number of times a MAC entry
flaps within a detection period. If the number of MAC flaps exceeds the upper
threshold, the system considers MAC route flapping to be occurring on the
network and consequently suppresses the flapping MAC routes. The suppressed
MAC routes cannot be sent to a remote PE through a BGP EVPN peer relationship.
In addition to suppressing MAC route flapping, you can also configure black-hole
MAC routing and AC interface blocking:
● After black-hole MAC routing has been configured, the system sets the
suppressed MAC routes to black-hole routes. If a PE receives traffic with the
same source or destination MAC address as the MAC address of a black-hole
MAC route, the PE discards the traffic.
● If AC interface blocking is also configured, that is, if the traffic comes from a
local AC interface and the source MAC address of the traffic is the same as
the MAC address of a black-hole MAC route, the AC interface is blocked. In
this way, a loop can be removed quickly. Only BD-EVPN instances support AC
interface blocking.
3.1.9 EVPN ORF

Background
The growing number of services over EVPNs has triggered a proliferation of new
users. As a result, BGP-EVPN peers on an EVPN are sending vast quantities of
EVPN routes to each other. Even if the remote peer does not have an RT-matching
EVPN instance, the local PE still sends it EVPN routes. To reduce network load,
each PE needs to receive only desired routes. If a separate export route policy is
configured for each user, the cost of O&M goes up. To address this issue, EVPN
outbound route filtering (ORF) can be deployed.
Implementation
After EVPN ORF is configured, each PE on the EVPN sends the import VPN target
(IRT) and original AS number of the local EVPN instance to the other PEs or BGP
EVPN RRs that function as BGP-EVPN peers. The information is sent through ORF
routes. Upon receipt, the peers construct export route policies based on these
routes so that the local PE only receives the expected routes, which reduces the
receiving pressure on the local PE.
Figure 3-59 shows the basic EVPN ORF network on which each device supports
EVPN ORF. PE1, PE2, and PE3 establish BGP-EVPN peer relationships with the RR,

(2020-10-09)
and are also clients of the RR. An EVPN instance with a specific RT is configured
on each PE.
Before EVPN ORF is enabled, the RR advertises all the routes received from PE1's
EVPN instances to PE2 and PE3. However, PE2 only needs routes with an export
VPN target (ERT) of 1:1, whereas PE3 only needs routes with an ERT of 2:2. As a
result, PE2 and PE3 discard unwanted routes upon receipt, which wastes device
resources.
After EVPN ORF is enabled on all devices and BGP-EVPN peer relationships are
established between the PEs and RR in the BGP-VT address family view, the BGP-
EVPN peers negotiate the EVPN ORF capability. Each device sends the IRT of its
local EVPN instance to the BGP-EVPN peers in the form of ORF routes. Each device
then constructs an export route policy based on the received ORF routes. Upon
construction, PE1 only sends EVPN1's and EVPN4's routes to the RR. The RR then
only sends routes with an ERT of 1:1 to PE2 and those with an ERT of 2:2 to PE3.
Figure 3-59 Basic usage scenario of EVPN ORF
The BGP-VT address family obtains the IRT configured on the local device
regardless of the type of the instance that the IRT comes from. If EVPN ORF is
enabled on a network that consists of devices that do not support EVPN ORF, the
EVPN service cannot run properly. However, the BGP-VT address family can resolve
this problem.
On the network shown in Figure 3-59, PE1, PE2, and PE3 establish BGP-EVPN peer
relationships with the RR. PE1, PE2, and PE3 are clients of the RR. Suppose that
PE1, PE2, and the RR all support EVPN ORF but that PE3 does not, as it is running
an early version. If EVPN ORF is enabled on the network and the BGP-VT peer
relationships are established, PE3 does not send ORF routes to the RR, which
means that PE1 does not receive the ORF routes with an ERT of 2:2 from the RR.
As a result, PE1 does not send EVPN4's routes to the RR, thereby compromising
the services between EVPN4 and EVPN2. Because the BGP-VT address family does
not differentiate the type of instance the IRT belongs to, you can configure an
L3VPN instance on PE3 and set both IRT and ERT to 2:2. This configuration allows
PE3 to advertise an ORF route with an IRT of 2:2 to the RR, which then advertises
this route to PE1. Upon receipt, PE1 modifies its export route policy so that it can
advertise EVPN2's routes to the other PEs.

(2020-10-09)
NOTE
In addition to configuring an L3VPN instance, you can also configure the RR to advertise
default ORF routes to PE1 and PE3 and delete the BGP-VT peer relationship between the RR
and PE3. After the configuration is complete, PE1, PE2, and PE3 advertise all routes to the
RR. The RR then advertises routes with ERTs of 1:1 and 2:2 to PE1, routes with an ERT of 1:1
to PE2, and all routes to PE3.
If both EVPN and L3VPN services are deployed on the network in Figure 3-59, the
preceding two ways cannot be used. If you use either of them, the L3VPN service
cannot run properly. On the network shown in Figure 3-60, only PE3 does not
support EVPN ORF. After EVPN ORF is enabled on the network, the EVPN service
cannot run properly. If an L3VPN instance is created, the new L3VPN instance
receives the other PEs' L3VPN routes from the RR, which compromises the L3VPN
service. To resolve this issue, you can disable the RR from filtering routes based on
the IRT for PE3, thereby ensuring that both EVPN and L3VPN services can run
properly.
Figure 3-60 An EVPN ORF network carrying both EVPN and L3VPN services
Benefits
● Bandwidth consumption is lowered (because the number of routes being
advertised is smaller).
● System resources such as CPU and memory are saved.
3.1.10 IGMP Snooping over EVPN MPLS

If the Ethernet virtual private network (EVPN) function is deployed on a network
to carry multicast services but Internet Group Management Protocol (IGMP)
snooping is not configured on PEs, multicast data packets are broadcast on the
network. The devices that do not need to receive the multicast data packets also
receive these packets, which wastes network bandwidth resources. To resolve this
issue, deploy IGMP snooping over EVPN Multiprotocol Label Switching (MPLS).
After IGMP snooping over EVPN MPLS is deployed, IGMP snooping packets are

(2020-10-09)
transmitted on the network through EVPN routes, and multicast forwarding

entries are generated on devices. Multicast data packets from a multicast source
are advertised only to the devices that need these packets, saving network
bandwidth resources.
For details about EVPN routes used by IGMP snooping over EVPN MPLS, see
Related Routes. For details about route advertisement and traffic forwarding, see
Route Advertisement and Traffic Forwarding.
Related Routes
EVPN routes used by IGMP snooping over EVPN MPLS include Selective Multicast
Ethernet Tag (SMET) and IGMP Join Synch routes.
● SMET route
SMET routes are used to transmit multicast group information between BGP
EVPN peers. A device that receives an SMET route can construct local (*, G) or
(S, G) entries based on the routing information. As shown in Figure 3-61, the
fields in the routing information are described as follows:
– Route Distinguisher: RD configured in an EVPN instance.
– Ethernet Tag ID: This field is set to 0 when the VLAN-based or VLAN
bundle service mode is used to access a user network.
– Multicast Source Length: length of a multicast source address. This field is
set to 0 for any multicast source.
– Multicast Source Address: address of a multicast source. Packets do not
contain this field for any multicast source.
– Multicast Group Length: length of a multicast group address.
– Multicast Group Address: address of a multicast group.
– Originator Router Length: address length of the device that generated the
SMET route.
– Originator Router Address: address of the device that generated the
SMET route.
– Flags: This field contains 8 bits. The first 4 most significant bits are
reserved, and the last 3 least significant bits are used to identify IGMP
versions. If bit 5 is set to 1, the IGMP version of the multicast entry
carried in the route is IGMPv3. Only one of these 3 bits can be set to 1.
Bit 4 indicates the filtering mode of group records in IGMPv3. The values
0 and 1 indicate Include and Exclude group types, respectively.

(2020-10-09)
Figure 3-61 SMET route format
● IGMP Join Synch route

IGMP Join Synch routes are used to synchronize multicast group join
information between dual-homed devices on the access side. A device that
receives an IGMP Join Synch route can add member entries to the local (S, G)
entries based on the routing information, ensuring that the local entries are
the same as those on the device connected to the same user network. As
shown in Figure 3-62, the fields in the routing information are described as
follows:
– Route Distinguisher: route distinguisher (RD) configured in an EVPN
instance.
– Ethernet Segment Identifier: unique identifier defined for a device to
connect to the access network.
– Ethernet Tag ID: This field is set to 0 when the VLAN-based or VLAN
bundle service mode is used to access a user network.
– Multicast Source Length: length of a multicast source address. This field is
set to 0 for any multicast source.
– Multicast Source Address: address of a multicast source. Packets do not
contain this field for any multicast source.
– Multicast Group Length: length of a multicast group address.
– Multicast Group Address: address of a multicast group.
– Originator Router Length: address length of the device that generated the
IGMP Join Synch route.
– Originator Router Address: address of the device that generated the IGMP
Join Synch route.
– Flags: This field contains 8 bits. The first 4 most significant bits are
reserved, and the last 3 least significant bits are used to identify IGMP
versions. If bit 5 is set to 1, the IGMP version of the multicast entry

(2020-10-09)
carried in the route is IGMPv3. Only one of these 3 bits can be set to 1.
Bit 4 indicates the filtering mode of group records in IGMPv3. The values
0 and 1 indicate Include and Exclude group types, respectively.
Figure 3-62 IGMP Join Synch route format
Route Advertisement and Traffic Forwarding

IGMP snooping over EVPN MPLS supports single- and dual-homing access.
Single-homing access for IGMP snooping over EVPN MPLS
Figure 3-63 shows single-homing access for IGMP snooping over EVPN MPLS.
Configure an EVPN instance on PE1, PE2, and PE3, and bind a BD to the EVPN
instance. Establish BGP EVPN peer relationships between the PEs, and deploy
EVPN IGMP proxy on each PE. Deploy PE1 as a sender PE, and deploy PE2 and PE3
as receiver PEs. Configure IGMP snooping and IGMP proxy on BD1 bound to the
EVPN instance on PE1, PE2, and PE3. Connect BD1 on PE1, PE2, and PE3 to CE1,
CE2, and CE3 through VLAN dot1q sub-interfaces, respectively. Configure PIM-SM
on CE1's interface connected to a multicast source and IGMP on CE1's interface
connected to PE1.

(2020-10-09)
Figure 3-63 Single-homing access for IGMP snooping over EVPN MPLS
The process of IGMP snooping over EVPN MPLS (single-homing access) is

described as follows:
1. PE1, PE2, and PE3 periodically send IGMP Query messages to the access side
in BD1.
2. Receiver A and Receiver B send IGMP Report messages to CE2 and CE3,
respectively. For example, Receiver A sends an IGMPv3 (S, G) Report message,
and Receiver B sends an IGMPv2 (*, G) Report message.
3. After receiving the corresponding IGMP Report messages, PE2 and PE3
establish (S, G) and (*, G) entries of IGMP snooping in BD1 and add the
interfaces connected to CE2 and CE3 as outbound interfaces, respectively.
4. PE2 sends a BGP EVPN SMET route to the other PEs through BGP EVPN peer
relationships. The route carries (S, G) entries, and the Flags field in the route
is set to IGMPv3 and Include.
relationships. The route carries (*, G) entries, and the Flags field in the route is
set to IGMPv2.
6. After receiving the corresponding BGP EVPN SMET routes, PE1 establishes (S,
G) and (*, G) entries of IGMP snooping in BD1 and adds the mLDP tunnel
interfaces of the corresponding EVPN instances as outbound interfaces.
7. PE1 sends IGMPv3 (S, G) Report and IGMPv2 (*, G) Report messages to CE1.
CE1 establishes IGMP and PIM entries and forwards multicast traffic to PE1.
8. After receiving the multicast traffic, PE1 forwards the traffic to PE2 and PE3
through the mLDP tunnel interfaces based on the (S, G) and (*, G) entries in
BD1.
9. After receiving the multicast traffic, PE2 and PE3 forward the traffic to
Receiver A and Receiver B based on the (S, G) and (*, G) entries, respectively.
Dual-homing access for IGMP snooping over EVPN MPLS on the multicast
source side
Figure 3-64 shows dual-homing access for IGMP snooping over EVPN MPLS on
the multicast source side. Configure an EVPN instance on PE1, PE2, PE3, and PE4,

(2020-10-09)
and bind a BD to the EVPN instance. Establish BGP EVPN peer relationships
between the PEs, and deploy EVPN IGMP proxy on each PE. Deploy PE1 and PE2
as sender PEs, and deploy PE3 and PE4 as receiver PEs. Connect BD1 on PE3 and
PE4 to CE3 and CE4 through VLAN dot1q sub-interfaces, respectively. Connect CE1
to PE1 and PE2 through Eth-Trunk interfaces, and configure PIM-SM and IGMP on
the interfaces. Bind the Eth-Trunk interfaces of CE1 to an E-Trunk on PE1 and PE2.
Configure static router interfaces, and set the same ESI. Configure the E-Trunk to
work in dual-active mode, and ensure that the Eth-Trunk interfaces on PE1 and
PE2 are both Up.
Figure 3-64 Dual-homing access for IGMP snooping over EVPN MPLS on the
multicast source side
The process of IGMP snooping over EVPN MPLS (dual-homing access on the
multicast source side) is described as follows:
1. PE3 and PE4 periodically send IGMP Query messages to the access side in
BD1.
2. Receiver A and Receiver B send IGMP Report messages to CE2 and CE3,
respectively. For example, Receiver A sends an IGMPv3 (S, G) Report message,
and Receiver B sends an IGMPv2 (*, G) Report message.
3. After receiving the corresponding IGMP Report messages, PE3 and PE4
establish (S, G) and (*, G) entries of IGMP snooping in BD1 and add the
interfaces connected to CE2 and CE3 as outbound interfaces, respectively.
relationships. The route carries (S, G) entries, and the Flags field in the route
is set to IGMPv3 and Include.
relationships. The route carries (*, G) entries, and the Flags field in the route is
set to IGMPv2.
6. After receiving the corresponding BGP EVPN SMET routes, PE1 and PE2
establish (S, G) and (*, G) entries of IGMP snooping in BD1 and add the mLDP
tunnel interfaces of the corresponding EVPN instances as outbound interfaces.

(2020-10-09)
7. The Eth-Trunk interface of CE1 periodically sends IGMP Query messages to

BD1 of PE1 or PE2 based on hash rules. PE1 or PE2 periodically sends IGMP
Report messages to CE1.
8. After receiving an IGMP Report message, CE1 creates IGMP and PIM entries
and forwards multicast traffic to PE1.
9. CE1 forwards the multicast traffic from the multicast source to BD1 of PE1 or
PE2 based on hash rules. PE1 or PE2 forwards the multicast traffic to PE3 and
PE4 through the mLDP tunnel interfaces based on the (*, G) and (S, G) entries
of BD1.
10. After receiving the multicast traffic, PE2 and PE3 forward the traffic to
Receiver A and Receiver B based on the (S, G) and (*, G) entries, respectively.
Dual-homing access for IGMP snooping over EVPN MPLS on the access side
Figure 3-65 shows dual-homing access for IGMP snooping over EVPN MPLS on
the access side. Configure an EVPN instance on PE1, PE2, and PE3, and bind a BD
to the EVPN instance. Establish BGP EVPN peer relationships between the PEs, and
deploy EVPN IGMP proxy on each PE. Deploy PE1 as a sender PE, and deploy PE2
and PE3 as receiver PEs. Configure IGMP snooping and IGMP proxy on BD1 bound
to the EVPN instance on PE1, PE2, and PE3. Connect BD1 on PE1, PE2, and PE3 to
CE1, CE2, and CE3 through VLAN dot1q sub-interfaces, respectively. Configure
PIM-SM and IGMP on CE1's interface connected to PE1, and connect CE2 to PE2
and PE3 through Eth-Trunk interfaces. Bind the Eth-Trunk interfaces of CE2 to an
E-Trunk and configure the same ESI on PE2 and PE3. Configure the E-Trunk on PE2
and PE3 to work in single-active mode, select PE2 as the master device, and
ensure that the Eth-Trunk interface of PE2 is up.
NOTE
IGMPv3 is not supported in access-side dual-homing access scenarios.
access side
The process of IGMP snooping over EVPN MPLS (dual-homing access on the
access side) is described as follows:
1. PE2 periodically sends IGMP Query messages to the access side in BD1.
2. The receiver sends an IGMP Report message, for example, IGMPv2 (*, G)
Report message, to CE2.
3. After receiving an IGMP Report message, PE2 establishes (*, G) entries of
IGMP snooping, adds the Eth-Trunk interface to CE2 as the outbound
interface, and sends the IGMP Join Synch route of BGP EVPN to other PEs. The

(2020-10-09)
route carries the access-side ESI of PE2 and contains the IGMP version and
source filtering mode.
4. After receiving the IGMP Join Synch route, PE3 creates the corresponding (*,
G) entries of IGMP snooping in BD1. PE3 does not need to send a BGP EVPN
SMET route, because it is a non-DF. Additionally, PE3 does not add the Eth-
Trunk interface to CE2 as the outbound interface, because the Eth-Trunk
interface is down.
5. PE2 functioning as a DF sends a BGP EVPN SMET route based on (*, G)
entries of IGMP snooping.
6. After receiving the BGP EVPN SMET route from PE2, PE1 creates (*, G) entries
of IGMP snooping and sends an IGMP Report message to CE1.
8. CE1 sends the multicast traffic received from the multicast source to PE1.
9. After receiving the multicast traffic, PE1 forwards the traffic to PE2 and PE3
through the mLDP tunnel interfaces based on the (*, G) entries in BD1.
10. After PE2 and PE3 receive the multicast traffic, PE2 forwards the traffic to CE2
based on the (*, G) entries, but PE3 does not. In this case, the receiver receives
only one copy of multicast traffic.
11. If some receivers are disconnected or do not need to receive multicast traffic,
PE2 updates the (*, G) entry based on the IGMP Report message received
from CE2 and then sends an IGMP Join Synch route withdraw message to PE3.
This ensures that PE3 deletes the (*, G) entry corresponding to the receiver, so
that the (*, G) entry on PE3 is the same as that on PE2.
12. If the access side of PE2 fails, the EVPN instance selects PE3 as a DF, and the
Eth-Trunk interface of PE3 goes up. PE3 then adds the Eth-Trunk interface to
CE2 as the outbound interface, so that multicast traffic is forwarded from PE3
to CE2.
IGMP snooping over EVPN MPLS access-side dual-homing access (Layer 2 to
Layer 3 in active-active mode)
As shown in Figure 3-66, CE2 is dual-homed to PE2 and PE3 on the IGMP
Snooping over EVPN MPLS access side. Configure PE1 as a sender PE and PE2 and
PE3 as receiver PEs. Configure PIM-SM on PE1, PE2, and PE3. Configure an EVPN
instance on PE2 and PE3, bind BD1 to the EVPN instance, create VBDIF1 for BD1,
and enable PIM-SM and IGMP on VBDIF1. IGMP snooping and IGMP snooping
proxy are automatically enabled in BD1. Establish a BGP EVPN peer relationship
between PE2 and PE3. CE1 is connected to PE1 through a common Layer 3
interface, and CE2 is connected to PE2 and PE3 through Eth-Trunk interfaces. Bind
the Eth-Trunk interfaces of CE2 to an E-Trunk and configure the same ESI on PE2
and PE3. The E-Trunks on PE2 and PE3 are configured to work in active-active
mode, and the Eth-Trunks on PE2 and PE3 are both up. In this example, PE2 is
selected as the DF, and PE3 is not selected as the DF.

(2020-10-09)
access side (Layer 2 accessing Layer 3 in active-active mode)
In a scenario of dual-homing access for IGMP snooping over EVPN on the access
side, devices are dual-homed to receivers, and Layer 2 multicast services access
Layer 3 multicast services. Then the IGMP snooping over EVPN MPLS working
1. PE2 and PE3 periodically send IGMP Query messages to the access side in
BD1.
2. The receiver sends an IGMP Report message, for example, IGMPv2 (*, G)
Report message, to CE2. CE2's Eth-Trunk connected to PE2 and PE3 is up. CE2
sends an IGMP Report message to PE2 or PE3 based on the hash rule.
3. Upon receipt of the IGMP Report message, PE2 or PE3 creates an IGMP
snooping (*, G) entry and sends an IGMP Join Synch route to each other. The
IGMP Join Synch route carries the ESI on the access side of PE2 or PE3, in
addition, the IGMP version and source filtering mode are included.
4. After PE2 or PE3 receives the IGMP Join Synch route, it creates an IGMP
snooping (*, G) entry in BD1. PE2 functions as a DF to advertise Layer 3 IGMP
(*, G) entries to VBDIF1 and uses the Eth-Trunk interface connected to CE2 as
an outbound interface. As a non-DF device, PE3 does not need to advertise
Layer 3 IGMP (*, G) entries to VBDIF1 or use the Eth-Trunk connected to CE2
as an outbound interface.
5. PE2 creates a Layer 3 PIM (*, G) entry, adds VBDIF1 as an outbound interface,
and sends a PIM Join message to PE1.
6. After receiving the PIM Join message from PE2, PE1 creates an IGMP (*, G)
entry and sends an IGMP Report message to CE1.
8. CE1 sends the multicast traffic received from the multicast source to PE1.
9. After receiving the multicast traffic, PE1 forwards the (*, G) entry to PE2 and
PE3 through the mLDP tunnel interfaces.
10. After PE2 and PE3 receive the multicast traffic, PE2 forwards the traffic to CE2
based on the (*, G) entries, but PE3 does not. In this case, the receiver receives
only one copy of multicast traffic.
11. If some receivers are disconnected or do not need to receive multicast traffic,
PE2 or PE3 updates the (*, G) entry based on the IGMP Report message
received from CE2 and then sends IGMP Join Synch route withdrawal

(2020-10-09)
messages to each other, which ensures that the (*, G) entries on PE2 and PE3
are the same.
12. If a fault occurs on the access side of PE2, the EVPN instance selects PE3 as
the DF and adds the Eth-Trunk interface connecting PE3 to CE2 as the
outbound interface so that multicast traffic can be forwarded from PE3 to
CE2.
3.1.11 Application Scenarios for EVPN
3.1.11.1 Using EVPN to Interconnect Other Networks

On the network shown in Figure 3-67, to interconnect different sites through a
public network, deploy EVPN by performing the following configurations:
● Configure a PE on the backbone network as an EVPN RR and the other PEs as
RR clients. Establish BGP EVPN peer relationships between the RR and clients,
but not between the clients. To improve reliability, you can configure two
EVPN RRs, one as the master and the other as the backup.
● Create EVPN instances on PEs. Configure the same RT values for the PEs to
allow EVPN route cross.
● Configure PE redundancy. If all PEs connecting to the same CE are configured
to work in All-Active mode, these PEs load-balance traffic destined for the CE.
Figure 3-67 EVPN application networking
3.1.11.2 EVPN L3VPN HVPN

At present, the IP bearer network uses L2VPN and L3VPN (HVPN) to carry Layer 2
and Layer 3 services, respectively. The protocols are complex. EVPN can carry both
Layer 2 and Layer 3 services. To simplify service bearer protocols, many IP bearer

(2020-10-09)
networks will evolve to EVPN. Specifically, L3VPN HVPN, which carries Layer 3
services, needs to evolve to EVPN L3VPN HVPN.
Figure 3-68 shows the basic architecture of an EVPN L3VPN HVPN consisting of
mainly UPEs, SPE, and NPE:
● UPE: A UPE is a device that is directly connected to a user and is referred to as
an underlayer PE or a user-end PE, therefore shortened as UPE. UPEs provide
access services for users.
● SPE: An SPE is a superstratum PE or service provider-end PE, which is
connected to UPEs and located at the core of a network. An SPE manages
and advertises VPN routes.
● NPE: An NPE is a network provider-end PE that is connected to SPEs and
located at the network side.
Figure 3-68 Basic EVPN L3VPN HVPN architecture
EVPN L3VPN HVPN is classified into EVPN L3VPN HoVPN or EVPN L3VPN H-VPN:
● EVPN L3VPN HoVPN: An SPE advertises only default routes or summarized
routes to UPEs. UPEs do not have specific routes to NPEs and can only send
service data to SPEs over default routes. As a result, route isolation is
implemented. An EVPN L3VPN HoVPN can use devices with relatively poor
route management capabilities as UPEs, reducing network deployment costs.
● EVPN L3VPN H-VPN: SPEs advertise specific routes to UPEs. UPEs function as
RR clients to receive the specific routes reflected by SPEs functioning as RRs.
This mechanism facilitates route management and traffic forwarding control.
As L3VPN HoVPN evolves towards EVPN L3VPN HoVPN, the following splicing
scenarios occur:
● Splicing between EVPN L3VPN HoVPN and common L3VPN: EVPN L3VPN
HoVPN is deployed between the UPEs and SPE, and L3VPN is deployed
between the SPE and NPE. The SPE advertises only default routes or
summarized routes to the UPEs. After receiving specific routes (EVPN routes)
from the UPEs, the SPE encapsulates these routes into VPNv4 routes and
advertises them to the NPE.
● Splicing between L3VPN HoVPN and BD EVPN L3VPN: L3VPN HoVPN is
deployed between the UPEs and SPE, and BD EVPN L3VPN is deployed
summarized routes to the UPEs. After receiving specific routes (L3VPN routes)
from the UPEs, the SPE encapsulates these routes into EVPN routes and

(2020-10-09)
Route Advertisement from CE1 to Device 1 on an EVPN L3VPN HoVPN or

EVPN L3VPN H-VPN
Figure 3-69 shows route advertisement from CE1 to Device 1 on an EVPN L3VPN
HoVPN or EVPN L3VPN H-VPN.
1. CE1 advertises an IPv4 route to the UPE using the IP protocol.
2. The UPE converts the IPv4 route into an IP prefix route with the next hop
being the UPE and then sends the IP prefix route to the SPE through a BGP-
EVPN peer relationship.
3. Upon receipt, the SPE advertises this route to the NPE in either of the
following ways:
– Using RR: Configure the SPE as an RR so that the RR directly reflects the
received IP prefix route to the NPE, and change the next hop of the route
to the SPE. An EVPN L3VPN H-VPN supports only this mode.
– Using re-encapsulation: The SPE re-encapsulates the IP prefix route into a
new IP prefix route with the next hop being the SPE. Then the SPE
advertises the new route to the NPE through a BGP-EVPN peer
relationship.
4. After receiving the IP prefix route, the NPE imports the route into its VRF
table under the condition that the route's next hop is reachable.
5. The NPE advertises the IPv4 route to Device 1 using the IP protocol.
Figure 3-69 Route advertisement from CE1 to Device 1 on an EVPN L3VPN

HoVPN or EVPN L3VPN H-VPN
Route Advertisement from Device 1 to CE1 on an EVPN L3VPN HoVPN

Figure 3-70 shows route advertisement from Device 1 to CE1 on an EVPN L3VPN
HoVPN.
1. Device 1 advertises an IPv4 route to the NPE using the IP protocol.
2. The NPE converts the IPv4 route into an IP prefix route with the next hop
being the NPE and then sends it to the SPE.
3. Upon receipt, the SPE converts the IP prefix route into an IPv4 route and
imports it into its VRF table under the condition that the route's next hop is
reachable.

(2020-10-09)
4. The SPE imports a default route or summarized route into its VRF table,
converts the default or summarized route into an IP prefix route with the next
hop being the SPE, and then advertises the IP prefix route to the UPE.
5. Upon receipt, the UPE converts the IP prefix route into an IPv4 route and
reachable.
6. The UPE advertises the IPv4 route to CE1 using the IP protocol.
Figure 3-70 Route advertisement from Device 1 to CE1 on an EVPN L3VPN

HoVPN
Route Advertisement from Device 1 to CE1 on an EVPN L3VPN H-VPN

Figure 3-71 shows route advertisement from Device 1 to CE1 on an EVPN L3VPN
H-VPN.
1. Device 1 advertises an IPv4 route to the NPE using the IP protocol.
2. The NPE converts the IPv4 route into an IP prefix route with the next hop
being the NPE and then sends it to the SPE.
3. Upon receipt, the RR-enabled SPE advertises the IP prefix route to the UPE,
and the route's next hop is changed to the SPE.
4. Upon receipt, the UPE converts the IP prefix route into an IPv4 route and
reachable.
5. The UPE advertises the IPv4 route to CE1 using the IP protocol.

(2020-10-09)
Figure 3-71 Route advertisement from Device 1 to CE1 on an EVPN L3VPN H-VPN
Route Advertisement from Device 1 to CE1 on an EVPN L3VPN HoVPN or

EVPN L3VPN H-VPN
Packet forwarding from Device 1 to CE1 on an EVPN L3VPN HoVPN or EVPN
L3VPN H-VPN is as follows:
1. Device 1 sends a VPN packet to the NPE.
2. After receiving the packet, the NPE searches its VPN forwarding table for a
tunnel to forward the packet based on the destination address of the packet.
Then, the NPE adds a VPN label (inner) and a tunnel label (outer) to the
packet and sends the packet to the SPE over the found tunnel.
3. Upon receipt, the SPE removes the outer tunnel label, replaces the inner VPN
label with a new one, and then adds the outer tunnel label to the packet.
Then, the SPE forwards the packet to the UPE through the tunnel.
4. After receiving the packet, the UPE removes the outer tunnel label and
searches for a VPN instance corresponding to the packet based on the inner
VPN label. Then, the UPE searches the forwarding table of the found VPN
instance for the outbound interface of the packet based on the destination
address of the packet. The UPE sends the packet from the corresponding
outbound interface to CE1. The packet sent by the UPE is a pure IP packet
with no label.
Packet Forwarding from CE1 to Device 1 on an EVPN L3VPN HoVPN

Packet forwarding from CE1 to Device 1 on an EVPN L3VPN HoVPN is as follows:
1. CE1 sends a VPN packet to the UPE.
2. After receiving the packet, the UPE searches its VPN forwarding table for a
tunnel to forward the packet based on the destination address of the packet
(the UPE does so by matching the destination address of the packet against
the forwarding entry for the default route or summarized route). Then, the
UPE adds a VPN label (inner) and a tunnel label (outer) to the packet and
sends the packet to the SPE over the found tunnel.
3. Upon receipt, the SPE removes the outer tunnel label and finds the
corresponding VPN instance based on the inner VPN label. The SPE then
removes the inner VPN label, searches the forwarding table of the VPN
instance for a tunnel to forward the packet based on the destination address
of the packet. Then, the SPE adds a new VPN label (inner) and tunnel label

(2020-10-09)
(outer) to the packet and sends the packet to the NPE through the found
tunnel.
4. After receiving the packet, the NPE removes the outer tunnel label and
VPN label. Then, the NPE searches the forwarding table of the found VPN
address of the packet. The NPE sends the packet from the corresponding
outbound interface to Device 1. The packet sent by the NPE is a pure IP
packet with no label.
Packet Forwarding from CE1 to Device 1 on an EVPN L3VPN H-VPN

Packet forwarding from CE1 to Device 1 on an EVPN L3VPN H-VPN is as follows:
1. CE1 sends a VPN packet to the NPE.
2. After receiving the packet, the UPE searches its VPN forwarding table for a
tunnel to forward the packet based on the destination address of the packet
(the UPE does so by matching the destination address of the packet against
the forwarding entry for the specific route received from the SPE). Then, the
UPE adds a VPN label (inner) and a tunnel label (outer) to the packet and
sends the packet to the SPE over the found tunnel.
3. Upon receipt, the SPE removes the outer tunnel label, replaces the inner VPN
label with a new one, and then adds the outer tunnel label to the packet.
Then, the SPE forwards the packet to the NPE through the tunnel.
4. After receiving the packet, the NPE removes the outer tunnel label and
VPN label. Then, the NPE searches the forwarding table of the found VPN
address of the packet. The NPE sends the packet from the corresponding
outbound interface to Device 1. The packet sent by the NPE is a pure IP
packet with no label.
Route advertisement and packet forwarding in scenarios where EVPN L3VPN
HoVPN and common L3VPN are spliced or L3VPN HoVPN and BD EVPN L3VPN
are spliced differ from those processes on an EVPN L3VPN HoVPN or L3VPN
HoVPN only in re-encapsulation of BGP VPNv4 or IP prefix routes on the SPE:
● Splicing between EVPN L3VPN HoVPN and common L3VPN: After receiving
the IP prefix route carrying CE1's specific route from the UPE, the SPE re-
encapsulates the IP prefix route into a BGP VPNv4 route and advertises it to
the NPE.
● Splicing between L3VPN HoVPN and BD EVPN L3VPN: After receiving the BGP
VPNv4 route carrying CE1's specific route from the UPE, the SPE re-
encapsulates the BGP VPNv4 route into an IP prefix route and advertises it to
the NPE.
3.1.11.3 EVPN 6VPE

6VPE is a VPN technology that allows connections to multiple IPv6 private sites
over an IPv4 public network or IPv4 backbone network. This ensures service
isolation between the IPv6 private sites of different users. On the network shown
in Figure 3-72, the components involved in the 6VPE function are the edge router
(PE), customer edge router (CE), and core router (P) of the backbone network.

(2020-10-09)
The virtual routing and forwarding (VRF) tables stored on PEs are used to process
the IPv6 routes of VPN sites. CEs that distribute user routes are connected to PEs
through physical or logical interfaces. Ps are the backbone network devices used
to forward VPN packets into which tunnel attributes are encapsulated.
Figure 3-72 6VPE model
Currently, EVPN supports the 6VPE function. The processing mechanism of EVPN
6VPE is similar to that of EVPN L3VPN. On the network shown in Figure 3-73, PEs
can exchange host routes and IP prefix routes to transmit IPv6 route information
of different sites in a VPN. The fields contained in the host routes and IP prefix
routes are as follows:
● Fields in host routes:
– Route Distinguisher (RD): Specifies the RD value set for an EVPN
instance.
– Ethernet Segment Identifier (ESI): Uniquely identifies a connection
between a PE and a CE.
– Ethernet Tag ID: In VLAN-Aware accessing BD EVPN scenarios, the value
is BD-Tag. In other scenarios, the value contains all 0s.
– MAC Address Length: Specifies the MAC address length in an ND entry.
– MAC Address: Specifies a MAC address in an ND entry.
– IPAddress Length: Specifies the IPv6 address length in an ND entry.
– IP Address: Specifies an IPv6 address in an ND entry.
– MPLS Label1: Specifies the VPN label of EVPN.
– MPLS Label2: Specifies the label used for Layer 3 traffic forwarding.
● Fields in IP prefix routes:
– RD: Specifies the RD value set for an EVPN instance.
– ESI: Uniquely identifies a connection between a PE and a CE.
– Ethernet Tag ID: Currently, the value of this field contains all 0s.
– IPAddress Length: Specifies the IPv6 address length in an ND entry.
– IP Address: Specifies an IPv6 address in an ND entry.

(2020-10-09)
– GW IP Address: Specifies the default gateway address.

– MPLS Label: Specifies the VPN label of EVPN.
Figure 3-73 EVPN 6VPE model
In Figure 3-74, the network has been deployed with the IP RAN solution and a
large number of IPv4-related services. If new services need to be deployed, IPv6
addresses may be used in consideration of IPv4 address exhaustion. In this case,
deploy EVPN L3VPNv6 HVPN in the 6VPE model to carry IPv6 services. The
processing mechanism of EVPN 6VPE is similar to that of L3VPN HVPN.
Figure 3-74 Application of EVPN 6VPE in IP RAN scenarios
Similarly, EVPN 6VPE can be deployed in DCI scenarios to carry IPv6-related

services. On the network shown in Figure 3-75, DCs are connected to the DCI
backbone network over VXLAN tunnels or through VLAN sub-interfaces. The DCI
backbone network uses the EVPN 6VPE function to transmit IPv6 routes between

(2020-10-09)
DCs. An MPLS or SR tunnel can be deployed between DCI-PEs to carry IPv6

services.
Figure 3-75 Application of EVPN 6VPE in DCI scenarios
3.1.11.4 EVPN Splicing Scenarios
Background
Currently, metro networks are evolving towards EVPN. An existing network with a
large number of aggregation devices cannot evolve to EVPN in an E2E mode at a
time. During the transition, conventional L3VPN, VPWS, or VPLS is used at the
aggregation layer, and the core network evolves to EVPN first. In this case, splicing
between the EVPN and existing networks is required.
L3VPN Accessing EVPN

Devices between the UPE and NPE1 reside at the aggregation layer, and devices
between NPE1 and NPE2 reside at the core layer. The L3VPN function is deployed
at the aggregation layer, and the EVPN function is deployed at the core layer.
After accepting access-side user routes, the UPE sends these routes to NPE1
through a BGP VPNv4 peer relationship. Upon receipt of the BGP VPNv4 routes,
NPE1 with both an EVPN instance and an L3VPN instance configured imports
these routes into the L3VPN instance, re-generates the routes as EVPN routes, and
sends the EVPN routes to NPE2 through a BGP EVPN peer relationship. Then,
network connectivity can be achieved in the L3VPN accessing EVPN scenario.

(2020-10-09)
Figure 3-76 L3VPN accessing EVPN
VLL Accessing EVPN

In the VLL accessing EVPN networking, a user named CE1 has three sites: CE1-1,
CE1-2, and CE1-3; another user named CE2 also has three sites: CE2-1, CE2-2, and
CE2-3. NIDs, which aggregate user site, add two VLAN tags to user packets before
sending these packets over the aggregation network. In a double-tagged user
packet, an S-VLAN ID identifies a NID, and a C-VLAN ID identifies a user site
connected to the NID. Users access the VLL network, which is a native Layer 2
network, through the NIDs. An MPLS network is deployed at the aggregation layer
between the UPE and NPE1, and uses VLL to carry services. Another MPLS
network is deployed at the core layer between NPE1 and NPE2, and uses EVPN to
carry services.
VLL accessing EVPN allows different sites of the same user to communicate in the
following scenarios:
● Single-homing scenario
The access-side main interfaces on NIDs can be used to provide user access. A
UPE establishes a PW to each NID. On the NPEs, an EVPN instance is created
for each user and the VLL accesses the EVPN instance in PW VE mode. The
VLL service is bound to the PW VE main interface, each EVPN instance is
bound to a PW VE sub-interface. The sub-interfaces use QinQ encapsulation
and forward packets based on S-VLAN and C-VLAN IDs, steering traffic to
different EVPN instances.
Figure 3-77 VLL accessing EVPN (one PW to each NID)

(2020-10-09)
Similarly, the VLL accessing EVPN scenario also allows multiple NIDs to
connect to a PW. Multiple NIDs are aggregated onto a switch and then
connect to the same PW.
Figure 3-78 VLL accessing EVPN (multiple NIDs connected to one PW)
● Dual-homing networking
A UPE is dual-homed to the master and backup NPEs through the primary
and secondary PWs, respectively, which improves access reliability. EVPN
services on the NPEs can be configured to work in single-active or all-active
mode. In all-active mode, load balancing can be implemented.
Figure 3-79 VLL accessing EVPN (dual-homing scenario)
VXLAN Accessing VPLS

When an enterprise campus network is connected to a data center network, an
EVPN VXLAN network needs to be deployed in the data center, and the data
center network is connected to the enterprise campus network through an MPLS
L2VPN. In this case, the functions of terminating VXLAN packets and accessing
VPLS need to be deployed.
In Figure 3-80, the EOR switch, functioning as a data center gateway, connects to
the backbone network through egress PE1 and PE2 of the data center network.
PE3, the egress of the enterprise campus network, is connected to PE1 and PE2
through the MPLS VPLS network. PE1 and PE2 are configured to terminate VXLAN

(2020-10-09)
packets and access the MPLS VPLS network to connect the data center to the
campus network.
Figure 3-80 VXLAN accessing VPLS networking
Splicing Primary and Secondary PWs with an Anycast VXLAN Tunnel in an

EVPN Active-Active Scenario
In Figure 3-81, PE1 and PE2 are egresses of the data center network. PE1 and PE2
work in active-active mode with a bypass VXLAN tunnel deployed between them.
They use an anycast VTEP address to establish a VXLAN tunnel with the EOR
switch. In this case, PE1, PE2, and the EOR switch can communicate with each
other. PE1 and PE2 communicate with the external network (an access network or
the Internet) through the VPLS network. VPLS PW redundancy is deployed on the
VPLS network. That is, the PE-AGG connects to PE1 and PE2 through primary and
secondary PWs, respectively. In this example, the PW between the PE-AGG and
PE1 is the primary PW.
Through the EOR, the server in the data center can send traffic to PE1 and PE2.
Traffic received by PE1 is sent directly to the PE-AGG through the primary PW.
Traffic received by PE2 is forwarded to PE1 through the bypass VXLAN tunnel and
also sent to the PE-AGG through the primary PW. Traffic from the PE-AGG to the
server is transmitted along the reverse paths of the preceding forward paths.
Figure 3-81 Splicing the primary and secondary PWs with an anycast VXLAN
tunnel in EVPN active-active scenario

(2020-10-09)
Splicing VPLS with MPLS EVPN

VPLS technology has some inherent defects. For example, it does not support load
balancing and consumes a large number of network resources (because MAC
learning and ARP learning involve broadcasting on the entire network). With the
application of EVPN on the live network, the VPLS network will gradually evolve
to the EVPN network. However, a user network environment is complex and may
not completely evolve to the EVPN network. VPLS is deployed on some devices,
and EVPN is deployed on the other devices. In this case, you can configure splicing
between VPLS and MPLS EVPN to implement connectivity of the entire network.
In Figure 3-82, VPLS is deployed between the CSG and ASG, and the CSG is
connected to ASGs through the primary and secondary PWs. EVPN is deployed
between the ASGs and RSG. BDs are configured and bound to VSIs and EVPN
instances on ASG1 and ASG2 so that all PWs in the VSIs access the EVPN instances
through BDs. If a CSG is dual-homed to ASG1 and ASG2, the same ESI must be set
for the primary and secondary PW interfaces on ASG1 and ASG2. The route
advertisement and traffic forwarding process is as follows:
1. ASG1 sends an Ethernet Auto-Discovery route to the RSG as the PW interface
is assigned an ESI and the PW is up on ASG1.
2. After the CSG forwards a Layer 2 packet sent by site 1 to ASG1, ASG1
generates a MAC route based on the MAC address carried in the Layer 2
packet and sends the route to the RSG through a BGP EVPN peer relationship.
The RSG uses the MAC route and Ethernet Auto-Discovery route to generate a
MAC forwarding entry. Similarly, the RSG sends a MAC route carrying site 2's
MAC address to ASG1, and ASG1 generate a MAC forwarding entry.
3. After the forwarding entries are created, they can be used to guide unicast
and BUM traffic forwarding. The process of forwarding unicast traffic from
site 1 to site 2 is used as an example. After traffic is sent to ASG1 through the
primary PW, ASG1 finds a next-hop MAC address based on a MAC route sent
by the RSG and forwards the traffic to the RSG. The RSG then forwards the
traffic to site 2.
NOTE
Although ASG1 and ASG2 exchange Ethernet segment routes, DF election between ASG1
and ASG2 is determined by the PW status, not by the Ethernet segment routes. ASG1
connected to the primary PW is the primary DF, and ASG2 connected to the secondary PW
is the secondary DF.
In BUM traffic forwarding scenarios, the network provides the split horizon function, and
the backup DF blocks traffic. Therefore, no traffic loop or excess packets occur on the
network.

(2020-10-09)
Figure 3-82 Splicing between VPLS and MPLS EVPN
3.1.11.5 Inter-AS EVPN Option C

Inter-AS EVPN Option C implements Layer 2 interconnection between networks in
different ASs.
Background
With the wide application of MPLS VPN solutions, different MANs of a service
provider or collaborative backbone networks of different service providers often
span multiple ASs. Similar to L3VPN services, EVPN services running on an MPLS
network must also have the capability of spanning ASs.
Implementation
By advertisement of labeled routes between PEs, end-to-end BGP LSPs can be
established to carry Layer 2 traffic in BGP ASs (including inter-IGP areas) and
inter-BGP ASs that only support Option C.
In Option C mode, an autonomous system boundary router (ASBR) does not
maintain or advertise EVPN routes. Instead, PEs exchange EVPN routes directly.
EVPN routes include the following:
● Ethernet auto-discovery routes
● MAC and IP routes
● Inclusive multicast routes
● Ethernet segment routes
● ASBRs advertise labeled IPv4 routes to PEs in their respective ASs through MP-
IBGP, and advertise labeled IPv4 routes received on PEs in the local AS to the
ASBR peers in other ASs. ASBRs in the transit AS also advertise labeled IPv4
routes. Therefore, a BGP LSP can be established between the ingress PE and
egress PE.
● PEs in different ASs establish multi-hop EBGP connections with each other
and exchange EVPN routes.

(2020-10-09)
● ASBRs do not store EVPN routes or advertise EVPN routes to each other.
Figure 3-83 Inter-AS EVPN Option C networking where PEs advertise labeled
EVPN routes
To improve expansibility, you can specify a route reflector (RR) in each AS. An RR
stores all EVPN routes and exchanges EVPN routes with PEs in the AS. RRs in two
ASs establish MP-EBGP connections with each other and advertise EVPN routes.
Figure 3-84 Inter-AS EVPN Option C networking with RRs
Inter-AS EVPN Option C can be implemented using the following solutions:

● A local ASBR learns a labeled public network BGP route from the peer ASBR,
assigns a label to this route based on a matching policy, and advertises this
route to its IBGP peer. Then, a complete public network LSP is established.
● The IBGP peer relationship between a PE and ASBR in the same AS is not
required. In this solution, a local ASBR learns a labeled public network BGP

(2020-10-09)
route from the peer ASBR and imports this route to an IGP to trigger LDP LSP
establishment. Then, a complete LSP is established between the ingress and
egress on the public network.
Benefits
● EVPN routes are directly exchanged between an ingress PE and egress PE. The
routes do not have to be stored and forwarded by intermediate devices.
● Only PEs exchange EVPN routing information. Ps and ASBRs forward packets
only. The intermediate devices need to support only MPLS forwarding rather
than MPLS VPN services. In such a case, ASBRs are no longer the performance
bottlenecks. Inter-AS EVPN Option C, therefore, is suitable for an EVPN that
spans multiple ASs.
3.1.11.6 DCI Scenarios

Data Center Interconnect (DCI) is a solution for communication between virtual
machines (VMs) in different data centers (DCs). DCI runs on carriers' networks. It
uses technologies such as Virtual eXtensible Local Area Network (VXLAN),
Ethernet virtual private network (EVPN), and BGP/MPLS IP VPN to ensure secure
and reliable transmission of packets from DCs, implementing communication
between VMs in different DCs.
Table 3-9 Basic DCI concepts
Concept Description
Overlay network ● An overlay network is a logical network

established on a physical network and
can be considered as a network
connected through virtual or logical
links.
● The overlay network has an
independent control plane and
forwarding plane.
● The overlay network deeply extends a
physical network to a cloud-based and
virtualized network and frees the cloud
resource pool from the limitations of the
physical network. This is the key to the
convergence of the cloud network.
Underlay network An underlay network carries an overlay

network and is usually a physical network
at the underlying layer.
Individual deployment of DC-GWs A DC-GW and a DCI-PE are different

and DCI-PEs devices.
Integrated deployment of DCI-PEs A DC-GW and a DCI-PE are a single device,

and DC-GWs which applies to scenarios where carriers
build their own DCs.

(2020-10-09)
On the network shown in Figure 3-85, gateways in the DCs (DC-GW1 and DC-
GW2) can access the carrier's network edge devices (DCI-PE1 and DCI-PE2) in
EVPN-VXLAN or VLAN mode. The L3VPN or EVPN-MPLS function can be deployed
on the DCI backbone network to transmit Layer 2 or Layer 3 service traffic. When
DC A and DC B exchange their tenant host IP addresses or MAC addresses, EVPN
integrated routing and bridging (IRB) routes, EVPN IP prefix routes, BGP VPNv4
routes, EVPN MAC routes, or ARP routes are used. For details about these routes,
see Table 3-10.
Figure 3-85 Basic DCI scenario

(2020-10-09)
Table 3-10 Route information

Route Function Fields Carried in a Route
● RD1: route distinguisher

1, indicating the route
ID of an EVPN instance.
● VM-MAC: MAC address
of a VM.
● VM-IP: IP address of a
VM.
● Label 1: L2VNI of a
VXLAN tunnel or Layer
2 MPLS label.
● Label 2: L3VNI of a
Used to transmit a tenant's VXLAN tunnel or Layer
EVPN IRB route host IP address and MAC 3 MPLS label.
address on an EVPN. ● NHP: next hop of a
route, usually a local IP
address used to
establish a BGP EVPN
peer relationship.
● ExtCommunity:
extended community
attributes of a route,
including the VXLAN
encapsulation mode,
Router-MAC, and export
route target (ERT) of a
route.

(2020-10-09)

● IP: VM's IP address or
address of the network
segment to which a
VM's IP address
belongs.
● Label: L3VNI of a
Used to transmit a tenant's
VXLAN tunnel or Layer
host IP address or the
3 MPLS label.
address of the network
EVPN IP prefix route ● NHP: next hop of a
segment to which the host
IP address belongs on an route, usually a local IP
EVPN. address used to
peer relationship.
● ExtCommunity:
extended community
including the VXLAN
encapsulation mode,
Router-MAC, and ERT of
a route.

2, indicating the ID of a
VPNv4 route.
VM.
Used to transmit a tenant's ● Label: VPN label carried
host IP address or the in VPNv4 routes.
address of the network ● NHP: next hop of a
VPNv4 route
segment to which the host route, usually a local IP
IP address belongs on an address used to
L3VPN. establish a BGP VPNv4
peer relationship.
● ExtCommunity:
extended community
attribute of a route,
only the ERT attribute.

(2020-10-09)

● VM-MAC: MAC address
of a VM.
VM. This field is carried
only in ARP routes.
● Label: L2VNI of a
Used to transmit a tenant's VXLAN tunnel or Layer
EVPN MAC route or 2 MPLS label.
host MAC address or ARP
ARP route
information on an EVPN. ● NHP: next hop of a
route, usually a local IP
address used to
peer relationship.
● ExtCommunity:
extended community
including the VXLAN
encapsulation mode
and ERT of a route.
DCI Control Plane

The DCI control plane advertises both Layer 3 and Layer 2 routes:
● During Layer 3 route advertisement, a DC sends an IRB route or IP prefix
route carrying a tenant's host IP address to a DCI-PE through the EVPN
protocol. Upon receipt, the DCI-PE re-encapsulates the routing information
into a BGP VPNv4 route if an L3VPN is deployed on the backbone network.
Alternatively, if EVPN-MPLS is deployed on the backbone network, the DCI-PE
re-encapsulates the received route into an IRB or IP prefix route. The re-
encapsulated routes carry the VM's IP route and are transmitted to the
remote DCI-PE through the backbone network.
● The process of Layer 2 route advertisement is that a DC uses EVPN to send
packets carrying the host's MAC address or ARP entries to the local DCI-PE.
The local DCI-PE then re-generates the EVPN MAC/ARP routes that carry the
MPLS encapsulation attribute. The regenerated routes that carry the VM's
MAC address or ARP entries are transmitted to the remote DCI-PE.
Table 3-11 describes Layer 3 route advertisement and Layer 2 route
advertisement.

(2020-10-09)
Table 3-11 Route advertisement

Advertisement Process
Deployme
Services DC-GW1 to DCI-PE1 to DCI- DCI-PE2 to DC-
nt Mode
DCI-PE1 PE2 GW2
Upon receipt,
DCI-PE2
imports the
BGP VPNv4
route into the
DCI-PE1 re- local IP VPN
encapsulates instance based
the EVPN route on the route RT
DC-GW1 sends received from and delivers
a tenant's host DC-GW1 into a information
IP address to BGP VPNv4 about MPLS
DCI-PE1 route, applying tunnel recursion
through an IRB the following to the VPN
route or IP changes: forwarding
prefix route. table. DCI-PE2
DCI-PE1 parses ● Changes the re-encapsulates
the tenant's next hop to the received
host IP route the local BGP VPNv4
from the device's IP route into an IP
received EVPN address used prefix route,
route. Then the to establish a applying the
system imports BGP VPNv4 following
L3VPN peer
Layer 3 the tenant's changes:
(VXLAN relationship.
services route into the IP ● Changes the
access)
VPN instance ● Replaces the next hop to
based on RT RD and RT the VTEP
matching values of the address of
between the EVPN route DCI-PE2.
EVPN route and with those of
the IP VPN an L3VPN ● Replaces the
instance and instance. RD and RT
delivers values of the
● Applies for BGP VPNv4
information and
about VXLAN route with
encapsulates those of the
tunnel recursion a VPN label.
to the VPN L3VPN
forwarding After re- instance and
table. encapsulation, pads the
DCI-PE1 sends route with
the route to an L3VNI.
DCI-PE2. After re-
encapsulation,
DCI-PE2 sends
the IP prefix
route to DC-
GW2.

(2020-10-09)
Deployme
nt Mode
DCI-PE1 PE2 GW2
DCI-PE1 re-
encapsulates
the VPN route
into an IP prefix
route, applying
the following
changes: After receiving
● Changes the the EVPN route,
DC-GW1 sends next hop to DCI-PE2
routes destined the local imports the
for the network device's IP route into the
segment on address used local IP VPN
which a tenant's to establish a instance based
host IP address BGP EVPN on the RT of
EVPN-
resides to DCI- peer the EVPN route,
MPLS Layer 3
PE1 through an relationship. generates a
(VLAN services
IGP or BGP VPN route
access) ● Adds the RD
route. Upon forwarding
and RT
receipt, DCI-PE1 entry, and
attributes to
delivers these advertises the
the EVPN
routes to the EVPN route to
route.
VPN forwarding DC-GW2
table. ● Applies for through a VPN
and IGP or BGP peer
encapsulates relationship.
a VPN label.
After re-
encapsulation,
DCI-PE1 sends
the route to
DCI-PE2.

(2020-10-09)
Deployme
nt Mode
DCI-PE1 PE2 GW2
DCI-PE1
generates an
EVPN MAC
route, applying
the following
changes:
● Changes the
next hop to
the local Upon receipt,
DCI-PE1 learns
device's IP DCI-PE2
the source MAC
address used imports the
address of
to establish a MAC/IP
service traffic
BGP EVPN advertisement
received from
peer route into the
DC-GW1. Then
Layer 2 relationship. local EVPN
DCI-PE1
services instance based
generates a ● Adds the RD
on the route RT
local MAC and RT
and generates a
forwarding attributes to
local Layer 2
entry and an the EVPN
forwarding
EVPN MAC route.
entry
route. ● Applies for accordingly.
and
encapsulates
a VPN label.
After re-
encapsulation,
DCI-PE1 sends
the route to
DCI-PE2.

(2020-10-09)
Deployme
nt Mode
DCI-PE1 PE2 GW2
DCI-PE1 re-
DC-GW1 sends encapsulates
a tenant's host the route into
IP address to an IRB or IP
DCI-PE1 prefix route. The Upon receipt,
through an IRB encapsulation DCI-PE2
route or IP mode changes imports the IRB
prefix route. from VXLAN to or IP prefix
DCI-PE1 parses MPLS: route into the
the tenant's ● Changes the IP VPN instance
host IP route next hop to and delivers
from the the local information
received EVPN device's IP about MPLS
route. Then the address used tunnel recursion
system imports to establish a to the VPN
EVPN-
the tenant's BGP EVPN forwarding
MPLS Layer 3
route into the IP peer table. DCI-PE2
(VXLAN services
VPN instance relationship. changes the L2
access)
based on RT and L3 VPN
● Adds the RD
matching labels in the
and RT
between the route to L2 and
attributes to
local EVPN L3 VNIs, re-
the EVPN
instance and encapsulates
route.
the IP VPN the route into
instance and ● Applies for an IRB or IP
delivers and prefix route,
information encapsulates and then sends
about VXLAN a VPN label. the route to
tunnel recursion After re- DC-GW2.
to the VPN encapsulation,
forwarding DCI-PE1 sends
table. the route to
DCI-PE2.

(2020-10-09)
Deployme
nt Mode
DCI-PE1 PE2 GW2
Upon receipt,
DCI-PE2
DCI-PE1 re- imports the
encapsulates MAC/IP
the EVPN routes advertisement
and change the route into the
next-hop IP local EVPN
address to the instance based
DC-GW1 sends IP address of on RT
a tenant's host the locally matching. DCI-
MAC address to established PE2 re-
DCI-PE1 EVPN peer. The encapsulates
through a RD and RT the EVPN route
MAC/IP attributes in the by changing the
advertisement EVPN routes next hop to its
route. DCI-PE1 that carry the own VTEP
Layer 2 imports the VXLAN address,
services MAC/IP encapsulation replacing the
advertisement attribute are RD and RT
route into the replaced with values of the
local EVPN the RD and RT EVPN route
instance based of the local with those of
on RT matching EVPN instance. the local EVPN
and generates a The MPLS label instance and
MAC forwarding is requested. padding the
entry. The reroute with an
encapsulated L2VNI. Then
MAC/IP DCI-PE2 sends
Advertisement the re-
routes are then encapsulated
advertised to MAC address
DCI-PE2. advertisement
route to DC-
GW2.
DCI Data Plane

Table 3-12 describes Layer 2 traffic forwarding and Layer 3 traffic forwarding.

(2020-10-09)
Table 3-12 Service traffic forwarding

Forwarding Process
Deployme
nt Mode
DCI-PE2 PE1 GW1
DCI-PE2 parses
the VXLAN data
Upon receipt,
packet to obtain
DCI-PE1
the VNI and
removes the
data packet.
public MPLS
Based on the
tunnel label,
VNI, DCI-PE2
and, based on
finds the
the VPN label,
corresponding
finds the
VPN instance
corresponding
and, based on
VPN instance.
the tenant's
Then, based on
host IP address
the tenant's
DC-GW2 sends for the MPLS
host IP address
L3VPN a data packet to tunnel to DCI-
Layer 3 for the VXLAN
(VXLAN DCI-PE2 PE1, searches
services tunnel to DC-
access) through the the
GW1, DCI-PE1
VXLAN tunnel. corresponding
searches the
VPN instance
corresponding
forwarding
VPN instance
table. After
forwarding
encapsulating a
table. DCI-PE1
VPN label and a
encapsulates
public MPLS
the data packet
tunnel label into
with a VXLAN
the data packet,
header and
DCI-PE2 sends
then sends the
the packet to
VXLAN packet
DCI-PE1
to DC-GW1.
through the
MPLS tunnel.

(2020-10-09)
Forwarding Process
Deployme
nt Mode
DCI-PE2 PE1 GW1
Upon receipt,
DCI-PE2 DCI-PE1
searches the removes the
forwarding table public MPLS
of the VPN tunnel label,
instance bound and, based on
to the interface the VPN label,
that receives the finds the
data packet corresponding
and, based on VPN instance.
the destination Based on the
DC-GW2 sends address of the tenant's host IP
EVPN-
a data packet to data packet, address, DC-PE1
MPLS Layer 3
DCI-PE2 finds the MPLS searches the
(VLAN services
through VPN tunnel to DCI- corresponding
access)
forwarding. PE1. After VPN instance
encapsulating a forwarding
VPN label and a table for the
public MPLS outbound
tunnel label into interface to DC-
the data packet, GW1. Then, DC-
DCI-PE2 sends PE1 sends the
the packet to data packet to
DCI-PE1 DC-GW1
through the through the
MPLS tunnel. outbound
interface.

(2020-10-09)
Forwarding Process
Deployme
nt Mode
DCI-PE2 PE1 GW1
Upon receipt,
DCI-PE2 DCI-PE1
searches the removes the
forwarding table public MPLS
of the EVPN tunnel label,
instance bound and, based on
to the interface the VPN label,
that receives the finds the
data packet corresponding
and, based on EVPN instance.
the destination Based on the
DC-GW2 sends
address of the MAC
a data packet to
data packet, forwarding
Layer 2 DCI-PE2
finds the MPLS entry for the
services through Layer 2
tunnel to DCI- broadcast
forwarding on
PE1. After domain bound
the data plane.
encapsulating a to the EVPN
VPN label and a instance, DC-
public MPLS PE1 finds the
tunnel label into corresponding
the data packet, outbound
DCI-PE2 sends interface and
the packet to sends the data
DCI-PE1 packet to DC-
through the GW1 through
MPLS tunnel. the outbound
interface.

(2020-10-09)
Forwarding Process
Deployme
nt Mode
DCI-PE2 PE1 GW1
DCI-PE2 parses
the VXLAN data
Upon receipt,
packet to obtain
DCI-PE1
the VNI and
removes the
data packet.
public MPLS
Based on the
tunnel label,
VNI, DCI-PE2
and, based on
finds the
the VPN label,
corresponding
finds the
VPN instance
corresponding
and, based on
VPN instance.
the tenant's
Then, based on
host IP address
the tenant's
DC-GW2 sends for the MPLS
EVPN- host IP address
a data packet to tunnel to DCI-
MPLS Layer 3 for the VXLAN
DCI-PE2 PE1, searches
(VXLAN services tunnel to DC-
through the the
access) GW1, DCI-PE1
VXLAN tunnel. corresponding
searches the
VPN instance
corresponding
forwarding
VPN instance
table. After
forwarding
encapsulating a
table. DCI-PE1
VPN label and a
encapsulates
public MPLS
the data packet
tunnel label into
with a VXLAN
the data packet,
header and
DCI-PE2 sends
then sends the
the packet to
VXLAN packet
DCI-PE1
to DC-GW1.
through the
MPLS tunnel.

(2020-10-09)
Forwarding Process
Deployme
nt Mode
DCI-PE2 PE1 GW1
DCI-PE2 parses
the VXLAN data
packet to obtain
the VNI and
data packet.
Based on the
VNI, DCI-PE2
finds the Upon receipt,
corresponding DCI-PE1
broadcast removes the
domain. Based public MPLS
on the tunnel label
broadcast and, based on
domain, DCI- the VPN label
PE2 finds the and BD ID, finds
forwarding table the
of the corresponding
corresponding broadcast
EVPN instance. domain, and
DC-GW2 sends DCI-PE2 then, based on
a data packet to searches for the the tenant's
Layer 2
DCI-PE2 forwarding host destination
services
through the information MAC address,
VXLAN tunnel. corresponding searches the
to the broadcast
destination domain for the
address of the VXLAN tunnel
data packet, to DC-GW1.
that is, DCI-PE1
information encapsulates
about the MPLS the data packet
tunnel to DCI- with a VXLAN
PE1. After header and
encapsulating a then sends the
VPN label and a VXLAN packet
public MPLS to DC-GW1.
tunnel label into
the data packet,
DCI-PE2 sends
the packet to
DCI-PE1
through the
MPLS tunnel.
3.1.11.7 NFVI Distributed Gateway (SR Tunnels)

The network function virtualization infrastructure (NFVI) telco cloud solution uses
the data center interconnect (DCI)+data center network (DCN) networking. A

(2020-10-09)
large amount of mobile phone traffic is sent to virtual unified gateways (vUGWs)
and virtual multiservice engines (vMSEs) on the DCN. After being processed by the
vUGWs and vMSEs, the IPv4 or IPv6 mobile phone traffic is forwarded over the
DCN to destination devices on the Internet. The destination devices send traffic to
mobile phones in similar ways. To achieve these functions and ensure traffic load
balancing on the DCN, you need to deploy the NFVI distributed gateway function.
NOTE
A vUGW is a unified gateway developed for Huawei's CloudEdge solution, which can be
used for 3GPP access in GPRS, UMTS, and LTE modes. A vUGW can be a GGSN, an S-GW, or
a P-GW, which meets the networking requirements of carriers in different stages and
operations scenarios.
A vMSE is a virtual type of an MSE. The current carrier network includes multiple functional
boxes, including the firewall box, video acceleration box, header enhancement box, and URL
filter box. All of these functions are enabled through patch installation, causing a more and
more complex network and difficult service provisioning and maintenance. To address the
problems, vMSEs incorporate the functions of these boxes, uniformly manage these
functions, and implement value-added service processing for the data service initiated by
users.
The NFVI distributed gateway function supports service traffic transmission over
SR or VXLAN tunnels. SR tunnels are classified as SR tunnels or E2E SR tunnels.
This section describes the implementation of the NFVI distributed gateway
function for traffic transmission over SR tunnels.
Networking Introduction
Figure 3-86 shows the networking of an NFVI distributed gateway (SR tunnels).
DC-GWs, which are the border gateways of the DCN, exchange Internet routes
with external devices over PEs. L2GW/L3GW1 and L2GW/L3GW2 are connected to
VNFs. VNF1 and VNF2 that function as virtualized NEs are deployed to implement
the vUGW functions and vMSE functions, respectively. VNF1 and VNF2 are each
connected to L2GW/L3GW1 and L2GW/L3GW2 through IPUs.

(2020-10-09)
Figure 3-86 NFVI distributed gateway networking
Function Deployment
In NFVI distributed gateway networking (SR tunnels) shown in Figure 3-86, users
need to plan the number of bridge domains (BDs) based on the number of
network segments corresponding to each IPU. An example assumes that the four
IP addresses planned for four IPUs belong to four network segments. In this case,
four BDs need to be planned. You need to configure the BDs and the
corresponding VBDIF interfaces on all DC-GWs and L2GW/L3GWs and bind all the
VBDIF interfaces to the same L3VPN instance. In addition, the following functions
need to be deployed on the DCN:
● Establish BGP VPN peer relationships between VNFs and DC-GWs so that the
VNFs can advertise mobile phone routes (UE IP) to DC-GWs.
● On L2GW/L3GW1 and L2GW/L3GW2, configure static VPN routes with the IP
addresses of VNFs as the destination addresses and the IP addresses of IPUs
as next-hop addresses.

(2020-10-09)
● Establish BGP EVPN peer relationships between any DC-GW and L2GW/L3GW.
Based on the BGP EVPN peer relationships, the L2GW/L3GW can flood the
static routes destined for VNFs to other devices, and the DC-GW can then
advertise local loopback routes and default routes to the L2GW/L3GW.
● Establish BGP VPNv4/v6 peer relationships between DC-GWs and PEs. DC-
GWs can then advertise mobile phone routes to PEs and receive the Internet
routes sent by external devices based on the BGP VPNv4/v6 peer
relationships.
● Deploy SR tunnels between PEs and DC-GWs and between DC-GWs and
L2GW/L3GWs to carry service traffic.
● The traffic transmitted between mobile phones and the Internet over VNFs is
north-south traffic. The traffic transmitted between VNF1 and VNF2 is east-
west traffic. To achieve load balancing of east-west traffic and north-south
traffic, deploy the load balancing function on DC-GWs and L2GW/L3GWs.
Establishment of Forwarding Entries

In NFVI distributed gateway networking, to avoid route loops between DC-GWs
and L2GW/L3GWs, both the mobile phone-to-Internet traffic and Internet-to-
mobile-phone traffic are forwarded from DC-GWs to VNFs at Layer 2 when
entering the DCN and forwarded from VNFs to DC-GWs at Layer 3 when leaving
out of the DCN. The procedures for establishing forwarding entries on each device
are as follows:
1. On L2GW/L3GWs, the number of BDs is planned based on the number of
network segments corresponding to the IPUs, the BDs are bound to the links
connecting to the corresponding IPUs, and VBDIF interfaces are configured as
the gateways of IPUs. Static VPN routes are configured on L2GW/L3GWs so
that the forwarding entries with the destination address as a VNF's address,
the next-hop address as an IPU's IP address, and outbound interface as the
VBDIF interface can be established on L2GW/L3GWs.
Figure 3-87 Forwarding entries of static routes on L2GW/L3GWs
2. L2GW/L3GWs learn the MAC addresses and ARP information of IPUs through
the data plane. Such information is advertised to DC-GWs through EVPN
routes and can be used for establishment of ARP entries and MAC entries for
Layer 2 forwarding.
– The destination MAC addresses in the MAC entries on L2GW/L3GWs are
IPUs' MAC addresses. For the IPU directly connected to an L2GW/L3GW,
this IPU is used as the outbound interface in MAC entries. For the IPUs
(such as IPU3 and IPU4 corresponding to L2GW/L3GW2 in Figure 3-86)

(2020-10-09)
connecting to non-direct-link L2GW/L3GWs, MAC entries include the

outbound interfaces of SR tunnels and the next-hop addresses, namely,
the IP addresses of the BGP EVPN peers of these L2GW/L3GWs.
– In the MAC entries on DC-GWs, the destination MAC address is an IPU's
MAC address, the IP address of the BGP EVPN peer of an L2GW/L3GW is
the next-hop address, and the outbound interface is the one for traffic
forwarding over SR tunnels.
NOTE
To allow inbound traffic to be forwarded only at Layer 2, configure these devices to

advertise only ARP or ND routes. In this manner, DC-GWs and L2GW/L3GWs do not
generate IP prefix routes based on IP addresses. If these devices are configured to
advertise IRB or IRBv6 routes, you need to enable asymmetric IRB on the devices
receiving routes.
Figure 3-88 MAC entries on DC-GWs and L2GW/L3GWs
3. After static VPN routes are configured on L2GW/L3GWs, these static VPN
routes are imported to the BGP EVPN routing table and sent to DC-GWs as IP
prefix routes based on BGP EVPN peer relationships.
NOTE
Because multiple links and static routes exist between L2GW/L3GWs and VNFs, to
achieve load balancing, the Add-Path function needs to be enabled during
configuration of importing static routes to the BGP EVPN routing table.

(2020-10-09)
4. By default, the next-hop address of the IP prefix routes received by DC-GWs is

the IP address of an L2GW/L3GW and routes are recursed over SR tunnels.
This allows inbound traffic to be forwarded at Layer 3. To achieve Layer 2
forwarding of inbound traffic, a route-policy needs to be deployed on L2GW/
L3GWs to add the Gateway IP attribute to the static routes destined for DC-
GWs. The gateway IP attribute indicates the IP address of an IPU. Upon
receipt of the IP prefix routes carrying the gateway IP attribute, DC-GWs
recurse routes to next-hop IP addresses, instead of tunnels. In this manner, the
destination IP address of the forwarding entries on DC-GWs is a VNF's IP
address, the next-hop address is an IPU's IP address, and the outbound
interface is the VBDIF interface corresponding to the network segment where
the IPU resides. The VBDIF interface looks for a forwarding entry mapped to
each VNF IP address and locates the outbound VBDIF interface. ARP entries
and MAC entries can be located based on the VBDIF interface to implement
Layer 2 forwarding.
Figure 3-89 Forwarding entries on DC-GWs and L2GW/L3GWs
5. To establish BGP VPN peer relationships between DC-GWs and VNFs, DC-GWs
need to advertise the routes destined for loopback addresses to L2GW/L3GWs.
After BGP VPN peer relationships are established between DC-GWs and VNFs,
VNFs can send DC-GWs the mobile phone routes whose next-hop address is a
VNF's IP address.

(2020-10-09)
6. Devices on the DCN do not need to get aware of external routes. Therefore, a
route-policy needs to be configured on DC-GWs to allow DC-GWs to send
only default routes except for the loopback routes to L2GW/L3GWs.

(2020-10-09)
7. DC-GWs function as the border gateways of the DCN and can exchange
Internet route information, such as the Internet server address, with PEs.

(2020-10-09)
8. PEs can obtain mobile phone routes and the routes carrying VNFs' IP
addresses from DC-GWs based on BGP VPNv4/v6 peer relationships. The next-
hop addresses of these routes are DC-GWs' IP addresses, and the outbound
interface is an SR tunnel connecting to a DC-GW.

(2020-10-09)
Figure 3-93 Forwarding entries on PEs, DC-GWs and L2GW/L3GWs
9. To achieve load balancing of east-west traffic and north-south traffic, the load
balancing function and Add-Path function need to be deployed on DC-GWs
and L2GW/L3GWs.
– Load balancing of north-south traffic: Taking DC-GW1 in Figure 3-86 as
an example, DC-GW1 can receive the EVPN routes destined for VNF2
from L2GW/L3GW1 and L2GW/L3GW2. By default, after the load
balancing function is configured, DC-GW1 sends half of the traffic
destined for VNF2 through L2GW/L3GW1 and the other half of the traffic
through L2GW/L3GW2. However, L2GW/L3GW1 connects to VNF2 over
one link and L2GW/L3GW2 connects to VNF2 over two links, causing the
load balancing function failed to achieve the desired effect. Therefore, the
Add-Path function needs to be deployed on L2GW/L3GWs. After the Add-
Path function is deployed on L2GW/L3GWs, L2GW/L3GW2 sends two
routes with the same destination address to DC-GW1, achieving load
balancing.
– East-west traffic load balancing: Taking L2GW/L3GW1 in Figure 3-86 as
an example, because the Add-Path function is deployed on L2GW/

(2020-10-09)
L3GW2, L2GW/L3GW1 receives two EVPN routes from L2GW/L3GW2 and

L2GW/L3GW1 has a static route with the next-hop address as IPU3's IP
address. The destination addresses of all these routes are VNF2's IP
address. Therefore, the load balancing function needs to be configured to
balance traffic over static routes and EVPN routes.
Traffic Forwarding Process

As shown in Figure 3-94, the procedure for forwarding north-south traffic from
mobile phones to the Internet is as follows:
1. Mobile phone traffic is sent to base stations (Nodes) and encapsulated with a
GPRS tunneling protocol (GTP) header. The destination IP address of the GTP
tunnel is a VNF's IP address. PEs send the encapsulated packets to DC-GWs
over SR tunnels based on the VPN routing table.
2. Upon receipt of the encapsulated packets, DC-GWs look for the VPN routing
table and find that the next-hop addresses of the forwarding entries
corresponding to VNFs' IP addresses are IPUs' IP addresses and the outbound
interface is the VBDIF interface. Therefore, routes destined for the network
segment corresponding to the VBDIF interface are hit. DC-GWs search the
MAC address that belongs to the network segment in an ARP table, look for
the MAC forwarding table based on the ARP information, and forward traffic
to L2GW/L3GWs over SR tunnels based on the MAC forwarding table.
3. Upon receipt of packets, L2GW/L3GWs find the corresponding BDs based on
EVPN labels, look for MAC forwarding entries in the BDs, and forward traffic
to VNFs based on the MAC information.
4. Upon receipt of packets, VNFs decapsulate the GTP tunnel header, search the
routing table based on the destination IP address in the decapsulated packets,
and forward the packets to L2GW/L3GWs based on the default gateways of
VNFs.
5. L2GW/L3GWs search for the VPN routing table on L2GW/L3GWs. The default
routes advertised by DC-GWs to L2GW/L3GWs are recursed over SR tunnels
and forwarded to DC-GWs after being encapsulated with a VPN label.
6. DC-GWs forward the packets to PEs using the VPN forwarding table found
based on VPN labels. Specifically, the packets are re-encapsulated with a VPN
label and an SR label before they are forwarded to PEs.

(2020-10-09)
Figure 3-94 North-south traffic forwarding from mobile phones to the Internet
As shown in Figure 3-95, the procedure for forwarding east-west traffic from the
Internet to mobile phones over VNFs is as follows:
1. Devices on the Internet send mobile phones the reply packets whose
destination IP addresses are the IP addresses of mobile phones. This is
because mobile phone routes are advertised by VNFs to DC-GWs based on
BGP VPN peer relationships and then advertised to the Internet by DC-GWs
through PEs. Therefore, reply packets must be first transmitted to VNFs.
2. Upon receipt of reply packets, PEs search the VPN routing table for the
forwarding entries corresponding to mobile phone routes whose next-hop
addresses are DC-GWs' IP addresses and the outbound interface is the one for

(2020-10-09)
SR tunnels. The reply packets are sent to DC-GWs after being encapsulated
with a VPN label and an SR label.
3. Upon receipt of the reply packets, DC-GWs search the VPN routing table for
the forwarding entries corresponding to the mobile phone routes based on
the BGP VPN peer relationships between DC-GWs and VNFs. These routes are
recursed to one or more VBDIF interfaces, and traffic is load balanced to these
VBDIF interfaces. The VBDIF interfaces look for ARP information and MAC
forwarding entries. Based on the MAC entries, the reply packets are forwarded
to L2GW/L3GWs over SR tunnels after being encapsulated with an EVPN
label.
4. Upon receipt of the reply packets, L2GW/L3GWs find the corresponding BDs
based on the EVPN label and search for the MAC forwarding entries. The
outbound interface information is then obtained based on the MAC
forwarding entries. The reply packets are then forwarded to VNFs.
5. Upon receipt of the reply packets, VNFs search for the base stations
corresponding to the destination IP addresses of mobile phones and add a tag
of tunnel information with the destination IP address as the IP address of a
base station. The reply packets are then forwarded to L2GW/L3GWs based on
default gateways.
6. Upon receipt of the reply packets, L2GW/L3GWs search the VPN routing table,
and the default routes advertised by DC-GWs to L2GW/L3GWs are hit. The
reply packets are then forwarded to DC-GWs over SR tunnels after being
encapsulated with a VPN label.
7. Upon receipt of the reply packets, DC-GWs find the corresponding VPN
forwarding table based on the VPN label, and the default routes or specific
routes are hit. The reply packets are then forwarded to PEs over SR tunnels
and then from PEs to base stations. After being encapsulated by base stations,
the reply packets are sent to the corresponding mobile phones.

(2020-10-09)
Figure 3-95 East-west traffic forwarding from the Internet to mobile phones
Upon receipt of user packets, a VNF finds that the packets need to be sent to
another VNF for value-added service processing. In this case, east-west traffic
occurs. On the network shown in Figure 3-96, the difference between forwarding
east-west traffic and forwarding north-south traffic lies in the processing of
packets after they arrive VNF1.
1. Upon receipt of user packets, VNF1 finds that the packets need to be
processed by VNF2 and then adds a tunnel label with the destination IP
address as VNF2's IP address. The user packets are sent to L2GW/L3GWs
based on default routes.
2. Upon receipt of user packets, an L2GW/L3GW searches the VPN forwarding
table and finds that multiple load-balancing forwarding entries exist. In some

(2020-10-09)
entries, the outbound interface is an IPU or the next-hop address is the IP

address of another L2GW/L3GW.
3. If the traffic hits the path of another L2GW/L3GW, an EVPN label is added to
the user packets and the routes are recursed to L2GW/L3GW2 over an SR
tunnel. L2GW/L3GW2 searches for the BD and destination MAC address based
on the EVPN label before forwarding the packets to VNF2.
4. Upon receipt of the user packets, VNF2 processes and forwards the packets to
the server. The subsequent forwarding follows the north-south traffic
forwarding procedure.
Figure 3-96 East-west traffic forwarding from VNF1 to VNF2
3.1.11.8 NFVI Distributed Gateway Function (BGP VPNv4/v6 over E2E SR

Tunnels)
The NFVI telco cloud solution uses the DCI+DCN networking. A large amount of
mobile phone traffic is sent to vUGWs and vMSEs on the DCN. After being
processed by the vUGWs and vMSEs, the IPv4 or IPv6 mobile phone traffic is
forwarded over the DCN to destination devices on the Internet. The destination
devices send traffic to mobile phones in similar ways. To achieve these functions
and ensure traffic load balancing on the DCN, you need to deploy the NFVI
distributed gateway function.

(2020-10-09)
NOTE
users.
SR or VXLAN tunnels. SR tunnels are classified as segmented SR tunnels or E2E SR
tunnels. In E2E SR tunnel scenarios, PEs use BGP VPNv4/VPNv6 or BGP EVPN to
connect to a DCN. The control-plane implementation varies according to the
protocol used. This section uses BGP VPNv4/VPNv6 as an example.
Figure 3-97 shows the networking of an NFVI distributed gateway (BGP VPNv4/
VPNv6 over E2E SR tunnels). DC-GWs, which are the border gateways of the DCN,
exchange Internet routes with external devices over PEs. L2GW/L3GW1 and
L2GW/L3GW2 are connected to VNFs. VNF1 and VNF2 that function as virtualized
NEs are deployed to implement the vUGW functions and vMSE functions,
respectively. VNF1 and VNF2 are each connected to L2GW/L3GW1 and L2GW/
L3GW2 through IPUs.

(2020-10-09)
Function Deployment
On the network shown in Figure 3-97, the number of BDs needs to be planned
based on the number of network segments corresponding to each IPU. An
example assumes that the four IP addresses planned for four IPUs belong to four
network segments. In this case, four BDs need to be planned. You need to
configure the BDs and the corresponding VBDIF interfaces on all L2GW/L3GWs
and bind all the VBDIF interfaces to the same L3VPN instance. In addition, the
following functions need to be deployed on the DCN:
The DC-GW can then advertise local loopback routes and default routes to

(2020-10-09)
the L2GW/L3GW. A route-policy needs to be configured on DC-GWs so that

the routes sent by DC-GWs to L2GW/L3GWs carry gateway addresses and the
next hops of the mobile phone routes received by L2GW/L3GWs from DC-
GWs are the VNF addresses. In addition, the BGP EVPN peer relationships
established between DC-GWs and L2GW/L3GWs can be used to advertise the
routes carrying the IP addresses used for establishing BGP VPN peer
relationships, and the BGP EVPN peer relationships established between
L2GW/L3GWs can be used to synchronize the MAC or ARP routes and the IP
prefix routes carrying gateway addresses with IPUs.
● Deploy EVPN RRs which can be either a standalone device or a DC-GW. In this
section, DC-GWs function as EVPN RRs, and L2GW/L3GWs function as RR
clients. L2GW/L3GWs can use EVPN RRs to synchronize MAC or ARP routes as
well as the IP prefix routes carrying a VNF address as the destination address
with IPUs.
● Establish BGP VPNv4/v6 peer relationships between L2GW/L3GWs and PEs.
L2GW/L3GWs advertise mobile phone routes to PEs based on BGP VPNv4/v6
peer relationships. DC-GWs send mobile phone routes to L2GW/L3GWs based
on BGP EVPN peer relationships. Therefore, mobile phone routes need to be
re-encapsulated as BGP VPNv4/v6 routes on L2GW/L3GWs before being
advertised to PEs.
● Configure static default routes on PEs and configure the PEs to send static
default routes to L2GW/L3GWs based on BGP VPNv4/v6 peer relationships.
● Deploy SR tunnels between PEs and L2GW/L3GWs and between DC-GWs and

In the networking of an NFVI distributed gateway (E2E SR tunnels), the
procedures for establishing forwarding entries on each device are as follows:

(2020-10-09)
2. After static VPN routes are configured on L2GW/L3GWs, these static VPN
routes are imported to the BGP EVPN routing table and sent to DC-GWs as IP
prefix routes based on BGP EVPN peer relationships. A route-policy needs to
be configured on L2GW/L3GWs so that L2GE/L3GWs send PEs only the routes
destined for VNFs.
Figure 3-99 Forwarding entries on PEs and L2GW/L3GWs
3. An L2GW/L3GW learns the MAC addresses and ARP information of IPUs

through the data plane. Such information is advertised to another L2GW/
L3GW through EVPN routes and can be used for establishment of ARP entries
and MAC entries for Layer 2 forwarding. Taking L2GW/L3GW1 as an example,
the destination MAC address of the MAC entries on L2GW/3GW1 is an IPU's
MAC address. For the IPU directly connected to L2GW/L3GW1, the IPU's

(2020-10-09)
interface is used as the outbound interface in MAC entries. For the IPU
connected to another L2GW/L3GW, the MAC entries contain the outbound
interface for SR tunnels and the IP address of the BGP EVPN peer of this
L2GW/L3GW as the next-hop address.
NOTE
L2GW/L3GWs exchange routes with a VNF's IP address as the destination IP address. If

two VNFs are connected to different L2GW/L3GWs, traffic is forwarded over routes.
Otherwise, route loops may occur. Therefore, a route-policy needs to be configured on
L2GW/L3GWs, so that the Gateway IP attribute is added to the routes exchanged
between L2GW/L3GWs. The Gateway IP attribute is still the next-hop address, which is
an IPU's IP address, and the outbound interface is the VBDIF interface. In this manner,
L2GW/L3GWs forward traffic based on the MAC forwarding table to prevent route
loops.
Figure 3-100 MAC entries on L2GW/L3GWs
4. DC-GWs can receive the IP prefix routes with a VNF's IP address as the
destination IP address from L2GW/L3GWs. However, DC-GWs do not have
VBDIF interfaces and therefore cannot recurse routes to the VBDIF interface
based on the Gateway IP attribute. DC-GWs need to recurse routes to SR
tunnels based on IP prefix routes. Therefore, DC-GWs must be enabled with
the function to ignore the Gateway IP attribute to send BGP packets to VNFs
over SR tunnels based on next-hop addresses.
After BGP VPN peer relationships are established between VNFs and DC-GWs,
VNFs send mobile phone routes to DC-GWs, and DC-GWs send mobile phone
routes to L2GW/L3GWs based on the BGP EVPN peer relationships. A route-
policy needs to be configured on DC-GWs to add the Gateway IP attribute to
the routes. The Gateway IP attribute is the IP address of a VNF. A route-policy
also needs to be configured on L2GW/L3GWs to allow L2GW/L3GWs to
receive only the mobile phone routes generated by the directly connected
VNFs. This prevents L2GW/L3GWs from sending a large number of repetitive
routes to PEs. Upon receipt of mobile phone routes from DC-GWs, L2GW/
L3GWs generate VPN forwarding entries and re-encapsulate EVPN routes as
BGP VPNv4/v6 routes before sending the routes to PEs. PEs then generate
VPN forwarding entries with the IP address of mobile phone routes as the
destination address, an L2GW/L3GW's IP address as the next-hop address, and
the interface for SR tunnels as the outbound interface.

(2020-10-09)
6. Devices on the DCN do not need to get aware of external routes. Therefore,
route-policies need to be configured on PEs to allow PEs to send only default
routes to L2GW/L3GWs.

(2020-10-09)
7. PEs can exchange information about Internet routes, such as the Internet
server address, with external devices.
balancing function and Add-Path function need to be deployed on PEs and
L2GW/L3GWs.
– Load balancing of north-south traffic: Taking PE1 in Figure 3-97 as an
example, PE1 can receive the VPN routes destined for VNF2 from L2GW/
L3GW1 and L2GW/L3GW2. By default, after the load balancing function
is configured, PE1 sends half of the traffic destined for VNF2 through
L2GW/L3GW1 and the other half of the traffic through L2GW/L3GW2.
However, L2GW/L3GW1 connects to VNF2 over one link and L2GW/
L3GW2 connects to VNF2 over two links, causing the load balancing
function failed to achieve the desired effect. Therefore, the Add-Path
function needs to be deployed on L2GW/L3GWs. After the Add-Path
function is deployed on L2GW/L3GWs, L2GW/L3GW2 sends two routes
with the same destination address to DC-GW1, achieving load balancing.

(2020-10-09)

tunnel is a VNF's IP address. PEs send the encapsulated packets to L2GW/
L3GWs over SR tunnels based on the VPN routing table.
2. Upon receipt of the encapsulated packets, L2GW/L3GWs look for the VPN
routing table and find that the next-hop addresses of the forwarding entries
segment corresponding to the VBDIF interface are hit. L2GW/L3GWs search
the MAC address that belongs to the network segment in an ARP table, look
for the MAC forwarding table based on the ARP information, and forward
traffic to VNFs based on the MAC forwarding table.
VNFs.
routes advertised by PEs to L2GW/L3GWs are recursed over SR tunnels and
forwarded to PEs after being encapsulated with a VPN label.
5. PEs use the VPN forwarding table to forward the packets to the Internet
based on the VPN label.

(2020-10-09)
because mobile phone routes are advertised by L2GW/L3GWs to VNFs based
on BGP VPNv4/v6 peer relationships and then advertised to the Internet by
PEs. Therefore, reply packets must be first transmitted to L2GW/L3GWs.
addresses are L2GW/L3GWs' IP addresses and the outbound interface is the
one for SR tunnels. The reply packets are sent to L2GW/L3GWs after being
encapsulated with a VPN label and an SR label.
3. Upon receipt of reply packets, L2GW/L3GWs find the VPN forwarding entries
based on the VPN label and the VBDIF interface based on the VPN forwarding
entries. The packets are then forwarded to VNFs based on the MAC entries
corresponding to the VBDIF interface.

(2020-10-09)
default gateways.
6. Upon receipt of reply packets, PEs use the VPN forwarding table to forward
the packets to base stations based on the VPN label. The base stations
decapsulate the packets before forwarding them to mobile phones.

(2020-10-09)

3.1.11.9 NFVI Distributed Gateway Function (BGP EVPN over E2E SR

Tunnels)
processed by the vUGWs and vMSEs, the IPv4 or IPv6 mobile phone traffic is
forwarded over the DCN to destination devices on the Internet. The destination
devices send traffic to mobile phones in similar ways. To achieve these functions
and ensure traffic load balancing on the DCN, you need to deploy the NFVI

(2020-10-09)
NOTE
users.
SR or VXLAN tunnels. SR tunnels are classified as segmented SR tunnels or E2E SR
tunnels. In E2E SR tunnel scenarios, PEs use BGP VPNv4/VPNv6 or BGP EVPN to
connect to a DCN. The control-plane implementation varies according to the
protocol used. This section describes the implementation principles in BGP EVPN
scenarios.
Figure 3-106 shows the networking of an NFVI distributed gateway (BGP EVPN
over E2E SR tunnels). DC-GWs, which are the border gateways of the DCN,
L3GW2 through IPUs.

(2020-10-09)
Function Deployment
On the network shown in Figure 3-106, the number of BDs needs to be planned
based on the number of network segments corresponding to each IPU. An
example assumes that the four IP addresses planned for four IPUs belong to four
network segments. In this case, four BDs need to be planned. You need to
configure the BDs and the corresponding VBDIF interfaces on all L2GW/L3GWs
and bind all the VBDIF interfaces to the same L3VPN instance. In addition, the
following functions need to be deployed on the DCN:
section, BGP EVPN peer relationships are established between all L2GWs/

(2020-10-09)
L3GWs, PEs, and DC-GWs, DC-GWs are deployed as RRs to reflect EVPN
routes, and L2GW/L3GWs function as RR clients. L2GW/L3GWs can use EVPN
RRs to synchronize MAC or ARP routes as well as the IP prefix routes carrying
a VNF address as the destination address with IPUs.
● Configure static default routes on PEs and use the EVPN RRs to reflect the
static default routes to L2GW/L3GWs.

In the networking of an NFVI distributed gateway (E2E EVPN over E2E SR
tunnels), the procedure for establishing forwarding entries on each device is as
follows:
2. After static VPN routes destined for VNFs are configured on L2GW/L3GWs,
these static VPN routes are imported to the BGP EVPN routing table and IP
prefix routes are generated. These routes are sent to DC-GWs and PEs based
on BGP EVPN peer relationships. To prevent these routes from being
transmitted to DC-GWs or PEs and recursed to VBDIF interfaces (DC-GWs and
PEs do not have VBDIF interfaces) because they carry gateway addresses,
configure an import route-policy on DC-GWs and PEs to delete gateway
addresses from the received routes.

(2020-10-09)
3. An L2GW/L3GW learns the MAC addresses and ARP information of IPUs

through the data plane. Such information is advertised to another L2GW/
L3GW through EVPN routes and can be used for establishment of ARP entries
and MAC entries for Layer 2 forwarding. Taking L2GW/L3GW1 as an example,
the destination MAC address of the MAC entries on L2GW/3GW1 is an IPU's
MAC address. For the IPU directly connected to L2GW/L3GW1, the IPU's
interface is used as the outbound interface in MAC entries. For the IPU
connected to another L2GW/L3GW, the MAC entries contain the outbound
interface for SR tunnels and the IP address of the BGP EVPN peer of this
L2GW/L3GW as the next-hop address.
NOTE
L2GW/L3GWs exchange routes with a VNF's IP address as the destination IP address. If

two VNFs are connected to different L2GW/L3GWs, traffic is forwarded over routes.
Otherwise, route loops may occur. Therefore, a route-policy needs to be configured on
L2GW/L3GWs, so that the Gateway IP attribute is added to the routes exchanged
between L2GW/L3GWs. The Gateway IP attribute is still the next-hop address, which is
an IPU's IP address, and the outbound interface is the VBDIF interface. In this manner,
L2GW/L3GWs forward traffic based on the MAC forwarding table to prevent route
loops.

(2020-10-09)
Figure 3-109 MAC entries on L2GW/L3GWs
After BGP VPN peer relationships are established between VNFs and DC-GWs,
VNFs can send mobile phone routes to DC-GWs, and DC-GWs send the
mobile phone routes as IP prefix routes to L2GW/L3GWs based on the BGP
VPN peer relationships. The Gateway IP attribute, which is the IP address of a
VNF, is added to the IP prefix routes based on a route-policy. Upon receipt of
IP prefix routes, L2GW/L3GWs generate VPN forwarding entries. L2GW/
L3GWs then send EVPN routes to PEs based on EBGP EVPN peer relationships
so that PEs can generate VPN forwarding entries with the destination address
as the IP address of mobile phone routes and the next-hop address as a VNF's
IP address. The routes are then recursed to VNFs, and the outbound interface
is an SR tunnel.

(2020-10-09)
5. Devices on the DCN do not need to get aware of external routes. Therefore,
route-policies need to be configured on PEs to allow PEs to send only default
routes to L2GW/L3GWs.

(2020-10-09)
6. PEs can exchange information about Internet routes, such as the Internet
server address, with external devices.
balancing function and Add-Path function need to be deployed on PEs and
L2GW/L3GWs.
– Load balancing of north-south traffic: Taking PE1 in Figure 3-106 as an
example, PE1 can receive the VPN routes destined for VNF2 from L2GW/
L3GW1 and L2GW/L3GW2. By default, after the load balancing function
is configured, PE1 sends half of the traffic destined for VNF2 through
L2GW/L3GW1 and the other half of the traffic through L2GW/L3GW2.
However, L2GW/L3GW1 connects to VNF2 over one link and L2GW/
L3GW2 connects to VNF2 over two links, causing the load balancing
function failed to achieve the desired effect. Therefore, the Add-Path
function needs to be deployed on L2GW/L3GWs. After the Add-Path
function is deployed on L2GW/L3GWs, L2GW/L3GW2 sends two routes
with the same destination address to DC-GW1, achieving load balancing.

(2020-10-09)


tunnel is a VNF's IP address. PEs send the encapsulated packets to L2GW/
L3GWs over SR tunnels based on the VPN routing table.
2. Upon receipt of the encapsulated packets, L2GW/L3GWs look for the VPN
routing table and find that the next-hop addresses of the forwarding entries
segment corresponding to the VBDIF interface are hit. L2GW/L3GWs search
the MAC address that belongs to the network segment in an ARP table, look
for the MAC forwarding table based on the ARP information, and forward
traffic to VNFs based on the MAC forwarding table.
VNFs.
routes advertised by PEs to L2GW/L3GWs are recursed over SR tunnels and
forwarded to PEs after being encapsulated with a VPN label.
5. PEs use the VPN forwarding table to forward the packets to the Internet
based on the VPN label.

(2020-10-09)
because mobile phone routes are advertised by L2GW/L3GWs to VNFs based
on BGP VPNv4/v6 peer relationships and then advertised to the Internet by
PEs. Therefore, reply packets must be first transmitted to L2GW/L3GWs.
addresses are L2GW/L3GWs' IP addresses and the outbound interface is the
one for SR tunnels. The reply packets are sent to L2GW/L3GWs after being
encapsulated with a VPN label and an SR label.
3. Upon receipt of reply packets, L2GW/L3GWs find the VPN forwarding entries
based on the VPN label and the VBDIF interface based on the VPN forwarding
entries. The packets are then forwarded to VNFs based on the MAC entries
corresponding to the VBDIF interface.

(2020-10-09)
default gateways.
6. Upon receipt of reply packets, PEs use the VPN forwarding table to forward
the packets to base stations based on the VPN label. The base stations
decapsulate the packets before forwarding them to mobile phones.

(2020-10-09)

3.1.11.10 Application Scenarios for EVPN E-LAN Accessing L3VPN
Service Overview
If point-to-multipoint Layer 2 services are carried using EVPN E-LAN and Layer 3
services are carried using MPLS L3VPN, EVPN E-LAN accessing L3VPN must be
configured on the devices where Layer 2 and Layer 3 services overlap.

(2020-10-09)
Networking Description
On the network shown in Figure 3-115, the first layer is the user-side access
network where Layer 2 services are carried between CPEs and UPEs to implement
VLAN forwarding. The second layer is the aggregation network where services are
carried using EVPN E-LAN and BD-based EVPN MPLS is deployed between UPEs
and NPEs. The third layer is the core network where services are carried using
MPLS L3VPN. In this case. NPEs must be deployed with EVPN E-LAN accessing
L3VPN. Specifically, configure an L2VE sub-interface to access BD EVPN on an NPE
and then configure an L3VE sub-interface to access L3VPN. In this manner, when
the public network packets of EVPN E-LAN reach the L2VE sub-interface on the
NPE, the corresponding tag is encapsulated into the packets based on the tag
processing behavior configured on the L2VE sub-interface. After the packets are
loopbacked to the L3VE interface, the corresponding L3VE sub-interface is
matched based on the tag carried in the packets, and the packets are forwarded
using the corresponding L3VPN instance.
Figure 3-115 Networking of EVPN E-LAN accessing L3VPN
Feature Deployment
Before deploying EVPN E-LAN accessing L3VPN, complete the following tasks on
an NPE:
● Create an L2VE interface and an L3VE interface and bind them to the same
VE-Group.
● Create an L2VE sub-interface and add it to the BD to which the EVPN
instance bound.
● Create an L3VE sub-interface, specify the associated VLAN, set the VLAN
encapsulation mode (configure the Tag), and bind it to the corresponding
L3VPN instance.
3.2 EVPN Configuration

This chapter provides an overview of Ethernet virtual private network (EVPN) and
describes its basic configurations.

(2020-10-09)
3.2.1 Overview of EVPN

Definition
Ethernet virtual private network (EVPN) is used for Layer 2 internetworking. EVPN
is similar to BGP/MPLS IP VPN. Using extended BGP reachability information,
EVPN implements MAC address learning and advertisement between Layer 2
networks at different sites on the control plane instead of on the data plane.
Purpose
As services grow rapidly, different sites have an increasingly strong need for Layer
2 interworking. VPLS, which is generally used for such a purpose, has the following
shortcomings:
● Lack of support for load balancing: VPLS does not support traffic load
balancing in multi-homing networking scenarios.
● High network resource usage: Interworking between sites requires all PEs
serving these sites on the ISP backbone network to be fully meshed, with PWs
established between any two PEs. If a large number of PEs exist, PW
establishment will consume a significant amount of network resources. In
addition, a large number of ARP messages must be transmitted for MAC
address learning. These ARP messages not only consume network bandwidth
but may also consume CPU resources on remote sites that do not need to
learn the MAC addresses carried in them.
EVPN solves the preceding problems with the following characteristics:
● EVPN uses extended BGP to implement MAC address learning and
advertisement on the control plane instead of on the data plane. This function
allows a device to manage MAC addresses in the same way as it manages
routes, implementing load balancing between EVPN routes with the same
destination MAC address but different next hops.
● EVPN does not require PEs on the ISP backbone network to be fully meshed.
PEs on an EVPN use BGP to communicate, and BGP provides the route
reflection function. PEs can establish BGP peer relationships only with RRs
deployed on the ISP backbone network, with RRs reflecting EVPN routes. This
implementation significantly reduces network complexity and minimizes the
number of network signaling messages.
● EVPN enables PEs to use ARP to learn the local MAC addresses and use
MAC/IP address advertisement routes to learn remote MAC addresses and IP
addresses corresponding to these MAC addresses, and store them locally.
After receiving another ARP request, a PE searches the locally cached MAC
address and IP address based on the destination IP address in the ARP
request. If the corresponding information is found, the PE returns an ARP
reply packet. This prevents ARP request packets from being broadcast to other
PEs, therefore reducing network resource consumption.
Benefits
EVPN offers the following benefits:
● Improved link usage and transmission efficiency: EVPN supports load
balancing, fully utilizing network resources and reducing network congestion.

(2020-10-09)
● Reduced network resource consumption: By deploying RRs on the public

network, EVPN decreases the number of logical connections required between
PEs on the public network.
● Reduces network resource consumption caused by ARP broadcast traffic: PEs
can respond to ARP requests from local sites based on locally cached MAC
addresses, preventing large-scale ARP request broadcast.
3.2.2 EVPN Licensing Requirements and Configuration

Precautions
LPUF-50/LPUF-50-L/ Plan services properly. ● When the LPUF-50/

LPUI-21-L/LPUI-51-L/ LPUF-50-L/LPUI-21-L/
LPUF-51/LPUF-51-B/ LPUI-51-L/LPUF-51/
LPUI-51/LPUI-51-B/ LPUF-51-B/LPUI-51/
LPUS-51/LPUF-101/ LPUI-51-B/LPUS-51/
LPUF-101-B/LPUI-101/ LPUF-101/LPUF-101-
LPUI-101-B/LPUS-101 B/LPUI-101/LPUI-101-
boards do not support B/LPUS-101 board is
SRv6 EVPN VPWS, EVPN installed after services
P2MP, or E-Tree per AC. are configured, the
board cannot be
registered.
● When the LPUF-50/
LPUF-50-L/LPUI-21-L/
LPUI-51-L/LPUF-51/
LPUF-51-B/LPUI-51/
LPUI-51-B/LPUS-51/
LPUF-101/LPUF-101-
B/LPUI-101/LPUI-101-
B/LPUS-101 board is
installed before
services are
configured, the
service configuration
fails.
EVPN instances in BD None EVPN instances in BD

VLAN-aware mode do VLAN-aware mode do
not support SRv6. not support SRv6.

(2020-10-09)
In a BGP EVPN L3VPN You need to switch to In an EVPN L3VPN over

over SR-MPLS BE the VPN view to SR-MPLS BE scenario
scenario, both the configure the following where fast tunnel fault
primary and secondary tunnel policy. When the detection (such as BFD
SR-MPLS BE tunnels exist SR-MPLS BE primary detection) is not
on the EVPN L3VPN tunnel fails, you can enabled, the restart of
edge PE and peer edge quickly switch to the edge PEs relies on hard
PE. If fast tunnel fault standby SR-MPLS BE convergence and the
detection is not enabled tunnel. Other types of secondary SR-MPLS BE
and the peer edge PE tunnels (such as LDP) tunnel is used. The
becomes faulty, a are no longer selected. tunnel switching speed is
primary/secondary The recommended low.
switchover is triggered configuration is as
by hard convergence. follows:
When multiple types of tunnel-policy AAA
tunnels exist, such as
LDP LSPs, to quicken tunnel select-seq sr-lsp
convergence, a tunnel ldp load-balance-number
policy must be 1 //Configure the tunnel
configured. In this case, policy and select only the
focus on only the status SR-MPLS BE tunnel.
of the primary and #
secondary SR-MPLS BE ip vpn-instance vpn-801
tunnels.
ipv4-family
route-distinguisher
100:801
tnl-policy AAA
ip frr
vpn-target 801:801
export-extcommunity
evpn
vpn-target 801:801
export-extcommunity
vpn-target 801:801
import-extcommunity
evpn
vpn-target 801:801
import-extcommunity
tnl-policy AAA evpn
evpn mpls routing-
enable

(2020-10-09)
The cloud VPN and DCI The cloud VPN and DCI The re-originated routes
scenarios support co- scenarios support co- on the DCI network are
existence of different existence of different advertised to the cloud
scenarios. scenarios. VPN, which affects
ARP/IRB routes: ARP/IRB routes: service traffic planning.
When vBDIF interfaces When vBDIF interfaces
are configured on a are configured on a
cloud VPN in an L2+L3 cloud VPN in an L2+L3
scenario, the following scenario, the following
situations may occur. A situations may occur. A
route-policy needs to be route-policy needs to be
configured to prevent configured to prevent
routes from being re- routes from being re-
originated. originated.
1. Layer 2 services 1. Layer 2 services
belong to different EVPN belong to different EVPN
instances. Layer 3 instances. Layer 3
services belong to the services belong to the
same EVPN instance but same EVPN instance but
are on different network are on different network
segments. In this case, a segments. In this case, a
route filter policy can be route filter policy can be
configured for the configured for the
network segments. network segments.
2. Layer 2 services 2. Layer 2 services
belong to different EVPN belong to different EVPN
instances, and Layer 3 instances, and Layer 3
services belong to services belong to
different VPN instances. different VPN instances.
In this case, a route filter In this case, a route filter
policy must be policy must be
configured for the routes configured for the routes
originated from the DC originated from the DC
side. side.
IP prefix routes: IP prefix routes:
Configure a route-policy Configure a route-policy
to prevent routes from to prevent routes from
being re-originated. For being re-originated. For
details, see the details, see the
description of situations description of situations
1 and 2 for ARP/IRB 1 and 2 for ARP/IRB
routes. routes.

(2020-10-09)
An ESI is applied to None An ESI is applied to

multiple sub-interfaces multiple sub-interfaces
on multi-homing PEs on multi-homing PEs
connected to a CE, and connected to a CE, and
the AC status is the AC status is
configured to influence configured to influence
DF election. In this DF election. In this
situation, the non- situation, the non-
revertive mode for ESI revertive mode for ESI
preference-based DF preference-based DF
election may fail on election may fail on
some sub-interfaces, and some sub-interfaces, and
BUM traffic on these BUM traffic on these
sub-interfaces is sub-interfaces is
switched back after the switched back after the
primary DF recovers. primary DF recovers.
Instance-based outbound Configure coloring by The correctness of ES

policy-based routing specifying the route type and ES-AD route
does not apply to ES and (ES or ES-AD routes) recursion to SR-policy
ES-AD routes. based on peer+. tunnels is affected.
In EVPN E-LAN Properly deploy EVPN E- Service deployment is

scenarios, MPLS EVPN LAN. affected.
VPLS and SRv6 cannot
co-exist on an instance.
Option B is not Properly deploy EVPN E- Service deployment is

supported in the EVPN LAN. affected.
E-LAN over SRv6 PE
scenario.
LPUF-50/LPUF-50-L/ None EVPN E-LAN over SRv6

LPUI-21-L/LPUI-51-L/ BE cannot be deployed
LPUF-51/LPUF-51-B/ on LPUF-50/LPUF-50-L/
LPUI-51/LPUI-51-B/ LPUI-21-L/LPUI-51-L/
LPUS-51/LPUF-101/ LPUF-51/LPUF-51-B/
LPUF-101-B/LPUI-101/ LPUI-51/LPUI-51-B/
LPUI-101-B/ LPUS-51/LPUF-101/
LPUS-101boards do not LPUF-101-B/LPUI-101/
apply to the EVPN E-LAN LPUI-101-B/
over SRv6 BE scenario. LPUS-101boards.
In EVPN E-LAN over None The switching

SRv6 BE scenarios, performance in single-
remote FRR in single- active scenarios is
active dual-homing affected.
mode is not supported.

(2020-10-09)
In EVPN E-LAN over None ACL filtering based on

SRv6 BE scenarios, only private network
the ACL filtering based addresses is affected.
on the IPv6 and public
network addresses is
supported on the
network side. ACL
filtering based on private
network addresses is not
supported.
EVPN L3VPNv4 routes None EVPN L3VPNv4 routes

can recurse to either cannot recurse to both
SRv6 BE or MPLS SRv6 BE and MPLS
tunnels, instead of both tunnels.
SRv6 BE and MPLS
tunnels.
EVPN L3VPNv6 does not None Hierarchical access to

support the import of EVPN L3VPNv6 is not
VPNv6 labeled routes. supported for level-2
carriers.
EVPN L3VPNv6 routes None EVPN L3VPNv6 routes

can recurse to either cannot recurse to both
SRv6 BE or MPLS SRv6 BE and MPLS
tunnels, instead of both tunnels.
SRv6 BE and MPLS
tunnels.
In an L3 EVPN scenario, In an L3 EVPN scenario, In an L3 EVPN scenario,

if an IP route with a it is not recommended if an IP route with a
prefix specified using the that an IP route with a prefix specified using the
gateway-ip field recurses prefix specified using the gateway-ip field recurses
to multiple tunnels, only gateway-ip field recurse to multiple tunnels, only
one recursive tunnel is to multiple tunnels one recursive tunnel is
used to forward traffic. working in load used to forward traffic.
balancing mode.
EVPN SRv6 instances do None EVPN instances enabled

not support the E-Tree with SRv6 do not
function, that is, the support E-Tree.
etree enable command
cannot be run for such
instances.

not support EVPN IGMP, with SRv6 do not
which is mutually support EVPN IGMP.
exclusive with the igmp-
snooping proxy
configuration.

(2020-10-09)

not support the mLDP with SRv6 do not
PMSI, which is mutually support mLDP.
exclusive with the
inclusive-provider-tunnel
configuration.

not support the tunnel with SRv6 do not
policy function, which is support tunnel policies.
mutually exclusive with
the tnl-policy policy-
name configuration.
LPUF-50/LPUF-50-L/ None If the LPUF-50/LPUF-50-

LPUI-21-L/LPUI-51-L/ L/LPUI-21-L/LPUI-51-L/
LPUS-51/LPUF-101/ LPUS-51/LPUF-101/
LPUI-101-B/ LPUI-101-B/
LPUS-101boards do not LPUS-101board exists on
apply to the EVPN VPWS a device, the EVPN VPWS
over SRv6 scenario. over SRv6 service cannot
be deployed on the
device. If such a board is
inserted into the device
after the EVPN VPWS
over SRv6 service is
deployed, the board
cannot be registered.
The evpn-vpws ignore- Properly plan network In case of dual-homing

ac-state command used deployment. access on one side and
to ignore the AC single-homing access on
interface status is in a the other side, if an AC-
dual-homing network interface goes down on
deployed with 1:1 the dual-homing side,
protection. This routes are not
command does not withdrawn. If bypass
apply to dual-homing attributes are not
access on one side and configured, packet loss
single-homing access on occurs.
the other side.

(2020-10-09)
EVPN does not support Properly plan route re- EVPN does not support
the following route re- origination scenarios. the following route re-
origination scenarios: origination scenarios:
Common L3VPN over Common L3VPN over
SRv6 and EVPN L3VPN SRv6 and EVPN L3VPN
over MPLS over MPLS
Common L3VPN over Common L3VPN over
SRv6 and EVPN L3VPN SRv6 and EVPN L3VPN
over SRv6 over SRv6
EVPN L3VPN over MPLS EVPN L3VPN over MPLS
and EVPN L3VPN over and EVPN L3VPN over
SRv6 SRv6
EVPN L3VPN over MPLS EVPN L3VPN over MPLS
MPLS MPLS
EVPN L3VPN over SRv6 EVPN L3VPN over SRv6
SRv6 SRv6
EVPN VPLS over MPLS EVPN VPLS over MPLS
and EVPN VPLS over and EVPN VPLS over
SRv6 SRv6
EVPN over VXLAN and EVPN over VXLAN and
EVPN over SRv6 EVPN over SRv6
In the scenario of N/A EVPN traffic fails to be

splicing between VLL forwarded or is
and EVPN, when a VE interrupted.
interface is configured
on an SPE, the VLL must
be bound to the VE
interface, and an EVPN
instance must be bound
to a VE sub-interface.
If the type of the VLL AC
interface on a UPE and
that of the EVPN
instance-bound AC
interface on the SPE are
both QinQ in
asymmetrical mode,
EVPN traffic between the
UPE and SPE fails to be
forwarded.

(2020-10-09)
In the scenario of None None

splicing between VLL
and EVPN, a VLL
supports only the
following tunnel types:
LDP, TE, and LDP over
TE.
The EVPN public Configure MF MF classification

network interface does classification for the configured for the EVPN
not support MF traffic inbound interface public network interface
classification. before the EVPN public does not take effect.
network interface.
EVPN loop protection Do not disable MAC EVPN loop protection

depends on MAC address address learning. fails.
learning. If MAC address
learning is disabled, the
function becomes
invalid.
EVPN peers and Configure the inbound The EVPN route-policy

instances do not support route-policy in mpls- fails to uniformly
outbound policy-based label mode for the EVPN configure the outbound
routing in mpls-label instance and EVPN route-policy in mpls-
mode. neighbor that receives label mode for all the
EVPN routes. remote devices.
In EVPN splicing with None MAC FRR can be enabled

VPLS scenarios, MAC FRR globally or based on a
is not supported on the BD. After MAC FRR is
PW side. If MAC FRR is enabled, PW-side MAC
enabled based on EVPN, FRR does not take effect.
PW-side MAC addresses
point to the PW
interface, instead of the
protection link.
IGMP snooping is not None The multicast service

supported in the EVPN deployment is affected.
splicing with VPLS
scenario.

(2020-10-09)
In EVPN splicing with None The EVPN master/slave

VPLS scenarios, only the switching performance is
primary/secondary PW affected.
+EVPN single-active
mode is supported. EVPN
active-active is not
supported. The PW
standalone mode is also
not supported. The
secondary PW cannot be
configured with the
ignore-standby
command.
LPUF-50/LPUF-50-L/ None LPUF-50/LPUF-50-L/

LPUI-21-L/LPUI-51-L/ LPUI-21-L/LPUI-51-L/
LPUS-51/LPUF-101/ LPUS-51/LPUF-101/
LPUI-101-B/ LPUI-101-B/
LPUS-101boards do not LPUS-101boards do not
apply to the EVPN apply to the EVPN
splicing with VPLS splicing with VPLS
scenario. service. If the service is
deployed on such boards,
the service will be
affected.
In an EVPN active-active On the access side, if one In the EVPN active-active

scenario, an access-side member interface or scenario, if a board fails,
Eth-Trunk interface has multiple member duplicate traffic may
multiple member interfaces are configured exist for a short time.
interfaces, and the on an Eth-Trunk, ensure
member interfaces are that the member
deployed on different interfaces resided on the
interface boards. if an same interface board.
ESI is associated with
BFD, the board where
the BFD state machine
resides may go Down,
causing BFD to go Down
unexpectedly. As a result,
a false EVPN active-
active switchover is
performed, causing
generation of extra
packets.

(2020-10-09)
In full-mesh networking, Configure a VPLS PW to An incorrect

a loop occurs in either of be in Hub or Spoken configuration results in a
the following scenarios: mode as required. loop.
● An EVPN is connected
to a VPLS whose PWs
are configured to be
in Spoken mode. (A
VPLS PW should be
configured to be in
Hub mode.)
● The E-Trunks through
which a CE is dual-
homed to PEs work in
active-active mode.
In IBGP scenarios, if Configure a route-policy. None

segment VXLAN is
configured on PE,
inclusive routes learned
by the local CE are
reflected to the remote
PE by an RR. As a result,
remote PE has an
excessive VXLAN tunnel
destined for the CE. To
resolve this issue,
configure a route-policy
on remote PE to deny
inclusive routes on the
CE side.
PW-VE interfaces cannot Properly plan VPN EVPN VPWS over SRv6
be bound to EVPL instance types. splicing with VPWS is not
instances in SRv6 mode. supported.
When a VLL accesses an None None

EVPN, only non-BD
EVPN (MPLS EVPN) is
supported.
When a VLL is connected Run the evpn access vll When a VLL is connected
to an EVPN, the convergence separate to an EVPN, the
loopback scheme is used disable command. loopback scheme is used
in the downstream in the downstream
direction. In this case, direction. In this case,
CAR rate limit is CAR rate limit is
inaccurate on a PWVE inaccurate on a PWVE
sub-interface in the sub-interface in the
downstream direction. downstream direction.

(2020-10-09)
Different devices cannot 1. Get aware of IP The configuration

be configured with the conflicts based on the conflict continues.
same static route or alarm information. During this period, loops
static ARP. 2. Determine whether may occur. In case of
the local device heavy traffic, the traffic
deployment is incorrect forwarding of other
based on network services is affected.
planning. Modify the
static route or static ARP
configuration on the
local device.
3.If the peer device is
incorrectly configured,
view the peer
information and re-
deploy the service on the
peer device.
The EVPN VPLS over None The EVPN VPLS over

SRv6 TE Policy function SRv6 TE Policy function
is not supported. is not supported.
EVPN VPLS over SRv6 TE None EVPN VPLS over SRv6 TE

tunnels are not tunnels are not
supported. supported.
MPLS VPLS EVPN Option None MPLS VPLS EVPN Option

B and SRv6 are mutually B and SRv6 are mutually
exclusive. exclusive.
The Option B scenario is None The Option B scenario is

not supported. not supported.
VLL access to SRv6 BD None After the segment-

EVPN VPLS is not routing ipv6 best-effort
supported. command is run for an
EVPN instance in BD
mode and the instance is
bound to a BD, the BD
cannot be bound to any
PW VE interface or sub-
interface.
Splicing of a VXLAN/ None After the segment-

VXLAN EVPN and an routing ipv6 best-effort
SRv6 BD EVPN VPLS is command is run for an
not supported. EVPN instance in BD
VNI.

(2020-10-09)
Splicing of a traditional None After the segment-

VPLS and SRv6 BD EVPN routing ipv6 best-effort
VPLS is not supported. command is run for an
EVPN instance in BD
VSI.
Except for SPEs in None Basic protocol interaction

HEVPN scenarios, labels and traffic forwarding
are distributed by EVPN are not affected.
instance, instead of by
route or next hop.
When a VSI is bound to When a VSI is bound to If the BDs to be bound

multiple BDs, if an EVPN multiple BDs, unbind the to EVPN instances are
instance is bound to one BDs to be bound to not removed from the
of the BDs, the VSI's PW EVPN instances from the VSI, services in the other
is set to Down. As a VSI. BDs are interrupted.
result, services in the
other BDs that are not
bound to EVPN instances
are interrupted.
Regarding EVPN E-Line: If an EVPN works in Traffic for other services

The EVPN single-active single-active mode, the may not be forwarded
mode blocks traffic on EVPN single-active properly.
an AC interface. If the services and active-active
master/backup E-Trunk or Layer 3 services
status is determined, the cannot be transmitted
backup E-Trunk interface through the same link.
is set Down. Therefore,
EVPN single-active
services and active-active
or Layer 3 services
cannot be transmitted
through the same link
for dual-homing access.

(2020-10-09)
Regarding EVPN active- None Traffic switching

active: performance in case of a
1. Dual-homed devices link failure is affected.
cannot reside in different
ASs.
2. Non-anycast VXLAN
active-active is not
supported.
3. ESIs on different dual-
homed interfaces cannot
be the same.
4. In active-active
scenarios, a CE must be
directly accessed to a PE,
without any
intermediate device.
In an active-active Do not configure the After the ignore-

scenario where primary ignore-standby-state standby-state
and secondary PWs of a parameter for the PW on parameter and dual-
VPLS are connected to a the device where the receive are configured on
VXLAN, the ignore- VPLS is connected to the the device where the
standby-state VXLAN. VPLS is connected to the
parameter cannot be VXLAN, duplicate
configured for the PW on multicast traffic is
the device where the generated in the
VPLS is connected to the direction from the
VXLAN. If both the VXLAN to the VPLS.
parameter and dual-
receive are configured,
duplicate multicast
traffic is generated in the
direction from the
VXLAN to the VPLS.
In an L2+L3 over HEVPN None Basic protocol interaction

scenario where the and traffic forwarding
distributed gateway is are not affected in L2+L3
deployed, the BDIF over HEVPNv6 scenarios.
interface is bound to an Only traffic forwarding
EVPN L3VPNv6 instance, over the shortest path is
and the BD interface is affected.
bound to an L2 EVPN
instance, traffic cannot
be forwarded over the
shortest path.

(2020-10-09)
EVPN in a non-BD mode None SRv6 cannot be enabled

does not support EVPN for EVPN instances in a
VPLS over SRv6. non-BD mode, that is,
the segment-routing ipv6
best-effort command
cannot be run for the
instances.
In a scenario where Import routes based on a The coloring correctness

routes are imported specified protocol type or in a scenario where
between the VPN and network segment to routes are imported
public network instances, prevent route import between the VPN and
the color attribute between the VPN and public network instances
cannot be changed public network instances. is affected.
based on the route-
policy. The imported
routes inherit the route
recursion result of the
source VPN instance.
Specifically, the source
route is iterated based
on the SR-MPLS TE
Policy even after import-
rib is configured. If a
configuration is not
supported by the source
route, it is also not
supported by the
imported routes.
ESI preference-based DF None The VPWS EVPN

election is not supported scenario is not
in the VPWS EVPN supported.
scenario.
If the PE at one end of a Re-plan the network Some services are

VPLS has only one VSI deployment. interrupted during the
and the PE at the other network reconstruction.
end has multiple VSIs,
the VPLS network cannot
be reconstructed into an
EVPN.

(2020-10-09)
If an instance receives Properly plan the tunnel The same VPN instance
multiple IP prefix routes type and RT import cannot be configured
with the same prefix but planning for VPN with different types
different label attributes, instances. (SRv6 and other types
determine the routes to such as MPLS and
be preferentially selected VXLAN) of tunnel
based on the tunnel type recursion and tunnel
in the instance. backup. When multiple
If the instance is enabled tunnels co-exist, traffic is
with SRv6 but routes do recursed only to
not carry the Prefix-SID instance-enabled
attribute, route import tunnels.
fails. If the instance is
not enabled with SRv6
but routes carry the
Prefix-SID attribute,
route import fails.
An SRv6-enabled VPN Configure the device to In an L2+L3 over

instance does not generate Vlink routes HEVPNv6 scenario, basic
support sending of IRB through ARP and send protocol interaction and
routes in SRv6 mode. the Vlink routes to the traffic forwarding are not
peer device based on L3 affected. Only traffic
EVPN IP prefix routes. forwarding over the
shortest path is affected.
An SRv6-enabled VPN Establish E2E SRv6 L3 The splicing between L3

instance does not EVPN during deployment EVPN over SRv6 and
support re-origination of planning. traditional L3VPN is not
VPNv4 routes and L3 supported, including SPE
EVPN routes. and HEP.
An SRv6-enabled VPN In DC scenarios, E2E L3 The splicing between the

instance and a VXLAN L3 EVPN over SRv6 is VXLAN DC (VXLAN L3
EVPN cannot co-exist. established over SRv6 EVPN) and DCI backbone
tunnels. network (SRv6 L3 EVPN)
is not supported in DCI
scenarios.
The same E-Tree None No impact.

attribute must be set on
the two dual-homing AC
interfaces. If different E-
Tree attributes are set,
traffic may flow back
from the dual-homing
PEs to the CE.

(2020-10-09)
For a BD bound to both None If a VPLS PW is set to be

an EVPN instance and a in Spoken mode, loops
VPLS VSI, the VPLS PWs may occur.
cannot be set to be in
Spoken mode.
SRv6 SID and MPLS Properly plan the tunnel The same service
cannot co-exist on a VPN type for VPN instances. instance cannot be
instance. configured with different
types (SRv6 and other
types such as MPLS and
VXLAN) of tunnel
recursion and tunnel
backup.
If a PE is configured with Configure different ERTs BUM traffic forwarding

two EVPN instances for different EVPN fails.
whose ERTs are the same instances on the same
and EVPN routes are PE.
flooded to peer devices
based on EVPN peer
relationships, a traffic
forwarding failure may
occur when the peer
device implements route
selection and sends BUM
traffic to the local PE.
The EVPN switch to When the VPLS network If the VPLS network is
which a user device is is reconstructed into the reconstructed into the
connected is replaced EVPN, manually shut EVPN before the MAC
with a VPLS network down the network device entry for the user device
switch. Before the MAC interface connecting to is aged, user services are
entry aging time expires, the switch and then re- interrupted until the
the user device is enable the interface VPLS network ages the
reconnected to the EVPN after the network MAC entry for the user
switch. As a result, reconstruction. device.
services are interrupted
until the VPLS network
ages the MAC entry for
the user device.

(2020-10-09)
An EVPN instance and a None Deleting the MAC

VSI are bound to the address learned from the
same BD. If the BD AC interface triggers
receives a MAC MAC address deletion on
Withdraw packet for a the EVPN. After the BD
PW from the remote VSI, relearns a MAC address
the BD deletes the MAC from the AC interface,
address learned from the the BD broadcasts the
AC interface but does MAC address on the
not clear the MAC EVPN.
address learned from the
EVPN instance.
In an EVPN dual-homing Configure static ESIs. Configuring dynamic ESIs

scenario, using dynamic cannot ensure high
ESIs cannot ensure fast switching performance in
fault-triggered switching, an EVPN dual-homing
and switching depends scenario.
only on protocol
convergence. Therefore,
using static ESIs is
recommended.
In an EVPN active-active Do not reset the BGP The BUM traffic doubles
scenario where a CE is connection between the
dual-homed to PEs, if a dual-homing Pes.
BGP connection between
the dual-homing PEs
goes down, the dual-
homing PEs both enter
the DF state. As a result,
the BUM traffic doubles,
and the dual-homing
and active-active
mechanism fails.
If an EVPN instance is Manually set the VPLS If an EVPN instance is

bound to a BD that has PW to Down. In master/ bound to a BD that has
been bound to a VSI for backup E-Trunk been bound to a VSI for
an existing VPLS service, scenarios, bind an EVPN an existing VPLS service,
services may be instance to a BD on the services may be
interrupted. After the backup E-Trunk first and interrupted.
EVPN instance is bound then perform the binding The MAC addresses
to the BD, services are on the master E-Trunk. learned by a BD are
restored. cleared, and then the BD
relearns the MAC
addresses. The unicast
mode is changed to
broadcast mode.

(2020-10-09)
The non-revertive mode None The non-revertive mode

for ESI preference-based for ESI preference-based
DF election must be DF election must be
enabled in the same ESI enabled in the same ESI
view on multi-homing view on multi-homing
PEs. PEs.
VPLS supports LDPs. 1. Use commands to VXLAN EVPN and VPLS

EVPN supports only allow BDs to be bound cannot be bound to the
MPLS EVPN. VPLS and to the VPLS only with same BD.
EVPN can be integrated the type of MPLS EVPN IRB routes cannot be
using the same BD. After or LDP. learned.
PWs access EVPN, the 2. Use commands to
learned MAC addresses Redirection based on the
disable the system from MAC addresses learned
can be sent to the supporting IRBs.
control plane. MAC FRR by PWs is not supported.
and IRB routes are not
supported. Redirection
based on the MAC
addresses learned
through PWs is not
supported.

(2020-10-09)
For the EVPN E-LAN Configure the same For the EVPN E-LAN
service, the control word control word function on service, the control word
can only be statically PEs of both ends of a can only be statically
configured. The same path. In dual-homing configured. The same
control word must be scenarios, configure the control word must be
configured on devices. same control word configured on devices.
For the EVPN VPWS function on the involved For the EVPN VPWS
service, a device checks PEs, including the single- service, a device checks
whether the control and dual-homing PEs. whether the control
word carried in a word carried in a
received route matches received route matches
the local control word. A the local control word. A
control word control word
inconsistency causes a inconsistency causes a
failure to create an EVPN failure to create an EVPN
VPWS service. Control VPWS service. Control
word self-negotiation word self-negotiation
(configured using the (configured using the
preferred control-word preferred control-word
command) is not command) is not
supported. supported.
In EVPN VPWS dual- In EVPN VPWS dual-
homing networking, a homing networking, a
bypass path needs to be bypass path needs to be
established. Therefore, established. Therefore,
the control word the control word
configuration must be configuration must be
consistent on all involved consistent on all involved
PEs (when a bypass path PEs (when a bypass path
is established between a is established between a
single-homing PE and single-homing PE and
each of dual-homing PEs each of dual-homing PEs
and between dual- and between dual-
homing PEs). A control homing PEs). A control
word inconsistency word inconsistency
causes a failure to causes a failure to
establish bypass paths. establish bypass paths.

(2020-10-09)
In the L2 EVPN access to Separately configure an Traffic forwarding is

L3 EVPN scenario, a interface MAC address adversely affected when
created L3VE main for each L3VE main sub-interfaces of
interface inherits the interface. different VE interfaces
system MAC address by are connected to a BD.
default. To connect to
L2VE interfaces mapped
to different L3VE main
interfaces in a BD, an
interface MAC address
must be separately
configured for each L3VE
main interface.
When routes over which This problem cannot be Basic VPLS forwarding
VLL VPN QoS traffic prevented in the VLL with BGP LSPs used as
travels recurse to BGP VPN QoS scenario. public network tunnel is
LSPs, the BGP entropy In basic VPLS forwarding supported. The entropy
label function is not scenarios, you must run label function is not
supported. both the mpls vpls supported, and the P
In the basic VPLS convergence separate node-based load
forwarding, VPLS VPN enable and mpls balancing is not
QoS, or PBB VPLS multistep separate supported.
scenario or when BGP enable commands so
LSPs function as public that the BGP entropy
network tunnels for function can be
VPLS, the BGP entropy supported.
label function is not
supported.
When the decoupling
between the public
network and private
network is not enabled
for both VPLS and MPLS
in the scenario of VPLS
routes recursive to BGP
LSPs, the BGP entropy
label function is not
supported for known
unicast traffic.

(2020-10-09)
When an EVPN E-LAN For BUM traffic, The switching

SRv6 egress is dual- associate an ESI with performance of BUM
homed to two PEs, the BFD for peer IP to traffic egress protection
egress protection implement fast BUM deteriorates.
function does not take traffic switching in case
effect for BUM traffic. of an egress failure.
Therefore, locators need
to be planned so that
the egress protection
function takes effect only
for known unicast routes.
In an EVPN VPLS Properly configure the The incorrect control

scenario, the control control word function word configuration may
word function can only based on the cause service failures.
be statically configured. requirements.
The control words on
both ends of a PW must
be the same.
In an EVPN VPWS
scenario, the negotiation
for the control word
carried in routes is
supported. A control
word inconsistency
causes a path
establishment failure.
The preferred control-
word auto-negotiation is
not supported.
On an EVPN VPWS dual-
homing network, a
bypass path needs to be
established between PEs.
Therefore, the control
words configured
between a single-
homing PE and each of
dual-homing PEs and
between dual-homing
PEs must be the same to
prevent a bypass path
establishment failure due
to a control word
inconsistency.

(2020-10-09)
In the E2E SRv6 telecom None FRR protection and

cloud scenario, if FRR is ECMP cannot coexist.
enabled on PEs and the
cost values of Add-Path
routes advertised by
different leaf nodes are
different, the PEs
generate merely ECMP
paths, but not FRR
+ECMP paths.

different, the PEs
paths, but not FRR
+ECMP paths.

different, the PEs
paths, but not FRR
+ECMP paths.

different, the PEs
paths, but not FRR
+ECMP paths.

(2020-10-09)

different, the PEs
paths, but not FRR
+ECMP paths.
In the scenario where L3 In the scenario where L3 By default, routes of an

EVPN and L3VPN coexist, EVPN and L3VPN coexist, L3VPN instance are sent
a device by default sends to enable a device to to the BGP-VPNv4
the routes of an L3VPN send the routes of an address family only.
instance to both the L3VPN instance only to
BGP-EVPN address the BGP-EVPN address
family and the BGP- family but not to the
VPNv4/v6 address family BGP-VPNv4/v6 address
(used in local route family, you need to
leaking). configure an export
route-policy in the
L3VPN instance IPv4/v6
address family.

(2020-10-09)
1. Egress protection is None The egress protection

not supported in the CE function may fail.
multi-homing scenario.
2. Different locators
need to be deployed for
single-homing and dual-
homing services. Egress
protection is not required
for the locators used by
single-homing services.
3. The BUM service of
the EVPN E-LAN service
and the unicast service
use different locators,
and the locator used by
the BUM service is not
configured with egress
protection.
4. In the scenario where
one route is leaked to
multiple VPN instances,
the remote SID can be
mapped only to one
local service instance.
Ensure that the route
leaking results on the
dual-homing PEs are the
same. (The RT used to
locally leaked routes
between VPN instances
on a dual-homing PE
must be the same as
that on the other dual-
homing PE. The local
route leaking
relationship configured
on a dual-homing PE
must be the same as
that on the other dual-
homing PE.)
3.2.3 Activating EVPN Interface Licenses on a Board

The device supports EVPN service activation by device or interface. If EVPN service
resources have been purchased based on the number of ports in the current
project, you must allocate these resources to specified ports.

(2020-10-09)
Before activating EVPN interface licenses on a board, complete the following tasks:
● The license file for the master main control board has been activated using
the license active file-name command.
● The interface-specific basic hardware licenses for the board have been
activated in batches using the active port-basic slot slot-id card card-id port
port-list command.
● The interface-specific basic hardware licenses for the board have been
activated in batches using the active port-basic slot slot-id card card-id
command.
Context
In VS mode, this chapter applies only to the admin VS.
Procedure
Step 2 Run license
The license view is displayed.
Step 3 Run active port-evpn slot slot-id card card-id port port-list
EVPN interface licenses are activated on the board.
Step 4 Run commit
----End

Run the display license resource usage port-evpn { all | slot slot-id } [ active |
deactive ] command to check whether EVPN interface licenses have been
activated on boards.
3.2.4 Configuring Common EVPN Functions

Configuring Common EVPN Functions involve configuring EVPN instances, BGP
EVPN peer relationships, BGP EVPN RRs, and ESIs.
Usage Scenario
EVPN is used for Layer 2 internetworking.
On the network shown in Figure 3-116, to allow Layer 2 networks at different
sites to communicate, configure EVPN. Specifically:
● Configure an EVPN instance on each PE and bind the EVPN instance on each
PE to the interface that connects the PE to a site.

(2020-10-09)
● Configure EVPN source IP addresses to identify PEs in the EVPN networking.

● Configure ESIs for PE interfaces connecting to CEs. PE interfaces connecting to
the same CE have the same ESI.
● Configure BGP EVPN peer relationships between PEs on the backbone
network to allow MAC addresses to be advertised over routes.
● Configure RRs to decrease the number of BGP EVPN peer relationships
required.
Figure 3-116 EVPN networking
Before configuring common EVPN, complete the following tasks:
● Configure an IGP on the backbone network to ensure IP connectivity.

● Configure MPLS LDP or TE tunnels on the backbone network.
● Configure Layer 2 connections between CEs and PEs.
3.2.4.1 Configuring an EVPN Instance

You can configure EVPN instances on PEs to manage EVPN routes.
Context
EVPN instances are used to isolate EVPN routes from public routes and isolate the
routes of EVPN instances from each other. EVPN instances are required in all EVPN
networking solutions.

(2020-10-09)
Procedure
Step 2 Run evpn vpn-instance vpn-instance-name
An EVPN instance is created, and its view is displayed.
Step 3 (Optional) Run description description-information
A description is configured for the EVPN instance.
Similar to a host name or an interface description, an EVPN instance description
helps you memorize the EVPN instance.
Step 4 Run route-distinguisher route-distinguisher
An RD is set for the EVPN instance.
different EVPN instances on the same PE must be different.
NOTE
After being configured, an RD cannot be modified but can be deleted. If the RD of an EVPN
instance is deleted, VPN targets configured for the EVPN instance are also deleted.
Step 5 Run vpn-target vpn-target &<1-8> [ both | export-extcommunity | import-

extcommunity ]
One or multiple VPN targets are configured for the EVPN instance.
acceptance and advertisement of EVPN routes. A maximum of eight import VPN
targets and eight export VPN targets can be configured each time the vpn-target
command is run. To configure more VPN targets for an EVPN instance address
family, run the vpn-target command multiple times.
NOTE
An RT of an Ethernet segment route is generated using the middle 6 bytes of an ESI. For
example, if the ESI is 0011.1001.1001.1001.1002, the Ethernet segment route uses
11.1001.1001.10 as its RT.
Step 6 (Optional) Run filter-policy { acl-number | acl-name acl-name } export

The device is enabled to filter EVPN routes to be advertised.
To precisely control EVPN routes, an export route-policy must be configured. An
export route-policy filters routes before they are sent to other PEs.
Step 7 (Optional) Run filter-policy { acl-number | acl-name acl-name } import
The EVPN instance is configured to filter received EVPN routes.
To precisely control EVPN routes, an import route-policy must be configured. An
import route-policy filters routes that are received from other PEs.
Step 8 (Optional) Run mac limit number [ simply-alert | mac-unchanged ]

(2020-10-09)
The maximum number of MAC addresses allowed in the EVPN instance is set.
A device consumes more system resources as it learns more MAC addresses,
meaning that the device may fail to operate when busy processing services. To
limit the maximum number of MAC addresses allowed in an EVPN instance and
thereby improving device security and reliability, run the mac limit command.
After this configuration, if the number of MAC addresses exceeds the preset value,
an alarm is triggered to prompt you to check the validity of existing MAC
addresses.
After the maximum number of MAC addresses allowed by an EVPN instance is
configured, you can run the mac threshold-alarm upper-limit upper-limit-value
lower-limit lower-limit-value command to configure an alarm threshold for MAC
addresses allowed by the EVPN instance. The alarm generation and clearance help
a device detect threshold-crossing events of MAC addresses.
Step 9 (Optional) Run tnl-policy policy-name
A tunnel policy is applied to the EVPN instance.
This configuration enables PEs to use TE tunnels to transmit data packets.
Step 10 (Optional) Run isolate spoken
The forwarding isolation function is enabled for the EVPN instance.
When users with the same service are bound to the same EVPN instance, you can
configure the forwarding isolation function for the EVPN instance to prevent
mutual access between users.
Step 11 (Optional) Run reserve-interface fast-switch enable
The reserve-interface fast switching function is enabled.
When the master interface board fails, you can perform this step to enable the
fast switchover of reserved interfaces so that broadcast traffic can be quickly
switched to the backup interface board.
Step 12 Run commit
----End
3.2.4.2 Configuring an EVPN Source Address

An EVPN source address uniquely identifies a PE in EVPN networking.
Context
The EVPN source address, which can be used to identify a PE on an EVPN, is part
of EVPN route information. Configuring EVPN source addresses is a mandatory
task for EVPN configuration.
Procedure

(2020-10-09)
Step 2 Run evpn source-address ip-address

Step 3 Run commit
----End
3.2.4.3 Binding an Interface to an EVPN Instance

After an interface is bound to an EVPN instance, the interface becomes a part of
the EVPN. Packets entering the interface will then be forwarded based on EVPN
instance traffic forwarding entries.
Context
After an EVPN instance is configured on a PE, an interface that belongs to the
EVPN must be bound to the EVPN instance. Otherwise, the interface functions as
a public network interface and cannot forward EVPN traffic.
Procedure
Step 2 Run interface interface-type interface-number
The interface view is displayed. In a CE dual-homing scenario, the interface must
be an Eth-Trunk interface.
Step 3 Run evpn binding vpn-instance vpn-instance-name
The interface is bound to an EVPN instance.
Step 4 Run commit
----End
3.2.4.4 Configuring an ESI

An ESI must be configured on a PE interface connected to a CE. The same ESI
must be configured for PE interfaces connecting to the same CE.
Context
The PEs connecting to the same CE must have the same ESI configured. After PEs
exchange routes that carry ESIs, a PE can be aware of the other PEs connecting to
the same CE, helping implement load balancing or FRR.
Before configuring an ESI on an interface, ensure that:
● The interface has been bound to an EVPN instance using the evpn binding
vpn-instance command.

(2020-10-09)
● The interface is in the up state. Otherwise, Ethernet segment routes cannot be

generated.
An ESI can be obtained for an interface in the following ways:
● An ESI is statically set on the interface.
● An ESI is dynamically generated on the interface.
Static configuration is recommended. Compared with dynamic ESI generation,
static configuration allows EVPN to implement faster traffic switching during a DF
election in a dual-homing scenario with active-active PEs.
NOTE
Functions, such as rapid convergence, split horizon, and DF election that are required in the
EVPN dual-homing scenario fail to take effect in a single-homing scenario. In such a scenario,
configuring an ESI is optional on a single-homing PE.
The format of a dynamically generated ESI is xxxx.xxxx.xxxx.xxxx.xxxx.xxxx, where x is a
hexadecimal number starting at 01 and consisting of the LACP system MAC address and LACP
port key value. The remaining bits are padded with 0.
Procedure
● Statically configure an ESI on an interface.
a. Run system-view
c. Run esi esi
An ESI is set.
d. Run commit
● Configure an interface to dynamically generate an ESI.
a. Run system-view
b. Run interface eth-trunk trunk-id
The Eth-Trunk interface view is displayed.
c. Run mode lacp-static
The working mode of the Eth-Trunk interface is set to static LACP.
d. Run commit
----End
3.2.4.5 Establishing a BGP EVPN Peer Relationships

After two PEs establish a BGP EVPN peer relationship, they can exchange EVPN
routes.

(2020-10-09)
Context
In EVPN networking, PEs have to establish BGP EVPN peer relationships before
exchanging EVPN routes to implement communication between the PEs within an
EVPN instance.
Perform the following steps on each PE.
Procedure
Step 2 Run bgp { as-number-plain | as-number-dot }
Step 3 Run peer ipv4-address as-number as-number
A peer device is configured as a BGP peer for the PE.
Step 4 Run peer ipv6-address connect-interface loopback interface-number
The interface on which a TCP connection to the specified BGP peer is established is
specified.
NOTE
A PE must use a loopback interface address with a 32-bit mask to establish an MP-IBGP
peer relationship with the peer PE so that VPN routes can recurse to tunnels. The route to
the local loopback interface is advertised to the peer PE using an IGP on the MPLS
backbone network.
Step 5 Run l2vpn-family evpn

The BGP-EVPN address family view is displayed.
Step 6 Run peer { ipv4-address | group-name } enable
group.
Step 7 (Optional) Run peer ipv4-address group group-name
A BGP EVPN peer is added to the peer group.
Adding BGP EVPN peers to peer groups simplifies BGP network configuration and
management.
Step 8 (Optional) Run timer df-delay delay-value
A designated forwarder (DF) election delay is configured.
If a network is unstable, PE interfaces connecting to CEs will frequently alternate
between Up and Down, resulting in repeated DF election and subsequent network
performance deterioration. To prevent repeated DF election, run the timer df-
delay command to set a longer DF election delay to improve network stability.
In an EVPN dual-homing scenario where interface-based DF election is enabled,
you need to run this command to set the delay for DF election to 0s prevent the

(2020-10-09)
long-time existence of dual backup devices during a switchback from causing a

traffic interruption.
Step 9 (Optional) Run peer { group-name | ipv4-address } mac-limit number
[ percentage ] [ alert-only | idle-forever | idle-timeout times ]
The maximum number of MAC/IP advertisement routes allowed to be accepted
from the specified peer is set.
If an EVPN instance imports many inapplicable MAC/IP advertisement routes from
a peer or peer group and they account for a large proportion of the total number
of MAC/IP advertisement routes, you are advised to run this command to limit the
maximum number of MAC/IP advertisement routes that can be imported. If the
imported MAC/IP advertisement routes exceed the specified maximum number,
the device displays an alarm, prompting you to check the validity of the MAC/IP
advertisement routes imported to the EVPN instance.
Step 10 (Optional) Perform the following operations to enable the device to advertise the
routes carrying the large-community attribute to BGP EVPN peers.
The large-community attribute can represent a whole 2-byte or 4-byte AS number,
and contain two 4-byte LocalData IDs, facilitating the flexible application of route-
policies. Before enabling the function to advertise the routes carrying the large-
community attribute to BGP EVPN peers, configure the route-policy related to the
large-community attribute and use the route-policy to set the large-community
attribute.
1. Run the peer { ipv4-address | group-name } route-policy route-policy-name
export command to configure an export route-policy for the BGP EVPN peer.
2. Run the peer { ipv4-address | group-name } advertise-large-community
command to enable the device to advertise the routes carrying the large-
community attribute to the specified BGP EVPN peer or peer group.
If the routes carrying the large-community attribute do not need to be
advertised to a specified BGP EVPN peer in a peer group, run the peer ipv4-
address advertise-large-community disable command.
Step 11 (Optional) Run peer peerIpv4Addr path-attribute-treat attribute-id { id [ to
id2 ] } &<1-255> { discard | withdraw | treat-as-unknown }
A special mode is specified to process specified path attributes in received BGP
EVPN Update messages.
A BGP EVPN Update message contains various path attributes. If a local device
receives Update messages containing malformed path attributes, the involved BGP
EVPN sessions may flap. To enhance reliability, you can configure a special mode
for processing specified path attributes in received BGP EVPN Update messages.
The special mode can be:
● Discards the specified path attributes.
● Withdraws the routes with the specified path attributes.
● Processes the specified attributes as unknown ones.
Step 12 Run commit
----End

(2020-10-09)
3.2.4.6 (Optional) Configuring the Global Redundancy Mode

A PE's global redundancy mode determines whether the PE can work with other
PEs in load-balancing mode.
Context
By default, EVPN PEs work in all-active mode. If a CE is multi-homed to several
EVPN PEs, these PEs will load-balance traffic. If you do not want to transmit traffic
in load balancing mode, you can switch the global redundancy mode of a PE from
all-active to single-active. When PEs work in all-active mode, each PE is in the
active state. When PEs work in single-active mode, one PE is in the active state,
and the other PEs are in the standby state.
In a scenario where a CE is multi-homed to PEs, an Eth-Trunk interface needs to

be configured on the CE to connect to the PEs, and an Eth-Trunk interface also
needs to be configured on the PEs to connect to the CE. Currently, only E-Trunk
can be used to determine the active/standby status of PEs. Perform the following
steps on a multi-homed PE:
Procedure
Step 2 Run e-trunk e-trunk-id
An E-Trunk is configured, and its view is displayed.
Step 3 Run priority priority
An E-Trunk priority value is set.
Step 4 Run peer-address peer-ip-address source-address source-ip-address
IP addresses are configured for the local and peer ends of the E-Trunk.
Step 5 Run quit
Step 6 Run interface eth-trunk trunk-id
The Eth-Trunk interface is added to the E-Trunk.
An Eth-Trunk interface can be added to only one E-Trunk.
Step 8 (Optional) Run e-trunk mode force-master
The E-Trunk member interface is forced to work in master mode.
In an all-active scenario, you need to run this command to set the status of
multiple PEs to master to implement load balancing. In single-active scenarios,
this command cannot be run on PEs.

(2020-10-09)
Step 9 Run quit

Step 10 Run lacp e-trunk system-id mac-address
An E-Trunk Link Aggregation Control Protocol (LACP) system ID is set.
The LACP system IDs for the same E-Trunk must be the same.
Step 11 (Optional) Run lacp e-trunk priority priority
An E-Trunk LACP system priority value is set.
The LACP system priority values for the same E-Trunk must be the same.
Step 12 (Optional) Run evpn redundancy-mode single-active
The global redundancy mode is set to single-active.
In single-active scenarios, this command must be configured on PEs. In all-active
scenarios, this command cannot be configured on PEs.
Step 13 Run commit
----End
3.2.4.7 (Optional) Configuring a BGP EVPN RR

Configuring a BGP EVPN RR helps reduce the number of required BGP EVPN peer
relationships, and therefore saves network resources.
Context
In an AS where a router serves as an RR, other routers can serve as RR clients. The
clients establish BGP EVPN peer relationships with the RR. The RR and its clients
form a cluster. The RR reflects routes among the clients, and therefore the clients
do not need to establish IBGP connections.
Procedure
Step 2 Run bgp as-number
Step 4 Run peer { ipv4-address | group-name } reflect-client
An RR and its clients are configured.
The device where the peer reflect-client command is run serves as the RR and
the specified peers or peer groups serve as clients.

(2020-10-09)
Step 5 (Optional) Run undo reflect between-clients

Route reflection between clients through the RR is disabled.
If the clients of an RR have established full-mesh connections with each other, you
can run the undo reflect between-clients command to disable route reflection
between clients through the RR to reduce the link cost. The undo reflect
between-clients command can only be run on an RR.
Step 6 (Optional) Run reflector cluster-id cluster-id
A cluster ID is configured for the RR.
If a cluster has multiple RRs, you can use this command to set the same cluster ID
for these RRs to prevent routing loops.
The reflector cluster-id command can only be run on an RR.
Step 7 Run commit
----End
3.2.4.8 (Optional) Setting a Redundancy Mode and DF Priority per ESI

Instance
In a scenario where multiple CEs are dual-homed to PEs, if you want to use
different transmission modes (load balancing and non-load balancing) to send
unicast traffic to different CEs or if you want to specify DFs for traffic forwarding
by setting priority values, you can set a redundancy mode and DF priority values
based on ESIs.
Context

(2020-10-09)
Figure 3-117 Setting a redundancy mode per ESI
An ESI can be dynamically generated or statically configured. A redundancy mode

per ESI instance must be set based on the ESI generation mode.
Procedure
● Set a redundancy mode based on a statically configured ESI.
a. Run system-view
b. Run evpn
The global EVPN configuration view is displayed.
c. Run esi esi
A static ESI instance name is configured. The esi value must be the same
as the name of the statically configured ESI.
d. Run evpn redundancy-mode { single-active | all-active }
A redundancy mode is configured for the static ESI instance.
e. (Optional) Run df-election type preference-based
Priority-based DF election is enabled.
f. (Optional) Run preference preference
A priority value is set. A larger value indicates a higher priority.
g. (Optional) Run non-revertive
The non-revertive mode is enabled.
As shown in Figure 3-117, CE2 is dual-homed to PE1 and PE2. PE1 is
elected as the primary DF to forward traffic because it has a higher
priority. If PE4 is deployed on the network and its DF priority is higher
than that of PE1, PE4 becomes the primary DF. That is, traffic is switched
to PE4 for forwarding. If you do not want traffic to be switched back, run
the non-revertive command on PE1 to disable the traffic switchback
function.
h. Run commit

(2020-10-09)
● Set a redundancy mode based on a dynamically generated ESI.

a. Run system-view
b. Run evpn
c. Run esi dynamic-name esi-name
A dynamic ESI instance name is configured.
A redundancy mode is configured for the dynamic ESI instance.
function.
h. Run quit
Return to the ESI-dynamic view.
i. Run quit
Return to the global EVPN configuration view.
j. Run quit
k. Run interface eth-trunk trunk-id
l. Run esi dynamic esi-name
A dynamic ESI instance is bound to the Eth-Trunk interface.
m. Run commit
----End
3.2.4.9 (Optional) Associating DF with BFD

When a CE is dual-homed to PEs, you can associate DF with BFD. If an access link
fails, this configuration accelerates the primary/backup DF switchover.

(2020-10-09)
Context
In a CE dual-homing scenario, to speed up primary/backup DF switching if an
access link fails, you can create a BFD session between the two PEs, specify an
access-side Eth-Trunk or PW-VE interface as the interface to be monitored by the
BFD session, and then associate the interface with the BFD session. After the
configuration is complete, if the access link connected to the PE on which the
master DF resides goes faulty, BFD can rapidly detect the fault and transmit the
fault to the other PE through the BFD session. This allows the backup DF to
quickly become the primary DF.
Procedure
Step 2 Run bfd
BFD is enabled globally, and the global BFD view is displayed.
Step 3 Run quit
Return to the previous view.
Step 4 Run bfd bfd-session-name bind peer-ip pe-ip-address track-interface interface
The binding between a BFD session and a peer IP address is created, and the BFD
session view is displayed. pe-ip-address indicates the IP address of the remote PE,
and interface-type interface-number indicates the type and number of the Eth-
Trunk or PW-VE interface on the access side.
Step 5 Run the following commands to configure BFD session discriminators:
● To set the local discriminator, run the discriminator local discr-value
command.
● To set the remote discriminator, run the discriminator remote discr-value
command.
The local discriminator at one end must be the remote discriminator at the other
end.
Step 6 Run quit
Return to the previous view.
Step 7 Run interface { eth-trunk trunk-id | PW-VE interface-number }
The Eth-Trunk interface view or PW-VE interface view is displayed.
Step 8 Run es track bfd bfd-session-name
The interface is associated with the BFD session.
Step 9 Run commit
----End

(2020-10-09)
3.2.4.10 (Optional) Improving the switching performance of broadcast

traffic if the master board fails
You can enable the device to deliver backup leaf node information to the standby
interface board, which helps improve the switching performance of broadcast
traffic if the master board fails.
Context
When packets enter a public network from an EVPN or BD EVPN for BUM
forwarding, board selection for internal loopback is performed based on a main
control board, enable the device to deliver backup leaf node information to the
standby interface board, this configuration allows primary and backup leaf nodes
to be delivered to different boards for protection, after a board is removed, the
PST down event on the reserved interface triggers a primary/backup leaf node
switchover, improving the link switching performance.
Procedure
Step 2 Run evpn reserve-interface enhancement
The device delivers backup leaf node information to the standby interface board.
Step 3 Run commit
----End
3.2.4.11 Verifying the EVPN Configuration

After configuring EVPN, verify the operating status and information about EVPN
functions.
Prerequisites
EVPN has been configured.
Procedure
● Run the display default-parameter evpn command to check default EVPN
configurations during EVPN initialization.
● Run the display evpn vpn-instance [ name vpn-instance-name ] command
to check EVPN instance information.
● Run the display evpn vpn-instance name vpn-instance-name df result [ esi
esi ] command to check the DF election result of an EVPN instance.
● Run the display evpn vpn-instance name vpn-instance-name df-timer state
command to check the DF timer status of an EVPN instance.

(2020-10-09)
● Run the display bgp evpn { all | vpn-instance vpn-instance-name } esi [ esi ]
command to check information about the ESIs of a specified or all EVPN
instances.
inclusive-route | mac-route | prefix-route } prefix ] command to check
information about EVPN routes.
● Run the display bgp evpn all routing-table statistics command to check
statistics about EVPN routes.
● Run the display evpn mac routing-table command to check MAC route
information about EVPN instances.
● Run the display evpn mac routing-table limit command to check MAC
address limits of EVPN instances.
● Run the display evpn mac routing-table statistics command displays MAC
route statistics of EVPN instances.
● Run the display arp broadcast-suppress user bridge-domain bd-id
command to check the ARP broadcast suppression table of a specified BD.
● Run the display arp packet statistics bridge-domain bd-id command to
check statistics about the ARP packets in a specified BD.
----End
3.2.5 Configuring BD-EVPN Functions

Configuring bridge domain BD-EVPN functions involves configuring an EVPN
instance in BD mode, creating a BD and binding an EVPN instance to the BD,
configuring an L3VPN instance and binding it to a VBDIF interface, and
configuring BGP EVPN peer relationships.
Usage Scenario
This section describes how to configure BD-EVPN functions. An EVPN in non-BD
mode can only carry Layer 2 services, whereas a BD-EVPN can carry both Layer 2
and Layer 3 services.
Before configuring a BD-EVPN, complete the following tasks:
● Configure an IGP on the backbone network to ensure IP connectivity.

● Configure MPLS LDP LSPs or TE tunnels on the backbone network.
● (Optional) In a CE dual-homing scenario where Layer 3 traffic is transmitted,
configure the function to send ARP packets at a constant speed to limit the
rate at which ARP broadcasts request packets. It is recommended that an ARP
request packet be broadcast every 10 ms. This ensures a rapid traffic
switchover after a CE fault occurs.

(2020-10-09)
3.2.5.1 Configuring an EVPN Instance in BD Mode

To implement service access based on a BD and manage EVPN routes, configure
EVPN instances in BD mode on PEs.
Context
EVPN instances are used to isolate EVPN routes from public routes and isolate the
routes of an EVPN instances from those of the other EVPN instances. EVPN
instances are required in all EVPN networking solutions.
Procedure
Step 2 Run evpn vpn-instance vpn-instance-name bd-mode
A BD EVPN instance is created, and the EVPN instance view is displayed.
NOTE

extcommunity ]
One or multiple VPN targets are set for the EVPN instance.
targets and eight export VPN targets can be configured each time the vpn-target
command is run. To configure more VPN targets for an EVPN instance address
family, run the vpn-target command multiple times.
NOTE
An RT of an Ethernet segment route is generated using the middle 6 bytes of an ESI. For
example, if the ESI is 0011.1001.1001.1001.1002, the Ethernet segment route uses
11.1001.1001.10 as its RT.

The EVPN instance is configured to filter EVPN routes to be advertised.

(2020-10-09)
To precisely control EVPN routes, an export route-policy must be configured. An

The EVPN instance is configured to filter EVPN routes to be accepted.
To precisely control EVPN routes, an import route-policy can be configured. An

import route-policy filters routes that are received from other PEs and are to be
accepted.
Step 8 (Optional) Run mac limit number [ simply-alert | mac-unchanged ]
The maximum number of MAC addresses allowed in the EVPN instance is set.
A device consumes more system resources as it learns more MAC addresses,

meaning that the device may fail to operate when busy processing services. To
limit the maximum number of MAC addresses allowed in an EVPN instance and
thereby improving device security and reliability, run the mac limit command.
After this configuration, if the number of MAC addresses exceeds the preset value,
an alarm is triggered to prompt you to check the validity of existing MAC
addresses.
After the maximum number of MAC addresses allowed by an EVPN instance is

configured, you can run the mac threshold-alarm upper-limit upper-limit-value
lower-limit lower-limit-value command to configure an alarm threshold for MAC
addresses allowed by the EVPN instance. The alarm generation and clearance help
a device detect threshold-crossing events of MAC addresses.
The EVPN instance is associated with a tunnel policy.
This configuration enables PEs to use TE or SR tunnels to transmit data packets.
Step 10 (Optional) Run bypass-vxlan disable
Inter-chassis VXLAN is disabled in the instance.
By default, after the bypass-vxlan enable command is run in the system view,
only EVPN VXLAN-related functions can be deployed on the device. This step is
required if you want to configure EVPN MPLS functions for some BD EVPN
instances.
Step 11 (Optional) Run control-word enable
The control word function is enabled for the EVPN.
In load balancing mode, out-of-order packets may be generated when the device
performs in-depth parsing on MPLS packets. In this case, you can enable the
control word function in the EVPN instances on both ends to reassemble MPLS
packets.
Step 12 Run commit
----End

(2020-10-09)
3.2.5.2 Configuring an EVPN Source Address

An EVPN source address uniquely identifies a PE in EVPN networking.
Context
The EVPN source address, which can be used to identify a PE on an EVPN, is part
of EVPN route information. Configuring EVPN source addresses is a mandatory
task for EVPN configuration.
Procedure
Step 3 Run commit
----End
3.2.5.3 Configuring an ESI

An ESI must be configured on a PE interface connected to a CE. The same ESI
must be configured for PE interfaces connecting to the same CE.
Context
The PEs connecting to the same CE or BD must have the same ESI configured.
After PEs exchange routes that carry ESIs, a PE can be aware of the other PEs
connecting to the same CE, helping implement load balancing or FRR.
The interface is in the up state. Otherwise, Ethernet segment routes cannot be

generated.
An ESI can be obtained for an interface in the following ways:

● An ESI is statically set on the interface.
● An ESI is dynamically generated on the interface.
Static configuration is recommended. Compared with dynamic ESI generation,

static configuration allows EVPN to implement faster traffic switching during a DF
election in a dual-homing scenario with active-active PEs.
NOTE
The features required in an EVPN dual-homing scenario, such as fast convergence, split horizon,
and DF election, all become invalid in a single-homing scenario. In such a scenario, configuring
an ESI is optional on a single-homing PE.

(2020-10-09)
Procedure
● Configure an interface to dynamically generate an ESI.
a. Run system-view

b. Run interface eth-trunk trunk-id

c. Run mode lacp-static
The working mode of the Eth-Trunk interface is set to static LACP.

d. Run commit

● Manually configure an ESI for an interface.
Perform this configuration if a VLAN is used to access an EVPN.
a. Run system-view


c. Run esi esi
An ESI is set.
d. Run commit

● Manually configure an ESI in a BD.
Perform this configuration if VXLAN is used to access an EVPN and the EVPN
transmits ARP or MAC routes.
a. Run system-view

b. Run bridge-domain bd-id
The BD view is displayed.

c. Run esi esi
An ESI is set.
d. Run commit
----End
3.2.5.4 Configuring a BD and Binding an EVPN Instance to the BD

An EVPN instance in BD mode is only bound to a BD instead of an interface.

(2020-10-09)
Context
An EVPN instance can be bound to a BD in two ways: using a VXLAN Network
Identifier (VNI) and using MPLS. In VNI mode, an EVPN instance is bound to a BD
after a VNI is configured. In MPLS mode, an EVPN instance is bound to a BD
directly in the BD view. If an EVPN instance needs to access a VPLS network, the
EVPN instance must be bound to a BD in VNI mode.
Procedure
Step 2 Run bridge-domain bd-id
The view of the BD to be bound to an EVPN instance is displayed.
Step 3 Run vxlan vni vni-id split-horizon-mode
A VNI is created and associated with the BD, and split horizon is specified for
packet forwarding.
Step 4 Run evpn binding vpn-instance evpn-name [ bd-tag bd-tag ]
The BD is bound to the EVPN instance. By specifying different bd-tag values, you
can bind multiple BDs to the same EVPN instance. In this way, VLAN services of
different BDs can access the same EVPN instance while being isolated.
Step 5 (Optional) Run reserve-interface fast-switch enable
The reserve-interface fast switching function is enabled.
When the master interface board fails, you can perform this step to enable the
fast switchover of reserved interfaces so that broadcast traffic can be quickly
switched to the backup interface board.
Step 6 Run quit
Step 7 Run interface interface-type interface-number.subnum mode l2
A Layer 2 sub-interface is created, and the Layer 2 sub-interface view is displayed.
NOTE
Before running this command, ensure that the involved Layer 2 main interface does not
have the port link-type dot1q-tunnel command configuration. If the configuration exists,
run the undo port link-type command to delete it.
Step 8 Run encapsulation { dot1q [ vid low-pe-vid [ to high-pe-vid ] ] | untag | qinq

[ vid pe-vid ce-vid { low-ce-vid [ to high-ce-vid ] | default } ] }
The flow encapsulation type is configured so that different interfaces can transmit
various types of data packets.
Step 9 Run rewrite pop { single | double }
The Layer 2 sub-interface is enabled to remove single or double VLAN tags from
received packets.

(2020-10-09)
If the received packets each carry a single VLAN tag, specify single.
If the encapsulation type of packets has been set to QinQ, specify double in this
step to remove double VLAN tags from the received packets.
The Layer 2 sub-interface is added to the BD to transmit data packets through this
BD.
Step 11 Run commit

----End
3.2.5.5 Creating an L3VPN Instance and Binding It to a VBDIF Interface

To enable an EVPN to transmit Layer 3 services, configure an L3VPN instance and
bind it to a VBDIF interface.
Context
To enable an EVPN to transmit Layer 3 services, configure an L3VPN instance and
bind it to a VBDIF interface. After this configuration, the L3VPN instance can
manage host routes received from the VBDIF interface.
Procedure
Step 2 Create an L3VPN instance on each device.
1. Run the ip vpn-instance vpn-instance-name command to create a VPN
instance and enter the VPN instance view.
2. Run the ipv4-family command to create the VPN instance IPv4 address family
and enter the VPN instance IPv4 address family view.
3. Run the route-distinguisher route-distinguisher command to set an RD for
the VPN instance IPv4 address family.
4. Run the vpn-target vpn-target &<1-8> [ both | export-extcommunity |
import-extcommunity ] evpn command to set one or multiple VPN targets
of the VPN instance IPv4 address family.
5. Run the evpn mpls routing-enable command to enable the device to
generate and advertise EVPN IP prefix routes and IRB routes.
6. (Optional) Run the tnl-policy policy-name evpn command to apply a
specified tunnel policy to the VPN instance IPv4 address family to associate
the tunnel policy with the EVPN routes leaked to the VPN instance IPv4
address family.
7. (Optional) Run the import route-policy policy-name evpn command to
apply an import route-policy to the VPN instance IPv4 address family to filter

(2020-10-09)
EVPN routes to be imported to the VPN instance IPv4 address family. Perform
this step to apply an import route-policy to the VPN instance IPv4 address
family and set attributes for eligible EVPN routes. This enables the device to
more precisely control EVPN routes to be imported into the VPN instance IPv4
address family more precisely.
8. (Optional) Run the export route-policy policy-name evpn command to apply
an export route-policy to the VPN instance IPv4 address family to filter EVPN
routes to be advertised. Perform this step to apply an export route-policy to
the VPN instance IPv4 address family and set attributes for eligible EVPN
routes. This enables the device to more precisely control EVPN routes to be
advertised.
9. Run the quit command to exit the VPN instance IPv4 address family view.
10. Run the quit command to exit the VPN instance view.

address family.
address family.
advertised.
Step 3 Run interface vbdif bd-id
A VBDIF interface is created, and the VBDIF interface view is displayed.

(2020-10-09)
Step 4 Run ip binding vpn-instance vpn-instance-name
The VBDIF interface is bound to a VPN instance.
Step 5 (Optional) Run ipv6 enable
Step 6 Run ip address ip-address { mask | mask-length } [ sub ] or ipv6 address { ipv6-
address prefix-length | ipv6-address/prefix-length }
An IPv4/v6 address is set for the VBDIF interface to implement Layer 3
communication.
Step 7 (Optional) Run mac-address mac-address
A MAC address is configured for the VBDIF interface.
Step 8 Run arp collect host enable or ipv6 nd collect host enable
The device is enabled to advertise host ARP/ND routes and IRB/IRBv6 routes.
Step 9 Run commit
----End
3.2.5.6 Configuring an EVPN BGP Peer Relationship

After two PEs establish a BGP EVPN peer relationship, they can exchange EVPN
routes.
Context
In EVPN networking, PEs have to establish BGP EVPN peer relationships before
exchanging EVPN routes to implement communication between the PEs within an
EVPN instance.
Perform the following steps on each PE.
Procedure
A remote PE is specified as a BGP peer for the PE.
specified.

(2020-10-09)
NOTE
backbone network.

group.
management.
Step 8 Run peer { ipv4-address | group-name } advertise { irb | arp | irbv6 | nd }
IRB/IRBv6 or ARP/ND route advertisement is enabled.
A designated forwarder (DF) election delay is set.
between up and down, resulting in repeated DF election and network
The maximum number of MAC routes allowed to be accepted from the specified
peer is set.
If an EVPN instance imports many inapplicable MAC routes from a peer or peer
group and they account for a large proportion of the total number of MAC routes,
you are advised to run this command to limit the maximum number of MAC
routes that can be imported. If the imported MAC routes exceed the specified
maximum number, the device displays an alarm, prompting you to check the
validity of the MAC routes imported to the EVPN instance.
Step 11 (Optional) Run route-select delay delay-value [ exclusive-eviad ]
The delayed route selection function is enabled. After the primary path recovers,
an appropriate delay ensures that traffic switches back to the primary path after
the intermediate device completes refreshing forwarding entries. The exclusive-
eviad command configures a route selection delay for non-Ethernet A-D per-EVI

(2020-10-09)
routes. To prevent the EVPN VPWS service from being adversely affected after the
route selection delay function is enabled, specify this parameter.
The large-community attribute can completely represent a 2-byte or 4-byte AS
number, and has two 4-byte LocalData IDs. This enables the administrator to
apply policies more flexibly. Before enabling the function to advertise the routes
carrying the large-community attribute to BGP EVPN peers, configure the route-
policy related to the large-community attribute and use the route-policy to set the
large-community attribute.
export command to configure an export route-policy to filter routes to be
advertised to a specified BGP EVPN peer or peer group.
Step 13 (Optional) Run peer ipv4-address graceful-restart static-timer restart-time
The maximum hold-off time is set for reestablishing BGP peer relationships,
namely, the maximum duration from the time the peer finds that the local device
restarts to the time the peer BGP reestablishes a BGP session.
Graceful restart (GR) prevents traffic interruption caused by the reestablishment
of BGP peer relationships. You can run the graceful-restart timer restart time or
peer graceful-restart static-timer command to set the maximum waiting time
for the local end to wait for the peer GR to recover.
● To set the maximum hold-off time for reestablishing all BGP peer
relationships, run the graceful-restart timer restart command in the BGP
view. The maximum hold-off time supported by this command is 3600s.
● To set the maximum hold-off time for reestablishing a specified BGP-EVPN
peer relationship, run the peer graceful-restart static-timer command in the
BGP-EVPN view. Run this command if you want to set a hold-off time longer
than 3600s.
If both the graceful-restart timer restart time and peer graceful-restart static-
timer commands are run, the configuration of the peer graceful-restart static-
timer command takes precedence over the graceful-restart timer restart time
command.
NOTE
This step can be performed only after GR is enabled using the graceful-restart command
in the BGP view.


(2020-10-09)
● Processes the specified path attributes as unknown ones.
Step 15 Run commit
----End
3.2.5.7 (Optional)Configuring a PE's Global RedundancyMode

Context

Procedure
Step 5 Run quit

(2020-10-09)

Step 9 Run quit
Step 13 Run commit
----End
3.2.5.8 (Optional) Setting a Redundancy Mode and DF Priority per ESI

Instance
In a scenario where multiple CEs are dual-homed to PEs, if you want to use
different transmission modes (load balancing and non-load balancing) to send
unicast traffic to different CEs or if you want to specify DFs for traffic forwarding
by setting priority values, you can set a redundancy mode and DF priority values
based on ESIs.
Context

(2020-10-09)

Figure 3-118 Setting a redundancy mode per ESI
An ESI can be dynamically generated or statically configured. A redundancy mode

per ESI instance must be set based on the ESI generation mode.
Procedure
● Set a redundancy mode based on a statically configured ESI.
a. Run system-view
b. Run evpn
c. Run esi esi
A static ESI instance name is configured. The esi value must be the same
as the name of the statically configured ESI.
A redundancy mode is configured for the static ESI instance.

(2020-10-09)

function.
h. Run commit

● Set a redundancy mode based on a dynamically generated ESI.
a. Run system-view

b. Run evpn

c. Run esi dynamic-name esi-name
A dynamic ESI instance name is configured.

A redundancy mode is configured for the dynamic ESI instance.




function.
h. Run quit
Return to the ESI-dynamic view.

i. Run quit

j. Run quit

k. Run interface eth-trunk trunk-id

l. Run esi dynamic esi-name
A dynamic ESI instance is bound to the Eth-Trunk interface.

(2020-10-09)
m. Run commit
----End
3.2.5.9 (Optional) Configuring a BGP EVPN RR

Configuring a BGP EVPN RR helps reduce the number of required BGP EVPN peer
relationships, and therefore saves network resources.
Context
In an AS where a router serves as an RR, other routers can serve as RR clients. The
clients establish BGP EVPN peer relationships with the RR. The RR and its clients
form a cluster. The RR reflects routes among the clients, and therefore the clients
do not need to establish IBGP connections.
Procedure
An RR and its clients are configured.
The device where the peer reflect-client command is run serves as the RR and
the specified peers or peer groups serve as clients.
Step 5 (Optional) Run undo reflect between-clients
If the clients of an RR have established full-mesh connections with each other, you
can run the undo reflect between-clients command to disable route reflection
between-clients command can only be run on an RR.
Step 6 (Optional) Run reflector cluster-id cluster-id
If a cluster has multiple RRs, you can use this command to set the same cluster ID
The reflector cluster-id command can only be run on an RR.
Step 7 Run commit

(2020-10-09)
----End
3.2.5.10 (Optional) Configuring Proxy ARP

When users access each other for the first time, they send ARP request packets.
These packets are broadcast on Layer 2 networks. Proxy ARP can be configured to
reduce the number of ARP broadcast packets.
Context
On an EVPN MPLS network, after a device receives an ARP request packet, it
broadcasts the packet within a BD. If the device receives a large number of ARP
request packets within a specified period and broadcasts these packets, excessive
ARP request packets are forwarded on the EVPN MPLS network, consuming
excessive network resources and causing network congestion. As a result, the
network performance deteriorates, and user services are affected.
To address this problem, configure proxy ARP on the device. Proxy ARP allows a
device to listen to a received ARP packet and generate an ARP snooping entry to
record the source user information, including the packet's source IP address,
source MAC address, and inbound interface. If proxy ARP is enabled on a device
and an ARP request packet is received, the device preferentially responds to the
request if an ARP snooping entry matches the user information in the ARP
request.
Procedure
Step 2 (Optional) Run arp host ip-conflict-check period period-value retry-times retry-
times-value
Host IP address conflict check is configured.
Step 5 Run peer { ipv4-address | group-name } advertise arp
ARP route advertisement is configured.
Step 6 Run quit
The BD vew is displayed.

(2020-10-09)
Step 8 Run arp l2-proxy enable
Proxy ARP is enabled.
Step 9 (Optional) Run arp l2-proxy timeout expire-time
An aging time is configured for ARP snooping entries.
Each ARP snooping entry has a life cycle, which is called the aging time. If an ARP
snooping entry is not updated before its aging time expires, the entry will be
deleted. If the corresponding ARP snooping entries are not released after a user
goes offline, CPU resources are wasted and ARP snooping entries for new users
cannot be properly generated. To resolve this problem, perform this step to set an
aging time so that ARP snooping entries are updated regularly.
Step 10 Perform the following operations as required:

● If a device needs to carry Layer 2 services, run the arp collect host enable
command to enable the EVPN MPLS network to collect host information by
BD.
● If a device needs to carry Layer 3 services or both Layer 2 and Layer 3
services, run the following commands:
a. Run quit
b. Run interface vbdif bd-id
c. Run arp collect host enable
The EVPN MPLS network is enabled to collect host information by VBDIF
interface.
Step 11 Run commit
----End
3.2.5.11 Checking the Configurations

After configuring EVPN, verify the operating status and information about EVPN
functions.
Prerequisites
EVPN has been configured.
Procedure
● Run the display default-parameter evpn command to check default EVPN
configurations during EVPN initialization.
● Run the display evpn vpn-instance [ name vpn-instance-name ] command
to check EVPN instance information.
esi ] command to check the DF election result of an EVPN instance.

(2020-10-09)
● Run the display evpn vpn-instance name vpn-instance-name df-timer state

command to check the DF timer status of an EVPN instance.
● Run the display bgp evpn { all | vpn-instance vpn-instance-name } esi [ esi ]
command to check information about the ESIs of a specified or all EVPN
instances.
information about EVPN routes.
● Run the display bgp evpn all routing-table statistics command to check
statistics about EVPN routes.
● Run the display evpn mac routing-table command to check MAC route
information about EVPN instances.
● Run the display evpn mac routing-table limit command to check MAC
address limits of EVPN instances.
● Run the display evpn mac routing-table statistics command displays MAC
route statistics of EVPN instances.
● Run the display arp broadcast-suppress user bridge-domain bd-id
command to check the ARP broadcast suppression table of a specified BD.
● Run the display arp packet statistics bridge-domain bd-id command to
check statistics about the ARP packets in a specified BD.
----End
3.2.6 Configuring EVPN VPWS over MPLS Functions

EVPN VPWS over MPLS allows you to establish P2P MPLS tunnels between PEs
and implement the P2P L2VPN function.
Usage Scenario
EVPN VPWS provides a P2P L2VPN service solution based on the EVPN service
architecture. Regarding this solution, a P2P MPLS tunnel is established between
PEs and traverses the backbone network. By binding the AC interface on the user
side to the P2P MPLS tunnel on the network side, traffic can be transmitted
between the AC interface and the P2P MPLS tunnel. As a result, traffic that enters
the AC interface is forwarded directly to the peer PE through the P2P MPLS tunnel.
This solution provides a simple Layer 2 packet forwarding mode for the connection
between AC interfaces at both ends, avoiding the need to search MAC address
entries. This service solution is named Ethernet Line (E-Line).
The basic EVPN VPWS architecture has the following components:
● AC: access circuit. An AC is an independent link or circuit that connects a CE

to a PE. An AC interface can be a physical interface or a logical interface. AC
attributes include the encapsulation type, maximum transmission unit (MTU),
and interface parameters of a specified link type.
● VPWS instance: virtual private wire service instance. Each VPWS instance
corresponds to an AC interface, indicating an Ethernet private line (EPL) or
Ethernet virtual private line (EVPL) access.

(2020-10-09)
● EVI: EVPN instance. Deployed on an edge PE, an EVI contains services that
have the same access-side or network-side attributes. Routes are transmitted
based on the RD and RTs configured in each EVI.
● Tunnel: tunnel on the network side.
Figure 3-119 Configuring EVPN VPWS over MPLS functions
Before configuring EVPN VPWS over MPLS, enable route reachability on an IPv4
network.
3.2.6.1 Configuring EVPN Functions

EVPN-VPWS is established based on the EVPN service architecture. Before
configuring EVPN VPWS over MPLS, you need to configure EVPN functions.
Procedure
Step 2 Run evpn vpn-instance vpn-instance-name vpws
An EVPN VPWS instance is created, and the instance view is displayed.

(2020-10-09)
NOTE

extcommunity ]
One or multiple VPN targets are set for the EVPN instance.
targets and eight export VPN targets can be configured using the vpn-target
command. To configure more VPN targets for an EVPN instance address family,
run the vpn-target command multiple times.
The EVPN instance is configured to filter EVPN routes to be advertised.
To precisely control EVPN routes, an export route-policy can be configured. An
The EVPN instance is configured to filter EVPN routes to be accepted.
To precisely control EVPN routes, an import route-policy can be configured. An
import route-policy filters routes that are received from other PEs.
A tunnel policy is applied to the EVPN instance.
This configuration enables PEs to use TE tunnels to transmit data packets.
Step 9 Run quit
Step 11 (Optional) Configure an ESI. In EVPN VPWS dual-homing networking, an ESI must
be configured on the PE interface connecting to a CE.
1. Run the interface interface-type interface-number command to enter the
interface view.
2. Run the esi esi command to set an ESI.
3. Run the quit command to return to the system view.
A remote PE is specified as a BGP peer for the PE.

(2020-10-09)
specified.
NOTE
backbone network.

group.
management.
Step 18 (Optional) Run peer { ipv4-address | group-name } reflect-client
An RR and its client are configured.
If all PEs are in the same AS, you can configure an RR to reduce IBGP connections.
The BGP device with the peer reflect-client command functions as an RR and
treats the specified peer or peer group as a client.
A DF election delay is configured.
between up and down, resulting in repeated DF election and network
The maximum number of MAC routes allowed to be accepted from the specified
peer is set.
If an EVPN instance imports many inapplicable MAC routes from a peer or peer
group and they account for a large proportion of the total number of MAC routes,
you are advised to run this command to limit the maximum number of MAC
routes that can be imported. If the imported MAC routes exceed the specified
maximum number, the device displays an alarm, prompting you to check the
validity of the MAC routes imported to the EVPN instance.

(2020-10-09)
The large-community attribute can completely represent a whole 2-byte or 4-byte
AS number, and has two 4-byte LocalData IDs. This enables the administrator to
apply policies more flexibly. Before enabling the function to advertise the routes
carrying the large-community attribute to BGP EVPN peers, configure the route-
policy related to the large-community attribute and use the route-policy to set the
large-community attribute.
export command to apply an export route-policy to filter routes to be
advertised to a specified BGP EVPN peer or peer group.
● Processes the specified path attributes as unknown ones.
Step 23 Run commit
----End
3.2.6.2 (Optional) Configuring the Global Redundancy Mode

Context

(2020-10-09)

Procedure
Step 5 Run quit
Step 9 Run quit

(2020-10-09)

Step 13 Run commit
----End
3.2.6.3 Configuring an EVPL Instance

Before binding an AC interface on the user side to an MPLS tunnel interface on
the network side, you must create an EVPL instance.
Procedure
Step 2 Run evpn vpn-instance vpn-instance-name
An EVPN instance is created, and its view is displayed.
An EVPN instance takes effect only after the RD is configured. The RDs of different
EVPN instances on a PE must be different.
NOTE
After being configured, an RD cannot be modified, but can be deleted. After you delete the
RD of an EVPN instance, the VPN targets of the EVPN instance will also be deleted.

extcommunity ]
A VPN target is a BGP extended community attribute. It is used to control the
receiving and advertisement of EVPN routes. A maximum of eight VPN targets can
be configured using a vpn-target command. To configure more VPN targets in the
EVPN instance address family, run the vpn-target command several times.
Step 5 (Optional) Run timer revert delay delay-value
The switchback delay time is configured.
In dual-homing scenarios, if a fault on the access-side link of the primary PE or
the primary PE is rectified, EVI AD routes are generated on the primary PE. Then,
EVI AD routes can be advertised to the remote PE based on the BGP EVPN peer
relationship. After receiving the EVI AD routes and generating forwarding entries,
the remote PE switches traffic from the path destined for the secondary PE to the
path destined for the primary PE. In this case, a few packets may be lost on the

(2020-10-09)
primary PE because not all forwarding entries are generated. To address this
problem, run the timer revert delay delay-value command on the remote PE to
configure a switchback delay time so that the generation of forwarding entries is
delayed after the remote PE receives EVI AD routes. Specifically, the forwarding
entries are generated after they become stable. If the delay times out, the remote
PE generates new forwarding entries and traffic is switched to the primary PE,
avoiding packet loss.
Step 6 Run quit
Step 7 Run evpl instance evpl-id mpls-mode
An EVPL instance is created, and its view is displayed.
Step 8 Run evpn binding vpn-instance vpn-instance-name
The EVPL instance is bound to an EVPN instance for a specified VPWS.
Step 9 Run local-service-id service-id remote-service-id service-id
remote service IDs.
Step 10 (Optional) Run load-balancing ignore-esi
Checking ESI validity when an EVPL instance load balancing is performed is

disabled.
When active-active protection is deployed in the EVPN VPWS scenario, if an access

device is single-homed to an aggregation device, no ESI is configured on the
access interface. To form active-active load balancing, you can run the load-
balancing ignore-esi command to enable the aggregation device to ignore ESI
validity check during EVPL instance load balancing.
Step 11 (Optional) Run control-word enable
The EVPL control-word function is enabled.
In load balancing mode, packet disorder may occur during the in-depth parsing of
MPLS packets. To resolve this problem, run the control-word enable command to
enable the EVPL control word function so that MPLS packets can be reassembled
using the control word.
Step 12 Run commit
----End
3.2.6.4 Configuring an AC Interface

In MPLS E-Line scenarios, a Layer 2 sub-interface can function as an AC interface,
and traffic encapsulation can be configured on the AC interface to transmit
different types of data packets.

(2020-10-09)
Procedure
Step 2 Run interface interface-type interface-number.subnum mode l2
NOTE
Before running this command, ensure that the Layer 2 main interface does not have the
port link-type dot1q-tunnel command configuration. If the configuration has existed, run
the undo port link-type command to delete it.
Step 3 Run evpl instance evpl-id

An EVPL instance is bound to the Layer 2 sub-interface.
Step 4 (Optional) Run evpn-vpws ignore-ac-state

The function to ignore the AC status on an interface is enabled.
This step can be performed to ensure EVPN VPWS service continuity after the AC
interface is configured with the CFM and interface association function in a
primary/secondary link networking scenario. In this case, if a primary/secondary
link switchover is triggered after the AC status of the interface is changed to
down, the AC status of the interface is ignored, and the EVPN VPWS service does
not need to be re-established during a primary/secondary link switchover.
Step 5 Run commit
----End
3.2.6.5 Configuring an MPLS LDP Tunnel

EVPN E-Line uses P2P MPLS LDP tunnels to traverse the backbone network. This
section describes how to configure an MPLS LDP tunnel.
Procedure
The LSR ID of the local node is configured.
When configuring an LSR ID, note the following:
● Configuring an LSR ID is the prerequisite of all MPLS configurations.
● An LSR ID must be manually configured because no default LSR ID is
available.
● Use the IP address of a loopback interface on an LSR as an LSR ID.

(2020-10-09)
NOTICE
The undo mpls command deletes all MPLS configurations, including the
established LDP sessions and LSPs.
Step 3 Run mpls
MPLS is enabled globally, and the MPLS view is displayed.
Step 4 Run mpls ldp
MPLS LDP is enabled globally, and the MPLS-LDP view is displayed.
Step 5 Run quit
The view of the interface on which an LDP session is to be established is displayed.
Step 7 Run mpls
Step 8 Run mpls ldp
MPLS LDP is enabled on an interface.
NOTE
Disabling MPLS LDP from an interface leads to interruptions of all LDP sessions on the
interface and deletions of all LSPs established over these LDP sessions.
Step 9 Run commit
----End
3.2.6.6 (Optional) Configuring a DF Election Mode for EVPN VPWS

In an EVPN VPWS over MPLS scenario where a CE is multi-homed to PEs in single-
active mode and no E-Trunk is configured, DF election needs to be performed
between the PEs to determine the active/standby status of the PEs.
Context
On the EVPN VPWS multi-homing network shown in Figure 3-120, CE1 is multi-
homed to PE1 and PE2, and PE1 and PE2 establish MPLS LDP tunnels with PE3,
allowing CE1 to communicate with CE2. In a multi-homing single-active scenario
where no E-Trunk is configured, to prevent CE1 from receiving duplicate traffic
from both PE1 and PE2, DF election needs to be performed between the PEs to
which CE1 is multi-homed, so that only one of PE1 and PE2 forwards multicast
traffic.

(2020-10-09)
Figure 3-120 Networking diagram for configuring MPLS E-Line
Procedure
Step 2 Run evpn
Step 3 Run vpws-df-election type service-id
Service ID-based DF election is enabled.
Step 4 Run commit
----End
3.2.6.7 (Optional) Configuring FRR

In EVPN VPWS over MPLS multi-homing single-active scenarios, FRR needs to be
configured to prevent traffic loss if the primary PE fails.
Usage Scenario
As shown in Figure 3-121, in the EVPN VPWS over MPLS multi-homing single-
active scenario, a CE is dual-homed to PE1 and PE2 in active-active mode, and PE3
forwards traffic to PE1 and PE2 working in active/standby mode. When PE1 is the
active device, the red path between CE1 and CE2 is the active path, and the blue
path is the standby path. To prevent traffic loss if the active path fails, FRR needs
to be configured.
In normal situations, downstream traffic of PE3 is sent to PE1. The local and
remote FRR function for MAC routes is enabled on PE1 and PE2. If PE1 detects a
fault on the link between itself and CE1, PE1 forwards traffic to PE2 and then to
CE1. Remote FRR is enabled on PE3. When PE3 detects a fault between itself and
PE1, PE3 rapidly switches traffic to PE2 and then sends traffic to CE1, preventing
traffic loss.

(2020-10-09)
Figure 3-121 EVPN VPWS over MPLS networking
Procedure
● Configure the local and remote FRR function for MAC routes on PE1 and PE2.
a. Run system-view

The EVPN VPWS instance view.

c. Run local-remote frr enable
The local and remote FRR function for MAC routes is enabled for the
EVPN VPWS instance.
NOTE
In addition to enabling the local and remote FRR function for MAC routes in the
EVPN VPWS instance view, you can run the local-remote vpws-frr enable
command in the global EVPN configuration view to enable the local and remote
FRR function for MAC routes.
d. Run commit

● Configure remote FRR on PE3.
a. Run system-view

The EVPN VPWS instance view.

c. Run remote frr { enable | disable }
Remote FRR is enabled for the EVPN VPWS instance.

(2020-10-09)
NOTE
In addition to enabling remote FRR in the EVPN VPWS instance view, you can run
the remote vpws-frr enable command in the global EVPN configuration view to
enable remote FRR globally. By default, if the remote frr command is not run in
the EVPN VPWS instance view, the remote frr command configuration in the
global view takes effect. If both the remote frr enable command and the
remote frr command are run in the EVPN VPWS instance view, the later
d. Run commit
----End
3.2.6.8 Verifying the Configuration

After configuring EVPN VPWS over MPLS, check EVPL instance information.
Prerequisites
EVPN VPWS over MPLS has been configured.
Procedure
● Run the display bgp evpn evpl brief command to check brief information
about all EVPL instances.
● Run the display bgp evpn evpl instance-id instance-id command to check
information about a specified EVPL instance.
----End
3.2.7 Configuring an EVPN to Carry Layer 3 Services

On DCI and IP RAN networks, you can configure EVPN functions to carry Layer 3
services.
Usage Scenario
On a traditional network, the BGP/MPLS IP VPN function is used to carry Layer 3
services. To additionally carry Layer 2 services, users have to deploy an L2VPN over
the existing network, which increases deployment and O&M costs. To address this
problem, users can deploy an EVPN to carry Layer 3 services. To additionally carry
Layer 2 services, users only add some EVPN configurations, implementing the
bearer of both Layer 2 and Layer 3 services.
EVPN can replace BGP/MPLS IP VPN in the following scenarios to carry Layer 3
services:
● Intra-AS mutual VPN communication
On the network shown in Figure 3-122, the VPNs at Site 1 and Site 2 need to
communicate with each other through a public MPLS network. To implement
this communication, perform the following configurations:
a. Configure an L3VPN instance on each PE to manage VPN routes.

(2020-10-09)
b. Establish a BGP EVPN peer relationship between the PEs to transmit

EVPN routes carrying VPN routes.
c. Establish an IGP neighbor relationship or BGP peer relationship between
each PE and CE at the access side to mutually transmit VPN routes.
Figure 3-122 Intra-AS mutual VPN communication
● Inter-AS mutual VPN communication

On the network shown in Figure 3-123, the VPNs at Site 1 and Site 2 need to
communicate with each other through two public MPLS networks in different
ASs. To implement this communication, perform the following configurations:
a. Configure an L3VPN instance on each PE to manage VPN routes.
b. Establish IBGP EVPN peer relationships between PEs and ASBRs and an
EBGP EVPN peer relationship between the ASBRs to transmit EVPN routes
carrying VPN routes between the PEs.
each PE and CE at the access side to mutually transmit VPN routes.
Figure 3-123 Inter-AS mutual VPN communication
● DCI network
The EVPN function applies to traditional DCs that interconnect through a DCI
network. On the network shown in Figure 3-124, DC-GWs and DCI-PEs are
separately deployed. The DCI-PEs consider the connected DC-GWs as CEs,
receive VM IP routes from the DCs through a routing protocol, and save and
maintain the received routes. Deploying an EVPN over the DCI backbone
network allows VM IP routes to be transmitted between DCs, implementing
inter-DC VM communication. To implement this communication, perform the
following configurations:
a. Configure an L3VPN instance on each PE to manage VM IP routes.
b. Establish an IBGP EVPN peer relationship between the PEs to transmit
EVPN routes carrying VM IP routes.

(2020-10-09)

each PE and DC-GW to mutually transmit VM IP routes.
Figure 3-124 DCI network
● L2VPN accessing L3VPN

In L2VPN accessing L3VPN scenarios, EVPN can be used as a substitute for
BGP VPNv4 to function as the control plane of an L3VPN. For details about
the method of configuring the L2VPN and splicing devices, see L2VPN
Accessing L3VPN Configuration. For details about the method of configuring
the L3VPN, see the corresponding information in this section.
Before configuring an EVPN to carry Layer 3 services, ensure Layer 3 route
reachability on the IPv4 network.
3.2.7.1 Configuring an L3VPN Instance

You can configure an L3VPN instance to store and manage received VPN routes or
VM routes.
Procedure
Step 2 Create an L3VPN instance on each device.

(2020-10-09)
address family.
advertised.
address family.

(2020-10-09)
address family.
advertised.
Step 3 Run interface interface-type interface-number.subinterface-number
An Ethernet sub-interface is created, and the Ethernet sub-interface view is
displayed.
Step 4 (Optional) Run vlan-type dot1q vlan-id
A VLAN to be associated with the Ethernet sub-interface is specified, and the
VLAN encapsulation type is set.
The Ethernet sub-interface is bound to the L3VPN instance.
Step 6 (Optional) Run ipv6 enable
Step 7 Run ip address ip-address { mask | mask-length } or ipv6 address { ipv6-address
prefix-length | ipv6-address/prefix-length }
An IPv4/IPv6 address is configured for the Ethernet sub-interface.
Step 8 Run commit
----End
3.2.7.2 Configuring BGP EVPN Peer Relationships

You can configure BGP EVPN peer relationships between PEs or between PEs and
ASBRs as required to mutually transmit EVPN routes between the PEs.
Additionally, you can configure BGP RRs to minimize the number of BGP EVPN
peer relationships, saving network resources.
Procedure
● Configure BGP EVPN peers.
NOTE
If a BGP RR needs to be configured on the network, establish BGP EVPN peer

relationships between all the PEs and the RR.

(2020-10-09)
b. Run peer ipv4-address as-number { as-number-plain | as-number-dot }
The remote PE is specified as the BGP peer.

c. (Optional) Run peer ipv4-address connect-interface interface-type
interface-number [ ipv4-source-address ]
A source interface and a source IP address are specified to set up a TCP
connection between the BGP peers.
NOTE
When loopback interfaces are used to establish a BGP connection, it is

recommended that the peer connect-interface command be run on both ends
to ensure correct connection. If this command is run on only one end, the BGP
connection may fail to be established.
d. (Optional) Run peer ipv4-address ebgp-max-hop [ hop-count ]
The maximum number of hops allowable is set for an EBGP EVPN

connection.
Generally, EBGP EVPN peers are directly connected. If they are not directly
connected, run the peer ebgp-max-hop command to allow the EBGP
EVPN peers to establish a multi-hop TCP connection.
NOTE
If loopback interfaces are used for an EBGP EVPN connection, the peer ebgp-
max-hop command must be run, with the hop-count value greater than or equal
to 2. If this configuration is absent, the EBGP EVPN connection fails to be
established.
e. Run ipv4-family vpn-instance vpn-instance-name or ipv6-family vpn-

f. Run import-route { direct | isis process-id | ospf process-id | rip process-
id | static | ospfv3 process-id | ripng process-id } [ med med | route-
policy route-policy-name ] *
The device is enabled to import non-BGP routing protocol routes into the
BGP-VPN instance IPv4/IPv6 address family. To advertise host IP routes,
only enable the device to import direct routes. To advertise the routes of
the network segment where a host resides, configure a dynamic routing
protocol (such as OSPF) to advertise the network segment routes. Then
enable the device to import routes of the configured routing protocol.
g. Run advertise l2vpn evpn
The BGP device is enabled to advertise IP prefix routes to the BGP peer.
This configuration allows the BGP device to advertise both host IP routes
and routes of the network segment where the host resides.
h. Run quit
Exit from the BGP-VPN instance IPv4/IPv6 address family view.

i. Run l2vpn-family evpn

(2020-10-09)
j. Run peer { ipv4-address | group-name } enable
The local BGP device is enabled to exchange EVPN routes with a peer or
peer group.
k. Run quit
Exit from the BGP view.

l. Run commit

● (Optional) Configure an RR. To minimize the number of BGP EVPN peers on
the network, deploy an RR so that the PEs establish BGP EVPN peer
relationships only with the RR.

b. Run l2vpn-family evpn

c. Run peer { ipv4-address | group-name } reflect-client
The local device is configured as an RR, and a peer or peer group is

specified as the RR client.
The router where the peer reflect-client command is run functions as

the RR, and the specified peer or peer group functions as a client.
d. (Optional) Run undo reflect between-clients
If the clients of an RR have established full-mesh connections with each

other, run the undo reflect between-clients command to disable route
reflection between clients through the RR to reduce the link cost. The
undo reflect between-clients command applies only to RRs.
e. (Optional) Run reflector cluster-id cluster-id
If a cluster has multiple RRs, run this command to set the same cluster ID
The reflector cluster-id command applies only to RRs.

f. Run commit
----End
3.2.7.3 Configuring Route Exchange Between a PE and an Access-side Device

PEs and access-side devices can communicate through BGP, static routes
(including default routes), or IGP. Configure route exchange between a PE and an
access-side device according to your network plan.

(2020-10-09)
Procedure
Step 1 Configure a dynamic routing protocol or static routes. For configuration details,
see Configuring Route Exchange Between PEs and CEs or Configuring Route
Exchange Between PEs and CEs (IPv6).
----End
3.2.7.4 (Optional) Re-Encapsulating IRB (v6) Routes into the desired Routes
If you want to convert the IRB routes carrying the network segment address of a
tenant host that are received by a device into host IP prefix routes or ARP routes,
or convert the IRBv6 routes carrying the IPv6 network segment address of a
tenant host that are received by a device into host IPv6 prefix routes or ND routes,
you must enable the device to re-encapsulate IRB or IRBv6 routes into the desired
routes.
Procedure
Step 2 Run evpn
The global EVPN configuration view is created and displayed.
Step 3 Run irb-reoriginated compatible
The device is enabled to re-encapsulate IRB routes into IP prefix routes and ARP
routes, or re-encapsulate IRBv6 routes into IPv6 prefix routes and ND routes.
Step 4 Run commit
----End
3.2.7.5 Verifying the Configuration of an EVPN to Carry Layer 3 Services

After configuring an EVPN to carry Layer 3 services, check the configurations.
Prerequisites
EVPN functions have been configured.
Procedure
information about BGP EVPN routes.
ipv6 routing-table vpn-instance vpn-instance-name command on the local
PE to check information about VPN routes received from the remote PE.
----End

(2020-10-09)
3.2.8 Splicing a Common L3VPN with an EVPN L3VPN

When an L3VPN is being reconstructed into an EVPN L3VPN, co-existence of the
EVPN L3VPN and L3VPN occurs. To prevent network reconstruction from
compromising communication, configure splicing between L3VPN and EVPN
L3VPN so that the EVPN L3VPN and L3VPN can communicate with each other.
Context
On the network shown in Figure 3-125, an L3VPN is already deployed. If a user
wants to deploy an EVPN L3VPN over the network, co-existence of the EVPN
L3VPN and L3VPN occurs during reconstruction. To ensure communication
between the two VPNs, the user must configure splicing between L3VPN and
EVPN L3VPN on NPE1.
Figure 3-125 Splicing between L3VPN and EVPN L3VPN
Before configuring splicing between L3VPN and EVPN L3VPN, complete the
following tasks:
● Configure basic MPLS functions on the UPE, NPE1, and NPE2.

● Configure an IGP on the UPE, NPE1, and NPE2 to implement route
reachability.
● Configure EVPN instances in BD mode on NPE1 and NPE2. For configuration
details, see 3.2.4.5 Establishing a BGP EVPN Peer Relationships.
● Configure an L3VPN between NPE1 and the UPE. For configuration details,
see Configuring a Basic BGP/MPLS IP VPN or Configuring a Basic BGP/MPLS
IPv6 VPN.
Procedure
● Configure NPE1 and NPE2 to generate and advertise IP prefix routes.
For IPv4 services, perform the following configurations.


(2020-10-09)
b. Run ipv4-family
The IPv4 address family is enabled for the VPN instance, and the VPN
instance IPv4 address family view is displayed.
c. Run vpn-target vpn-target &<1-8> [ both | export-extcommunity |
import-extcommunity ] evpn
VPN targets are configured for the VPN instance IPv4 address family to
mutually import routes with the local EVPN instance.
d. Run evpn mpls routing-enable
EVPN is enabled to generate and advertise IP prefix routes and IRB
routes.
e. (Optional) Run tnl-policy policy-name evpn
EVPN routes that can be imported into the VPN instance IPv4 address
family are associated with a tunnel policy.
f. Run quit
Exit from the VPN instance IPv4 address family view.
g. Run quit
Exit from the VPN instance view.
h. Run commit
For IPv6 services, perform the following configurations.
b. Run ipv6-family
c. Run vpn-target vpn-target &<1-8> [ both | export-extcommunity |
import-extcommunity ] evpn
d. Run evpn mpls routing-enable
EVPN is enabled to generate and advertise IP prefix routes and IRB
routes.
e. (Optional) Run tnl-policy policy-name evpn
EVPN routes that can be imported into the VPN instance IPv6 address
family are associated with a tunnel policy.
f. Run quit
g. Run quit
h. Run commit
● Configure NPE1 to advertise routes regenerated by the EVPN address family
to the BGP VPNv4/VPNv6 peer (UPE).

(2020-10-09)

b. Run l2vpn-family evpn
c. Run peer { ipv4-address | group-name } import reoriginate
The BGP device is enabled to add the regeneration flag to the routes
received from the BGP EVPN peer.
d. Run quit
Return to the BGP view.
e. Run ipv4-family vpnv4 or ipv6-family vpnv6
The BGP-VPNv4/VPNv6 address family view is displayed.
f. Run peer { ipv4-address | group-name } reflect-client
NPE1 is configured as an RR, and the UPE is specified as the RR client to
reflect BGP VPNv4/VPNv6 routes into which EVPN routes are re-
encapsulated.
g. Run peer { ipv4-address | group-name } advertise route-reoriginated
evpn { mac-ip | ip | mac-ipv6 | ipv6 }
NPE1 is configured to advertise routes regenerated by the EVPN address
family to the BGP VPNv4/VPNv6 peer (UPE).
After the peer { ipv4-address | group-name } advertise route-
reoriginated evpn { mac-ip | ip | mac-ipv6 | ipv6 } command is run,
NPE1 uses MPLS to re-encapsulate the EVPN routes received from NPE2
into BGP VPNv4/VPNv6 routes and then sends them to the UPE.
h. Run quit
i. Run quit
j. Run commit
● Configure NPE1 to advertise routes regenerated by the VPNv4/VPNv6 address
family to the BGP EVPN peer (NPE2).
b. Run ipv4-family vpnv4 or ipv6-family vpnv6
c. Run peer { ipv4-address | group-name } import reoriginate
The BGP device is enabled to add the regeneration flag to the routes
received from the BGP VPNv4/VPNv6 peer.
d. Run quit

(2020-10-09)
e. Run l2vpn-family evpn

f. Run peer { ipv4-address | group-name } reflect-client
NPE1 is configured as an RR, and NPE2 is specified as the RR client to
reflect BGP EVPN routes into which BGP VPNv4/VPNv6 routes are re-
encapsulated.
g. Run peer { ipv4-address | group-name } advertise route-reoriginated
{ vpnv4 | vpnv6 }
NPE1 is configured to advertise routes regenerated by the VPNv4/VPNv6
address family to the BGP EVPN peer (NPE2).
After the peer { ipv4-address | group-name } advertise route-
reoriginated { vpnv4 | vpnv6 } command is run, NPE1 re-encapsulates
the MPLS-encapsulated VPNv4/VPNv6 routes received from the UPE into
EVPN routes and then sends them to NPE2.
h. Run quit
i. Run ipv4-family vpn-instance vpn-instance-name or ipv6-family vpn-
j. Run advertise l2vpn evpn
The BGP device is enabled to advertise IP prefix routes to the BGP peer.
This configuration allows the BGP device to advertise both host IP routes
and routes of the network segment where the host resides.
k. Run quit
l. Run quit
m. Run commit
----End

● Run the display bgp evpn all routing-table command on NPE2 to check
information about EVPN routes received from the UPE.
● Run the display ip routing-table vpn-instance vpn-instance-name command
on NPE2 or the UPE to check information about VPN routes received from
each other.

(2020-10-09)
3.2.9 Splicing a VPLS in PW Redundancy Mode with an

Anycast VXLAN in an EVPN Active-Active Scenario
This section describes how to configure splicing to enable communication between
an anycast VXLAN in an EVPN active-active scenario and a VPLS in PW
redundancy mode configured.
Context
On the network shown in Figure 3-126, PE1 and PE2 are egress devices of the
data center network. PE1 and PE2 work in active-active mode with a bypass
VXLAN tunnel deployed between them. They use an anycast VTEP address to
establish a VXLAN tunnel with the TOR. In this manner, PE1, PE2, and the TOR can
communicate with each other. PE1 and PE2 communicate with the external
network through the VPLS network, on which PW redundancy is configured.
Specifically, the PE-AGG connects to PE1 and PE2 through primary and secondary
PWs, respectively.
Figure 3-126 Splicing a VPLS in PW Redundancy Mode with an Anycast VXLAN in

an EVPN Active-Active Scenario
To implement the splicing, perform the following configurations:

● Configure VPLS PW redundancy on the PE-AGG, PE1, and PE2.
● Configure the dynamic VXLAN active-active scenario on PE1 and PE2.
● Configure the PWs connecting to the VPLS network to work in AC mode on
PE1 and PE2. This configuration is required on the EVPN anycast VXLAN
active-active network to prevent split horizon, which is configured on PE1 and
PE2, from interrupting traffic. For details, see Procedure.
Procedure

(2020-10-09)
Step 2 Run vsi vsi-name bd-mode
A VSI in BD mode is created.
Step 3 Run pwsignal ldp
LDP is configured as the PW signaling protocol, and the VSI-LDP view is displayed.
Step 4 Run vsi-id vsi-id
A VSI ID is configured.
Step 5 Run peer peer-address [ negotiation-vc-id vc-id ] [ encapsulation { ethernet |

vlan } ] [ tnl-policy policy-name ] ac-mode
A PW is set to AC mode.
Step 6 Run commit
----End
Verifying the Configuration of Splicing a Network with PW Redundancy and

an EVPN Anycast VXLAN Active-Active Network
After configuring the splicing function, verify the configuration. For details, see
Verifying the VXLAN Configuration and Verifying the VPLS PW Redundancy
Configuration.
3.2.10 Configuring EVPN E-LAN over mLDP P2MP Tunnels

An EVPN can carry multicast services. To reduce redundant traffic and conserve
bandwidth resources, you can configure EVPN to use an mLDP P2MP tunnel for
service transmission.
Usage Scenario
Multicast services, such as IPTV, multimedia conferencing, and Massive Multiplayer
Online Role Playing Game (MMORPG) services, are becoming more and more
common. As a result, the number of multicast services carried over EVPNs is
growing. On the network shown in Figure 3-127, PE1 is the root node, and PE2
and PE3 are leaf nodes. The access side is the multicast source and the receiver. By
default, an EVPN sends multicast service traffic from PE1 to PE2 and PE3 by
means of ingress replication. Specifically, PE1 replicates a multicast packet into
two copies and sends them to the P. The P then sends one copy to PE2 and the
other copy to PE3. For each additional receiver, an additional copy of the multicast
packet is sent. This increases the volume of traffic on the link between PE1 and
the P, consuming bandwidth resources. To conserve bandwidth resources, you can
configure EVPN to use an mLDP P2MP tunnel to transmit multicast services. After
the configuration is complete, PE1 sends only one copy of multicast traffic to the
P. The P replicates the multicast traffic into copies and sends them to the leaf
nodes, reducing the volume of traffic between PE1 and P.

(2020-10-09)
Figure 3-127 Carrying multicast services over an EVPN
Before configuring EVPN E-LAN over mLDP P2MP tunnels, complete the following
tasks:
● Configure BD-based EVPN functions over the EVPN.
Procedure
● Perform the following steps on the root node:
a. Run system-view
The view of a BD-EVPN instance is displayed.
c. Run inclusive-provider-tunnel
The EVI I-PMSI view is created and displayed.
d. Run root
The current device is specified as the root node for the multicast EVPN,
and the EVI I-PMSI root view is displayed.
e. Run mldp p2mp
An mLDP P2MP tunnel is specified for the BD-EVPN instance to carry
multicast services, and the EVI I-PMSI root mLDP view is displayed.
f. Run root-ip ip-address
An IP address is specified for the root node of the mLDP P2MP tunnel.
g. (Optional) Run data-delay-time delay-time
A hold-off time for the mLDP P2MP tunnel to go Up is set. If you want
the mLDP P2MP tunnel to go Up after all leaf nodes are configured, run
this command to set a hold-off time for the mLDP P2MP tunnel to go Up.

(2020-10-09)
h. (Optional) Run data-switch disable
Multicast traffic is disabled from being forwarded through a P2P tunnel if

the mLDP P2MP tunnel goes Down.
Before an mLDP P2MP tunnel carries multicast services, you can establish
a bypass tunnel to provide mLDP P2MP FRR protection for the primary
mLDP P2MP tunnel. The bypass tunnel is a P2P tunnel. If both the
primary P2MP tunnel and bypass P2P tunnel go Down, the backup mLDP
P2MP tunnel carries multicast services. After the bypass P2P tunnel for
the primary mLDP P2MP tunnel goes Up, the P2P tunnel carries multicast
services. Because the primary mLDP P2MP tunnel remains Down, a leaf
node also receives multicast traffic from the backup mLDP P2MP tunnel.
As a result, the leaf node receives and forwards duplicate copies of traffic.
To prevent this issue, run this command to disable multicast traffic from
being forwarded through a P2P tunnel when the mLDP P2MP tunnel goes
Down.
i. Run commit

● Perform the following steps on each leaf node:
a. Run system-view


c. Run inclusive-provider-tunnel
The EVI I-PMSI view is created and displayed.

d. Run leaf
The current device is specified as a leaf node for the multicast EVPN.
e. (Optional) Run root-ip root-ip use-next-hop
In a cross-IGP-area EVPN E-LAN scenario, you must run this command on

a leaf node to configure the next hop of a BGP EVPN route as the root
node IP address, which is used as the IP address of the ABR on the area
border. Without this configuration, EVPN cannot use an mLDP P2MP
tunnel for service transmission.
f. Run commit
----End
Verifying the Configuration of EVPN to Use an mLDP P2MP Tunnel for

Service Transmission
Run the display evpn vpn-instance name vpn-instance-name inclusive-provider-
tunnel verbose command to check information about EVPN using an mLDP P2MP

(2020-10-09)
3.2.11 Configuring an EVPN Route-Policy

An EVPN route-policy can be configured to control EVPN route receiving and
advertisement.
Context
An EVPN route-policy is used to match specified EVPN route information or some
attributes in EVPN route information and to change these attributes as required.
In addition, an EVPN route-policy can be deployed to control the routing table
size, thereby conserving system resources.
A route-policy can consist of multiple nodes, and each node can comprise the
following clauses:
● if-match clause
Defines the matching rules that EVPN routes meet. The matching objects are
some attributes of the EVPN routes.
● apply clause
Specifies actions. Specifically, configuration commands are run after a route
satisfies the matching rules specified by the if-match clauses. The apply
clauses can change some attributes of EVPN routes.
After a route-policy is created, apply the route-policy to EVPN or L3VPN to make it
take effect.
Procedure
● Create a route-policy.
a. Run system-view
b. Run route-policy route-policy-name { permit | deny } node node
A route-policy node is created, and the route-policy view is displayed.
c. Run commit
● Configure filter criteria (if-match clause).

(2020-10-09)
Filter Criteria Configuration Procedure
Filtering by VNI 1. Run the system-view command to enter the

system view.
2. Run the filter-list vni vni-list-name command to
create a VNI list.
3. Run the vni vni-id command to configure a VNI
ID.
4. Run the quit command to return to the system
view.
5. Run the route-policy route-policy-name { permit
| deny } node node to enter the route-policy view.
6. Configure matching rules based on VNI lists:
● Run the if-match l2vni l2vni-list-name
command to configure a matching rule based
on a Layer 2 VNI list.
● Run the if-match l3vni l3vni-list-name
command to configure a matching rule based
on a Layer 3 VNI list.
7. Run the commit command to commit the
configuration.
Filtering by MPLS 1. Run the system-view command to enter the

label system view.
3. Run the if-match { mpls-label | mpls-label2 } *
command to configure a matching rule based on
an MPLS label.
configuration.
Filtering by route 1. Run the system-view command to enter the

type system view.
3. Run the if-match route-type evpn { ad | es |
inclusive | join | leave | mac | prefix | smet } *
a route type.
configuration.

(2020-10-09)
Filtering by 1. Run the system-view command to enter the

Ethernet tag system view.
2. Run the filter-list eth-tag eth-tag-list command
to create an Ethernet tag list.
3. Run the eth-tag ethtag-value command to
configure an Ethernet tag of the Ethernet tag list.
view.
6. Run the if-match eth-tag-list eth-tag-list-name
the Ethernet tag.
configuration.
Filtering by MAC 1. Run the system-view command to enter the

address system view.
2. Run the filter-list mac mac-list-name command
to create a MAC address list.
3. Run the mac mac-address command to configure
MAC addresses in the MAC address list.
view.
6. Run the if-match mac-list mac-list-name
the MAC address list.
configuration.

(2020-10-09)
Filtering by 1. Run the system-view command to enter the

encapsulation system view.
extended 2. Configure a filter for encapsulation extended
community community attributes.
attribute
● Run the ip extcommunity-list encapsulation
basic encapsulation-name [ index index-
value ] { permit | deny } { encap-value } &
<1-16> command to create a filter for basic
encapsulation extended community attributes.
● Run the ip extcommunity-list encapsulation
advanced encapsulation-name [ index index-
value ] { permit | deny } encap-value regular
command to create a filter for advanced
encapsulation extended community attributes.
NOTE
In an EVPN VXLAN scenario, EVPN routes carry the
VXLAN-encapsulated extended community attributes.
You can set encap-value to 0:8 to filter the EVPN routes
in this scenario. In an EVPN MPLS scenario, a device may
receive EVPN routes that carry MPLS-encapsulated
extended community attributes. To filter these EVPN
routes, set encap-value to 0:10.
4. Run the if-match extcommunity-list
encapsulation encapsulation-name command to
configure a matching rule based on the extended
community attribute filter.
configuration.
● Configure an apply clause.

(Optional) Configuring an apply Clause helps you add or modify the
attributes of EVPN routes.
● Apply a route-policy.

(2020-10-09)
Usage Scenario Configuration Procedure
Control route 1. Run the system-view command to enter the

receiving and system view.
advertisement 2. Run the bgp { as-number-plain | as-number-dot }
between BGP EVPN command to enter the BGP view.
peers.
3. Run the l2vpn-family evpn command to enter
the BGP-EVPN address family view.
4. Run the peer { group-name | ipv4-address }
route-policy route-policy-name { import |
export } command to configure a route-policy for
the routes received from the BGP EVPN peer
(group) or advertised to the BGP EVPN peer
(group).
configuration.
Control the routes 1. Run the system-view command to enter the

sent by an EVPN system view.
instance through 2. Enter the common EVPN instance view or BD
EVPN or the routes EVPN instance view.
received by an
EVPN instance ● Run the evpn vpn-instance vpn-instance-name
through BGP EVPN. command to create a common EVPN instance
and enter the common EVPN instance view.
● Run the evpn vpn-instance vpn-instance-name
bd-mode command to create a BD EVPN
instance and enter the BD EVPN instance view.
3. Run the import route-policy policy-name
command to associate the EVPN instance with an
import route-policy and apply the route-policy to
the routes imported to the EVPN instance.
4. Run the export route-policy policy-name
command to associate the EVPN instance with an
export route-policy and apply the route-policy to
the routes exported from the EVPN instance.
configuration.

(2020-10-09)
Usage Scenario Configuration Procedure
Control the routes 1. Run the system-view command to enter the

sent by an L3VPN system view.
instance through 2. Run the ip vpn-instance vpn-instance-name
EVPN or the routes command to create a VPN instance and enter the
received by an view of this VPN instance.
L3VPN instance
through BGP EVPN. 3. Run the ipv4-family or ipv6-family command to
enter the IPv4 or IPv6 address family view of the
VPN instance.
4. Run the import route-policy policy-name evpn
command to associate the IPv6 address family of
the VPN instance with an import route-policy to
filter the IPv6 address family routes imported from
the VPN instance through EVPN.
5. Run the export route-policy policy-name evpn
command to associate the IPv6 address family of
the VPN instance with an export route-policy to
filter the IPv6 address family routes that are
exported from the VPN instance and advertised to
EVPN.
configuration.
----End
Result
● Run the display bgp evpn all routing-table command to check the EVPN
route information after the EVPN route-policy is applied.
ipv6 routing-table vpn-instance vpn-instance-name command to check the
VPN IP route information after the EVPN route-policy is applied.
3.2.12 Configuring BGP EVPN Soft Reset

BGP EVPN soft reset allows a device to receive EVPN routes from BGP EVPN peers
again.
Usage Scenario
BGP EVPN soft reset performs a soft reset on BGP EVPN connections, which
triggers BGP EVPN peers to send EVPN routes to a local device without tearing
down the BGP EVPN connections and allows the local device to apply a new
filtering policy and refresh the BGP EVPN routing table.
Before configuring BGP EVPN soft reset, configure EVPN functions.

(2020-10-09)
Procedure
● Run refresh bgp evpn { all | peer-address | group group-name } { export |
import }
BGP EVPN soft reset is configured.
----End
3.2.13 Configuring VLAN-based DF Election

In CE dual-homing networking, to balance the broadcast, unknown unicast, and
multicast (BUM) traffic between the CE and PEs, you can configure virtual local
area network (VLAN)-based designated forwarder (DF) election.
Usage Scenario
In CE dual-homing networking, the following conditions must be met to balance
BUM traffic:
1. An Eth-Trunk sub-interface is bound to an EVPN instance created on each PE.
2. VLAN-based DF election is configured.
For details on how to meet the first condition, see Eth-Trunk Interface
Configuration. This section describes how to configure VLAN-based DF election.
Before configuring VLAN-based DF election, bind an Eth-Trunk sub-interface to an
EVPN instance and configure EVPN Functions.
Perform the following steps on each PE with the EVPN instance created.
Procedure
Step 2 Run evpn
The global EVPN configuration view is created and displayed.
Step 3 Run df-election type vlan
VLAN-based DF election is configured.
Step 4 Run commit
----End

After configuring VLAN-based DF election, run the display evpn vpn-instance
name vpn-instance-name df result command to view the DF election result in the
EVPN instance.

(2020-10-09)
3.2.14 Configuring EVPN Reliability Functions

This section describes how to configure Ethernet VPN (EVPN) reliability. To
improve reliability for an EVPN, you can configure reliability functions.

(2020-10-09)
Reliability Function Scenario
Configuration
Configure a PE to On an EVPN where a CE is dual-homed to PEs, after a

monitor the BGP PE restarts due to a fault or other reasons, traffic may
EVPN peer status. be lost. As shown in Figure 3-128, CE1 is dual-homed to
PE1 and PE2, and PE1 is elected as the primary
designated forwarder (DF). Once PE1 fails, PE2 changes
to be the primary DF and takes over the broadcast,
unknown unicast, and multicast (BUM) traffic. After PE1
recovers, if PE1 establishes a BGP peer relationship with
PE2 before with PE3, PE1 and PE2 send Ethernet
segment (ES) routes to each other. At this time, PE1
becomes the primary DF, and PE2 becomes the backup
DF again. In this case, if PE3 still forwards the BUM
traffic to PE2, the traffic will be discarded. However, if
PE1 establishes a BGP peer relationship with PE3 before
with PE2, PE1 and PE2 both become the primary DFs. In
this case, PE3 forwards the BUM traffic to both PE1 and
PE2, causing CE1 to receive duplicate copies of traffic.
To resolve this issue, configure PE1's interface connected
to CE1 to monitor the BGP EVPN peer status.
This configuration allows PE1 to trigger a timer for
delaying ES route advertisement once PE1 recovers and
PE1's interface connected to CE1 goes up. After the
delay timer is triggered, PE1 monitors the status of its
BGP peers PE2 and PE3. If the BGP peer relationships
both go up before the delay time elapses, PE1 sends ES
routes to PE2 and PE3. If the timer-specified delay
elapses, PE1 sends ES routes only to the peer with which
the BGP peer relationship is up. After PE1 sends ES
routes, PE1 performs DF election based on all received
ES routes.
NOTE
The delay after which ES routes are sent must be set based on
the BGP peer relationship status. If a BGP peer relationship is
not established after the delay elapses, two primary or backup
DFs exist. If two primary DFs exist, duplicate copies of traffic
are sent. If two backup DFs exist, the traffic is discarded.
Figure 3-128 CE dual-homing networking

(2020-10-09)

Configuration
Set a delay after If the PE functioning as the primary DF recovers from a

which ES routes are fault, the traffic on the network side may be dropped
advertised. due to slow connection recovery on the access side. As
shown in Figure 3-129, at least one of PE1 and PE2 is
configured to work in the single-active mode. If PE1
fails, the connection between CE1 and PE1 is
interrupted, and the Ethernet segment identifier (ESI)
configured for the connection to CE1 becomes invalid.
As a result, PE1 becomes the backup DF, and PE2
becomes the primary DF. Traffic is switch from the path
CE2 → PE3 → PE1 → CE1 to the path CE2 → PE3 → PE2
→ CE1. After PE1 recovers, PE1's ESI becomes valid
again, and PE1 generates ES routes immediately for DF
election so that PE1 switches to be the primary DF
rapidly. However, PE1 still fails to establish the
connection to CE1. CE1 has to keep sending traffic to
PE2, causing traffic loss.
To resolve this issue, on PE1's interface connected to
CE1, set a delay after which ES routes are advertised.
This configuration allows PE1 to generate ES routes only
after restoring the communication with the access-side
network.
Figure 3-129 CE dual-homing networking

(2020-10-09)

Configuration
Enable the function In CE dual-homing networking, an AC interface's sub-

that the AC interfaces on the access side are bound to an EVPN
interface influences instance. If an ESI is set on the interface and one of the
DF election on a PE. sub-interfaces goes down due to a fault or some other
reason, the ESI remains valid because the other sub-
interfaces bound to the EVPN instance remain up. As a
result, the PE does not regenerate ES routes to trigger
DF election, which may prevent the BUM traffic from
being forwarded.
To resolve this issue, enable the function that the AC
interface status influences DF election. This
configuration helps check whether the PE has received
the auto discovery (AD) routes from all PEs during DF
election to determine whether these PEs are qualified
for DF election. If a PE has not received the AD routes
from a peer PE, the peer PE cannot participate in DF
election.
Set a delay for a In a scenario where a VLL accesses an EVPN in active-

public-network active mode, when the backup PE restarts, BUM traffic
outbound interface can still be forwarded due to the unstable status. As a
to go up. result, extra packets are sent. To resolve this issue,
configure a delay on all public network outbound
interfaces of the VLL on the backup PE so that the
outbound interfaces can go up only after the delay
elapses. Setting a 5-minute delay for an interface to go
up is recommended.
Configure FRR for In an EVPN active-active or single-active scenario, a CE

MAC ro... is dual-homed to two PEs. After FRR is enabled for MAC
routes on dual-homing PEs, traffic destined for a CE can
be rapidly switched to the link connected to the other PE
if the link between the CE and a PE fails, which ensures
traffic continuity.
NOTE
The configuration described in this section applies to common
EVPN and BD EVPN scenarios. For details about how to
configure FRR in an EVPN VPWS scenario, see Configuring
EVPN VPWS over MPLS.
Before configuring EVPN reliability functions, configure EVPN functions.
Procedure
● Configure a PE to monitor the BGP EVPN peer status.
a. Enter the system view.
system-view

(2020-10-09)
b. Enter the Eth-Trunk interface view.

interface eth-trunk trunk-id
c. Enable the PE to monitor the BGP EVPN peer status.
es track evpn-peer peer-address
To monitor the status of multiple BGP EVPN peers, repeat this step.
d. Commit the configuration.
commit
● Set a delay on the PE, after which ES routes are advertised.
system-view
b. Enter the Eth-Trunk interface view.
interface eth-trunk trunk-id
c. Set the delay in generating Ethernet segment routes.
timer es-recovery interval
The recommended value is 30 seconds.
commit
● Enable the function that the AC interface influences DF election on the PE.
system-view
b. Enter the global EVPN configuration view.
evpn
c. Allow the AC interface status to affect DF election.
df-election ac-influence enable
commit
● Set a delay for a public-network outbound interface to go up.
system-view
b. Enter the interface view.
interface interface-type interface-number
c. Set a hold time, after which the PE responds to an interface up event.
carrier up-hold-time interval
commit
● Configure FRR for MAC routes on dual-homing PEs.

(2020-10-09)
system-view
b. Enter the global EVPN configuration view.
evpn
c. Enable the PE to allow the extended VLAN community attribute to be
carried in local routes before the routes are advertised to peers.
vlan-extend private enable

d. Enable the PE to redirect the received routes carrying the extended VLAN
community attribute.
vlan-extend redirect enable

e. Enable FRR for MAC routes on dual-homing PEs using either of the
following methods:
▪ Global configuration mode: Run the local-remote frr enable

command in the global EVPN configuration view.
▪ EVPN instance-specific configuration mode: Run the local-remote frr

enable command in the EVPN instance or BD EVPN instance view.
By default, the configuration of FRR for MAC routes on dual-homing PEs

in an EVPN instance is the same as that in the global EVPN configuration
view. After FRR for MAC routes on dual-homing PEs is configured in the
EVPN instance view, the configuration in the EVPN instance takes effect.
----End

Run the display current-configuration command to check whether the EVPN
reliability function is successfully configured.
3.2.15 Configuring MAC Duplication Suppression for EVPN

When PEs are interconnected both through network-side and access-side links,
MAC route flapping may occur. To resolve this issue, you can configure MAC
duplication suppression.
Usage Scenario
On the EVPN E-LAN shown in Figure 3-130, the two PEs may be interconnected
both through network-side and access-side links. If this is the case, a BUM traffic
loop and MAC route flapping both occur, preventing devices from working
properly. By default, MAC duplication suppression is enabled on a device. Also by
default, the system checks the number of times a MAC entry flaps within a
detection period. If the number of MAC flaps exceeds the upper threshold, the
system considers MAC route flapping to be occurring on the network and
consequently suppresses the flapping MAC routes. The suppressed MAC routes
cannot be sent to a remote PE through a BGP EVPN peer relationship.

(2020-10-09)
Figure 3-130 MAC duplication suppression for EVPN
If you want to modify parameter configurations related to MAC duplication

suppression, perform the following procedure.
Before configuring MAC duplication suppression, 3.2.5 Configuring BD-EVPN
Functions or 3.2.4 Configuring Common EVPN Functions must have been
performed on the network.
Procedure
● Configure MAC duplication suppression for all EVPN instances.
a. Run system-view
b. Run evpn
c. Run mac-duplication
The EVPN-MAC-duplication view is displayed.
d. Run detect loop-times loop-times detect-cycle detect-cycle-time
Loop detection parameters for MAC duplication suppression are
configured, including the detection period and the threshold for the
number of MAC entry flaps within a detection period. The default
detection period is 180s, and the default threshold is 5.
e. Run retry-cycle retry-times
A hold-off time to unsuppress MAC routes is configured.
f. Run commit
● Configure MAC duplication suppression for a specified EVPN instance.
a. Run system-view
b. Run either of the following commands:
▪ evpn vpn-instance vpn-instance-name

(2020-10-09)
The view of an EVPN instance is displayed.
▪ evpn vpn-instance vpn-instance-name bd-mode

c. Run mac-duplication
The EVPN instance MAC-duplication view is displayed.

d. Run detect loop-times loop-times detect-cycle detect-cycle-time
Loop detection parameters for MAC duplication suppression are

configured, including the detection period and the threshold for the
number of MAC entry flaps within a detection period.
e. Run retry-cycle retry-times
A hold-off time to unsuppress MAC routes is configured.

f. Run black-hole-dup-mac [ block-source-interface ]
The flapping MAC routes are set to black-hole MAC routes. If the source
or destination MAC address of the forwarded traffic is the same as the
MAC address of the black-hole MAC route, the traffic is discarded.
The block-source-interface parameter enables AC interface blocking.

This means that, if the traffic comes from a local AC interface and the
source MAC address of the traffic is the same as the MAC address of a
black-hole MAC route, the AC interface is blocked. In this way, a loop can
be removed quickly.
NOTE
Only BD-EVPN instances support AC interface blocking.

To enable AC interface blocking, first enable MAC flapping-based loop detection
in the BD.
g. (Optional) To disable the function of MAC duplication suppression for the
current EVPN instance, run the following steps:
i. Run quit
Return the EVPN instance or BD-EVPN instance view.
ii. Run mac-duplication disable
The function of MAC duplication suppression for the current EVPN
instance is disabled.
h. Run commit
----End
Follow-up Procedure
When a MAC route to a specific MAC address or MAC routes in a specific BD have
stopped flapping and you want to restore them before the configured hold-off
timer expires, run the reset evpn vpn-instance mac-duplication [ bridge-
domain bd-id ] [ mac-address mac-address ] command. This allows you to
manually clear the suppression state of the MAC routes.

(2020-10-09)
Under certain conditions, a MAC route is unsuppressed automatically. For this to

take place, a static MAC address must be configured or an EVPN instance must
receive a MAC address that carries the static flag. The MAC address must be the
same as that of the suppressed MAC route.
Verifying the Configuration of MAC Duplication Suppression

Run the display evpn vpn-instance name vpn-instance-name mac-duplication
[ bridge-domain bd-id ] [ mac-address mac-address ] command to check
information about MAC duplication suppression. The command output shows
parameters related to MAC duplication suppression and information about the
suppressed MAC routes.
3.2.16 Configuring EVPN E-Tree

This section describes how to configure EVPN E-Tree. This function isolates traffic
between different interfaces in the same broadcast domain.
Usage Scenario
As the number of services carried on an EVPN increases, the number of user MAC
addresses managed by the EVPN is also increasing. The user MAC addresses are
flooded on the network through EVPN routes. As a result, all interfaces in the
same broadcast domain can communicate with each other at Layer 2. However,
broadcast, unknown unicast, multicast (BUM), and unicast traffic cannot be
isolated for users who do not need to communicate with each other. To isolate
interfaces that do not need to communicate with each other in the same
broadcast domain, you can deploy the EVPN E-Tree function on the network.
EVPN E-Tree implements the E-Tree model defined by the Metro Ethernet Forum
(MEF) by setting the root or leaf attribute for AC interfaces. An AC interface with
the leaf attribute is a leaf AC interface, and an AC interface with the root attribute
is a root AC interface.
● A leaf AC interface and a root AC interface can send traffic to each other.
However, flows between leaf AC interfaces are isolated from each other.
● A root AC interface can communicate with other root AC interfaces and with
leaf AC interfaces.
Before configuring EVPN E-Tree, 3.2.5 Configuring BD-EVPN Functions or 3.2.4
Configuring Common EVPN Functions has been performed on the network.
Procedure
● Configure EVPN E-Tree for a BD-EVPN.
a. Run system-view


(2020-10-09)
c. Run etree enable
EVPN E-Tree is enabled.

d. Run quit

e. Run interface interface-type interface-number.subnum mode l2
The view of a Layer 2 sub-interface that a BD will be associated with is

displayed.
f. Run bridge-domain bd-id
The Layer 2 sub-interface is added to a bridge domain (BD).

g. Run evpn e-tree-leaf
The leaf attribute is configured for the Layer 2 sub-interface.

h. Run commit

● Configure EVPN E-Tree for a basic EVPN.
a. Run system-view

The view of a EVPN instance is displayed.

c. Run etree enable
EVPN E-Tree is enabled.

d. Run quit

e. Run interface interface-type interface-number
The view of the interface to which a basic EVPN instance will be bound is
displayed.
f. Run evpn binding vpn-instance vpn-instance-name
The interface is bound to the EVPN instance.

g. Run evpn e-tree-leaf
The leaf attribute is configured for the interface.

h. Run commit
----End
Verifying the EVPN E-Tree Configuration

Run the display bgp evpn all routing-table [ ad-route ad-route | mac-route
mac-route ] command to check the leaf attribute carried in EVPN MAC routes.

(2020-10-09)
3.2.17 Configuring EVPN ORF

After EVPN outbound route filtering (ORF) is configured, the BGP-EVPN address
family can filter the routes being advertised to a peer by comparing the export
VPN target (ERT) of the routes with the import VPN target (IRT) of the remote
peer. This reduces network load.
Usage Scenario
The growing number of services over EVPNs has triggered a proliferation of new
users. As a result, BGP-EVPN peers on an EVPN send vast quantities of EVPN
routes to each other. Even if the remote peer does not have an RT-matching EVPN
instance, the local PE still sends it EVPN routes. To reduce network load, each PE
needs to receive only desired routes. If a separate export route policy is configured
for each user, the cost of O&M goes up. To address this issue, EVPN ORF can be
deployed.
After this function is configured, each PE on the EVPN sends the IRT and original
AS number of locally desired routes to the other PEs or BGP EVPN RRs that
function as BGP-EVPN peers. The information is sent through ORF routes. Upon
receipt, the peers construct export route policies based on these routes so that the
local PE only receives the expected routes, which reduces the receiving pressure on
the local PE.
Before configuring EVPN ORF, ensure that one of the following EVPN functions
has been configured: PBB-EVPN, BD-EVPN Functions, Common EVPN Functions,
and EVPN VPWS over MPLS Functions
Procedure
Step 3 Run ipv4-family vpn-target
The BGP-VT address family view is displayed.
Step 4 Run peer ipv4-address enable
ORF route exchange with a specified peer or peer group is enabled.
Step 5 (Optional) Run peer { group-name | ipv4-address } reflect-client
RR is enabled, and the peer is specified as an RR. Even on an EVPN where an RR is
deployed, perform this step on the RR to enable the RR function in the BGP-VT
Step 6 Run quit
Exit from the BGP-VT address family view.

(2020-10-09)

Step 8 Run vpn-orf enable
EVPN ORF is enabled.
Step 9 (Optional) Run peer { ipv4-address | group-name } vpn-orf disable
EVPN ORF is disabled for a specified BGP EVPN peer or peer group.
On a network where EVPN and L3VPN services are both deployed, a PE does not
support EVPN ORF because of running an early version. After an RR establishes
BGP-VT peer relationships with all the PEs on the entire network and EVPN ORF is
enabled on the other PEs and RR, the PE running an early version cannot
exchange EVPN routes with the RR. As a result, EVPN services cannot run properly.
To resolve this issue, run the peer vpn-orf disable command to disable the RR
from filtering routes based on the IRT for the PE running an early version so that
the PE can advertise and receive EVPN routes properly. This ensures that the EVPN
services run properly.
Step 10 Run commit
----End
Verifying the EVPN ORF Configuration

Run the display bgp vpn-target routing-table command to check the routing
information in the BGP-VT address family.
Run the display bgp evpn all routing-table peer peer-address advertised-routes
command to check the information about the advertised routes.
3.2.18 Setting a Delay in Releasing an Obtained Label in a

BGP EVPN FRR Switchover Scenario
After you set a delay in releasing an obtained label in a BGP EVPN FRR switchover
scenario, you can prevent second-time packet loss.
Usage Scenario
As shown in Figure 3-131, Device A and Device D belong to AS100, and Device B,
Device C, Device E, and Device F belong to AS200 in a BGP EVPN FRR switchover
scenario. Device B selects the optimal route that is learned from the EBGP EVPN
peer Device A and the sub-optimal route that is learned from the IBGP EVPN peer
Device E. In normal situations, Device B preferentially selects a labeled BGP route
learned from EBGP EVPN peer Device A and advertises the route to the IBGP EVPN
peer Device C. Device B delivers an incoming label map (ILM) entry and next hop
label forwarding entry (NHLFE), and Device C also delivers an NHLFE entry. If
Device A is restarted due to a fault, Device B withdraws the route learned from
Device A, selects the sub-optimal route learned from IBGP EVPN peer Device E,
and reflects the route to Device C through the RR. Then, Device B releases the
applied label and deletes the ILM entry mapped to the label. If traffic arrives at

(2020-10-09)
Device C before Device C updates the NHLFE entry, Device C still uses this entry to
forward traffic to Device B. Because Device B has released the label and deleted
the ILM entry, packets are lost for the second time.
Figure 3-131 Networking for packet loss during a BGP EVPN FRR switchover
To prevent traffic loss during a BGP EVPN FRR switchover, configure the local
device to delay deleting the ILM entry.
Before setting a delay in releasing an obtained label in a BGP EVPN FRR
switchover scenario, complete the following tasks:
● Configure EVPN or BD EVPN.

● Configure BGP Auto FRR in the BGP-EVPN address family view.
Procedure
Step 4 Run label-free delay delay-value
A delay time in releasing obtained labels is set.
Step 5 Run commit
----End

(2020-10-09)

After setting a delay in releasing an obtained label in a BGP EVPN FRR switchover
scenario, verify the configuration.
Run the display current-configuration command to check the current
configuration.
3.2.19 Splicing a VLL with a Common EVPN E-LAN

Traditional VLL is still used at the aggregation layer of a network, whereas the
core network has evolved into EVPN. To allow communication between different
layers, splicing between VLL and common EVPN must be configured.
Context
As the MAN is evolving into EVPN, a large number of devices at the aggregation
layer still use traditional VLLs, making E2E evolution into EVPN at a time difficult.
However, the core network has evolved into EVPN. To implement communication
between different network layers, VLL splicing common EVPN must be supported.
On the network shown in Figure 3-132, CE1 with two sites attached is connected
to a UPE through a NID (switch). The UPE and NPEs are connected through an
MPLS network at the aggregation layer, and services are carried using a VLL.
NPE1, NPE2, and NPE3 are connected through an MPLS network at the core layer,
and services are carried through an EVPN.
Figure 3-132 Splicing a VLL with a common EVPN E-LAN
● A UPE is dual-homed to NPE1 and NPE2, which improves access reliability.

The UPE establishes the primary and secondary PWs with the master and
slave NPEs, respectively. Traffic is sent through the primary PW, and the UPE
is enabled to receive traffic through both the primary and secondary PWs.
● On NPE1 and NPE2, the VLL is connected to the EVPN through PW VE
interfaces. Specifically, the VLL is configured on the PW VE interfaces, and
EVPN instances are bound to the PW VE sub-interfaces that are configured as
QinQ VLAN tag termination sub-interfaces. In this manner, traffic is imported
to the EVPN instances.
Before splicing a VLL with a common EVPN E-LAN, complete the following tasks:

(2020-10-09)
● Configure interfaces and their IP addresses on the UPE, NPE1, NPE2, and
NPE3.
● Configure an IGP on the UPE, NPE1, NPE2, and NPE3 to implement route
connectivity.
● Configuring master/slave mode of PW redundancy on the UPE.
● Configure EVPN functions on NPE3.
● Configure basic MPLS functions on NPE1, NPE2, and NPE3.
Procedure
Step 1 Configure basic EVPN functions on NPE1 and NPE2.
1. Configure an EVPNinstance
2. Configure an EVPN source address
3. Configure a BGP EVPN peer relationship
Step 2 (Optional) Run evpn access vll convergence separate disable
The EVPN-accessing-VLL coupling flag is enabled.
Step 3 Run mpls l2vpn
MPLS L2VPN is enabled on NPE1 and NPE2.
Step 4 Configure PW VE interfaces and sub-interfaces on NPE1 and NPE2. Bind the VLL to
the PW VE interfaces and bind EVPN instances to the PW VE sub-interfaces.
The PW VE interface view is displayed.
2. Run mpls l2vc { ip-address | pw-template template-name } * vc-id [ tunnel-
policy policy-name | [ control-word | no-control-word ] | [ raw | tagged ] |
access-port | ignore-standby-state ] *
A VPWS connection is created.
3. Run esi esi
An ESI is configured.
4. Run quit
5. Run interface interface-type interface-number [ .subinterface-number ]
The PW VE sub-interface view is displayed.
6. Run encapsulationqinq-termination [ local-switch | rt-protocol ]
The encapsulation type of the sub-interface is set to QinQ VLAN tag
termination.
7. Run qinq termination pe-vid pe-vid [ to high-pe-vid ] ce-vid ce-vid [ to
high-ce-vid ]
The sub-interface is configured as a QinQ VLAN tag termination sub-
interface.

(2020-10-09)
The PW VE sub-interface is bound to an EVPN instance.

9. Run commit
----End

● Run the display evpn vpn-instance [ verbose ] command to view
information about the EVPN instance-bound PW VE sub-interfaces.
● Run the display mpls l2vc [ vc-id | brief | interface interface-type interface-
number | remote-info [ vc-id | unmatch | verbose ] | state { down | up } ]
command to view the VLL-bound PW VE interfaces.
3.2.20 Splicing a VLL with an MPLS EVPN E-Line

The traditional VLL is still used at the aggregation layer of a network, whereas the
layers, VLL splicing MPLS EVPN must be configured.
Context
As the MAN is evolving into EVPN, a large number of devices at the aggregation
layer still use traditional VLLs, making E2E evolution into EVPN at a time difficult.
However, the core network has evolved into EVPN. To implement communication
between different network layers, VLL accessing EVPN must be supported. EVPN-
VPWS services involve the E-Line and E-LAN models. This section describes how to
splice a VLL with an MPLS EVPN E-Line.
On the network shown in Figure 3-133, CE1 with two sites attached is connected
to a UPE through a NID (switch). The UPE and NPEs are connected through an
MPLS network at the aggregation layer, and services are carried using a VLL.
NPE1, NPE2, and NPE3 are connected through an MPLS network at the core layer,
and services are carried through an EVPN.
Figure 3-133 Splicing a VLL with an MPLS EVPN E-Line
● A UPE is dual-homed to NPE1 and NPE2, which improves access reliability.

The UPE establishes the primary and secondary PWs with the master and
slave NPEs, respectively. Traffic is sent through the primary PW, and the UPE
is enabled to receive traffic through both the primary and secondary PWs.

(2020-10-09)
● On NPE1 and NPE2, the VLL is connected to the EVPN through PW VE

interfaces. Specifically, the VLL is configured on the PW VE interfaces, and
EVPN instances are bound to the PW VE sub-interfaces that are configured as
QinQ VLAN tag termination sub-interfaces. In this manner, traffic is imported
to the EVPN instances.
Before splicing a VLL with an MPLS EVPN E-Line, complete the following tasks:
● Configure interfaces and their IP addresses on NPE1, NPE2, NPE3, and the
UPE.
● Configure an IGP on NPE1, NPE2, NPE3, and the UPE to implement Layer 3
reachability.
● Configure PW redundancy in master/slave mode on the UPE.
● Configuring EVPN VPWS over MPLS Functions on NPE1, NPE2, and NPE3.
● Configure basic MPLS LDP functions on NPE1, NPE2, NPE3, and the UPE.
● Configure an EVPL instance on each of NPE1, NPE2, and NPE3.
Perform the following steps on the NPE.
Procedure
Step 2 (Optional) Run evpn access vll convergence separate disable
The EVPN-accessing-VLL coupling flag is enabled.
The view of a main PW-VE interface is displayed.
Step 4 Run mpls l2vc { ip-address | pw-template template-name } * vc-id [ tunnel-

policy policy-name | [ control-word | no-control-word ] | [ raw | tagged ] |
access-port | ignore-standby-state ] *
A dynamic VPWS connection is created.
Step 5 Run esi esi
An ESI is configured.
Step 6 Run quit
Step 7 Run interface interface-type interface-number.subnum
A PW-VE sub-interface is created, and the PW-VE sub-interface view is displayed.

(2020-10-09)
NOTE
Before running this command, ensure that the Layer 2 interface on which the PW-VE sub-
interface is to be created does not have the port link-type dot1q-tunnel command
configuration. If this configuration exists, run the undo port link-type command to delete
the configuration.
In addition to a Layer 2 sub-interface, an Ethernet main interface, Layer 3 sub-interface, or
Eth-Trunk interface can also function as an AC interface.
Step 8 Configure an encapsulation type for the PW-VE sub-interface.

● Configure a QinQ VLAN tag termination sub-interface:
a. Run control-vid vid qinq-termination [ local-switch | rt-protocol ] or
encapsulation qinq-termination [ local-switch | rt-protocol ]
The encapsulation type for a VLAN tag termination sub-interface is
configured to be QinQ.
▪ Specify local-switch so that the QinQ VLAN tag termination sub-

interface supports local switching.
▪ Specify rt-protocol so that the QinQ VLAN tag termination sub-

interface supports routing protocols.
b. Run qinq termination pe-vid pe-vid [ to high-pe-vid ] ce-vid ce-vid [ to
high-ce-vid ] [ vlan-group group-id ]
The VLAN tag termination function is configured for the QinQ VLAN tag
termination sub-interface.
After you specify rt-protocol, the sub-interface terminates double-tagged
packets, and both inner and outer tags must be specific VLAN IDs.
● Configure a dot1q VLAN tag termination sub-interface:
a. Run control-vid vid dot1q-termination [ rt-protocol ] or encapsulation
dot1q-termination [ rt-protocol ]
The encapsulation type for a VLAN tag termination sub-interface is
configured to be dot1q.
Specify rt-protocol so that the dot1q VLAN tag termination sub-interface
supports routing protocols.
b. Run either of the following commands:
▪ To configure a dot1q VLAN tag termination sub-interface, run the

dot1q termination vid low-pe-vid [ to high-pe-vid ] [ vlan-group
group-id ] command.
▪ To configure a dot1q VLAN tag termination sub-interface and a
matching policy for the sub-interface, run the dot1q termination vid
low-pe-vid [ to high-pe-vid ] { 8021p { 8021p-value1 [ to 8021p-
value2 ] } &<1-8> | dscp { dscp-value1 [ to dscp-value2 ] } &<1-10> |
eth-type pppoe | default } [ vlan-group group-id ] command.

(2020-10-09)
NOTE
▪ If you do not configure a matching policy, the dot1q VLAN tag termination
sub-interface terminates the VLAN tags of packets carrying the specified
VLAN ID. If you configure a matching policy, the sub-dot1q VLAN tag
termination sub-interface terminates the VLAN tags of packets carrying the
specified VLAN ID+802.1p value/DSCP value/EthType.
▪ After the dot1q termination vid low-pe-vid [ to high-pe-vid ] [ vlan-group

group-id ] command is run in the Ethernet sub-interface view, the specified
VLAN range belongs to the sub-interface, and any VLAN ID in the VLAN
range cannot be configured together with the 802.1p value/DSCP value/
EthType on other sub-interfaces.
Step 9 Run evpl instance evpl-id

The PW-VE sub-interface is bound to the EVPL instance.
Step 10 Run commit

----End

Run the display bgp evpn all routing-table command on the NPEs and check for
EVI AD routes received by the NPEs.
3.2.21 Splicing VPLS and MPLS EVPN E-LAN

On an IP RAN where VPLS is still used at the access layer but the aggregation
network has evolved to MPLS EVPN, the function of VPLS splicing with MPLS
EVPN E-LAN needs to be enabled.
Context
During IP RAN evolution towards EVPN, if VPLS is still commonly used on access-
layer devices, it is difficult to implement E2E evolution towards MPLS EVPN.
However, the aggregation network has already evolved to MPLS EVPN. In this
case, the IP RAN needs to be configured with VPLS splicing with MPLS EVPN E-
LAN.
As shown in Figure 3-134, CSGs and ASGs are connected over the access network
where the VPLS function is deployed to carry services, and ASGs and RSGs are
connected over the aggregation network where the BD EVPN function is deployed
to carry services. On ASGs, a BD needs to be configured and bound to a BD EVPN
instance and a VSI to achieve VPLS splicing with MPLS EVPN E-LAN.

(2020-10-09)
Figure 3-134 Networking of VPLS splicing with MPLS EVPN E-LAN
Before splicing VPLS with MPLS EVPN E-LAN, complete the following tasks:
● Configure LDP VPLS between CSGs and ASGs.
NOTE
The VSIs for BDs must be configured using the vsi bd-mode command.
● Configure BD EVPN between ASGs and RSGs.
Perform the following operations on each ASG:
Procedure
Step 2 Run evpn
Step 3 Run esi esi
The name of a static ESI instance is configured.
Step 4 Run evpn redundancy-mode single-active
The redundancy mode of the static ESI instance is set to single-active.
Step 5 Run quit
Step 6 Run quit
Step 7 Run vsi vsi-name bd-mode
The VSI view is displayed.
Step 8 Run pwsignal ldp
LDP is configured as the PW signaling protocol, and the VSI-LDP view is displayed.
Step 9 Run vsi-id vsi-id
A VSI ID is configured.

(2020-10-09)
Step 10 Configure a CSG as the UPE.

● Run the peer peer-address [ negotiation-vc-id vc-id ] [ tnl-policy policy-
name ] upe command to specify a CSG as the UPE.
● Run the peer peer-address [ negotiation-vc-id vc-id ] [ tnl-policy policy-
name ] static-npe trans transmit-label recv receive-label command to
configure a static VPLS PW.
Step 11 Run peer peer-address [ negotiation-vc-id vc-id ] pw pw-name
A PW is created, and the VSI-LDP-PW view is displayed.
Step 12 Run esi esi
An ESI is configured for the PW interface.
The value of esi must be consistent with the name of the static ESI instance.
Step 13 (Optional) Run evpn e-tree-leaf
The leaf attributes of the PW interface are configured.
If users do not want the CE1-to-CSG1 traffic to be sent back to CSG2 and then
CE1 over ASG1 and ASG2, users can configure leaf attributes for ASG1 and ASG2
in the VSI-LDP-PW view.
Step 14 Run quit
Return to the VSI-LDP view.
Step 15 Run quit
Return to the VSI view.
Step 16 Run quit
Step 18 Run l2 binding vsi vsi-name [ pw-tag pw-tag-value ]
The BD is bound to a VSI instance.
Step 19 Run evpn binding vpn-instance evpn-name
The BD is bound to an EVPN instance.
Step 20 Run commit
----End

vpn-instance vpn-instance-name } routing-table { ad-route | es-route |
inclusive-route | mac-route | prefix-route } prefix command on an ASG to
view details about BGP EVPN routes, including information about access-side
PWs.

(2020-10-09)

esi ] command on an ASG to view the DF election result of an EVPN instance,
including information about access-side PWs.
3.2.22 Configuring EVPN E-LAN Accessing L3VPN

If point-to-multipoint Layer 2 services are carried using EVPN E-LAN and Layer 3
services are carried using MPLS L3VPN, EVPN E-LAN accessing L3VPN must be
configured on L2-to-L3 devices.
Usage Scenario
On the network shown in Figure 3-135, the first layer is the user-side access
network where Layer 2 services are carried between CPEs and UPEs to implement
VLAN forwarding. The second layer is the aggregation network where services are
carried using EVPN E-LAN and BD-based EVPN MPLS is deployed between UPEs
and NPEs. The third layer is the core network where services are carried using
MPLS L3VPN. In this case, EVPN E-LAN accessing L3VPN must be configured on
NPEs.
Figure 3-135 Networking of EVPN E-LAN accessing L3VPN
Before configuring EVPN E-LAN accessing L3VPN, complete the following tasks:
● Configuring BD-EVPN Functions on UPEs and NPEs.

● Configuring a Basic BGP/MPLS IP VPN or Configuring a Basic BGP/MPLS IPv6
VPN on NPEs.
3.2.22.1 Creating an L2VE Interface

This section describes how to configure an L2VE interface to terminate an EVPN
and bind the L2VE interface to a VE-Group.
Context
Perform the following steps on an NPE:

(2020-10-09)
Procedure
Step 2 Run interface virtual-ethernet interface-number or interface global-ve

interface-number
A VE interface or a global VE interface is created, and the VE interface view or

global VE interface view is displayed.
Step 3 Run ve-group ve-group-id l2-terminat
The VE interface or global VE interface is configured as an L2VE interface to

terminate an EVPN and is bound to a VE-Group.
NOTE
● A VE-Group contains only one L2VE interface and one L3VE interface. Two VE interfaces
in a VE-Group cannot reside on different boards.
● Two global VE interfaces in a VE-Group can reside on different boards.
Step 4 Run commit
----End

This section describes how to configure an L3VE interface to access an L3VPN and
bind the L3VE interface to a VE-Group.
Context
Procedure
Step 2 Run interface virtual-ethernet interface-number or interface global-ve

interface-number
A VE interface or a global VE interface is created, and the VE interface view or

global VE interface view is displayed.
Step 3 Run ve-group ve-group-id l3-access
The VE interface or global VE interface is configured as an L3VE interface to

access an L3VPN and is bound to a VE-Group.

(2020-10-09)
NOTE
● A VE-Group contains only one L2VE interface and one L3VE interface. Two VE interfaces
in a VE-Group cannot reside on different boards.
Step 4 Run commit
----End
3.2.22.3 (Optional) Configuring MAC Addresses for L2VE and L3VE Interfaces
When the MAC address of an L2VE or L3VE interface conflicts with the MAC
address of another type of interface, you can change the MAC address of the L2VE
or L3VE interface to allow normal communication.
Context
Procedure
Step 2 Run slot slot-id
The slot view is displayed.
Step 3 Run set l2ve-mac mac-address
The MAC address of an L2VE interface is configured.
You can modify the MAC address of an L2VE interface on an NPE if this MAC
address is the same as that of the UPE interface that connects to the NPE. An
L2VE interface has only one MAC address.
Step 4 Run set access-ve-mac mac-addre
The MAC address of an L3VE interface is configured.
When an L2VE interface is in the same BD as a sub-interface of an Eth-Trunk or

portswitch interface and this sub-interface needs to communicate with an L3VE
interface at Layer 3, you can change the MAC address of the L3VE interface to
prevent the packets that are supposed to be sent to the L3VE interface from being
discarded on a Layer 2 interface. This is because both the L3VE interface and the
portswitch or Eth-Trunk interface use a bridge MAC address as their MAC address.
An L3VE interface has only one MAC address.
Step 5 Run commit
----End

(2020-10-09)
3.2.22.4 Adding an L2VE Interface to a BD

You can add an L2VE interface to the BD so that EVPN E-LAN services are
terminated on the L2VE interface.
Context
Procedure
Step 2 Run interface virtual-ethernet interface-number.subinterface-number or

interface global-ve interface-number.subinterface-number
The L2VE sub-interface or global L2VE sub-interface view is displayed.
Step 3 Run encapsulation { dot1q [ vid low-pe-vid [ to high-pe-vid ] ] | untag | qinq

[ vid pe-vid ce-vid { low-ce-vid [ to high-ce-vid ] | default } ] }
An encapsulation type of packets allowed to pass through the Layer 2 sub-

interface is specified.
Step 4 Run rewrite pop { single | double }
The traffic behavior is set to pop so that the Ethernet sub-interface removes VLAN
tags from received packets.
If the received packets each carry a single VLAN tag, specify single.
If the encapsulation type of packets has been set to QinQ, specify double in this
step to remove double VLAN tags from the received packets.
The Layer 2 sub-interface is added to a BD so that the sub-interface can transmit

data packets only through this BD.
Step 6 Run commit
----End
3.2.22.5 Associating an L3VE Interface with a VPN Instance

This section describes how to configure an IP address for an L3VE sub-interface
and bind it to a VPN instance to access L3VPN.
Context

(2020-10-09)
Procedure
Step 2 Run interface virtual-ethernet interface-number.subinterface-number or

interface global-ve interface-number.subinterface-number
The L3VE sub-interface or global L3VE sub-interface view is displayed.
Step 3 Run vlan-type dot1q vlan-id
A VLAN to be associated with the sub-interface is specified, and the VLAN

encapsulation type is set to dot1q.
The sub-interface is bound to a VPN instance.
Step 5 Run ip address ip-address { mask | mask-length }
A private network IP address is configured for the MPLS L3VPN.
Step 6 Run commit
----End
3.2.22.6 Verifying the configuration of EVPN E-LAN accessing L3VPN

After EVPN E-LAN accessing L3VPN is configured, you can view the binding
relationship between VE interfaces and a VE-Group, as well as EVPN instance
information.
Prerequisites
All configurations for EVPN E-LAN accessing L3VPN are complete.
Procedure
Step 1 Run the display virtual-ethernet ve-group [ ve-group-id | slot slot-id ] command
to check the binding relationship between VE interfaces and the VE-Group.
Step 2 Run the display evpn vpn-instance [ name vpn-instance-name ] command to

check EVPN instance information.
----End
3.2.23 Configuring EVPN HVPN to Carry Layer 2 Services

The EVPN HVPN function can be configured as a replacement of HVPLS to carry
Layer 2 services on a hierarchical network.

(2020-10-09)
Context
On an HVPLS-deployed network, if users want to evolve the VPLS function to the
EVPN function, users can deploy the EVPN HVPN function as a replacement of
HVPLS to carry Layer 2 services.
As shown in Figure 3-136, UPEs and SPEs are connected over the access network,
and SPEs and NPEs are connected over the aggregation network. An IGP needs to
be deployed on both the access network and aggregation network to achieve
route communication at each layer. The BD EVPN function needs to be deployed
between neighboring devices. In addition, the EVPN RR function can be deployed
on SPEs to allow CE1 and CE2 to transmit information, such as the MAC address.
Figure 3-136 Networking of configuring EVPN HVPN to carry Layer 2 services
Before configuring EVPN HVPN to carry Layer 2 services, complete the following
tasks:
● Configure BD EVPN between SPEs and NPEs.
Perform the following operations on each SPE to implement the EVPN RR

function:
Procedure
Step 4 Specify a UPE and an RR client.

● Run the peer { ipv4-address | group-name } upe command to configure a
peer as the UPE.
● Specify an RR client.
a. Run the peer { ipv4-address | group-name } reflect-client command to
configure the RR function and specify the UPE as an RR client.

(2020-10-09)
b. Run the peer { ipv4-address | group-name } next-hop-local command to

configure a device to use its own IP address as the next-hop IP address
during route advertisement.
To allow an SPE to use its own IP address as the next-hop IP address
when advertising routes to UPEs and NPEs, run the peer next-hop-local
command on the SPE twice with different parameters specified for UPEs
and NPEs.
Step 5 (Optional) Run apply-label per-nexthop
The next-hop-based label distribution function is enabled for EVPN routes.
In an EVPN HVPN scenario, if an SPE needs to send a large number of EVPN
routes but the MPLS labels are insufficient, next-hop-based label distribution can
be configured on the SPE to conserve MPLS label resources.
NOTICE
After next-hop-based label distribution is enabled or disabled, the label allocated

by the SPE changes, causing packet loss.
Step 6 Run commit

----End
Follow-up Procedure
On NPEs, configure the MAC-based load balancing function to improve network
resource utilization.
1. Run the system-view command to enter the system view.
2. Enter the EVPN instance view or BD-EVPN instance view.
– Run the evpn vpn-instance vpn-instance-name command to enter the
EVPN instance view.
– Run the evpn vpn-instance vpn-instance-name bd-mode command to
enter the BD-EVPN instance view.
3. Run the mac load-balancing command to enable MAC-based load balancing.
4. Run the commit command to commit the configuration.

vpn-instance vpn-instance-name } routing-table { ad-route | es-route |
inclusive-route | mac-route | prefix-route } prefix command on an ASG to
view details about BGP EVPN routes.
3.2.24 Configuring MPLS EVPN Splicing with Static VXLAN

In MetroFabric scenarios deployed with CU separation, MPLS EVPN splicing with
static VXLAN must be deployed on metro edge function (MEF) devices.

(2020-10-09)
Context
In a MetroFabric scenario with CU separation deployed, as shown in Figure 3-137,
MPLS EVPN runs on the metro network, and static VXLAN tunnels are established
between the MEF devices and vBRAS-UPs. Therefore, the MEF1 and MEF2 devices
must support MPLS EVPN splicing with static VXLAN to establish E2E forwarding
path for traffic.
Figure 3-137 Networking of MPLS EVPN splicing with static VXLAN
MPLS EVEPN splicing with static VXLAN supports the following key functions:
● MEF1 and MEF2 learn MAC routes on the static VXLAN tunnel side.
● A VXLAN EVPN peer relationship is established between MEF1 and MEF2.
Both MEF1 and MEF2 can re-originate the MAC routes learned on the static
VXLAN tunnel side and flood the MAC routes through BGP EVPN.
● An MPLS EVPN peer relationship is established between MEF1 and MEF2.
MEF1 and MEF2 flood ES routes to each other and support DF election.
● MEF1 and MEF2 advertise the MAC routes (maybe the re-originated MAC
routes) learned on the static VXLAN tunnel side to MEF3 (the BGP EVPN peer
on the MPLS EVPN side) through EVPN. MAC load balancing is implemented
on MEF3.
● MAC mobility is supported between MEF1 and MEF2.
Before configuring MPLS EVPN splicing with static VXLAN, complete the following
tasks:
● Configure BD EVPN between MEF1 and MEF3 and between MEF2 and MEF3.
Specifically, configure BD-based MPLS EVPN. To allow MEF1 and MEF2 to
implement load balancing, configure the same ESI in the BDs on MEF1 and
MEF2.
● Configure VXLAN tunnels between MEF1, MEF2, and vBRAS-UPs. MEF1 and
MEF2 function as aggregation devices, and vBRAS-UPs function as BRASs.
Currently, only static VXLAN tunnels can be established.

(2020-10-09)
NOTE
MEF1 and MEF2 form the anycast relationship. Therefore, the same source VTEP IP
address must be configured for MEF1 and MEF2.
After the pre-configuration tasks are complete, perform the following operations.
Procedure
Step 1 Configure a BGP EVPN peer relationship between MEF1 and MEF2.
The remote device is specified as the BGP peer.
4. (Optional) Run peer ipv4-address connect-interface interface-type interface-
number [ ipv4-source-address ]
The source interface and source IP address are specified for the TCP
connection to be set up between BGP peers.
NOTE
If loopback interfaces are used to establish a BGP connection, running the peer
connect-interface command on both ends is recommended to ensure the
connectivity. If this command is run on only one end, the BGP connection may fail to
be established.
5. (Optional) Run peer ipv4-address ebgp-max-hop [ hop-count ]
The maximum number of allowed hops is set for an EBGP EVPN connection.
Generally, EBGP EVPN peers are directly connected. If they are not directly
connected, run the peer ebgp-max-hop command to allow the EBGP EVPN
peers to establish a multi-hop TCP connection.
NOTE
If loopback interfaces are used for an EBGP EVPN connection, the peer ebgp-max-
hop command must be run, with the hop-count value greater than or equal to 2. If
this configuration is absent, the EBGP EVPN connection fails to be established.
The function to exchange EVPN routes with a peer or peer group is enabled.
8. Run peer { ipv4-address | group-name } advertise encap-type vxlan
The device is enabled to advertise EVPN routes carrying the VXLAN
encapsulation attribute to peers.
9. (Optional) Run peer { group-name | ipv4-address } route-policy route-policy-
name { import | export }

(2020-10-09)
A route-policy is specified for the routes received from or to be advertised to a

BGP EVPN peer or peer group.
After the route-policy is applied, the routes received from or to be advertised
to a specified BGP EVPN peer or peer group will be filtered, ensuring that only
desired routes are imported or advertised. This configuration helps manage
routes and reduce required routing entries and system resources.
10. (Optional) Run peer { group-name | ipv4-address } next-hop-invariable
The device is enabled to advertise routes with the next hop unchanged to an
EBGP EVPN peer. If an EBGP VPN peer relationship is established between a
spine node and a gateway, run the peer next-hop-invariable command on
the spine node to ensure that the next hop of the routes received by this
gateway is another gateway.
11. (Optional) Run peer { group-name | ipv4-address } mac-limit number
The maximum number of MAC advertisement routes that can be received
from a peer is configured.
If an EVPN instance imports many invalid MAC advertisement routes from
peers and these routes occupy a large proportion of the total MAC
advertisement routes, run the mac-limit command to configure the
maximum number of MAC advertisement routes that can be received from
each peer. If the number of received MAC advertisement routes exceeds the
specified maximum number, the system displays an alarm, instructing users to
check the validity of the MAC advertisement routes received in the EVPN
instance.
Step 2 Configure the function to re-originate EVPN routes between MEF1 and MEF2.
1. Run peer { ipv4-address | group-name } import reoriginate
The function to re-originate the routes received from BGP EVPN peers is
enabled.
2. Run peer { ipv4-address | group-name } advertise route-reoriginated evpn
mac
The function to re-originate MAC routes through EVPN and send the re-
originated MAC routes to a specified BGP EVPN peer is enabled.
3. Run quit
Exit the BGP-EVPN address family view.
4. Run quit
Exit the BGP view.
Step 3 Enable MEF1 and MEF2 to advertise the MAC routes (maybe the re-originated
MAC routes) learned on the static VXLAN tunnel side to the BGP EVPN peer on
the MPLS EVPN side through EVPN.
1. Run evpn
2. Run advertise vxlan-tunnel mac
The device is enabled to advertise the MAC routes on the static VXLAN tunnel
side to the BGP EVPN peers on the MPLS EVPN side through EVPN.

(2020-10-09)
Step 4 Run commit
----End

Run the display bgp evpn all routing-table mac-route [ prefix ] command on
MEF1, MEF2, and MEF3 to view details about EVPN MAC routes.
3.2.25 Splicing a VXLAN EVPN with a VPLS
Usage Scenario
When a DC with an EVPN VXLAN deployed interconnects to an enterprise campus
through an MPLS L2VPN, splicing a VXLAN EVPN and a VPLS must be deployed.
On the network shown in Figure 3-138, the TOR, which is a DC's gateway,
accesses the backbone network through the egress routers PE1 and PE2 on the DC
network. PE3, which is the egress router on the campus network, interconnects to
PE1 and PE2 through the MPLS VPLS network. Splicing VXLAN and VPLS is
configured on PE1 and PE2 to implement communication between the DC and
campus network.
Figure 3-138 Splicing a VXLAN EVPN with a VPLS
Before splicing a VXLAN EVPN with a VPLS, complete the following tasks:
● Configure interfaces and IP addresses for the egress device PE3 on the campus
network, egress devices PE1 and PE2 on the DC network, and the TOR.
● Configure an IGP on PE3, PE1, PE2, and the TOR to implement IP connectivity
on the backbone network.
● Enable MPLS on PE3, PE1, and PE2. Configure MPLS LDP LSPs between PE3
and PE1 and between PE3 and PE2.

(2020-10-09)
3.2.25.1 Creating VSIs and Configuring PW Connections

Before enabling interconnection between PE1, PE2, and PE3 on an MPLS VPLS
network, you must create VSIs and configure PWs on them.
Procedure
● Configure PE1 and PE2.
a. Run system-view
b. Run vsi vsi-name [ static | auto ] bd-mode
c. Run pwsignal { ldp | bgp }
LDP is configured as the VSI signaling protocol, and the VSI-LDP view is
displayed.
d. Run vsi-id vsi-id
An ID is configured for the VSI.
e. Run peer peer-address [ negotiation-vc-id vc-id ] pw pw-name
PE3 is specified as the VSI peer.
f. Run commit
● Configure PE3.
a. Run system-view
b. Run vsi vsi-name [ static | auto ] bd-mode
c. Run pwsignal { ldp | bgp }
The VSI-LDP view is displayed.
d. Run vsi-id vsi-id
An ID is configured for the VSI.
e. Run peer peer-address [ negotiation-vc-id vc-id ] pw pw-name
PE1 and PE2 are specified as the VSI peers of PE3.
f. Run protect-group group-name
A PW protection group is created, and the PW protection group view is
displayed.
g. Run protect-mode pw-redundancy { master | independent }
The PW redundancy mode of the current PW protection group is
specified.
Network protection depends on the VPLS's network's protection solution.
It is recommended that PW redundancy in master mode instead of
independent be configured on PE3.

(2020-10-09)
h. Run peer peer-address [ negotiation-vc-id vc-id ] preference preference-

value
The PWs connected to PE1 and PE2 are added to the PW protection
group, and priorities of the PWs are specified. The smaller the value, the
higher the priority. The PW with a higher priority serves as the primary
PW.
i. Run quit
Exit from the PW protection group view.
j. Run quit
Exit from the VSI-LDP view.
k. Run pw-redundancy mac-withdraw rfc-compatible
PE3 is enabled to instruct the peer PEs to clear the MAC addresses of the
PWs if their primary/secondary status is changed.
When the master/backup status of PE1 and PE2 changes, PE3 performs a
primary/secondary PW switchover. In this case, PE3 must notify PE1 and
PE2 of the current PW status and instruct them to clear the MAC
addresses.
l. Run commit
----End
3.2.25.2 Configuring a VXLAN EVPN

Before enabling interconnection between PE1, PE2, and the TOR, configure basic
EVPN and VXLAN functions on PE1 and PE2, and create EVPN instances and NVE
interfaces.
Procedure
Step 2 Run evpn vpn-instance vpn-instance-name bd-mode
An EVPN instance in BD mode is created, and the EVPN instance view is displayed.
extcommunity ]
VPN targets (RTs) are configured for the EVPN instance.
Step 5 Run quit
Exit from the EVPN instance view.
Step 6 Run interface nve nve-number

(2020-10-09)
The view of a Network Virtualization Edge (NVE) interface is displayed.
Step 7 Run source ip-address
An IP address is configured for the source virtual tunnel end point (VTEP).
Step 8 Run vni vni-id head-end peer-list protocol bgp
An ingress replication list is configured.
Step 9 Run quit
Exit from the NVE interface view.
Step 10 Run commit
----End
3.2.25.3 Establishing BGP Peer Relationships

This section describes how to establish a BGP peer relationship between each of
PE1 and PE2 and the TOR and configure BGP peers.
Procedure
The TOR is specified as the BGP peer.
Step 4 Run peer ipv4-address ebgp-max-hop [ hop-count ]
The maximum number of hops allowed for a BGP peer session is specified.
The source interface for sending BGP messages is specified.
Step 7 Run undo policy vpn-target
The function of filtering received EVPN routes based on RTs is disabled.
The capability to exchange EVPN routes with the specified peer or peer group is
enabled.
Step 9 Run peer { ipv4-address | group-name } advertise encap-type vxlan

(2020-10-09)
The device is configured to advertise EVPN routes carrying the VXLAN

encapsulation attribute to the TOR.
Step 10 Run quit
Step 11 Run commit
----End
3.2.25.4 Binding EVPN Instances and VSIs to BDs

To implement interconnection between an enterprise campus network and a DC,
bind an EVPN instance and a VSI to the same BD created on each of PE1 and PE2.
Procedure
● Configure PE1 and PE2.
a. Run bridge-domain bd-id
b. Run vxlan vni vni-id split-horizon-mode
A VNI is created and associated with the BD, and forwarding in split
horizon mode is enabled.
c. Run evpn binding vpn-instance vpn-instance-name [ bd-tag bd-tag ]
A specified EVPN instance is bound to the BD. By specifying different bd-
tag values, you can bind multiple BDs with different VLANs to the same
EVPN instance and isolate services in the BDs.
d. Run l2 binding vsi vsi-name
A specified VSI is bound to the BD.
NOTE
On a node that splices VXLAN and VPLS, the BD-bound VSI does not support pw-tag,
and the PW configured in the VSI must be in Raw mode rather than in Tag mode.
e. Run quit
f. Run commit
NOTE
● The BD bound to an EVPN instance and a VSI do not support AC interface access.
● A node that splices VXLAN and VPLS can have only one VSI and one EVPN
instance bound to its BD. Specifically, one BD cannot be bound to multiple VSIs or
EVPN instances. Additionally, multiple VSIs or EVPN instances cannot be bound to
the same BD.
● Bind the AC interface to the BD on PE3.

(2020-10-09)
a. Run system-view
c. Run l2 binding vsi vsi-name [ pw-tag pw-tag-value ]
A specified VSI is bound to the BD.
d. Run quit
Exit from the BD view.
e. Run interface interface-type interface-number.subnum mode l2
f. Run bridge-domain bd-id
The Layer 2 sub-interface is bound to the BD.
The Layer 2 sub-interface and the vsi are bound to the same BD.
g. Run quit
Exit from the sub-interface view.
h. Run commit
----End
3.2.25.5 (Optional) Configuring BFD for VPLS PW

Configuring BFD for VPLS PW accelerates PW fault detection, speeding up
switching of upper-layer applications.
Context
On the network shown in Figure 3-139, PE3 is dual-homed to PE1 and PE2, and
an MPLS L2VPN is deployed between the PEs, with PW connections configured. To
accelerate PW fault detection, static BFD for VPLS PW can be configured on PE1,
PE2, and PE3. The configuration allows fast switching of upper-layer applications.
Figure 3-139 Splicing VXLAN and VPLS

(2020-10-09)
Procedure
Step 2 Run bfd
BFD is enabled globally, and the global BFD view is displayed.
Step 3 Run quit
Step 4 Run bfd session-name bind pw vsi vsi-name peer peer-address [ vc-id vc-id ]
[ remote-peer remote-peer-address pw-ttl { auto-calculate | ttl-number } ]
BFD configuration items are created.
Step 5 Run the following commands to configure BFD session discriminators:
● Run the discriminator local discr-value command to set the local
discriminator.
● Run the discriminator remote discr-value command to set the remote
discriminator.
NOTE
The local discriminator on one end must be the remote discriminator on the other end.
Step 6 Run commit

If the status of a PW is Down, the BFD session can be established but cannot go
Up.
NOTE
● You must simultaneously configure or cancel BFD for PW on both PEs. Otherwise, the
PW status on both ends may be inconsistent.
● To modify parameters of a created BFD session, run the min-tx-interval, min-rx-
interval, and detect-multiplier commands as needed.
----End
3.2.25.6 Verifying the Configuration of Splicing a VXLAN EVPN with a VPLS

After configuring splicing a VXLAN EVPN with a VPLS, verify the configuration.
Prerequisites
All configurations of splicing a VXLAN EVPN with a VPLS have been completed.
Procedure
● Check the VPLS configurations.
– Run the display vsi [ name vsi-name ] [ verbose ] command to check
VSI information of the VPLS.

(2020-10-09)
– Run the display vpls connection [ ldp | vsi vsi-name ] [ down | up ]

[ verbose ] command to check VPLS connections.
– Run the display admin-vsi binding [ admin-vsi vsi-name ] command to
check the binding relationship between a management VSI and a service
VSI.
– Run the display vsi { name vsi-name peer-info [ peer-ip-address ] |
peer-info } command to check the PW status of the peer.
– Run the display vsi name vsi-name [ protect-group ] [ verbose |
history ] command to check summary or detailed information about the
PW protection group of a specified VSI, or PW switchover information
about the PW protection group of a specified VSI.
● Check the EVPN and VXLAN configurations.
– Run the display bridge-domain [ binding-info | bd-id [ brief | verbose |
binding-info ] ] command to check BD configurations.
– Run the display evpn vpn-instance [ vpn-instance-name ] command to
– Run the display bgp evpn all routing-table command to check BGP
– Run the display vxlan tunnel [ tunnel-id ] [ verbose ] command to
check VXLAN tunnel information.
3.2.26 Configuring MPLS EVPN E-LAN Option B

In a scenario in which the backbone network spans two ASs, ASBRs need to
advertise BGP-EVPN routes through MP-EBGP.
Usage Scenario
If an ASBR can manage BGP-EVPN routes but there are not enough interfaces for
all inter-AS EVPNs, MPLS EVPN E-LAN Option B can be used. MPLS EVPN E-LAN
Option B requires ASBRs to help to maintain and advertise EVPN routes, and you
do not need to create EVPN instances on the ASBRs. In the basic networking of
inter-AS VPN Option B, an ASBR cannot play other roles, such as the PE or RR, and
an RR is not required in each AS.
On the network shown in Figure 1, the interfaces connected between ASBRs do

not need to be bound to the EVPN. A single-hop MP-EBGP peer relationship is set
up between the ASBRs to transmit all inter-AS EVPN routing information.
Figure 3-140 MPLS EVPN E-LAN Option B networking

(2020-10-09)
Before configuring MPLS EVPN E-LAN Option B, complete the following tasks:
● Configure an IGP for the MPLS backbone network of each AS to ensure IP
connectivity of the backbone network in each AS.
● Configure MPLS and MPLS LDP both globally and per interface on each node
of the MPLS backbone network in each AS and establish an LDP LSP or TE
tunnel between MP-IBGP peers.
● Configure Configuring an EVPN Instance on the PE connected to the CE.
● Configure Configuring an EVPN Source Address on the PE connected to the
CE.
● Configure Binding an Interface to an EVPN Instance on the PE connected to
the CE.
● Configure Configuring an ESI on the PE connected to the CE.
3.2.26.1 Configuring MP-IBGP Between a PE and an ASBR in the Same AS

By introducing extended community attributes into BGP, MP-IBGP can advertise
BGP-EVPN routes between the PE and ASBR.
Procedure
Step 3 Run peer peer-address as-number as-number
The IBGP peer relationship is set up between the PE and ASBR in the same AS.
Step 4 Run peer peer-address connect-interface loopback interface-number
The loopback interface is specified as the outbound interface of the BGP session.
Step 5 Run ipv4-family unicast
Step 6 Run peer peer-address enable
The function to exchange IPv4 routes between the PE and ASBR is enabled.
Step 7 Run quit
The function to exchange EVPN routes between the PE and ASBR is enabled.

(2020-10-09)
Step 10 Run peer ipv4-address esad-route-compatible enable

Enable PE and ASBR to send ES AD routes in the standard format defined in
relevant standards.
Step 11 Run commit
----End
3.2.26.2 Configuring MP-EBGP Between ASBRs in Different ASs

Configuring MP-EBGP Between ASBRs in Different ASs
Context
In inter-AS EVPN Option B, you do not need to create EVPN instances on ASBRs.
The ASBR does not filter the EVPN routes received from the PE in the same AS
based on VPN targets. Instead, it advertises the received routes to the peer ASBR
through MP-EBGP.
Procedure
Step 3 Run ip address ip-address { mask | mask-length }
An IP address is configured for the interface.
Step 4 Run mpls
The MPLS capability is enabled.
Step 5 Run quit
Step 7 Run peer peer-address as-number as-number
The peer ASBR is specified as an EBGP peer.
The function to exchange IPv4 routes with the peer ASBR is enabled.
Step 10 Run quit

(2020-10-09)

Step 12 Run peer ipv4-address enable
The function to exchange EVPN routes with the peer ASBR is enabled.
Step 13 Run peer ipv4-address esad-route-compatible enable
Enable PE and ASBR to send ES AD routes in the standard format defined in
relevant standards.
Step 14 Run commit
----End
3.2.26.3 Configuring ASBRs Not to Filter EVPN Routes Based on VPN Targets
In inter-AS EVPN OptionB mode, ASBRs do not have EVPN instances. If you want
ASBRs to keep received EVPN routes, configure ASBRs not to filter EVPN routes
based on VPN targets.
Context
By default, an ASBR filters the VPN targets of only the received EVPN routes. The
routes are imported into the routing table if they pass the filtration; otherwise,
they are discarded. Therefore, if no VPN instance is configured on the ASBR or no
VPN target is configured for the EVPN instance, the ASBR discards all the received
EVPN routes.
In inter-AS EVPN OptionB mode, the ASBR does not need to store EVPN instance
information, but must store all the EVPN routing information and advertise the
routing information to the peer ASBR. In this situation, the ASBR needs to import
all the received EVPN routes without filtering them based on VPN targets.
Procedure
The system view of the ASBR is displayed.
Step 4 Run undo policy vpn-target
The function to filter EVPN routes based on VPN targets is disabled.
Step 5 Run commit

(2020-10-09)
----End
3.2.26.4 (Optional) Configuring One-Label-per-Next-Hop Label Distribution

on an ASBR
To save label resources on an ASBR, configure one-label-per-next-hop label
allocation on the ASBR. One-label-per-next-hop label allocation on ASBRs and
one-label-per-instance label distribution on PEs must be used together.
Context
In an inter-AS EVPN Option B scenario, after one-label-per-next-hop label
distribution is configured on an ASBR, the ASBR assigns only one label to EVPN
routes that share the same next hop and outgoing label. Compared with on-label-
per-route label distribution, one-label-per-next-hop label distribution significantly
saves label resources.
Perform the following steps on an ASBR:
Procedure
Step 4 Run apply-label per-nexthop
One-label-per-next-hop label distribution is enabled on the ASBR.
NOTICE
After one-label-per-next-hop label distribution is enabled or disabled on an ASBR,
the labels assigned by the ASBR to routes change. As a result, temporary packet
loss may occur.
Step 5 Run commit
----End
3.2.26.5 (Optional) Configuring the Protection Switching Function

A protection switching function, such as link or node protection, can be configured
to provide high availability for an inter-AS EVPN-OptionB network.

(2020-10-09)
Context
On an intra-AS EVPN-OptionB network that has protection switching enabled, if a
link or node fails, traffic switches to a backup path, which implements
uninterrupted traffic transmission.
Procedure
Step 4 Run auto-frr
The BGP Auto fast reroute (FRR) is enabled.
Step 5 (Optional) Run bestroute nexthop-resolved tunnel
Configure BGP EVPN routes that recurse to LSPs to participate in route selection.
Step 6 Run commit
----End
3.2.26.6 (Optional) Configuring BGP-EVPN Route Reflection on an ASBR

When multiple PEs exist in the ASs, you can configure an ASBR as an RR to lower
configuration complexity.
Context
In inter-AS EVPN Option B mode, if multiple PEs exist in an AS, you can configure
an ASBR as an RR to reduce the number of MP-IBGP connections needed between

(2020-10-09)
PEs. Configuring an ASBR as an RR will burden the ASBR. Therefore, it is

recommended that a high-performance device be used as the ASBR. On the
network shown in Figure 1, ASBR1 is configured as an RR so that PE1 and PE2 do
not need to set up an MP-IBGP peer relationship.
Procedure
The ASBR1 system view is displayed.
Step 4 Run peer peer-ipv4-address reflect-client
The ASBR is configured as an RR, and the PE is configured as a client. If you need
to configure multiple PEs as clients, repeatedly run this command.
Step 5 Run peer peer-ipv4-address next-hop-local
The ASBR is configured to change the next hop address of a route to the device's
own IP address before the device advertises the route to an IBGP peer.
Step 6 (Optional) Run rr-filter extended-list-number
A reflection policy is configured for the RR. Only IBGP routes whose VPN targets
meet the matching rules can be reflected. This allows load balancing among RRs.
Step 7 (Optional) Run rr-filter extended-list-number
A reflection policy is configured for the RR.
Step 8 (Optional) Run reflect change-path-attribute
You can enable the RR to modify BGP route attributes using an export policy.
NOTE
After the reflect change-path-attribute command is run on the RR

● Under BGP-EVPN address family view, peer route-policy export command takes
precedence over the peer next-hop-invariable command.
● Under BGP-EVPN address family view, peer next-hop-local command takes precedence
over the peer route-policy export command.

(2020-10-09)
Step 9 Run commit
----End
3.2.26.7 Verifying the Configuration MPLS EVPN E-Lan OptionB

After configuring MPLS EVPN E-LAN OptionB, check the status of all BGP peer
relationships and EVPN routing information on PEs or ASBRs.
Prerequisites
MPLS EVPN E-Lan OptionB has been configured.
Procedure
● Run the display bgp evpn all peer command on the PE or ASBR to check the
status of all BGP peer relationships.
● Run the display bgp evpn all routing-table command on the PE or ASBR to
check information about EVPN routes.
----End
3.2.27 Configuring an EVPN L3VPN HVPN

An EVPN L3VPN hierarchical VPN (HVPN) is a hierarchical EVPN, on which PEs
play different roles and provide different functions. These PEs form a hierarchical
architecture to provide functions that are provided by one PE on a non-hierarchical
VPN. EVPN L3VPN HVPNs lower the performance requirements for PEs.
Usage Scenario
services, needs to evolve to EVPN L3VPN HVPN.
Figure 3-141 shows the basic architecture of an HVPN that consists of the
following device roles:
● UPE: A UPE is a device that is directly connected to a user and is referred to as
an underlayer PE or a user-end PE, therefore shortened as UPE. UPEs provide
access services for users.
● SPE: An SPE is a superstratum PE or service provider-end PE, which is
connected to UPEs and located at the core of a network. An SPE manages
and advertises VPN routes.
● NPE: An NPE is a network provider-end PE that is connected to SPEs and
located at the network side.

(2020-10-09)
Figure 3-141 Basic EVPN L3VPN HVPN architecture
The UPEs and SPE are connected at the access layer. The SPE and NPE are
connected at the aggregation layer. An EVPN L3VPN HVPN can be deployed only
after separate IGPs are deployed at the access and aggregation layers to
implement interworking.
EVPN L3VPN HVPN is classified into EVPN L3VPN HoVPN or EVPN L3VPN H-VPN:
● EVPN L3VPN HoVPN: An SPE advertises only default routes or summarized
routes to UPEs. UPEs do not have specific routes to NPEs and can only send
implemented. An EVPN L3VPN HoVPN can use devices with relatively poor
route management capabilities as UPEs, reducing network deployment costs.
● EVPN L3VPN H-VPN: SPEs advertise specific routes to UPEs. UPEs function as
RR clients to receive the specific routes reflected by SPEs functioning as RRs.
This mechanism facilitates route management and traffic forwarding control.
As L3VPN HoVPN evolves towards EVPN L3VPN HoVPN, the following splicing
scenarios occur:
● Splicing between EVPN L3VPN HoVPN and common L3VPN: EVPN L3VPN
HoVPN is deployed between the UPEs and SPE, and L3VPN is deployed
summarized routes to the UPEs. After receiving specific routes (EVPN routes)
from the UPEs, the SPE encapsulates these routes into VPNv4 routes and
● Splicing between L3VPN HoVPN and EVPN L3VPN: L3VPN HoVPN is deployed
between the UPEs and SPE, and EVPN L3VPN is deployed between the SPE
and NPE. The SPE advertises only default routes or summarized routes to the
UPEs. After receiving specific routes (L3VPN routes) from the UPEs, the SPE
encapsulates these routes into EVPN routes and advertises them to the NPE.
Before configuring an EVPN L3VPN HVPN, complete the following tasks:
Configure an IGP on each network layer (between the UPEs and SPE, and between
the SPE and NPE) to implement interworking. Different IGPs can be deployed at
the access and aggregation layers, or the same IGP with different process IDs can
be deployed at the different layers.

(2020-10-09)
3.2.27.1 Configuring an EVPN L3VPN HoVPN

On an EVPN L3VPN HoVPN, a UPE only needs to obtain a default route from an
SPE. This mechanism isolates routes and reduces the route storage space required
on a UPE.
Context
On an EVPN L3VPN HoVPN, the following configurations must be performed:
1. Create VPN instances on UPE, SPEs, and NPEs and bind the VPN instances to
AC interfaces or bind the IPv6 VPN instances to AC interfaces on the UPEs and
NPEs.
NOTE
According to relevant standards, the VPN instance status obtained from an NMS is Up
only if at least one interface bound to the VPN instance is Up. On an HoVPN, VPN
instances on SPEs are not bound to interfaces. As a result, the VPN instance status
obtained from an NMS is always Down. To solve this problem, run the transit-vpn
command in the VPN instance view or VPN instance IPv4 address family view of an
SPE. Then, the VPN instance status obtained from the NMS is always Up, regardless of
whether the VPN instance is bound to interfaces.
2. Configure BGP-EVPN peer relationships between UPEs and SPEs and between
SPEs and NPEs. For details, see 3.2.4.5 Establishing a BGP EVPN Peer
Relationships.
3. Configure routing protocols for NPEs and UPEs to exchange routes with CEs.
This configuration is similar to configuring PEs and CEs to exchange routes on
a BGP/MPLS VPN. For more information, see Configuring Route Exchange
Between PEs and CEs or Configuring IPv6 Route Exchange Between PEs and
CEs.
4. Configure SPEs to advertise only default or summarized routes to UPEs. For
details, see Procedure.
Procedure
Step 1 Configure an SPE to advertise only default or summarized routes to a UPE.
● Configure the SPE to advertise default routes to the UPE.
a. Run system-view
b. Run ip route-static vpn-instance vpn-instance-name 0.0.0.0 { 0.0.0.0 |
0 } { nexthop-address | interface-type interface-number [ nexthop-
address ] } or ipv6 route-static vpn-instance vpn-instance-name 0::0 0
{ nexthop-ipv6-address | interface-type interface-number [ nexthop-ipv6-
address ] }
A default IPv4/IPv6 static route is created for the VPN instance.
c. Run bgp { as-number-plain | as-number-dot }
d. Run ipv4-family vpn-instance vpn-instance-name or ipv6-family vpn-

(2020-10-09)
e. Run network 0.0.0.0 [ 0.0.0.0 | 0 ] [ route-policy route-policy-

name ]network 0::0 0 [ route-policy route-policy-name ]
The default route is imported to the IPv4/IPv6 VPN instance routing table.
f. Run advertise l2vpn evpn
The SPE is enabled to advertise IP prefix routes.
g. Run quit
Exit from the BGP-VPN instance IPv4 address family view.
h. Run l2vpn-family evpn
i. Run peer { ipv4-address | group-name } upe
The UPE is specified as a lower-level PE of the SPE.
j. Run quit
Exit from the BGP-EVPN address family view.
k. Run quit
l. Run commit
NOTE
Configure a route policy on the NPE to prevent the NPE from receiving default routes.
● Configure the SPE to advertise summarized routes to the UPE.
a. Run system-view
c. Run ipv4-family vpn-instance vpn-instance-name or ipv6-family vpn-
d. Run aggregate ipv4-address { mask | mask-length } [ as-set | attribute-
policy route-policy-name1 | detail-suppressed | origin-policy route-
policy-name2 | suppress-policy route-policy-name3 ] * or aggregate
ipv6-address prefix-length [ as-set | attribute-policy route-policy-name1
| detail-suppressed | origin-policy route-policy-name2 | suppress-policy
route-policy-name3 ] *
A summarized route is created.
e. Run advertise l2vpn evpn
The SPE is enabled to advertise IP prefix routes.
f. Run quit
g. Run l2vpn-family evpn
h. Run peer { ipv4-address | group-name } upe
The UPE is specified as a lower-level PE of the SPE.

(2020-10-09)
i. Run quit
j. Run quit
k. Run commit
Step 2 Configure route next hop modification on the SPE.

1. Run system-view
4. Run peer { ipv4-address | group-name } reflect-client
The UPE is specified as the BGP-EVPN RR to reflect BGP EVPN routes.
5. Run peer { ipv4-address | group-name } next-hop-local
The SPE is configured to use its own IP address as the next hop of routes
when advertising these routes to the NPE.
6. Run commit
----End
3.2.27.2 Configuring an EVPN L3VPN H-VPN

On an EVPN L3VPN H-VPN, SPEs function as route reflectors (RRs), and UPEs and
NPEs function as RR clients. UPEs and NPEs receive specific routes from SPEs.
Context
On an EVPN L3VPN H-VPN, the following configurations must be performed:
1. Create VPN instances on UPE and NPEs and bind the VPN instances to AC
interfaces or bind the IPv6 VPN instances to AC interfaces on the UPEs and
NPEs.
2. Configure BGP-EVPN peer relationships between UPEs and SPEs and between
SPEs and NPEs. For details, see 3.2.4.5 Establishing a BGP EVPN Peer
Relationships.
3. Configure routing protocols for NPEs and UPEs to exchange routes with CEs.
CEs.
4. Configure SPEs as RRs, and specify UPEs and NPEs as RR clients. For details,
see Procedure.

(2020-10-09)
Procedure
The SPE is configured as an RR, and UPEs are specified as its clients.
Step 5 Run peer { ipv4-address | group-name } next-hop-local
The SPE is configured to use its own IP address as the next hop of routes when
advertising these routes.
To enable an SPE to use its own IP address as the next hop of routes when
advertising these routes to UPEs and NPEs, run the peer next-hop-local
command with different parameters specified on the SPE for each UPE and each
NPE.
Step 6 (Optional) Run apply-label per-nexthop
One-label-per-next-hop label distribution is enabled on the SPE.
On an EVPN L3VPN H-VPN, if an SPE needs to send large numbers of EVPN routes
but the MPLS labels are inadequate, configure one-label-per-next-hop label
distribution on the SPE.
NOTICE
After one-label-per-next-hop label distribution is enabled or disabled, the label

allocated by the SPE for a route changes, which results in packet loss.
Step 7 Run commit

----End
3.2.27.3 Splicing an EVPN L3VPN HoVPN with a Common L3VPN

As L3VPN HoVPN evolves towards EVPN L3VPN HoVPN, splicing between EVPN
L3VPN HoVPN and common L3VPN occurs. An EVPN L3VPN HoVPN is deployed
between UPEs and SPEs, and a common L3VPN is deployed between SPEs and
NPEs.
Context
On a network with an EVPN L3VPN HoVPN and a common L3VPN spliced, the
following configurations must be performed:

(2020-10-09)
● Create VPN instances on UPEs and SPEs and bind the VPN instances to AC
interfaces or bind the IPv6 VPN instances to AC interfaces on the UPEs.
NOTE
● For IPv4 services, please configure VPN instances and bind the VPN instances
to AC interfaces on NPEs; For IPv6 services, please Configure IPv6 VPN
instances and bind the IPv6 VPN instances to AC interfaces on NPEs.
● Configure the default static VPN routes on the SPEs. For details, see Creating
IPv4 Static Routes or Creating IPv6 Static Routes.
● For IPv4 services, please configure a BGP VPNv4 peer relationship between
each SPE and NPE. This configuration is similar to configuring a BGP VPNv4
peer relationship between PEs on a BGP/MPLS IPv4 VPN. For more
information, see Establishing MP-IBGP Peer Relationships Between PEs; For
IPv6 services, please configure a BGP VPNv6 peer relationship between each
SPE and NPE. This configuration is similar to configuring a BGP VPNv6 peer
relationship between PEs on a BGP/MPLS IPv6 VPN. For more information, see
Establishing MP-IBGP Peer Relationships Between PEs.
● Configure BGP-EVPN peer relationships between UPEs and SPEs. For details,
see 3.2.4.5 Establishing a BGP EVPN Peer Relationships.
● Configure SPEs to advertise only default or summarized routes to UPEs. For
details, see 3.2.27.1 Configuring an EVPN L3VPN HoVPN.
● Configure routing protocols for NPEs and UPEs to exchange routes with CEs.
CEs.
● Configure SPEs to advertise re-encapsulated VPNv4 routes to NPEs. For
details, see Procedure.
Perform the following steps on an SPE.
Procedure
Step 4 Run peer { ipv4-address | group-name } import reoriginate

(2020-10-09)
The SPE is enabled to add the regeneration flag to the routes received from the
UPE.
Step 5 Run quit
Step 6 Run ipv4-family vpnv4 or ipv6-family vpnv6
Step 7 Run peer { ipv4-address | group-name } advertise route-reoriginated evpn { ip |
ipv6 }
The SPE is configured to re-encapsulate the EVPN routes received from the UPE
into BGP VPNv4/VPNv6 routes and then send them to the NPE.
Step 8 Run commit
----End
3.2.27.4 Splicing an L3VPN HoVPN with an EVPN L3VPN

As L3VPN HoVPN evolves towards EVPN HoVPN, splicing between L3VPN HoVPN
and EVPN L3VPN occurs. An L3VPN HoVPN is deployed between UPEs and SPEs,
and an EVPN L3VPN is deployed between SPEs and NPEs.
Context
On a network with an L3VPN HoVPN and an EVPN L3VPN spliced, the following
configurations must be performed:
● Configure VPN instances on SPEs and NPEs and bind the VPN instances to the
NPE interfaces that connect to CEs. For details, see 3.2.5.5 Creating an
L3VPN Instance and Binding It to a VBDIF Interface.
NOTE
● Configure VPN instances and bind the VPN instances to AC interfaces on
UPEs.
● Configure BGP-EVPN peer relationships between SPEs and NPEs. For details,
see 3.2.4.5 Establishing a BGP EVPN Peer Relationships.
● Configure a BGP VPNv4 peer relationship between each SPE and UPE. This
configuration is similar to configuring a BGP VPNv4 peer relationship between
PEs on a BGP/MPLS VPN. For more information, see Establishing MP-IBGP
Peer Relationships Between PEs.
● Configure routing protocols for NPEs and UPEs to exchange routes with CEs.

(2020-10-09)

Between PEs and CEs.
● Configure SPEs to advertise only default or summarized routes to UPEs.
● Configure SPEs to advertise re-encapsulated EVPN routes to NPEs. For details,
see Procedure.
Perform the following steps on each SPE.
Procedure
Step 3 Run ipv4-family vpnv4
Step 4 Run peer { ipv4-address | group-name } import reoriginate
The SPE is enabled to add the regeneration flag to the routes received from the
UPE.
Step 5 Run quit
Step 7 Run peer { ipv4-address | group-name } advertise route-reoriginated vpnv4
The SPE is configured to re-encapsulate the BGP VPNv4 routes received from the
UPE into EVPN routes and then send them to the NPE.
Step 8 Run commit
----End
3.2.27.5 Verifying the EVPN L3VPN HVPN Configuration

After configuring an EVPN L3VPN HVPN, verify the configuration.
Prerequisites
All EVPN L3VPN HVPN configurations are complete.
Procedure
● Run the display ip routing-table vpn-instance or display ipv6 routing-table
vpn-instance vpn-instance-name command on a UPE or an NPE to check the
VPN routing table for default or specific routes sent by the remote end.

(2020-10-09)
● Run the display bgp evpn routing-table command on an EVPN-enabled UPE

or NPE to check the EVPN routing table for EVPN routes sent by the remote
end.
----End
3.2.28 Configuring IGMP Snooping over EVPN MPLS

IGMP snooping over EVPN MPLS can be configured to save bandwidth resources
for EVPN networks that carry multicast traffic.
Usage Scenario
By default, when the EVPN function is deployed on a network to carry Layer 2
multicast services, multicast data packets are broadcast on the network. The
devices that do not need to receive the multicast data packets also receive these
packets, which wastes network bandwidth resources. To resolve this issue, deploy
IGMP snooping over EVPN MPLS. After IGMP snooping over EVPN MPLS is
deployed, IGMP snooping packets are transmitted on the network through EVPN
routes, and multicast forwarding entries are generated on devices. Multicast data
packets from a multicast source are advertised only to the devices that need these
packets, saving network bandwidth resources.
Figure 3-142 IGMP snooping over EVPN MPLS networking
Before configuring IGMP snooping over EVPN MPLS, complete the following task:
● Configure BD-based EVPN functions.
● Configure EVPN E-LAN over mLDP P2MP tunnels.
3.2.28.1 Configuring IGMP Snooping and Proxy

To implement IGMP snooping over EVPN MPLS, you must configure basic IGMP
snooping and proxy functions.

(2020-10-09)
Procedure
Step 2 Run igmp-snooping enable
IGMP snooping is enabled globally.
The bridge domain view is displayed.
Step 4 Run igmp-snooping enable
IGMP snooping is enabled in the BD.
Step 5 (Optional) Run igmp-snooping version number
An IGMP version is configured for IGMP snooping.
IGMP snooping can process IGMPv1, IGMPv2, and IGMPv3 messages. By default,
IGMP snooping can process IGMPv1 and IGMPv2 messages but cannot process
IGMPv3 messages.
● If number is set to 1, only IGMPv1 messages can be processed.
● If number is set to 2, both IGMPv1 and IGMPv2 messages can be processed.
● If number is set to 3, IGMPv1, IGMPv2, and IGMPv3 messages can all be
processed.
Step 6 Run igmp-snooping proxy
IGMP snooping proxy is enabled in the BD.
Step 7 Run commit
----End
3.2.28.2 Configuring the Access Side

You can configure IGMP snooping over EVPN MPLS on the access side of an EVPN
that carries multicast services for various scenarios.
Context
The configurations required for various scenarios are as follows:
● A CE is single-homed to a source PE or dual-homed to source PEs on the
multicast source side. In this scenario, no additional configuration is required
on the access side. You must configure IGMP signaling synchronization based
on BGP EVPN IGMP Join Synch routes in a BD.
● A CE is single-homed to a receiver PE on the access side. In this scenario, no
additional configuration is required on the access side. You must configure
IGMP signaling synchronization based on BGP EVPN IGMP Join Synch routes
in a BD.

(2020-10-09)
● A CE is dual-homed to receiver PEs on the access side. In this scenario, you

must configure IGMP signaling synchronization based on BGP EVPN IGMP
Join Synch routes in a BD, associate the EVI-RT extended community
attributes of IGMP Join Synch routes with the BD, and enable the DF status
ignoring function on non-DF nodes.
● A CE is dual-homed to receiver PEs on the access side, and Layer 2 multicast
services on the access side access Layer 3 multicast services. In this scenario,
you must enable IGMP and PIM-SM on a VBDIF interface, configure IGMP
signaling synchronization based on BGP EVPN IGMP Join Synch routes in a
BD, associate the EVI-RT extended community attributes of IGMP Join Synch
routes with the BD, and enable the DF status ignoring function on non-DF
nodes.
Procedure
● A CE is single-homed to a receiver PE on the access side.
a. Run system-view
c. Run igmp-snooping signal-synch enable
IGMP signaling synchronization through BGP EVPN IGMP Join Synch
routes is enabled.
d. (Optional) Run evi vpn-target
The EVI-RT extended community attribute is associated with IGMP Join
Synch routes in the BD.
e. Run commit
● A CE is dual-homed to receiver PEs on the access side.
a. Run system-view
c. Run igmp-snooping signal-synch enable
routes is enabled.
d. Run igmp-snooping signal-ignore-df enable
DF status ignorance is enabled in a bridge domain on the non-DF node.
e. Run evi vpn-target vrfRt [ vrfRtType ]
f. Run commit

(2020-10-09)
● A CE is dual-homed to receiver PEs on the access side, and Layer 2 multicast

services on the access side access Layer 3 multicast services.
a. Run system-view


c. Run undo igmp-snooping proxy
IGMP snooping proxy is disabled in the BD.

d. Run quit

e. Run interface vbdif bd-id
The VBDIF interface view is displayed.

f. Run pim sm
PIM is enabled.
g. Run igmp enable
IGMP is enabled.
h. Run quit

i. Run bridge-domain bd-id

j. Run igmp-snooping signal-synch enable

routes is enabled.
k. Run igmp-snooping signal-ignore-df enable
DF status ignorance is enabled in a bridge domain on the non-DF node.

l. Run evi vpn-target vrfRt [ vrfRtType ]

m. Run commit
----End
3.2.28.3 Verifying the Configuration

After configuring IGMP snooping over EVPN MPLS, verify the configuration.
Prerequisites
IGMP snooping over EVPN MPLS has been configured.

(2020-10-09)
Procedure
● Run the display bgp evpn { vpn-instance evpn-name | route-distinguisher
route-distinguisher } routing-table { smet-route | join-route } [ prefix ] or
display bgp evpn all routing-table [ peer peer-address advertised-routes ]
{ smet-route | join-route } [ prefix ] command to check information about
BGP EVPN SMET or IGMP Join routes.
----End
3.2.29 Splicing an EVPN L3VPN over SRv6 with a Common

L3VPN over MPLS
During network evolution, an EVPN L3VPN over SRv6 and a common L3VPN over
MPLS may coexist. To ensure normal communication between the two types of
networks, splice an EVPN L3VPN over SRv6 with a common L3VPN over MPLS.
Context
On the network shown in Figure 3-143, area A is a newly built network deployed
with the EVPN L3VPN over SRv6 service, and area B is the legacy network
deployed with the common L3VPN over MPLS service. To ensure normal
communication between the two networks, splice the EVPN L3VPN over SRv6 with
the common L3VPN over MPLS on border leaves.
Figure 3-143 Networking of splicing an EVPN L3VPN over SRv6 with a common
L3VPN over MPLS
Before splicing an EVPN L3VPN over SRv6 with a common L3VPN over MPLS,
● On the network in area A, 2.2.4.2 Configuring EVPN L3VPN over SRv6 BE.
● On the network in area B, Configuring a Basic BGP/MPLS IP VPN or
Configuring a Basic BGP/MPLS IPv6 VPN.

(2020-10-09)
Procedure
Step 1 Configure a border leaf to advertise the routes that are re-originated in the BGP-
EVPN address family to a BGP VPNv4/VPNv6 peer (PE).
1. Run system-view
4. Run peer ipv6-address import reoriginate
The function to re-originate the routes received from a specified BGP EVPN
IPv6 peer is enabled.
5. Run quit
6. Run ipv4-family vpnv4 or ipv6-family vpnv6
{ ip | ipv6 }
The function to advertise the routes re-originated in the BGP-EVPN address
family to a BGP VPNv4/VPNv6 peer or peer group is enabled.
After this step is performed, the border leaf re-originates the SRv6-
encapsulated EVPN IPv4/IPv6 prefix routes that are received from access leaf
nodes and then advertises the MPLS-encapsulated BGP VPNv4/VPNv6 routes
to the BGP VPNv4/VPNv6 peer (PE).
Step 2 Configure the border leaf to advertise the routes that are re-originated in the BGP-
VPNv4/VPNv6 address family to a BGP EVPN peer (access leaf).
The device is enabled to re-originate the routes received from a BGP VPNv4
peer.
2. Run quit
4. Run peer ipv6-address advertise route-reoriginated { vpnv4 | vpnv6 }
The border leaf is enabled to advertise the routes re-originated in the BGP
VPNv4/VPNv6 address family to the BGP VPN IPv6 peer.
After this step is performed, the border leaf re-originates the MPLS-
encapsulated VPNv4/VPNv6 routes that are received from the BGP VPNv4/
VPNv6 peer (PE) and then advertises SRv6-encapsulated EVPN routes to the
BGP EVPN peer (access leaf).

(2020-10-09)
5. Run quit
Step 3 Enable the EVPN route advertisement in the BGP-VPN instance address family
view.

2. Run advertise l2vpn evpn
The device is enabled to advertise the host IPv4/IPv6 routes in the VPN
instance as EVPN IPv4/IPv6 prefix routes.
Step 4 Run commit
----End

● Run the display bgp evpn all routing-table command to check the EVPN
routes re-originated by the border leaf upon receipt of MPLS-encapsulated
VPNv4/VPNv6 routes received by the PE.
● Run the display bgp vpnv4 routing-table command to check the VPNv4
routes re-originated by the border leaf upon receipt of SRv6-encapsulated
EVPN IPv4 prefix routes received by the access leaf.
● Run the display bgp vpnv6 routing-table command to check the VPNv6
routes re-originated by the border leaf upon receipt of SRv6-encapsulated
EVPN IPv6 prefix routes received by the access leaf.
3.2.30 Configuring a Border Leaf Node to Splice an EVPN

L3VPN over SRv6 TE Policy with a Common L3VPN over MPLS
During network evolution, an EVPN L3VPN over SRv6 TE Policy and a common
L3VPN over MPLS may coexist. To allow these two networks to communicate,
configure each border leaf node to splice the EVPN L3VPN over SRv6 TE Policy
with the common L3VPN over MPLS.
Context
In Figure 3-144, network A is newly deployed and runs the EVPN L3VPN over
SRv6 TE Policy service. Network B is a legacy network and runs the common
L3VPN over MPLS service. Alternatively, network A runs the EVPN L3VPNv6 over
SRv6 TE Policy service, and network B runs the common L3VPNv6 over MPLS
service. To ensure that these two types of networks can communicate with each
other and services are running properly, configure each border leaf node to splice
the EVPN L3VPN over SRv6 TE Policy with the common L3VPN over MPLS.

(2020-10-09)
Figure 3-144 Networking diagram for configuring a border leaf node to splice an
EVPN L3VPN over SRv6 TE Policy with a common L3VPN over MPLS
Before configuring a border leaf node to splice an EVPN L3VPN over SRv6 TE
Policy with a common L3VPN over MPLS, complete the following tasks:
● Configure EVPN L3VPN over SRv6 TE Policy or 2.2.7.3 Configuring EVPN
L3VPNv6 over SRv6 TE Policy on the network that contains area A.
● Configure a basic BGP/MPLS IPv4 VPN and configure a basic BGP/MPLS IPv6
VPN on network B.
Procedure
Step 1 Configure each border leaf node to advertise the re-originated BGP-EVPN address
family routes to a specified VPNv4 or VPNv6 peer (PE) or peer group.
1. Run system-view
4. Run peer ipv6-address import reoriginate
The border leaf node is configured to re-originate the routes received from a
specified BGP EVPN IPv6 peer.
5. Run quit
The BGP-VPNv4 or BGP-VPNv6 address family view is displayed.
{ ip | ipv6 }

(2020-10-09)
The border leaf node is configured to advertise re-originated routes in the

BGP-EVPN address family to a specified BGP VPNv4 or VPNv6 peer or peer
group.
After this step is performed, the border leaf node re-originates SRv6-
encapsulated EVPN IPv4 or IPv6 prefix routes received from access leaf nodes.
Then, the border leaf node advertises MPLS-encapsulated BGP VPNv4 or
VPNv6 routes to the specified BGP VPN peer (PE) or peer group.
Step 2 Configure the border leaf node to advertise the routes that are re-originated in
the BGP-VPNv4 or BGP-VPNv6 address family to a specified BGP EVPN IPv6 peer
(access leaf) or peer group.
The border leaf node is configured to re-originate routes received from a
specified VPNv4 peer or peer group in the BGP-VPN address family view.
2. Run quit
4. Run peer ipv6-address advertise route-reoriginated { vpnv4 | vpnv6 }
The border leaf node is configured to advertise the routes re-originated in the
BGP-VPNv4 or BGP-VPNv6 address family to a specified BGP EVPN IPv6 peer.
After this step is performed, the border leaf node re-originates MPLS-
encapsulated VPNv4 or VPNv6 routes that are received from the PEs. Then,
the border leaf node advertises the SRv6-encapsulated EVPN routes to the
specified access leaf node.
5. Run quit
Step 3 Enable EVPN route advertisement in the BGP-VPN instance address family view.
The BGP-VPN instance IPv4 or IPv6 address family view is displayed.
The border leaf node is configured to advertise IPv4 or IPv6 routes in the VPN
instance as EVPN IPv4 or IPv6 prefix routes.
Step 4 Run commit
----End

● Run the display bgp evpn all routing-table command to check information
about EVPN routes re-originated after the border leaf node receives VPNv4 or
VPNv6 routes encapsulated in MPLS packets from PEs.

(2020-10-09)
● Run the display bgp vpnv4 all routing-table command to check information
about VPNv4 routes re-originated after the border leaf node receives EVPN IP
prefix routes encapsulated in SRv6 packets from access leaf nodes.
● Run the display bgp vpnv6 all routing-table command to check information
about VPNv6 routes re-originated after the border leaf node receives EVPN IP
prefix routes encapsulated in SRv6 packets from access leaf nodes.
3.2.31 Configuring EVPN VPLS over SRv6 Access to Each BRAS

If EVPN VPLS over SRv6 is used to carry E-LAN services, configure EVPN VPLS over
SRv6 on each device that functions as a BRAS that provides access services for
users.
Context
On the network shown in Figure 3-145, EVPN VPLS over SRv6 is deployed on
Metro Edge Function (MEF) devices and vBRAS-physical user planes (vBRAS-pUPs)
to carry E-LAN services. To allow users to access the Internet, configure EVPN
VPLS over SRv6 on each vBRAS-pUP.
Figure 3-145 EVPN VPLS over SRv6 accessing each BRAS
Before configuring EVPN VPLS over SRv6 access to each BRAS, complete the
following tasks:
2.2.4.4 Configuring EVPN VPLS over SRv6 BE or 2.2.7.5 Configuring EVPN VPLS
over SRv6 TE Policy on each MEF device, P, and vBRAS-pUP.

Configure an L2VE interface on a vBRAS-pUP to terminate EVPN services and bind
the interface to a VE-Group.

(2020-10-09)
Procedure
Step 1 Enter the system view.
system-view
Step 2 Run either of the following commands:
● To create a VE and enter the VE interface view, run the interface virtual-
ethernet interface-number command.
● To create a global VE interface and enter the global VE interface view, run the
interface global-ve interface-number command.
Step 3 Configure a VE or global VE interface as an L2VE interface that terminates EVPN
information and bind it to a VE-Group.
ve-group ve-group-id l2-terminate
NOTE
● A VE-Group has only one L2VE interface and one L3VE interface. The two VE interfaces
in a VE-Group must be on the same board.
Step 4 Commit the configuration.

commit
----End

Configure an L3VE interface on a vBRAS-pUP and bind the L3VE interface to a VE-
Group.
Procedure
system-view
● To create a VE interface and enter the VE interface view, run the interface
virtual-ethernet interface-number command.
● To create a global VE interface and enter the global VE interface view, run the
interface global-ve interface-number command.
Step 3 Configure a VE or global VE interface as an L3VE interface that accesses a BRAS
and bind the L3VE interface to a VE-Group.
ve-group ve-group-id l3-access
NOTE
● A VE-Group has only one L2VE interface and one L3VE interface. The two VE interfaces
in a VE-Group must be on the same board.

(2020-10-09)

commit
----End
3.2.31.3 (Optional) Configuring MAC Addresses for the L2VE and L3VE
Interfaces
If the MAC address of the L2VE or L3VE interface is the same as that of another
interface on a vBRAS-pUP, configure a new MAC address for the L2VE or L3VE
interface for proper communication.
Procedure
system-view
Step 2 Enter the slot view.
slot slot-id
Step 3 Configure a MAC address for the L2VE interface.
set l2ve-mac mac-address
You can modify the MAC address of the L2VE interface on an NPE if this MAC
address is the same as the MAC address of the UPE interface that connects to the
NPE.
Step 4 Configure a MAC address for the L3VE interface.
set access-ve-mac mac-address
Perform this step to change the MAC address of the L3VE interface if an L2VE
interface is bound to the same BD as an Eth-Trunk interface or a sub-interface of
an interface on which the portswitch command is run, and the preceding Eth-
Trunk interface or sub-interface needs to communicate with the L3VE interface at
Layer 3. The L3VE interface uses a bridge MAC address as an interface MAC
address. If the same bridge MAC address is also used by an Eth-Trunk interface or
an interface on which the portswitch command is run, the Layer 2 interface
incorrectly discards packets before the packets are sent to the L3VE interface.
commit
----End
3.2.31.4 Associating an L2VE Interface with a BD

Associate an L2VE interface with a BD on a vBRAS-pUP so that E-LAN services can
be terminated on the L2VE interface.

(2020-10-09)
Procedure
system-view

● To enter the VE Layer 2 sub-interface view, run the interface virtual-ethernet
interface-number.subinterface-number command.
● To enter the global VE Layer 2 sub-interface view, run the interface global-ve
interface-number.subinterface-number command.
Step 3 Configure the flow encapsulation type so that each interface accepts a specific
type of data packet.
encapsulation { dot1q [ vid low-pe-vid [ to high-pe-vid ] ] | untag | qinq [ vid

pe-vid ce-vid { low-ce-vid [ to high-ce-vid ] | default } ] }
Step 4 Configure the vBRAS-pUP to remove VLAN tags from received packets.
rewrite pop { single | double}
If the flow encapsulation type of packets is set to dot1q, specify single for the
sub-interface to remove the tag from each received single-tagged packet.
If the flow encapsulation type of packets is set to QinQ, specify double in this step
for the sub-interface to remove double VLAN tags from each received double-
tagged packet.
Step 5 Associate the Layer 2 sub-interface with a BD so that the sub-interface can
forward packets through the BD.
bridge-domain bd-id
commit
----End
3.2.31.5 Configuring an L3VE Interface as a BAS Interface

Configure an L3VE interface on a vBRAS-pUP as a BAS interface to implement
BRAS access.
Context
A BAS interface on a vBRAS-pUP can be configured in either of the following
modes:
● The BAS interface configuration is performed on the vBRAS-pUP and applies
to scenarios where CU separation is not deployed.
● The BAS interface configuration is delivered by a vBRAS-CP to the vBRAS-pUP
in the southbound direction. This configuration applies to CU separation
scenarios.

(2020-10-09)
Procedure
● Perform the configuration on the vBRAS-pUP. For details, see PPPoE Access
Configuration.
● Configure a vBRAS-CP to deliver the configuration to the vBRAS-pUP through
a southbound interface. In this case, the vBRAS-UP configuration needs to be
completed on the vBRAS-CP and delivered to the vBRAS-pUP through a
southbound channel. For details, see VNE 9000 (vBRAS-CP) Product
Documentation > Configuration Guide > User Access Configuration > PPPoE
Access Configuration.
----End
3.2.31.6 Verifying the Configuration of Configuring EVPN VPLS over SRv6

Access to BRASs
After configuring EVPN VPLS over SRv6 access to BRASs, verify the binding
between the VE or global VE interface and VE-Group and EVPN route information
on each vBRAS-pUP.
Prerequisites
EVPN VPLS over SRv6 access to BRAS has been configured.
Procedure
Step 1 Run the display virtual-ethernet ve-group [ ve-group-id | slot slot-id ] command
to check the binding relationship between the VE or global VE interface and the
VE-Group.
Step 2 Run the display bgp evpn all routing-table command to check EVPN routing
information.
----End
3.2.32 Configuring DCI Functions

This section describes how to configure Data Center Interconnect (DCI) functions,
which helps you understand basic DCI information.
Background
To meet the requirements of cross-region operation, user access, and inter-city
disaster recovery that arise during enterprise development, an increasing number
of enterprises have deployed data centers in multiple regions and across carrier
networks. Currently, leased fibers or leased lines are commonly used to
interconnect cross-region data centers, causing the following disadvantages:
● For enterprises, leased fibers or leased lines are costly.
● For carriers, service exploration is difficult, and resource utilization is low.
To cope with these disadvantages, a DCI network that is characterized by high
security and reliability and flexible scheduling needs to be constructed and
operated. Data Center Interconnect (DCI) provides solutions to interconnect data
centers. Using Virtual extensible local area network (VXLAN), Ethernet virtual

(2020-10-09)
private network (EVPN), and BGP/MPLS IP VPN technologies, DCI solutions allow
packets that are exchanged between data centers to be transmitted securely and
reliably over carrier networks, allowing VMs in different data centers to
Figure 3-146 Configuring DCI functions
Before configuring DCI functions, configure MPLS tunnels over the DCI backbone
network.
3.2.32.1 Configuring E2E VXLAN EVPN in a DCI scenario with Gateways

Deployed
An end-to-end VXLAN EVPN uses the same service platform, which helps
implement unified VXLAN VNI resource management.
Context
Gateways and DCI-PEs are deployed individually. As edge devices of the underlay
network, DCI-PEs only advertise VTEP routes across DCs, but do not store the
tenant or host information of DCs.
On the network shown in Figure 3-147, an end-to-end VXLAN tunnel can be
established between Device1 and Device2 to implement communication between
DC A and DC B. For example, VMa1 and VMb2 need to communicate with each
other. To meet this requirement, establish a BGP EVPN peer relationship between
Device1 and Device2 so that they can learn MAC and IP routes from each other. In

(2020-10-09)
addition, GW1 and GW2 in the data centers are connected to DCI-PE1 and DCI-
PE2, respectively, on the backbone network. An L3VPN based on an MPLS TE
tunnel is established between DCI-PE1 and DCI-PE2 to transmit VXLAN packets.
Figure 3-147 Configuring E2E VXLAN EVPN in a DCI scenario with gateways
deployed
Procedure
Step 1 Configure basic L3VPN functions on the DCI backbone network. For configuration
details, see Configuring a Basic BGP/MPLS IP VPN.
Step 2 Configure an E2E VXLAN tunnel based on BGP EVPN on Device1 and Device2. For
details, see Configuring VXLAN.
If only Layer 2 communication between VMs needs to be implemented, Layer 3

gateways do not need to be configured. If VMs need to communicate with each
other at Layer 3 or with external networks, a Layer 3 gateway needs to be
configured.
----End
3.2.32.2 Configuring a DCI Scenario with a VLAN Layer 3 Sub-interface

Accessing a Common L3VPN
The DCI Scenario with a VLAN Layer 3 Sub-interface Accessing a Common L3VPN
uses different cloud management platforms, and a Layer 3 Ethernet sub-interface
is associated with a VLAN to access an L3VPN.

(2020-10-09)
Context
An underlay VLAN can access a DCI network through a Layer 3 gateway when
traditional DCs are connected through the DCI network.
GWs and DCI-PEs are separately deployed. Each DCI-PE considers the GW of a
data center as a CE, uses a Layer 3 VPN routing protocol to receive VM host routes
from the data center, and saves and maintains the routes.
If VXLAN is deployed in the data center, the solution of Underlay VLAN Layer 3
access to DCI can be used. In Figure 3-148, VXLAN tunnels are established within
data centers to allow intra-DC VM communication. To allow inter-data center VM
communication, BGP/MPLS IP VPN functions are deployed on the DCI backbone
network, and a Layer 3 Ethernet sub-interface is configured on each DCI-PE,
added to the same VLAN, and bound to the VPN instance of each DCI-PE.
Figure 3-148 Configuring a DCI Scenario with a VLAN Layer 3 Sub-interface

Procedure
details, see Configuring a Basic BGP/MPLS IP VPN.
Step 2 Configure a dot1q VLAN tag termination sub-interface and bind the sub-interface
to a VPN instance.
1. Run interface interface-type interface-number.subinterface-number
An Ethernet sub-interface is created, and its view is displayed.
2. Run vlan-type dot1q vlan-id
A VLAN is bound to the sub-interface, and a VLAN encapsulation mode is
specified.

(2020-10-09)

The sub-interface is bound to a VPN instance.
An IP address is configured for the sub-interface.
Step 3 Run commit
----End
3.2.32.3 Configuring a DCI Scenario with a VXLAN EVPN L3VPN Accessing a

Common L3VPN
The DCI scenario with a VXLAN EVPN L3VPN accessing a common L3VPN uses
different cloud management platforms, and a VXLAN tunnel is used to access the
DCI backbone network.
Context
GWs and DCI-PEs are separately deployed. EVPN is used as a control plane
protocol to dynamically establish VXLAN tunnels. A DCI-PE runs EVPN to learn a
VM's IP route information from a DC and uses VPNv4/VPNv6 to send received host
IP routes to the peer DCI-PE, and packets of VM hosts can be forwarded at Layer
3.
In Figure 3-149, data center gateway devices GW1 and GW2 are connected to the
DCI backbone network. To allow inter-data center VM communication, BGP/MPLS
IPv4/IPv6 VPN functions are deployed on the DCI backbone network. In addition,
EVPN and a VXLAN tunnel are deployed between the GW and DCI-PE to transmit
VM host routes so that VMs in different data centers can communicate with each
other.

(2020-10-09)
Figure 3-149 Configuring a DCI scenario with a VXLAN EVPN L3VPN accessing a
common L3VPN
Procedure
Step 1 Configure a VXLAN tunnel between each DCI PE and the corresponding GW. For
configuration details, see Configuring VXLAN.
details, see Configuring a Basic BGP/MPLS IP VPN or Configuring a Basic BGP/
MPLS IPv6 VPN.
Step 3 Configure the DCI-PE to send the routes that are regenerated in the EVPN address
family to a VPNv4/VPNv6 peer.


The DCI-PE is configured to add the regeneration flag to the routes to be

received from a BGP EVPN peer.
4. Run quit


(2020-10-09)

{ mac-ip | ip | mac-ipv6 | ipv6 }
The DCI-PE is configured to send the routes that are regenerated in the EVPN
address family to a VPNv4/VPNv6 peer.
After the peer { ipv4-address | group-name } advertise route-reoriginated

evpn { mac-ip | ip | mac-ipv6 | ipv6 } command is run and EVPN routes that
are received from the DC side and carry the VXLAN encapsulation attribute
are regenerated on the DCI-PE, the DCI-PE advertises VPNv4/VPNv6 routes
that carry the MPLS encapsulation attribute to the VPNv4/VPNv6 peer on the
DCI backbone network.
Step 4 Configure the DCI-PE to send the routes that are regenerated in the VPNv4/VPNv6
address family to a BGP EVPN peer.


The DCI-PE is configured to add the regeneration flag to the routes received
from a VPNv4/VPNv6 peer.
4. Run quit


6. Run peer { ipv4-address | group-name } advertise route-reoriginated
{ vpnv4 | vpnv6 }
The DCI-PE is configured to send the routes that are regenerated in the
VPNv4/VPNv6 address family to a BGP EVPN peer.
After the peer { ipv4-address | group-name } advertise route-reoriginated

{ vpnv4 | vpnv6 } command is run and VPNv4/VPNv6 routes that are received
from the DCI backbone network and carry the MPLS encapsulation attribute
are regenerated on the DCI-PE, the DCI-PE advertises EVPN routes that carry
the VXLAN encapsulation attribute to the BGP EVPN peer on the DC.
7. Run peer { ipv4-address | group-name } advertise encap-type vxlan
EVPN routes that carry the VXLAN encapsulation attribute are sent to the BGP
EVPN peer on the data center side.
Step 5 Run commit
----End

(2020-10-09)
3.2.32.4 Configuring a DCI Scenario with a VLAN Base Accessing an MPLS

EVPN IRB
In a DCI scenario, Ethernet sub-interfaces are associated with VLANs to access
gateways or the DC network and the EVPN IRB function is enabled to allow the
DCI network to carry Layer 2 or Layer 3 services.
Context
A VXLAN tunnel can be established in each DC to implement interworking
between VMs in a DC. To achieve Layer 2 or Layer 3 service communication
between VMs in a DC, associate Ethernet sub-interfaces with VLANs on PEs in the
DCI backbone network, create an L3VPN or EVPN instance, and enable the EVPN
IRB function. Such a network can be deployed in either of the following modes:
● Centralized deployment mode: As shown in Figure 3-150, the DC gateway
and the PE on the DCI backbone network are the same device (DCI-PE-GW).
Specifically, the PE also functions as the DC gateway to access the DC
network.
Figure 3-150 Configuring a DCI scenario with a VLAN base accessing an

MPLS EVPN IRB (The PE functions as a gateway)
● Distributed deployment mode: As shown in Figure 3-151, the DC gateway

and PE (DCI-PE) are separately deployed, and DCI-PE takes the gateway as a
CE. After Ethernet sub-interfaces and VBDIF interfaces are associated with
VLANs to receive Layer 2 and Layer 3 service traffic, the traffic can be
forwarded to other DCs over the DCI backbone network.

(2020-10-09)
Figure 3-151 Configuring a DCI scenario with a VLAN base accessing an

MPLS EVPN IRB (PE and gateway are separately deployed)
Before configuring a DCI scenario with a VLAN base accessing an MPLS EVPN IRB,
ensure that routes on the IPv4 network are reachable.
Procedure
Step 1 Configure BGP EVPN peers.
NOTE
The remote PE is specified as the BGP peer.
NOTE
When loopback interfaces are used to establish a BGP connection, it is recommended

that the peer connect-interface command be run on both ends to ensure correct
connection. If this command is run on only one end, the BGP connection may fail to
be established.

(2020-10-09)

5. Run import-route { direct | isis process-id | ospf process-id | rip process-id |
static | ospfv3 process-id | ripng process-id } [ med med | route-policy route-
policy-name ] *
The device is enabled to import non-BGP routing protocol routes into the
BGP-VPN instance IPv4/IPv6 address family. To advertise host IP routes, only
enable the device to import direct routes. To advertise the routes of the
network segment where a host resides, configure a dynamic routing protocol
(such as OSPF) to advertise the network segment routes. Then enable the
device to import routes of the configured routing protocol.
The BGP device is enabled to advertise IP prefix routes to the BGP peer. This
configuration allows the BGP device to advertise both host IP routes and
routes of the network segment where the host resides.
7. Run quit
The local BGP device is enabled to exchange EVPN routes with a peer or peer
group.
10. Run peer { ipv4-address | group-name } advertise { irb | irbv6 }
The BGP device is enabled to advertise IRB/IRBv6 routes to the BGP EVPN
peer.
11. Run quit
12. Run quit
Step 2 (Optional) Configure an L3VPN instance to store and manage received VM routes.
You must perform this step if you want the network to carry Layer 3 services.

(2020-10-09)

address family.
advertised.
address family.
address family.

(2020-10-09)
advertised.
Step 3 Configure access-side interfaces.
● If you want the network to carry both Layer 2 and Layer 3 services, perform
the following configurations:
a. Run the bridge-domain bd-id command to enter the BD view.
b. Run the evpn binding vpn-instance vpn-instance-name [ bd-tag bd-
tag ] command to bind a specified EVPN instance to the BD. By specifying
different bd-tag values, you can bind multiple BDs with different VLANs
to the same EVPN instance and isolate services in the BDs.
c. Run the quit command to exit from the BD view.
d. Run the interface interface-type interface-number.subnum mode l2
command to create a Layer 2 sub-interface and enter the Layer 2 sub-
interface view.
e. Run the encapsulation { dot1q [ vid low-pe-vid [ to high-pe-vid ] ] |
untag | qinq [ vid pe-vid ce-vid { low-ce-vid [ to high-ce-vid ] |
default } ] } command to configure a traffic encapsulation type so that
different interfaces can access different data packets.
f. Run the rewrite pop { single | double } command to remove VLAN tags
of received packets.
g. Run the bridge-domain bd-id command to add the Layer 2 sub-interface
to the BD so that the sub-interface can transmit data packets through
this BD.
h. Run the quit command to exit from the sub-interface view and return to
the system view.
i. Run the interface vbdif bd-id command to create a VBDIF interface enter
the VBDIF interface view.
j. Run the ip binding vpn-instance vpn-instance-name command to bind
the VBDIF interface to the VPN instance.
k. (Optional) Run ipv6 enable
l. Run ip address ip-address { mask | mask-length } [ sub ] or ipv6 address
{ ipv6-address prefix-length | ipv6-address/prefix-length }
An IPv4/IPv6 address is configured for the VBDIF interface to implement
Layer 3 interworking.
m. (Optional) Run the mac-address mac-address command to specify a
MAC address for the VBDIF interface.
n. Run the vxlan anycast-gateway enable command to enable the
After distributed gateway is enabled, the device discards the ARP packets
received from the network side, learns only ARP packets from hosts on
the user side, and generates host routes.
o. Run the arp collect host enable or ipv6 nd collect host enable
command to collect host information.

(2020-10-09)
p. Run the quit command to exit from the interface view and return to the
system view.
● If you want the network to carry only Layer 2 services, perform the following
configurations:
a. Run the bridge-domain bd-id command to enter the BD view.
b. Run the evpn binding vpn-instance vpn-instance-name [ bd-tag bd-
tag ] command to bind a specified EVPN instance to the BD. By specifying
different bd-tag values, you can bind multiple BDs with different VLANs
to the same EVPN instance and isolate services in the BDs.
c. Run the quit command to exit from the BD view.
d. Run the interface interface-type interface-number.subnum mode l2
command to create a Layer 2 sub-interface and enter the Layer 2 sub-
interface view.
e. Run the encapsulation { dot1q [ vid low-pe-vid [ to high-pe-vid ] ] |
untag | qinq [ vid pe-vid ce-vid { low-ce-vid [ to high-ce-vid ] |
default } ] } command to configure a traffic encapsulation type so that
different interfaces can access different data packets.
f. Run the rewrite pop { single | double } command to remove VLAN tags
of received packets.
g. Run the bridge-domain bd-id command to add the Layer 2 sub-interface
to the BD so that the sub-interface can transmit data packets through
this BD.
h. Run the quit command to exit from the interface view and return to the
system view.
● If you want the network to carry only Layer 3 services, see Binding Interfaces
to a VPN Instance or Binding Interfaces to a IPv6 VPN Instance.
Step 4 Configure an EVPN instance in BD mode.

An EVPN instance in BD mode is created, and the EVPN instance view is

displayed.

extcommunity ]
VPN targets are configured for the EVPN instance. The export RT of the local
EVPN instance must be the same as the import RT of the remote EVPN
instance. Similarly, the import RT of the local EVPN instance must be the
same as the export RT of the remote EVPN instance.
4. (Optional) Run import route-policy policy-name
The EVPN instance is associated with an import route-policy.
To strictly control the import of routes into the EVPN instance, specify an
import route policy to filter routes and set route attributes for routes that
meet the filter criteria.
5. (Optional) Run export route-policy policy-name

(2020-10-09)
The EVPN instance is associated with an export route-policy.

To strictly control the advertisement of EVPN routes, specify an export route
policy and set route attributes for routes that meet the filter criteria.
6. (Optional) Run tnl-policy policy-name
EVPN routes that can be imported into the VPN instance IPv4 address family
are associated with a tunnel policy.
This configuration allows data packets between PEs to be forwarded through
a TE tunnel.
7. (Optional) Run mac limit number { simply-alert | mac-unchanged }
The maximum number of MAC addresses allowable is set for the EVPN
instance.
If a device imports a large number of MAC addresses, which consumes a lot
of system resources, device operation may be affected when the system
processes many services concurrently. To improve system security and
reliability, run the mac limit command to limit the number of MAC addresses
to be imported into the EVPN instance. After this configuration, if the number
of MAC addresses exceeds the preset value, an alarm is triggered to prompt
you to check the validity of existing MAC addresses.
8. Run quit
Exit from the EVPN instance view.
Step 5 (Optional) Configure an RR. To minimize the number of BGP EVPN peers on the
network, deploy an RR so that the PEs establish BGP EVPN peer relationships only
with the RR.
3. Run peer { ipv4-address | group-name } reflect-client
The local device is configured as an RR, and a peer or peer group is specified
as the RR client.
The router where the peer reflect-client command is run functions as the RR,
and the specified peer or peer group functions as a client.
4. (Optional) Run undo reflect between-clients
If the clients of an RR have established full-mesh connections with each other,
run the undo reflect between-clients command to disable route reflection
between-clients command applies only to RRs.
5. (Optional) Run reflector cluster-id cluster-id
If a cluster has multiple RRs, run this command to set the same cluster ID for
these RRs to prevent routing loops.

(2020-10-09)
The reflector cluster-id command applies only to RRs.

6. Run quit
7. Run quit
Step 6 Run commit
----End
3.2.32.5 Configuring a DCI Scenario with a VXLAN EVPN Accessing an MPLS

EVPN IRB
In a DCI scenario with a VXLAN EVPN accessing an MPLS EVPN IRB, different
cloud platforms are used for management. VXLAN tunnels are established to
access the DCI backbone network, over which EVPN MPLS is used to carry Layer 3
services.
Context
DC-GWs and DCI-PEs are separately deployed, and EVPN is used as the control
plane protocol to establish VXLAN tunnels. A DCI-PE runs EVPN to learn a VM's IP
route from a DC and sends the learned host IP route to the peer DCI-PE through a
BGP EVPN peer relationship to implement Layer 3 service forwarding between
VMs.
On the network shown in Figure 3-152, the DC-GWs GW1 and GW2 are
connected to the DCI backbone network with BGP EVPN configured. After BGP
EVPN peer relationships and VXLAN tunnels are established between the DC-GWs
and the DCI-PEs, host IP routes can be exchanged between different DCs,
implementing communication between VMs in different DCs.

(2020-10-09)
Figure 3-152 Configuring a DCI Scenario with a VXLAN EVPN Accessing an MPLS
EVPN IRB
Before configuring a DCI scenario with a VXLAN EVPN accessing an MPLS EVPN
IRB, ensure Layer 3 route reachability on the IPv4 network.
Procedure
Step 1 Configure an IGP on the DCI backbone network to ensure IP connectivity.
Step 2 Configure VXLAN tunnels on the DCI-PEs destined for the DC-GWs. For
configuration details, see 4.2 VXLAN Configuration.
Step 3 Configure VPN instances to exchange routes with EVPN instances.
2. Run ipv4-family
extcommunity ]

(2020-10-09)
mutually import routes with the remote PE's L3VPN instance.
extcommunity ] evpn
6. Run evpn mpls routing-enable
EVPN is enabled to generate and advertise IP prefix routes and IRB routes.
The VPN instance IPv4 address family of the current VPN instance is
associated with an import routing policy to filter routes imported from the
EVPN instance. To control route import more precisely, perform this step to
associate the VPN IPv4 address family with an import routing policy and set
attributes for eligible routes.
associated with an export routing policy to filter routes to be advertised to the
EVPN instance. To control route export more precisely, perform this step to
associate the VPN IPv4 address family with an export routing policy and set
10. Run quit
11. Run quit
2. Run ipv6-family
extcommunity ]
mutually import routes with the remote PE's L3VPN instance.
extcommunity ] evpn
6. Run evpn mpls routing-enable

(2020-10-09)
EVPN is enabled to generate and advertise IP prefix routes and IRB routes.
associated with an import routing policy to filter routes imported from the
EVPN instance. To control route import more precisely, perform this step to
associate the VPN IPv6 address family with an import routing policy and set
associated with an export routing policy to filter routes to be advertised to the
EVPN instance. To control route export more precisely, perform this step to
associate the VPN IPv6 address family with an export routing policy and set
10. Run quit
11. Run quit
Step 4 Establish on the local DCI-PE a BGP EVPN peer relationship with the remote DCI-
PE, and enable the local DCI-PE to advertise routes regenerated by the EVPN
address family to the BGP EVPN peer.
1. Run system-view



The remote DCI-PE is specified as the BGP peer.

NOTE
When loopback interfaces are used to establish a BGP connection, it is recommended

that the peer connect-interface command be run on both ends to ensure correct
connection. If this command is run on only one end, the BGP connection may fail to
be established.

(2020-10-09)
The local BGP device is enabled to exchange EVPN routes with a peer or peer
group.
The BGP device is enabled to add regeneration flags to the routes received
from the BGP EVPN peer.
9. Configure types of routes to be advertised:
– If you want the network to carry only Layer 2 services, perform the
i. Run the peer { ipv4-address | group-name } advertise route-
reoriginated evpn { mac-ip | mac } command to configure the
device to regenerate EVPN routes and advertise them to the BGP
EVPN peer.
ii. Run the peer { ipv4-address | group-name } advertise { arp | nd }
command to configure the device to advertise ARP (ND) routes.
– If you want the network to carry only Layer 3 services, perform the
reoriginated evpn { mac-ip | ip | mac-ipv6 | ipv6 } command to
configure the device to regenerate EVPN routes and advertise them
to the BGP EVPN peer.
ii. Run the peer { ipv4-address | group-name } advertise { irb | irbv6 }
command to configure the device to advertise IRB/IRBv6 routes.
– If you want the network to carry both Layer 2 and Layer 3 services,
perform the following configurations:
reoriginated evpn { mac | mac-ip | ip | mac-ipv6 | ipv6 } command
to configure the device to regenerate EVPN routes and advertise
them to the BGP EVPN peer.
ii. Run the peer { ipv4-address | group-name } advertise { irb | irbv6 }
command to configure the device to advertise IRB/IRBv6 routes.
Step 5 Run commit
----End
3.2.32.6 Verifying the Configuration of DCI Functions

After configuring the DCI solution, check the VPN instance, EVPN instance, and
VXLAN tunnel configurations.
Prerequisites
A DCI solution has been configured.

(2020-10-09)
Procedure
● Run the display ip vpn-instance vpn-instance-name command to check brief
information about a specified VPN instance.
● Run the display ip vpn-instance verbose vpn-instance-name command to
check detailed information about a specified VPN instance, including
information in the IPv4 address family of the VPN instance.
● Run the display ip vpn-instance [ vpn-instance-name ] interface command
to view information about the interfaces bound to a specified VPN instance.
● Run the display evpn vpn-instance [ vpn-instance-name ] command to
● Run the display vxlan tunnel [ tunnel-id ] [ verbose ] command to check
VXLAN tunnel information.
● Run the display evpn mac routing-table { all-evpn-instance | mac-address
mac-address } command to check information about MAC routes of a
specified EVPN instance.
● Run the display bgp evpn peer [ [ ipv4-address ] verbose ] command to
check information about BGP EVPN peers.
vpn-instance vpn-instance-name } routing-table mac-route command to
check MAC route information.
vpn-instance vpn-instance-name } routing-table command to check BGP
VPNv4 route information.
vpn-instance vpn-instance-name } routing-table command to check BGP
VPNv6 route information.
----End
3.2.33 Configuring the NFVI Distributed Gateway Function

(SR Tunnels)
In the network function virtualization infrastructure (NFVI) telco cloud solution,
the NFVI distributed gateway function allows mobile phone service traffic to be
transmitted to virtual unified gateways (vUGWs) and virtual multiservice engines
(vMSEs) through a SR tunnel over a data center network (DCN) in load balancing
mode.
Usage Scenario
The NFVI telco cloud solution uses the data center interconnect (DCI)+DCN
networking. A large amount of mobile phone traffic is sent to virtual unified
gateways (vUGWs) and virtual multiservice engines (vMSEs) on the DCN. After
being processed by the vUGWs and vMSEs, the mobile phone traffic is forwarded
over the DCN to destination devices on the Internet. The destination devices send
traffic to mobile phones in similar ways. To achieve these functions and ensure
traffic load balancing on the DCN, you need to deploy the NFVI distributed
gateway function.
Figure 3-153 shows the networking of an NFVI distributed gateway (SR tunnels).
DC-GWs, which are the border gateways of the DCN, exchange Internet routes

(2020-10-09)
with external devices over PEs. L2GW/L3GW1 and L2GW/L3GW2 are connected to
virtualized network function (VNF) devices. VNF1 and VNF2 that function as
virtualized NEs are deployed to implement the vUGW functions and vMSE
functions, respectively. VNF1 and VNF2 are connected to L2GW/L3GW1 and
L2GW/L3GW2 through interface process units (IPUs).
In NFVI distributed gateway networking (SR tunnels), the number of bridge
domains (BDs) needs to be planned based on the number of network segments
corresponding to each IPU. An example assumes that the five IP addresses
planned for five IPUs belong to four network segments. In this case, four BDs need
to be planned. You need to configure the BDs and the corresponding VBDIF
interfaces on all DC-GWs and L2GW/L3GWs and bind all the VBDIF interfaces to
the same L3VPN instance. In addition, the following functions need to be deployed
on the DCN:
L2GW/L3GWs can then flood the static routes destined for VNFs to other
devices based on the BGP EVPN peer relationships. DC-GWs can then
advertise local loopback routes and default routes to L2GW/L3GWs.
● Establish BGP VPNv4/v6 peer relationships between DC-GWs and PEs. DC-
GWs can then advertise mobile phone routes to PEs and receive the Internet
routes sent by external devices based on the BGP VPNv4/v6 peer
relationships.
NOTE
The NFVI distributed gateway function supports both IPv4 and IPv6 services. If a step does
not differentiate IPv4 and IPv6 services, this step applies to both IPv4 and IPv6 services.

(2020-10-09)
Figure 3-153 Networking of an NFVI distributed gateway (SR tunnels)
Before configuring the NFVI distributed gateway function, complete the following
tasks:
● Allow the routes between PEs and DC-GWs and between DC-GWs and L2GW/
L3GWs to be reachable.
L2GW/L3GWs.
● Configure the BD EVPN function on DC-GWs and L2GW/L3GWs. The
configuration includes creating EVPN instances and L3VPN instances,
establishing BGP EVPN peer relationships, and configuring VBDIF interfaces.
● Deploy the EBGP VPNv4 or EBGP VPNv6 function between PEs and DC-GWs.
● Configure the static routes destined for VNF1 and VNF2 on L2GW/L3GWs by
referring to Static VPN IPv4 Routes or Static VPN IPv6 Routes.

(2020-10-09)
3.2.33.1 Configuring Route Recursion over SR Tunnels

If SR tunnels are used to carry service traffic, the function to recurse routes over
SR tunnels must be configured.
Context
You can configure a tunnel policy or an SR-MPLS BE tunnel-preferred policy to
recurse routes over SR tunnels.
Procedure
● Configure a tunnel policy on PEs, DC-GWs, and L2GW/L3GWs and apply the
tunnel policy. You can choose to recurse routes over SR-MPLS BE or SR-MPLS
TE tunnels. For configuration details, see Configuring and Applying a Tunnel
Policy.
● If both the LDP and SR-MPLS BE tunnels are deployed and users want route
recursion over SR-MPLS BE tunnels, configure an SR-MPLS BE tunnel-preferred
policy on each device.
a. Run system-view
The segment routing view is displayed.
c. Run tunnel-prefer segment-routing
SR-MPLS BE tunnels are enabled to take precedence over LDP tunnels.
d. Run commit
----End
3.2.33.2 Configuring Route Advertisement on DC-GWs

Route advertisement can be configured on DC-GWs to allow the DC-GWs to
construct their own forwarding entries based on the received EVPN or BGP routes.
Procedure
Step 1 Configure DC-GWs to advertise default static VPN routes and VPN loopback routes
through EVPN.
1. Run system-view
2. Run interface Loopback interface-number
The loopback interface view is displayed.
The loopback interface is bound to an L3VPN instance.

(2020-10-09)
IPv6 is enabled on the loopback interface. This step is mandatory when the
loopback interface is configured with an IPv6 address.
5. Configure an IPv4 or IPv6 address for the loopback interface.
– Run the ip address ip-address { mask | mask-length } command to
configure an IPv4 address for the loopback interface.
– Run the ipv6 address { ipv6-address prefix-length | ipv6-address/prefix-
length } command to configure an IPv6 address for the loopback
interface.
6. Run quit
Exit from the loopback interface view.

7. Configure default static VPN routes.
– Run the ip route-static vpn-instance vpn-instance-name 0.0.0.0 { 0.0.0.0
| 0 } { nexthop-address | interface-type interface-number [ nexthop-
address ] } [ tag tag ] command to create a default static VPN IPv4
route.
– Run the ip route-static vpn-instance vpn-instance-name :: 0 { nexthop-
ipv6–address | interface-type interface-number [ nexthop-ipv6-address ] }
[ tag tag ] command to create a default static VPN IPv6 route.
8. Create a route-policy so that default static VPN routes and VPN loopback
routes of the L3VPN instance can be filtered out. For configuration details, see
Configuring a Route-Policy.

10. Enter the IPv4 or IPv6 address family view of the VPN instance.
– Run the ipv4-family command to enter the IPv4 address family view of
the VPN instance.
the VPN instance.
11. Run export route-policy policy-name evpn
The L3VPN instance is bound to an export route-policy. This route-policy is

used to filter the routes advertised to the EVPN instance from the L3VPN
instance so that the L3VPN instance advertises only the default static VPN
routes and VPN loopback routes to the EVPN instance.
12. Run quit
Exit from the IPv4 or IPv6 address family view of the VPN instance.
13. Run quit

14. Create a route-policy to filter the mobile phone routes received by the DC-GW
from the L2GW/L3GW and prohibit the advertisement of such mobile phone
routes. For details about how to create a route-policy, see Configuring a
Route-Policy.

(2020-10-09)

17. Run peer { group-name | ipv4-address } route-policy route-policy-name
export
The route-policy is used to prohibit DC-GWs from advertising mobile phone
routes to each other.
18. Run quit
19. Enter the IPv4 or IPv6 address family view of a BGP-VPN instance.
– Run the ipv4-family vpn-instance vpn-instance-name command to enter
the IPv4 address family view of a BGP-VPN instance.
20. Run import-route direct [ med med | route-policy route-policy-name ] *
VPN loopback routes are imported to the IPv4 or IPv6 address family of the
BGP-VPN instance.
21. Run network { 0.0.0.0 0 | :: 0 }
Default static VPN routes are imported to the IPv4 or IPv6 address family of
the BGP-VPN instance.
The function to advertise IP routes from the VPN instance to the EVPN
instance is enabled.
23. Run quit
Exit from the IPv4 or IPv6 address family view of the BGP-VPN instance.
24. Run quit
Step 2 Establish BGP VPN peer relationships between DC-GWs and VNFs.
1. Run route-policy route-policy-name deny node node
A route-policy that denies all routes is created.
2. Run quit
Exit from the route-policy view.
5. Run peer { ipv4-address | ipv6-address | group-name } as-number { as-
number-plain | as-number-dot }

(2020-10-09)
A BGP VPN peer relationship is established.

6. Run peer { ipv4-address | ipv6-address | group-name } connect-interface
interface-type interface-number [ ipv4-source-address ]
7. Run peer { ipv4-address | ipv6-address | group-name } route-policy route-
policy-name export
The route-policy is applied so that DC-GWs do not advertise BGP VPN routes
to VNFs. This prevents route loops.
8. Run quit
Step 3 Configure DC-GWs to generate ARP or ND entries for Layer 2 forwarding based on
the ARP or ND information in EVPN routes.
1. Run interface vbdif bd-id
The VBDIF interface view is displayed.
2. Run anycast-gateway enable
The distributed gateway function is enabled.
3. Configure DC-GWs to generate ARP or ND entries for Layer 2 forwarding
based on the ARP or ND information in EVPN routes.
– Run the arp generate-rd-table enable command to allow DC-GWs to
generate ARP entries for Layer 2 forwarding based on the ARP
information in EVPN routes.
– Run the ipv6 nd generate-rd-table enable command to allow DC-GWs
to generate ND entries for Layer 2 forwarding based on the ND
4. (Optional) Run ipv6 nd dad attempts 0
Duplicate address detection (DAD) is prohibited. This command is mandatory
in IPv6 scenarios to prevent service interruptions occurred because the system
detects that the IPv6 address of another device is the same as the VBDIF
interface's IP address.
5. Run quit
Exit from the VBDIF interface view.
Step 4 (Optional) Configure the asymmetric mode for IRB routes. If L2GW/L3GWs are
configured to advertise IRB or IRBv6 routes to DC-GWs, the asymmetric IRB
function needs to be configured on DC-GWs.

(2020-10-09)
3. Run irb asymmetric

The asymmetric mode is enabled for IRB routes.
4. Run quit
Step 5 Run commit
----End
3.2.33.3 Configuring Route Advertisement on L2GW/L3GWs

Route advertisement can be configured on L2GW/L3GWs to allow the L2GW/
L3GWs to construct their own forwarding entries based on the received EVPN or
BGP routes.
Procedure
Step 1 Configure L2GW/L3GWs to generate ARP or ND entries for Layer 2 forwarding
1. Run system-view
3. Configure L2GW/L3GWs to generate ARP or ND entries for Layer 2 forwarding
– Run the arp generate-rd-table enable command to allow L2GW/L3GWs
to generate ARP entries for Layer 2 forwarding based on the ARP
– Run the ipv6 nd generate-rd-table enable command to allow L2GW/
L3GWs to generate ND entries for Layer 2 forwarding based on the ND
4. Configure the function to collect host information by VBDIF interface.
– Run the arp collect host enable command to enable the function to
collect host information by VBDIF interface for IPv4 services.
– Run the ipv6 nd collect host enable command to enable the function to
collect host information by VBDIF interface for IPv6 services.
DAD is prohibited. This command is mandatory in IPv6 scenarios to prevent
service interruptions occurred because the system detects that the IPv6
address of another device is the same as the VBDIF interface's IP address.
6. Run quit
Step 2 Configure an L3VPN instance to advertise the static VPN routes destined for VNFs
to an EVPN instance.

(2020-10-09)
1. Create a route-policy so that the static VPN routes destined for VNFs can be
filtered out in the L3VPN instance. For configuration details, see Configuring a
Route-Policy. During configuration of an apply clause, run the apply
gateway-ip { origin-nexthop | ipv4-address } or apply ipv6 gateway-ip
{ origin-nexthop | ipv6-address } command to specify the original next-hop
address of a static VPN route as a gateway address.
the VPN instance.
the VPN instance.
instance so that the L3VPN instance advertises only the static VPN routes
destined for VNFs to the EVPN instance.
5. Run quit
6. Run quit
9. Run import-route static [ med med | route-policy route-policy-name ] *
Static routes are imported to the IPv4 or IPv6 address family of the BGP-VPN
instance.
If the load balancing function needs to be deployed on the network, specify
the import-route-multipath parameter so that the VPN instance can
advertise all the routes with the same destination address to the EVPN
instance.
11. (Optional) Run irb asymmetric
The asymmetric mode is enabled for IRB routes.
If L2GW/L3GWs are configured to advertise ARP or ND routes to each other,
skip this step. If L2GW/L3GWs are configured to advertise IRB or IPBv6 routes

(2020-10-09)
to each other, perform this step so that L2GW/L3GWs do not generate IP

prefix routes. This prevents route loops.
12. Run quit
Step 3 Configure L2GW/L3GWs to send IRB/IRBv6 or ARP/ND routes to DC-GWs.
2. Run peer { ipv4-address | group-name } advertise { irb | arp | irbv6 | nd }
L2GW/L3GWs are configured to advertise IRB/IRBv6 or ARP/ND routes.
If L2GW/L3GWs are configured to advertise ARP or ND routes, L2GW/L3GWs
send only the routes carrying MAC addresses and ARP information to DC-
GWs. If L2GW/L3GWs are configured to advertise IRB or IRBv6 routes, L2GW/
L3GWs send routes carrying MAC address, ARP information, and L3 VNIs to
DC-GWs. In this case, you need to run the irb asymmetric command on DC-
GWs so that DC-GWs do not generate IP prefix routes based on IP addresses
and L3 VNIs. This prevents route loops.
3. Run quit
4. Run quit
Step 4 Run commit
----End
3.2.33.4 (Optional) Configuring the Load Balancing Function

The load balancing function needs to be deployed to achieve balanced loads of
network traffic.
Procedure
● Configure PEs.
b. Enter the IPv4 or IPv6 address family view of a BGP-VPN instance.
▪ Run the ipv4-family vpn-instance vpn-instance-name command to

enter the IPv4 address family view of a BGP-VPN instance.

c. Run maximum load-balancing ebgp number [ ecmp-nexthop-
changed ]
The maximum number of equal-cost routes for load balancing is set.

(2020-10-09)
d. Run quit
e. Enter the BGP-VPNv4 or BGP-VPNv6 address family view.
▪ Run the ipv4-family vpnv4 command to enter the BGP-VPNv4

▪ Run the ipv6-family vpnv6 command to enter the BGP-VPNv6

f. Run peer { ipv4-address | group-name } capability-advertise add-path
{ send | receive | both }
The function to send or receive Add-Path routes from a specified peer is

enabled.
g. Run quit
Exit from the BGP-VPNv4 or BGP-VPNv6 address family view.

h. Run quit

i. Run commit

● Configure DC-GWs.



c. Run maximum load-balancing [ ebgp | ibgp ] number [ ecmp-
nexthop-changed ]

d. Run quit


enabled.
g. Run quit

(2020-10-09)
h. Run quit

i. Run commit

● Configure L2GW/L3GWs.



nexthop-changed ]

d. Run quit

f. Run bestroute add-path path-number path-number
BGP Add-Path is enabled, and the number of preferred routes that can be
selected is configured.
g. Run peer { ipv4-address | group-name } capability-advertise add-path

enabled.
h. Run peer { ipv4-address | group-name } advertise add-path path-
number path-number
The number of preferred routes that can be advertised to a specified peer

is configured.
i. Run quit

j. Run quit

k. Run commit
----End

(2020-10-09)
3.2.33.5 Verifying the Configurations of the NFVI Distributed Gateway

Function
After configuring the NFVI distributed gateway function, verify the configurations.
On DC-GWs, you can view the VPN peer relationships between DC-GWs and VNFs
and the information about the mobile phone routes received from VNFs.
Prerequisites
The NFVI distributed gateway function has been configured.
Procedure
Step 1 Run the display bgp { vpnv4 | vpnv6 } vpn-instance vpn-instance-name peer
command on DC-GWs to check whether the VPN peer relationships have been
established between DC-GWs and VNFs.
Step 2 Run the display bgp vpnv4 vpn-instance vpn-instance-name routing-table or
display bgp vpnv6 vpn-instance vpn-instance-name routing-table command on
DC-GWs to check whether DC-GWs can receive mobile phone routes from VNFs
and whether the next-hop addresses of the mobile phone routes are VNF
addresses.
Step 3 Run the display ip routing-table vpn-instance vpn-instance-name or display
ipv6 routing-table vpn-instance vpn-instance-name command on DC-GWs to
check whether the VPN routing tables of DC-GWs include mobile phone routes
and whether the outbound interfaces of the mobile phone routes are VBDIF
interfaces.
----End

(BGP VPNv4/VPNv6 over E2E SR Tunnels)
In the NFVI telco cloud solution, the NFVI distributed gateway function allows
mobile phone traffic to be processed by vUGWs and vMSEs and transmitted over a
DCN through E2E SR tunnels as well as being transmitted within a DCN in load
balancing mode.
Usage Scenario
processed by the vUGWs and vMSEs, the mobile phone traffic is forwarded over
the DCN to destination devices on the Internet. The destination devices send
gateway function.
Figure 3-154 shows the networking of an NFVI distributed gateway (BGP VPNv4/
VPNv6 over E2E SR tunnels). DC-GWs, which are the border gateways of the DCN,

(2020-10-09)
L3GW2 through IPUs.
In NFVI distributed gateway networking (BGP VPNv4/VPNv6 over E2E SR tunnels),

the number of BDs needs to be planned based on the number of network
segments corresponding to each IPU. An example assumes that the four IP
addresses planned for four IPUs belong to four network segments. In this case,
four BDs need to be planned. You need to configure the BDs and the
corresponding VBDIF interfaces on all L2GW/L3GWs and bind all the VBDIF
interfaces to the same L3VPN instance. In addition, the following functions need
to be deployed on the DCN:
The DC-GW can then advertise local loopback routes and default routes to
the L2GW/L3GW. A route-policy needs to be configured on DC-GWs so that
the routes sent by DC-GWs to L2GW/L3GWs carry gateway addresses and the
next hops of the mobile phone routes received by L2GW/L3GWs from DC-
GWs are the VNF addresses. In addition, the BGP EVPN peer relationships
established between DC-GWs and L2GW/L3GWs can be used to advertise the
routes carrying the IP addresses used for establishing BGP VPN peer
relationships, and the BGP EVPN peer relationships established between
L2GW/L3GWs can be used to synchronize the MAC or ARP routes and the IP
prefix routes carrying gateway addresses with IPUs.
section, DC-GWs function as EVPN RRs, and L2GW/L3GWs function as RR
clients. L2GW/L3GWs can use EVPN RRs to synchronize MAC or ARP routes as
well as the IP prefix routes carrying a VNF address as the destination address
with IPUs.
● Establish BGP VPNv4/v6 peer relationships between L2GW/L3GWs and PEs.
L2GW/L3GWs advertise mobile phone routes to PEs based on BGP VPNv4/v6
peer relationships. DC-GWs send mobile phone routes to L2GW/L3GWs based
on BGP EVPN peer relationships. Therefore, mobile phone routes need to be
re-encapsulated as BGP VPNv4/v6 routes on L2GW/L3GWs before being
advertised to PEs.
● Configure static default routes on PEs and configure the PEs to send static
default routes to L2GW/L3GWs based on BGP VPNv4/v6 peer relationships.
NOTE

(2020-10-09)
tasks:
L2GW/L3GWs.
On DC-GWs, the configuration involves only creating L3VPN instances and
establishing BGP EVPN peer relationships.
● Deploy L3VPN instances on PEs, and EBGP VPNv4 or EBGP VPNv6 has been
deployed between PEs and L2GW/L3GWs.

(2020-10-09)

By default, routes are recursed to a BD EVPN or BGP VPNv4/VPNv6 network over
MPLS LDP tunnels. If SR tunnels are used to carry service traffic, the function to
recurse routes over SR tunnels must be configured.
Context
Procedure
Policy.
● Configure an SR-MPLS BE tunnel-preferred policy on PEs, DC-GWs, and
L2GW/L3GWs so that users can choose to recurse routes over SR-MPLS BE
tunnels.
a. Run system-view


SR-MPLS BE tunnels are enabled to take precedence over other tunnels.

d. Run commit
----End
3.2.34.2 Configuring Route Advertisement on PEs

The route advertisement allows PEs to advertise default static routes to L2GW/
L3GWs based on BGP VPNv4 peer relationships.
Procedure
Step 2 Configure default static VPN routes.

● Run the ip route-static vpn-instance vpn-instance-name 0.0.0.0 { 0.0.0.0 |
0 } { nexthop-address | interface-type interface-number [ nexthop-address ] }

(2020-10-09)
● Run the ipv6 route-static vpn-instance vpn-instance-name ::0 { nexthop-

Step 4 Enter the IPv4 or IPv6 address family view of a BGP-VPN instance.
● Run the ipv4-family vpn-instance vpn-instance-name command to enter the
IPv4 address family view of a BGP-VPN instance.
Step 5 Run network { 0.0.0.0 0 | :: 0 }
Default static VPN routes are imported to the IPv4 or IPv6 address family of the
BGP-VPN instance.
Step 6 Run quit
Step 7 Run quit
Step 8 Run commit
----End

construct their own forwarding entries based on the received EVPN or BGP routes.
Procedure
Step 1 Configure DC-GWs to advertise the VPN loopback routes and the mobile phone
routes received from VNFs through EVPN.
1. Run system-view
interface is configured with an IPv6 address.

(2020-10-09)

interface.
6. Run quit
7. Create a route-policy to filter and modify the advertised and received routes.
For configuration details, see Configuring a Route-Policy. A route-policy must
support the following functions:
– Export route-policy: An if-match clause configured in the route-policy can
be used to filter VPN loopback routes and mobile phone routes in the
L3VPN instance. You can run the apply gateway-ip { origin-nexthop |
ipv4-address } or apply ipv6 gateway-ip { origin-nexthop | ipv6-
address } command to configure the original next-hop address of mobile
phone routes as a gateway address.
– Import route-policy: You can run the apply gateway-ip none or apply
ipv6 gateway-ip none command to delete gateway addresses from the
routes received from L2GW/L3GWs to ensure that the BGP VPN packets
sent by DC-GWs to VNFs can be recursed over SR tunnels, instead of
being forwarded through VBDIF interfaces based on gateway addresses
(DC-GWs do not have VBDIF interfaces).
the VPN instance.
the VPN instance.
instance so that the L3VPN instance advertises only the mobile phone routes
and VPN loopback routes to the EVPN instance.
11. Run import route-policy policy-name evpn
The L3VPN instance is bound to an import route-policy. This route-policy is
used to filter the routes received by the L3VPN instance so that the gateway
addresses are deleted from the routes received from L2GW/L3GWs.
12. Run quit
13. Run quit
Route-Policy.

(2020-10-09)

export
18. Run quit
BGP-VPN instance.
22. Run quit
23. Run quit
2. Run quit

(2020-10-09)

policy-name export
8. Run peer { ipv4-address | ipv6-address | group-name } reflect-client
The RR function is configured to reflect BGP VPN routes. This function allows
VNFs to share mobile phone routes.
9. Run quit
Step 3 Configure the RR function in BGP EVPN to synchronize EVPN routes between
L2GW/L3GWs.
2. Run peer { group-name | ipv4-address } reflect-client
An L2GW/L3GW is configured as an RR client.
Step 4 Run commit
----End

BGP routes.
Procedure
1. Run system-view

(2020-10-09)

5. Run quit
1. Create a route-policy to filter the locally generated static VPN routes destined
for VNFs. For configuration details, see Configuring a Route-Policy. During
configuration of an apply clause, run the apply gateway-ip { origin-nexthop
| ipv4-address } or apply ipv6 gateway-ip { origin-nexthop | ipv6-address }
command to specify the original next-hop address of a static VPN route as a
gateway address.
the VPN instance.
the VPN instance.
destined for VNFs to the EVPN instance.
5. Run quit
6. Run quit
instance.

(2020-10-09)

instance is enabled. If the load balancing function needs to be deployed on
the network, specify the import-route-multipath parameter so that the VPN
instance can advertise all the routes with the same destination address to the
EVPN instance.
The asymmetric mode is enabled for IRB routes. If L2GW/L3GWs are
configured to advertise ARP or ND routes to each other, skip this step. If
L2GW/L3GWs are configured to advertise IRB or IPBv6 routes to each other,
perform this step so that L2GW/L3GWs do not generate IP prefix routes. This
prevents route loops.
12. Run quit
Step 3 Configure the function to regenerate routes for PEs. Specifically, configure the
function to regenerate IP prefix routes as VPNv4/VPNv6 routes.
The function to add the regeneration flag to the routes received from the DC-
GWs is enabled.
3. Run quit
4. Enter the BGP-VPNv4 or BGP-VPNv6 address family view.
– Run the ipv4-family vpnv4 command to enter the BGP-VPNv4 address
family view.
family view.
{ mac-ip | ip | mac-ipv6 | ipv6 }
The function to advertise the routes regenerated by the EVPN address family
to a BGP VPNv4/VPNv6 peer is enabled.
6. Run quit
7. Run quit
Step 4 (Optional) Configure a route-policy to allow L2GW/L3GWs to send only the
mobile phone routes generated by the directly connected VNFs to PEs. This step is
mandatory if a VNF is directly connected to only one L2GW/L3GW. Ensure that
this L2GW/L3GW can receive the mobile phone routes generated by the directly
connected VNF only from DC-GWs.
1. Create a route-policy to filter the mobile phone routes generated by a locally
generated VNF. For configuration details, see Configuring a Route-Policy.

(2020-10-09)

3. Enter the BGP-VPNv4 or BGP-VPNv6 address family view.
family view.
family view.
export
An export route-policy is applied to the routes destined for PEs.
5. Run quit
6. Run quit
Step 5 Run commit
----End
3.2.34.5 Configuring the Load Balancing Function

network traffic.
Procedure
● Configure PEs.


c. Run maximum load-balancing ebgp number [ ecmp-nexthop-
changed ]
d. Run quit
e. Run quit
f. Run commit

(2020-10-09)



nexthop-changed ]
d. Run quit
enabled.
g. Run quit
h. Run quit
i. Run commit


nexthop-changed ]
d. Run quit

(2020-10-09)

enabled.
number path-number
is configured.
i. Run quit
j. Run quit
k. Run commit
----End
3.2.34.6 Verifying the Configurations of the NFVI DistributedGateway

Function
Prerequisites
Procedure
addresses.

(2020-10-09)
interfaces.
----End

(BGP EVPN over E2E SR Tunnels)
In the NFVI telco cloud solution, the NFVI distributed gateway function allows
mobile phone traffic to be processed by vUGWs and vMSEs and transmitted over a
DCN through E2E SR tunnels as well as being transmitted within a DCN in load
balancing mode.
Usage Scenario
processed by the vUGWs and vMSEs, the mobile phone traffic is forwarded over
the DCN to destination devices on the Internet. The destination devices send
gateway function.
Figure 3-155 shows the networking of an NFVI distributed gateway (BGP EVPN
over E2E SR tunnels). DC-GWs, which are the border gateways of the DCN,
L3GW2 through IPUs.
In NFVI distributed gateway networking (BGP EVPN over E2E SR tunnels), the
number of BDs needs to be planned based on the number of network segments
corresponding to each IPU. An example assumes that the four IP addresses
planned for four IPUs belong to four network segments. In this case, four BDs
need to be planned. You need to configure the BDs and the corresponding VBDIF
interfaces on all L2GW/L3GWs and bind all the VBDIF interfaces to the same
L3VPN instance. In addition, the following functions need to be deployed on the
DCN:
section, BGP EVPN peer relationships are established between all L2GW/
L3GWs, PEs, and DC-GWs, DC-GWs are deployed as RRs to reflect EVPN
routes, and other devices function as RR clients. The functions of a BGP EVPN
RR are as follows:
– DC-GWs can reflect the mobile phone routes learned by VNFs to L2GW/
L3GWs and PEs so that mobile phone routes can be transmitted outside
the DCN and the traffic sent to mobile phone users can be introduced to
the DCN. Route-policies need to be configured DC-GWs so that the

(2020-10-09)
mobile phone routes sent by DC-GWs to L2GW/L3GWs and PEs carry the
gateway addresses which are VNFs' loopback addresses.
– DC-GWs receive the IP prefix routes destined for VNFs from an L2GW/
L3GW based on BGP EVPN peer relationships and reflect the IP prefix
routes to PEs and other L2GWs/L3GWs. The EVPN RR can also be used to
synchronize the MAC or ARP routes of IPUs and the IP prefix routes
destined for VNFs between L2GW/L3GWs.
● Configure static default routes on PEs and use the EVPN RRs to reflect the
static default routes to L2GW/L3GWs.
NOTE

(2020-10-09)
tasks:
L2GW/L3GWs.
On DC-GWs, the configuration involves only creating L3VPN instances and
establishing BGP EVPN peer relationships.

(2020-10-09)

By default, routes are recursed to a BD EVPN or BGP VPNv4/VPNv6 network over
MPLS LDP tunnels. If SR tunnels are used to carry service traffic, the function to
recurse routes over SR tunnels must be configured.
Context
Procedure
Policy.
● Configure an SR-MPLS BE tunnel-preferred policy on PEs, DC-GWs, and
L2GW/L3GWs so that users can choose to recurse routes over SR-MPLS BE
tunnels.
a. Run system-view


SR-MPLS BE tunnels are enabled to take precedence over other tunnels.

d. Run commit
----End
3.2.35.2 Configuring Route Advertisement on PEs

The route advertisement function allows PEs to advertise default static routes to
L2GW/L3GWs through BGP EVPN RRs.
Procedure
Step 2 Create a route-policy to filter and modify the advertised and received routes. For
configuration details, see Configuring a Route-Policy. You can run the apply
gateway-ip none or apply ipv6 gateway-ip none command to delete gateway
addresses from the VNF routes received from L2GW/L3GWs so that the routes
sent from PEs to VNFs can be recursed over SR tunnels, instead of being
forwarded based on gateway addresses.
Step 3 Configure default static VPN routes.

(2020-10-09)
● Run the ip route-static vpn-instance vpn-instance-name 0.0.0.0 { 0.0.0.0 |

0 } { nexthop-address | interface-type interface-number [ nexthop-address ] }
● Run the ipv6 route-static vpn-instance vpn-instance-name :: 0 { nexthop-
Step 4 Run ip vpn-instance vpn-instance-name
Step 5 Enter the IPv4 or IPv6 address family view of the VPN instance.
● Run the ipv4-family command to enter the IPv4 address family view of the
VPN instance.
● Run the ipv6-family command to enter the IPv6 address family view of the
VPN instance.
Step 6 Run import route-policy policy-name evpn
The L3VPN instance is bound to an import route-policy. This route-policy is used

to filter the routes received by the L3VPN instance so that the gateway addresses
are deleted from the routes received from L2GW/L3GWs.
Step 7 Run quit
Step 8 Run quit
Step 10 Enter the IPv4 or IPv6 address family view of a BGP-VPN instance.
Step 11 Run network { 0.0.0.0 0 | :: 0 }
Default static VPN routes are imported to the IPv4 or IPv6 address family of the
BGP-VPN instance.
Step 12 Run advertise l2vpn evpn
The function to advertise IP routes from the VPN instance to the EVPN instance is
enabled.
Step 13 Run quit
Step 14 Run quit

(2020-10-09)
Step 15 Run commit

----End

construct their own forwarding entries based on the received EVPN routes.
Procedure
Step 1 Configure DC-GWs to advertise the VPN loopback routes and the mobile phone
routes received from VNFs through EVPN.
1. Run system-view
loopback interface is configured with an IPv6 address.
interface.
6. Run quit
7. Create a route-policy to filter and modify the advertised and received routes.
For configuration details, see Configuring a Route-Policy. A route-policy must
support the following functions:
– Export route-policy: An if-match clause configured in the route-policy can
be used to filter VPN loopback routes and mobile phone routes in the
L3VPN instance. You can run the apply gateway-ip { origin-nexthop |
ipv4-address } or apply ipv6 gateway-ip { origin-nexthop | ipv6-
address } command to configure the original next-hop address of mobile
phone routes as a gateway address.
– Import route-policy: You can run the apply gateway-ip none or apply
ipv6 gateway-ip none command to delete gateway addresses from the
routes received from L2GW/L3GWs to ensure that the BGP VPN packets
sent by DC-GWs to VNFs can be recursed over SR tunnels, instead of
being forwarded through VBDIF interfaces based on gateway addresses
(DC-GWs do not have VBDIF interfaces).

(2020-10-09)

the VPN instance.
the VPN instance.
instance so that the L3VPN instance advertises only the mobile phone routes
and VPN loopback routes to the EVPN instance.
11. Run import route-policy policy-name evpn
The L3VPN instance is bound to an import route-policy. This route-policy is
used to filter the routes received by the L3VPN instance so that the gateway
addresses are deleted from the routes received from L2GW/L3GWs.
12. Run quit
13. Run quit
Route-Policy.
export
18. Run quit
BGP-VPN instance.

(2020-10-09)
22. Run quit
23. Run quit

2. Run quit


policy-name export
8. Run peer { ipv4-address | ipv6-address | group-name } reflect-client
The RR function is configured to reflect BGP VPN routes. This function allows
VNFs to share mobile phone routes.
9. Run quit
Step 3 Configure RRs in BGP EVPN so that EVPN routes can be synchronized between
L2GW/L3GWs and the EVPN routes sent by L2GW/L3GWs can be reflected to PEs.

(2020-10-09)
2. Run peer { group-name | ipv4-address } reflect-client
L2GW/L3GWs and PEs are configured as RR clients.

3. Run peer { group-name | ipv4-address } next-hop-invariable
DC-GWs are configured not to modify the next hop during route
advertisement to PEs and L2GW/L3GWs and the next-hop address is still the
IP address of an L2GW/L3GW when a PE receives routes from a VNF. Upon
receipt of default routes, the next -hop addresses of L2GW/L3GWs are the IP
addresses of PEs. In this way, routes are recursed over E2E SR-MPLS TE
tunnels.
Step 4 Run commit
----End

BGP routes.
Procedure
1. Run system-view



5. Run quit

(2020-10-09)
1. Create a route-policy so that the static VPN routes destined for VNFs can be
filtered out in the L3VPN instance. For configuration details, see Configuring a
Route-Policy. During configuration of an apply clause, run the apply
gateway-ip { origin-nexthop | ipv4-address } or apply ipv6 gateway-ip
{ origin-nexthop | ipv6-address } command to specify the original next-hop
address of a static VPN route as a gateway address.

the VPN instance.
the VPN instance.

destined for VNFs to the EVPN instance and gateway addresses are added to
the static VPN routes.
5. Run quit
6. Run quit


instance.
instance is enabled. If the load balancing function needs to be deployed on
the network, specify the import-route-multipath parameter so that the VPN
instance can advertise all the routes with the same destination address to the
EVPN instance.
The asymmetric mode is enabled for IRB routes. If L2GW/L3GWs are

configured to advertise ARP or ND routes to each other, skip this step. If
L2GW/L3GWs are configured to advertise IRB or IPBv6 routes to each other,

(2020-10-09)
perform this step so that L2GW/L3GWs do not generate IP prefix routes. This
prevents route loops.
12. Run quit
Step 3 Run commit
----End
3.2.35.5 Configuring the Load Balancing Function

network traffic.
Procedure
● Configure PEs.



nexthop-changed ]

d. Run quit


enabled.
g. Run quit

h. Run quit

i. Run commit

(2020-10-09)



nexthop-changed ]

d. Run quit


enabled.
g. Run quit

h. Run quit

i. Run commit




nexthop-changed ]

d. Run quit

(2020-10-09)

enabled.
number path-number
is configured.
i. Run quit
j. Run quit
k. Run commit
----End
3.2.35.6 Verifying the Configurations of the NFVI DistributedGateway

Function
Prerequisites
Procedure
addresses.

(2020-10-09)
interfaces.
----End
3.2.36 Configuration Examples for EVPN

This section provides EVPN configuration examples.
3.2.36.1 Example for Configuring an Eth-Trunk Sub-Interface to Access a BD

EVPN (Dual-Homing Active-Active)
This section provides an example for configuring hybrid forwarding of Layer 2 and
Layer 3 traffic in a scenario where a CE is dual-homed to PEs of a BD EVPN in
active-active mode.
On the network shown in Figure 3-156, to allow sites to communicate over the
backbone network, configure EVPN so that the sites can exchange EVPN routes to
transmit Layer 2 traffic. If the sites belong to the same network segment, an EVPN
instance is created on each PE to store MAC routes and perform Layer 2
forwarding based on MAC addresses. A route reflector (RR) is deployed to reflect
EVPN routes.
To improve reliability in dual-homing active-active scenarios, configure the local

and remote FRR function for MAC routes and BFD on PE1 and PE2.
Figure 3-156 Configuring an Eth-Trunk sub-interface to access a BD EVPN in dual-

homing active-active mode
NOTE

(2020-10-09)
Configuration Notes
When configuring an Eth-Trunk sub-interface to access a BD EVPN in dual-homing
active-active mode, note the following:
● Currently, the dual-homing active-active mode can only be implemented by
configuring an E-Trunk.
● RTs in the export RT list of the EVPN instance on the local PE must be the
same as RTs in the import RT list of the remote PE.
● Using the local loopback interface address of each PE as an EVPN source
address is recommended.
1. Configure an IGP on the backbone network to allow PEs and the RR to
communicate.
2. Configure basic MPLS functions and enable MPLS LDP to establish LDP LSPs
4. Configure an ESI and E-Trunk to implement the dual-homing active-active
networking.
5. Configure the local and remote FRR function for MAC routes on dual-homing
PEs.
6. On PE1 and PE2, configure a BFD session to monitor Eth-Trunk member
interfaces; configure a BFD session and associate it with the access-side Eth-
Trunk interface.
7. Establish a BGP EVPN peer relationship.
8. Configure each CE to access the PEs through the Eth-Trunk interface.
9. Configure IP addresses on the same network segment on CE1 and CE2.
Perform a ping on the same network segment to instruct the local and
remote PEs to learn the MAC address of the CE.
Data Preparation
● EVPN instance name: evpna
● EVPN instance evpna's RDs (100:1, 200:1, and 300:1) and RTs (1:1) on each PE
● Hold-down time on the access-side interface of each PE, which is the time
elapsed before a PE waits for the EVPN service on the network side to recover
and then responds after the interface goes up: 600000 ms
● UDP port number for EVPN pruning status negotiation between active-active
PEs: 1345
● Name of the BFD session for detecting Eth-Trunk member interfaces: PEtoCE;
names of the BFD sessions associated with the access-side Eth-Trunk
interfaces: pe1tope2 and pe2tope1

(2020-10-09)
Procedure
Step 1 Assign an IP address to each interface on the RR and PEs according to Figure
3-156. For configuration details, see Configuration Files in this section.
Step 2 Configure an IGP on the backbone network to allow PEs and the RR to
communicate. OSPF is used in this example.
# Configure PE1.
[~PE1] ospf 1
[*PE1-ospf-1-area-0.0.0.0] commit
[~PE1-ospf-1-area-0.0.0.0] quit
[~PE1-ospf-1] quit
# Configure PE2.
[~PE2] ospf 1
[~PE2-ospf-1] quit
# Configure PE3.
[~PE3] ospf 1
[~PE3-ospf-1] quit
# Configure the RR.

[~RR] ospf 1
[*RR-ospf-1] area 0
[*RR-ospf-1-area-0.0.0.0] network 10.1.1.0 0.0.0.255
[*RR-ospf-1-area-0.0.0.0] commit
[~RR-ospf-1-area-0.0.0.0] quit
[~RR-ospf-1] quit
After the configurations are complete, PE1, PE2, and PE3 can establish OSPF
neighbor relationships with the RR. Run the display ospf peer command. The
command output shows that State is Full. Run the display ip routing-table
command. The command output shows that the RR and PEs have learned the
routes to Loopback1 of one another.
[~PE1] display ospf peer
(M) Indicates MADJ neighbor
OSPF Process 1 with Router ID 1.1.1.1

Neighbors
Area 0.0.0.0 interface 10.1.1.1 (GE2/0/0)'s neighbors

Router ID: 3.3.3.3 Address: 10.1.1.2

(2020-10-09)
State: Full Mode:Nbr is Master Priority: 1

DR: 10.1.1.1 BDR: 10.1.1.2 MTU: 0
Dead timer due in 38 sec
Retrans timer interval: 5
Neighbor is up for 00h01m12s
Authentication Sequence: [ 0 ]
------------------------------------------------------------------------------

2.2.2.2/32 OSPF 10 2 D 10.1.1.2 GigabitEthernet2/0/0
Step 3 Configure basic MPLS functions and enable MPLS LDP to establish LDP LSPs on
the backbone network.
# Configure PE1.
[*PE1] mpls
[*PE1-mpls] quit
[*PE1] mpls ldp
# Configure PE2.
[*PE2] mpls
[*PE2-mpls] quit
[*PE2] mpls ldp
# Configure the RR.

[~RR] mpls lsr-id 3.3.3.3
[*RR] mpls
[*RR-mpls] quit
[*RR] mpls ldp
[*RR-mpls-ldp] quit
[*RR] interface gigabitethernet 1/0/0
[*RR-GigabitEthernet1/0/0] mpls
[*RR-GigabitEthernet1/0/0] mpls ldp
[*RR-GigabitEthernet1/0/0] quit

(2020-10-09)

[*RR-GigabitEthernet3/0/0] commit
[~RR-GigabitEthernet3/0/0] quit
# Configure PE3.
[*PE3] mpls
[*PE3-mpls] quit
[*PE3] mpls ldp
After the configurations are complete, LDP sessions can be established between
the PEs and RR. Run the display mpls ldp session command. The command
output shows that Status is Operational. Then, run the display mpls ldp lsp
command. The command output shows that an LDP LSP has been successfully
established on each device.
--------------------------------------------------------------------------
--------------------------------------------------------------------------
--------------------------------------------------------------------------
[~PE1] display mpls ldp lsp
LDP LSP Information
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
1.1.1.1/32 3/NULL 3.3.3.3 127.0.0.1 Loop1
*1.1.1.1/32 Liberal/32828 DS/3.3.3.3
2.2.2.2/32 NULL/32829 - 10.1.1.2 GE2/0/0
2.2.2.2/32 32829/32829 3.3.3.3 10.1.1.2 GE2/0/0
3.3.3.3/32 NULL/3 - 10.1.1.2 GE2/0/0
3.3.3.3/32 32828/3 3.3.3.3 10.1.1.2 GE2/0/0
4.4.4.4/32 NULL/32830 - 10.1.1.2 GE2/0/0
4.4.4.4/32 32830/32830 3.3.3.3 10.1.1.2 GE2/0/0
-------------------------------------------------------------------------------
Step 4 Configure an EVPN instance on each PE.

# Configure PE1.
[~PE1] evpn vpn-instance evpna bd-mode

(2020-10-09)
[*PE1-evpn-instance-evpna] route-distinguisher 100:1

[*PE1-evpn-instance-evpna] vpn-target 1:1
[*PE1-evpn-instance-evpna] quit
[*PE1-bd10] evpn binding vpn-instance evpna
[*PE1-bd10] quit
[*PE1] commit
# Configure PE2.
[*PE2-bd10] quit
[*PE2] commit
# Configure PE3.
[*PE3-bd10] quit
[*PE3] commit
Step 5 Configure a source address on each PE.

# Configure PE1.
[*PE1] commit
# Configure PE2.
[*PE2] commit
# Configure PE3.
[*PE3] commit
Step 6 Configure an ESI and E-Trunk to implement the dual-homing active-active

networking.
# Configure PE1.
[~PE1] lacp e-trunk system-id 00e0-fc00-0000
[*PE1] lacp e-trunk priority 1
[*PE1] e-trunk 1
[*PE1-e-trunk-1] peer-address 2.2.2.2 source-address 1.1.1.1
[*PE1-Eth-Trunk10] mode lacp-static
[*PE1-Eth-Trunk10] esi 0000.1111.2222.1111.1111
[*PE1-Eth-Trunk10] timer es-recovery 120

(2020-10-09)

[*PE1-GigabitEthernet1/0/0] carrier up-hold-time 600000
[*PE1] evpn enhancement port 1345
[*PE1] commit
# Configure PE2.
[*PE2] e-trunk 1
[*PE2-Eth-Trunk10] esi 0000.1111.2222.1111.1111
[*PE2-Eth-Trunk10] timer es-recovery 120
[*PE2-GigabitEthernet1/0/0] carrier up-hold-time 600000
[*PE2] evpn enhancement port 1345
[*PE2] commit
# Configure PE3.
[~PE3] interface eth-trunk 10
[*PE3] commit
Step 7 Configure the local and remote FRR function for MAC routes on dual-homing PEs.
# Configure PE1.
[~PE1] evpn
[*PE1-evpn] vlan-extend private enable
[*PE1-evpn] vlan-extend redirect enable
[*PE1-evpn] local-remote frr enable
[*PE1-evpn] quit
[*PE1] commit
# Configure PE2.
[~PE2] evpn
[*PE2-evpn] quit
[*PE2] commit
Step 8 On PE1 and PE2, configure a BFD session to monitor Eth-Trunk member interfaces;
configure a BFD session and associate it with the access-side Eth-Trunk interface.

(2020-10-09)
# Configure PE1.
[~PE1] bfd
[*PE1-bfd] quit
[*PE1] bfd PEtoCE bind peer-ip default-ip interface GigabitEthernet1/0/0
[*PE1-bfd-session-PEtoCE] discriminator local 3
[*PE1-bfd-session-PEtoCE] discriminator remote 4
[*PE1-bfd-session-PEtoCE] quit
[*PE1] bfd pe1tope2 bind peer-ip 2.2.2.2
[*PE1-bfd-session-pe1tope2] quit
[*PE1] bfd pe2tope1 bind peer-ip 2.2.2.2 track-interface interface Eth-Trunk10
[*PE1-Eth-Trunk10] es track bfd pe1tope2
[*PE1] commit
# Configure PE2.
[~PE2] bfd
[*PE2-bfd] quit
[*PE2] bfd PEtoCE bind peer-ip default-ip interface GigabitEthernet1/0/0
[*PE2-bfd-session-PEtoCE] discriminator local 4
[*PE2-bfd-session-PEtoCE] discriminator remote 3
[*PE2-bfd-session-PEtoCE] quit
[*PE2] bfd pe1tope2 bind peer-ip 1.1.1.1 track-interface interface Eth-Trunk10
[*PE2] bfd pe2tope1 bind peer-ip 1.1.1.1
[*PE2-Eth-Trunk10] es track bfd pe2tope1
[*PE2] commit
Step 9 Establish a BGP EVPN peer relationship.
# Configure PE1.
[~PE1] bgp 100
[*PE1-bgp-af-evpn] timer df-delay 0
[*PE1-bgp] quit
[*PE1] commit
# Configure PE2.
[~PE2] bgp 100
[*PE2-bgp-af-evpn] timer df-delay 0
[*PE2-bgp] quit
[*PE2] commit
# Configure PE3.

(2020-10-09)
[~PE3] bgp 100

[*PE3-bgp] quit
[*PE3] commit
# Configure the RR.

[~RR] bgp 100
[*RR-bgp] peer 1.1.1.1 as-number 100
[*RR-bgp] peer 1.1.1.1 connect-interface loopback 1
[*RR-bgp] l2vpn-family evpn
[*RR-bgp-af-evpn] undo policy vpn-target
[*RR-bgp-af-evpn] peer 1.1.1.1 enable
[*RR-bgp-af-evpn] peer 1.1.1.1 reflect-client
[*RR-bgp-af-evpn] quit
[*RR-bgp] quit
[*RR] commit
After completing the configurations, run the display bgp evpn peer command on
the RR. The command output shows that BGP peer relationships have been
established between the PEs and RR and are in the Established state.
[~RR] display bgp evpn peer


1.1.1.1 4 100 10 18 0 00:00:11 Established 6
2.2.2.2 4 100 10 20 0 00:00:12 Established 6
4.4.4.4 4 100 6 18 0 00:00:13 Established 2
Step 10 Configure the CE to access the PEs through the Eth-Trunk interface.
# Configure CE1.
[~CE1] vlan 2
[*CE1-vlan2] quit
[*CE1] interface Eth-Trunk10
[*CE1-Eth-Trunk10] portswitch
[*CE1-Eth-Trunk10] port link-type trunk
[*CE1-Eth-Trunk10] port trunk allow-pass vlan 2
[*CE1-Eth-Trunk10] mode lacp-static
[*CE1] commit
# Configure CE2.
[~CE2] vlan 2
[*CE2-vlan2] quit
[*CE2] interface Eth-Trunk 10

(2020-10-09)
[*CE2] commit
Step 11 Configure IP addresses on the same network segment on CE1 and CE2 and
perform a ping operation on the same network segment.
# Configure CE1.
[~CE1] interface vlanif2
[~CE1-Vlanif2] ip address 192.168.1.11 24
[*CE1-Vlanif2] quit
[~CE1] commit
# Configure CE2.
[*CE2-Vlanif2] ip address 192.168.1.12 24
[*CE2-Vlanif2] quit
[~CE2] commit
# On CE1, ping an IP address on the same network segment as CE2. The following
example uses the command output on CE1.
[~CE1] ping 192.168.1.12
--- 192.168.1.12 ping statistics ---

0.00% packet loss

Run the display bgp evpn all routing-table mac-route command on PE3. The
command output shows the MAC route sent by the remote PE and the MAC route
destined for CE1. In the active-active scenario, the next hops of the MAC routes on
CE1 are PE1 and PE2, implementing load balancing.


*>i 0:48:00e0-fc12-5678:32:0.0.0.0 1.1.1.1
*>i 0:48:00e0-fc12-5678:32:0.0.0.0 2.2.2.2

(2020-10-09)
*> 0:48:00e0-fc12-3333:32:0:0.0.0.0 0.0.0.0
EVPN-Instance evpna:
*>i 0:48:00e0-fc12-5678:32:0.0.0.0 1.1.1.1
*i 2.2.2.2
*> 0:48:00e0-fc12-3333:32:0:0.0.0.0 0.0.0.0
----End
Configuration Files
#
sysname PE1
#
lacp e-trunk system-id 00e0-fc00-0000
lacp e-trunk priority 1
#
evpn enhancement port 1345
#
evpn
local-remote frr enable
#
mac-duplication
#
evpn vpn-instance evpna bd-mode
#
bfd
#
mpls lsr-id 1.1.1.1
#
mpls
#
bridge-domain 10
evpn binding vpn-instance evpna
#
mpls ldp
#
ipv4-family
#
e-trunk 1
peer-address 2.2.2.2 source-address 1.1.1.1
authentication-mode enhanced-hmac-sha256
#
mode lacp-static
e-trunk 1
es track bfd pe1tope2
esi 0000.1111.2222.1111.1111
timer es-recovery 120
#
rewrite pop single
bridge-domain 10
#
undo shutdown

(2020-10-09)
carrier up-hold-time 600000

eth-trunk 10
#
undo shutdown
ip address 10.1.1.1 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 1.1.1.1 255.255.255.255
#
bfd pe1tope2 bind peer-ip 2.2.2.2
#
bfd pe2tope1 bind peer-ip 2.2.2.2 track-interface interface Eth-Trunk10
#
bfd PEtoCE bind peer-ip default-ip interface GigabitEthernet1/0/0
#
bgp 100
#
ipv4-family unicast
peer 3.3.3.3 enable
#
l2vpn-family evpn
policy vpn-target
timer df-delay 0
peer 3.3.3.3 enable
#
ospf 1
area 0.0.0.0
network 1.1.1.1 0.0.0.0
network 10.1.1.0 0.0.0.255
#
#
return
#
sysname PE2
#
#
evpn enhancement port 1345
#
evpn
#
mac-duplication
#
#
bfd
#
mpls lsr-id 2.2.2.2

(2020-10-09)
#
mpls
#
bridge-domain 10
#
mpls ldp
#
ipv4-family
#
e-trunk 1
#
mode lacp-static
e-trunk 1
es track bfd pe2tope1
esi 0000.1111.2222.1111.1111
timer es-recovery 120
#
rewrite pop single
bridge-domain 10
#
undo shutdown
carrier up-hold-time 600000
eth-trunk 10
#
undo shutdown
ip address 10.2.1.1 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 2.2.2.2 255.255.255.255
#
bfd pe1tope2 bind peer-ip 1.1.1.1 track-interface interface Eth-Trunk10
#
bfd pe2tope1 bind peer-ip 1.1.1.1
#
bfd PEtoCE bind peer-ip default-ip interface GigabitEthernet1/0/0
#
bgp 100
#
ipv4-family unicast
peer 3.3.3.3 enable
#
l2vpn-family evpn
policy vpn-target
timer df-delay 0
peer 3.3.3.3 enable
#
ospf 1
area 0.0.0.0

(2020-10-09)
network 2.2.2.2 0.0.0.0

network 10.2.1.0 0.0.0.255
#
#
return

#
sysname PE3
#
#
mpls lsr-id 4.4.4.4
#
mpls
#
bridge-domain 10
#
mpls ldp
#
ipv4-family
#
#
rewrite pop single
bridge-domain 10
#
undo shutdown
ip address 10.3.1.2 255.255.255.0
mpls
mpls ldp
#
undo shutdown
eth-trunk 10
#
interface LoopBack1
ip address 4.4.4.4 255.255.255.255
#
bgp 100
#
ipv4-family unicast
peer 3.3.3.3 enable
#
l2vpn-family evpn
policy vpn-target
peer 3.3.3.3 enable
#
ospf 1
area 0.0.0.0
network 4.4.4.4 0.0.0.0
network 10.3.1.0 0.0.0.255
#
#
return
● RR configuration file

(2020-10-09)
#
sysname RR
#
mpls lsr-id 3.3.3.3
#
mpls
#
mpls ldp
#
ipv4-family
#
undo shutdown
ip address 10.1.1.2 255.255.255.0
mpls
mpls ldp
#
undo shutdown
ip address 10.2.1.2 255.255.255.0
mpls
mpls ldp
#
undo shutdown
ip address 10.3.1.1 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 3.3.3.3 255.255.255.255
#
bgp 100
#
ipv4-family unicast
peer 1.1.1.1 enable
peer 2.2.2.2 enable
peer 4.4.4.4 enable
#
l2vpn-family evpn
peer 1.1.1.1 enable
peer 1.1.1.1 reflect-client
peer 2.2.2.2 enable
peer 4.4.4.4 enable
#
ospf 1
area 0.0.0.0
network 3.3.3.3 0.0.0.0
network 10.1.1.0 0.0.0.255
network 10.2.1.0 0.0.0.255
network 10.3.1.0 0.0.0.255
#
return
#
sysname CE1
#
vlan batch 2
#

(2020-10-09)
vlan 2
#
interface Vlanif2
ip address 192.168.1.11 255.255.255.0
#
portswitch
port link-type trunk
port trunk allow-pass vlan 2
mode lacp-static
#
undo shutdown
eth-trunk 10
#
undo shutdown
eth-trunk 10
#
return

#
sysname CE2
#
vlan batch 2
#
vlan 2
#
interface Vlanif2
ip address 192.168.1.12 255.255.255.0
#
portswitch
#
undo shutdown
eth-trunk 10
#
return
3.2.36.2 Example for Configuring an Eth-Trunk Sub-Interface to Access a BD

EVPN (Dual-Homing Single-Active)
This section provides an example for configuring hybrid forwarding of Layer 2 and
Layer 3 traffic in a scenario where a CE is dual-homed to PEs of a BD EVPN in
single-active mode.
On the network shown in Figure 3-157, to allow sites to communicate over the
backbone network, configure EVPN so that the sites can exchange EVPN routes to
transmit Layer 2 traffic. If the sites belong to the same network segment, an EVPN
instance is created on each PE to store MAC routes and perform Layer 2
forwarding based on MAC addresses. An RR is deployed to reflect EVPN routes.
To improve reliability in dual-homing single-active scenarios, configure the local
and remote FRR function for MAC routes on PE1 and PE2.

(2020-10-09)
Figure 3-157 Configuring an Eth-Trunk sub-interface to access a BD EVPN in dual-

homing single-active mode
NOTE
Configuration Notes
When configuring an Eth-Trunk sub-interface to access a BD EVPN in dual-homing
single-active mode, note the following:
● Currently, the dual-homing single-active mode can only be implemented by
configuring an E-Trunk.
● RTs in the export RT list of the EVPN instance on the local PE must be the
same as RTs in the import RT list of the remote PE.
communicate.
4. Configure an ESI and E-Trunk to implement the dual-homing single-active
networking.
5. Configure the local and remote FRR function for MAC routes on dual-homing
PEs.

(2020-10-09)
6. Create a BFD session and bind it to the E-Trunk on PE1 and PE2 to speed up
traffic switching if a fault occurs.
7. Establish a BGP EVPN peer relationship.
8. Configure the CE to access the PEs through the Eth-Trunk interface.
9. Configure IP addresses on the same network segment on CE1 and CE2.
Perform a ping on the same network segment to instruct the local and
remote PEs to learn the MAC address of the CE.
Data Preparation
● EVPN instance name: evpna
● EVPN instance evpna's RDs (100:1, 200:1, and 300:1) and RTs (1:1) on each PE
● Name of the BFD session bound to the E-Trunk: ForEtrunk
Procedure
# Configure PE1.
[~PE1] ospf 1
[~PE1-ospf-1] quit
# Configure PE2.
[~PE2] ospf 1
[~PE2-ospf-1] quit
# Configure PE3.
[~PE3] ospf 1
[~PE3-ospf-1] quit
# Configure the RR.

[~RR] ospf 1
[*RR-ospf-1] area 0

(2020-10-09)

[~RR-ospf-1] quit
routes to Loopback1 of one another.

Neighbors

DR: 10.1.1.1 BDR: 10.1.1.2 MTU: 0
------------------------------------------------------------------------------

# Configure PE1.
[*PE1] mpls
[*PE1-mpls] quit
[*PE1] mpls ldp
# Configure PE2.

(2020-10-09)
[*PE2] mpls
[*PE2-mpls] quit
[*PE2] mpls ldp
# Configure the RR.

[*RR] mpls
[*RR-mpls] quit
[*RR] mpls ldp
[*RR-mpls-ldp] quit
# Configure PE3.
[*PE3] mpls
[*PE3-mpls] quit
[*PE3] mpls ldp
After the configurations are complete, LDP sessions can be established between
the PEs and RR. Run the display mpls ldp session command. The command
output shows that Status is Operational. Then, run the display mpls ldp lsp
command. The command output shows that an LDP LSP has been successfully
established on each device.
--------------------------------------------------------------------------
--------------------------------------------------------------------------
--------------------------------------------------------------------------
LDP LSP Information
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------

(2020-10-09)
1.1.1.1/32 3/NULL 3.3.3.3 127.0.0.1 Loop1

*1.1.1.1/32 Liberal/32828 DS/3.3.3.3
2.2.2.2/32 NULL/32829 - 10.1.1.2 GE2/0/0
2.2.2.2/32 32829/32829 3.3.3.3 10.1.1.2 GE2/0/0
3.3.3.3/32 NULL/3 - 10.1.1.2 GE2/0/0
3.3.3.3/32 32828/3 3.3.3.3 10.1.1.2 GE2/0/0
4.4.4.4/32 NULL/32830 - 10.1.1.2 GE2/0/0
4.4.4.4/32 32830/32830 3.3.3.3 10.1.1.2 GE2/0/0
-------------------------------------------------------------------------------
# Configure PE1.
[*PE1-bd10] quit
[*PE1] commit
# Configure PE2.
[*PE2-bd10] quit
[*PE2] commit
# Configure PE3.
[*PE3-bd10] quit
[*PE3] commit
# Configure PE1.
[*PE1] commit
# Configure PE2.
[*PE2] commit
# Configure PE3.
[*PE3] commit

(2020-10-09)
Step 6 Configure an ESI and E-Trunk to implement the dual-homing single-active

networking.
# Configure PE1.
[*PE1] e-trunk 1
[*PE1-Eth-Trunk10] esi 0000.1111.2222.1111.1111
[*PE1] evpn redundancy-mode single-active
[*PE1] commit
# Configure PE2.
[*PE2] e-trunk 1
[*PE2-Eth-Trunk10] esi 0000.1111.2222.1111.1111
[*PE2] evpn redundancy-mode single-active
[*PE2] commit
# Configure PE3.
[*PE3-Eth-Trunk10] esi 0000.1111.3333.4444.5555
[*PE3] commit
Step 7 Configure the local and remote FRR function for MAC routes on dual-homing PEs.
# Configure PE1.

(2020-10-09)
[~PE1] evpn
[*PE1-evpn] quit
[*PE1] commit
# Configure PE2.
[~PE2] evpn
[*PE2-evpn] quit
[*PE2] commit
Step 8 Create a BFD session and bind it to the E-Trunk on PE1 and PE2.
# Configure PE1.
[~PE1] bfd
[*PE1-bfd] quit
[*PE1] bfd ForEtrunk bind peer-ip 2.2.2.2 source-ip 1.1.1.1
[*PE1-bfd-session-ForEtrunk] discriminator local 1
[*PE1-bfd-session-ForEtrunk] discriminator remote 2
[*PE1-bfd-session-ForEtrunk] quit
[*PE1] e-trunk 1
[*PE1-e-trunk-1] e-trunk track bfd-session session-name ForEtrunk
[*PE1] commit
# Configure PE2.
[~PE2] bfd
[*PE2-bfd] quit
[*PE2] bfd ForEtrunk bind peer-ip 1.1.1.1 source-ip 2.2.2.2
[*PE2-bfd-session-ForEtrunk] discriminator local 2
[*PE2-bfd-session-ForEtrunk] discriminator remote 1
[*PE2-bfd-session-ForEtrunk] quit
[*PE2] e-trunk 1
[*PE2-e-trunk-1] e-trunk track bfd-session session-name ForEtrunk
[*PE2] commit
Step 9 Establish a BGP EVPN peer relationship.
# Configure PE1.
[~PE1] bgp 100
[*PE1-bgp] quit
[*PE1] commit
# Configure PE2.
[~PE2] bgp 100
[*PE2-bgp] quit
[*PE2] commit
# Configure PE3.

(2020-10-09)
[~PE3] bgp 100

[*PE3-bgp] quit
[*PE3] commit
# Configure the RR.

[~RR] bgp 100
[*RR-bgp] quit
[*RR] commit


1.1.1.1 4 100 10 18 0 00:00:11 Established 6
2.2.2.2 4 100 10 20 0 00:00:12 Established 6
4.4.4.4 4 100 6 18 0 00:00:13 Established 2
Step 10 Configure the CE to access the PEs through the Eth-Trunk interface.
# Configure CE1.
[~CE1] vlan 2
[*CE1-vlan2] quit
[*CE1-Eth-Trunk10] mode lacp-static
[*CE1-Eth-Trunk10] max active-linknumber 1
[*CE1-Eth-Trunk10] lacp preempt enable
[*CE1-Eth-Trunk10] lacp preempt delay 180
[*CE1] commit
# Configure CE2.

(2020-10-09)
[~CE2] vlan 2
[*CE2-vlan2] quit
[*CE2] commit
Step 11 Configure IP addresses on the same network segment on CE1 and CE2 and
perform a ping operation on the same network segment.
# Configure CE1.
[*CE1-Vlanif2] quit
[~CE1] commit
# Configure CE2.
[*CE2-Vlanif2] quit
[~CE2] commit
# On CE1, ping an IP address on the same network segment as CE2. The following
example uses the command output on CE1.
[~CE1] ping 192.168.1.12
--- 192.168.1.12 ping statistics ---

0.00% packet loss

Run the display bgp evpn all routing-table mac-route command on PE3. The
command output shows the MAC route sent by the remote PE and the MAC route
destined for CE1. In the single-active scenario, the next hop of the MAC route on
CE1 is PE1 on the primary path.


*>i 0:48:00e0-fc12-5678:32:0.0.0.0 1.1.1.1

(2020-10-09)
*> 0:48:00e0-fc12-3333:0:0.0.0.0 0.0.0.0
*>i 0:48:00e0-fc12-5678:32:0.0.0.0 1.1.1.1
*> 0:48:00e0-fc12-3333:0:0.0.0.0 0.0.0.0
----End
Configuration Files
#
sysname PE1
#
#
#
evpn
#
mac-duplication
#
#
bfd
#
mpls lsr-id 1.1.1.1
#
mpls
#
bridge-domain 10
#
mpls ldp
#
ipv4-family
#
e-trunk 1
priority 50
e-trunk track bfd-session session-name ForEtrunk
#
mode lacp-static
e-trunk 1
esi 0000.1111.2222.1111.1111
#
rewrite pop single
bridge-domain 10
#
undo shutdown
eth-trunk 10
#

(2020-10-09)
undo shutdown
ip address 10.1.1.1 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 1.1.1.1 255.255.255.255
#
bfd ForEtrunk bind peer-ip 2.2.2.2 source-ip 1.1.1.1
#
bgp 100
#
ipv4-family unicast
peer 3.3.3.3 enable
#
l2vpn-family evpn
policy vpn-target
peer 3.3.3.3 enable
#
ospf 1
area 0.0.0.0
network 1.1.1.1 0.0.0.0
network 10.1.1.0 0.0.0.255
#
#
return
#
sysname PE2
#
#
#
evpn
#
mac-duplication
#
#
bfd
#
mpls lsr-id 2.2.2.2
#
mpls
#
bridge-domain 10
#
mpls ldp
#
ipv4-family
#
e-trunk 1

(2020-10-09)
e-trunk track bfd-session session-name ForEtrunk

#
mode lacp-static
e-trunk 1
esi 0000.1111.2222.1111.1111
#
rewrite pop single
bridge-domain 10
#
undo shutdown
eth-trunk 10
#
undo shutdown
ip address 10.2.1.1 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 2.2.2.2 255.255.255.255
#
bfd ForEtrunk bind peer-ip 1.1.1.1 source-ip 2.2.2.2
#
bgp 100
#
ipv4-family unicast
peer 3.3.3.3 enable
#
l2vpn-family evpn
policy vpn-target
peer 3.3.3.3 enable
#
ospf 1
area 0.0.0.0
network 2.2.2.2 0.0.0.0
network 10.2.1.0 0.0.0.255
#
#
return
#
sysname PE3
#
#
mpls lsr-id 4.4.4.4
#
mpls
#
bridge-domain 10
#
mpls ldp
#

(2020-10-09)
ipv4-family
#
#
rewrite pop single
bridge-domain 10
#
undo shutdown
ip address 10.3.1.2 255.255.255.0
mpls
mpls ldp
#
undo shutdown
eth-trunk 10
#
interface LoopBack1
ip address 4.4.4.4 255.255.255.255
#
bgp 100
#
ipv4-family unicast
peer 3.3.3.3 enable
#
l2vpn-family evpn
policy vpn-target
peer 3.3.3.3 enable
#
ospf 1
area 0.0.0.0
network 4.4.4.4 0.0.0.0
network 10.3.1.0 0.0.0.255
#
#
return
#
sysname RR
#
mpls lsr-id 3.3.3.3
#
mpls
#
mpls ldp
#
ipv4-family
#
undo shutdown
ip address 10.1.1.2 255.255.255.0
mpls
mpls ldp
#
undo shutdown
ip address 10.2.1.2 255.255.255.0
mpls
mpls ldp
#
undo shutdown
ip address 10.3.1.1 255.255.255.0

(2020-10-09)
mpls
mpls ldp
#
interface LoopBack1
ip address 3.3.3.3 255.255.255.255
#
bgp 100
#
ipv4-family unicast
peer 1.1.1.1 enable
peer 2.2.2.2 enable
peer 4.4.4.4 enable
#
l2vpn-family evpn
peer 1.1.1.1 enable
peer 2.2.2.2 enable
peer 4.4.4.4 enable
#
ospf 1
area 0.0.0.0
network 3.3.3.3 0.0.0.0
network 10.1.1.0 0.0.0.255
network 10.2.1.0 0.0.0.255
network 10.3.1.0 0.0.0.255
#
return

#
sysname CE1
#
vlan batch 2
#
vlan 2
#
interface Vlanif2
ip address 192.168.1.11 255.255.255.0
#
portswitch
mode lacp-static
lacp preempt enable
max active-linknumber 1
lacp preempt delay 180
#
undo shutdown
eth-trunk 10
#
undo shutdown
eth-trunk 10
#
return

(2020-10-09)
#
sysname CE2
#
vlan batch 2
#
vlan 2
#
interface Vlanif2
ip address 192.168.1.12 255.255.255.0
#
portswitch
#
undo shutdown
eth-trunk 10
#
return
3.2.36.3 Example for Configuring EVPN VPWS over MPLS (Dual-Homing

Active-Active)
This section provides an example for configuring EVPN VPWS services on a dual-
homing active-active network.
Context
On the network shown in Figure 3-158, PE1, PE2, the RR, and PE3 belong to the
same AS. They need to communicate with each other using OSPF, and MPLS
tunnels need to be deployed to carry EVPN VPWS services.
Figure 3-158 Configuring EVPN VPWS over MPLS

NOTE

(2020-10-09)
communicate.
4. Establish BGP EVPN peer relationships between PEs and the RR, and configure
the PEs as RR clients.
5. Configure the local and remote FRR function for MAC routes on PEs.
Data Preparation
● EVPN instance's RDs: 100:1, 100:2, and 100:3; RTs: 1:1
Procedure
# Configure PE1.
[~PE1] ospf 1
[~PE1-ospf-1] quit
# Configure PE2.
[~PE2] ospf 1
[~PE2-ospf-1] quit
# Configure PE3.
[~PE3] ospf 1
[~PE3-ospf-1] quit

(2020-10-09)
# Configure the RR.

[~RR] ospf 1
[*RR-ospf-1] area 0
[~RR-ospf-1] quit
# Configure PE1.
[*PE1] mpls
[*PE1-mpls] quit
[*PE1] mpls ldp
# Configure PE2.
[*PE2] mpls
[*PE2-mpls] quit
[*PE2] mpls ldp
# Configure the RR.

[*RR] mpls
[*RR-mpls] quit
[*RR] mpls ldp
[*RR-mpls-ldp] quit
# Configure PE3.
[*PE3] mpls
[*PE3-mpls] quit
[*PE3] mpls ldp

(2020-10-09)

# Configure PE1.
[~PE1] evpn vpn-instance evrf1 vpws
[*PE1] evpl instance 1 mpls-mode
[*PE1-evpl-mpls1] evpn binding vpn-instance evrf1
[*PE1-evpl-mpls1] local-service-id 100 remote-service-id 200
[*PE1-evpl-mpls1] quit
[*PE1-GigabitEthernet 1/0/0] esi 0001.0002.0003.0004.0005
[*PE1-GigabitEthernet 1/0/0] quit
[*PE1] commit
# Configure PE2.
[*PE2-GigabitEthernet 1/0/0] esi 0001.0002.0003.0004.0005
[*PE2] commit
# Configure PE3.
[*PE2] commit
# Configure PE1.
[*PE1] commit

(2020-10-09)
# Configure PE2.
[*PE2] commit
# Configure PE3.
[*PE3] commit
Step 6 Establish BGP EVPN peer relationships between PEs and the RR, and configure the
PEs as RR clients.
# Configure PE1.
[~PE1] bgp 100
[*PE1-bgp] quit
[*PE1] commit
# Configure PE2.
[~PE2] bgp 100
[*PE2-bgp] quit
[*PE2] commit
# Configure PE3.
[~PE3] bgp 100
[*PE3-bgp] quit
[*PE3] commit
# Configure the RR.

[~RR] bgp 100
[*RR-bgp] quit
[*RR] commit

(2020-10-09)


1.1.1.1 4 100 9 15 0 00:03:41 Established 1
2.2.2.2 4 100 9 15 0 00:03:42 Established 1
4.4.4.4 4 100 8 15 0 00:03:42 Established 1
Step 7 Configure the local and remote FRR function for MAC routes on PEs.
# Configure PE1.
[*PE1-vpws-evpn-instance-evrf1] local-remote frr enable
[*PE1] commit
# Configure PE2.
[*PE2] commit
# Configure PE3.
[*PE3-vpws-evpn-instance-evrf1] remote frr enable
[*PE3] commit

Run the display bgp evpn all routing-table ad-route command on PE3 to check
EVPN Ethernet A-D route information.
[~PE3] display bgp evpn all routing-table ad-route


*>i 0001.0002.0003.0004.0005:100 1.1.1.1
*>i 0001.0002.0003.0004.0005:100 2.2.2.2
*> 0000.0000.0000.0000.0000:200 127.0.0.1
*>i 0001.0002.0003.0004.0005:100 1.1.1.1
*i 2.2.2.2
*> 0000.0000.0000.0000.0000:200 127.0.0.1
Run the display bgp evpn all routing-table ad-route

0001.0002.0003.0004.0005:100 command on PE3. The command output shows

(2020-10-09)
detailed information about the EVPN Ethernet A-D routes sent by PE1 and PE2
and label information about the bypass tunnel after FRR is configured.
From: 3.3.3.3 (3.3.3.3)
Relay Tunnel Out-Interface: LDP LSP
Ext-Community: RT <1 : 1>, EVPN L2 Attributes <MTU:1500 C:0 P:1 B:0>, Bypass Label<0 : 0 : 48124>
Originator: 1.1.1.1
Cluster list: 3.3.3.3

From: 3.3.3.3 (3.3.3.3)
Originator: 2.2.2.2
Remote-Cross route
From: 3.3.3.3 (3.3.3.3)
Originator: 1.1.1.1

Remote-Cross route
From: 3.3.3.3 (3.3.3.3)

(2020-10-09)

for router ID
Originator: 2.2.2.2
----End
Configuration Files
#
sysname PE1
#
#
evpl instance 1 mpls-mode
#
mpls lsr-id 1.1.1.1
#
mpls
#
mpls ldp
#
undo shutdown
esi 0001.0002.0003.0004.0005
#
evpl instance 1
#
undo shutdown
ip address 10.1.1.1 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 1.1.1.1 255.255.255.255
#
bgp 100
#
ipv4-family unicast
peer 3.3.3.3 enable
#
l2vpn-family evpn
peer 3.3.3.3 enable
#
ospf 1
area 0.0.0.0
network 1.1.1.1 0.0.0.0

(2020-10-09)
network 10.1.1.0 0.0.0.255

#
#
return
#
sysname PE2
#
#
#
mpls lsr-id 2.2.2.2
#
mpls
#
mpls ldp
#
undo shutdown
esi 0001.0002.0003.0004.0005
#
evpl instance 1
#
undo shutdown
ip address 10.2.1.1 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 2.2.2.2 255.255.255.255
#
bgp 100
#
ipv4-family unicast
peer 3.3.3.3 enable
#
l2vpn-family evpn
peer 3.3.3.3 enable
#
ospf 1
area 0.0.0.0
network 2.2.2.2 0.0.0.0
network 10.2.1.0 0.0.0.255
#
#
return
#
sysname PE3
#

(2020-10-09)
remote frr enable

#
#
mpls lsr-id 4.4.4.4
#
mpls
#
mpls ldp
#
undo shutdown
ip address 10.3.1.2 255.255.255.0
mpls
mpls ldp
#
evpl instance 1
#
interface LoopBack1
ip address 4.4.4.4 255.255.255.255
#
bgp 100
#
ipv4-family unicast
peer 3.3.3.3 enable
#
l2vpn-family evpn
peer 3.3.3.3 enable
#
ospf 1
area 0.0.0.0
network 4.4.4.4 0.0.0.0
network 10.3.1.0 0.0.0.255
#
#
return
#
sysname RR
#
mpls lsr-id 3.3.3.3
#
mpls
#
mpls ldp
#
undo shutdown
ip address 10.2.1.2 255.255.255.0
mpls
mpls ldp
#
undo shutdown
ip address 10.1.1.2 255.255.255.0
mpls
mpls ldp
#

(2020-10-09)
undo shutdown
ip address 10.3.1.1 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 3.3.3.3 255.255.255.255
#
bgp 100
#
ipv4-family unicast
peer 1.1.1.1 enable
peer 2.2.2.2 enable
peer 4.4.4.4 enable
#
l2vpn-family evpn
peer 1.1.1.1 enable
peer 2.2.2.2 enable
peer 4.4.4.4 enable
#
ospf 1
area 0.0.0.0
network 3.3.3.3 0.0.0.0
network 10.1.1.0 0.0.0.255
network 10.2.1.0 0.0.0.255
network 10.3.1.0 0.0.0.255
#
return
3.2.36.4 Example for Configuring EVPN VPWS over MPLS (Dual-Homing

Single-Active)
This section provides an example for configuring EVPN VPWS services on a dual-
homing single-active network.
Context
On the network shown in Figure 3-159, PE1, PE2, the RR, and PE3 belong to the
same AS. They need to communicate with each other using OSPF, and MPLS
tunnels need to be deployed to carry EVPN VPWS services. CE1 is dual-homed to
PE1 and PE2 in single-active mode. PE1 is the active PE, and PE2 is the standby PE.
CE2 is single-homed to PE3.
Figure 3-159 Configuring EVPN VPWS over MPLS

NOTE

(2020-10-09)
communicate.
4. Configure an E-Trunk on each PE to implement the EVPN single-active mode.
5. Establish BGP EVPN peer relationships between PEs and the RR, and configure
6. Configure the local and remote FRR function for MAC routes on PEs.
Data Preparation
● EVPN instance's RDs: 100:1, 100:2, and 100:3; RTs: 1
Procedure
# Configure PE1.
[~PE1] ospf 1

(2020-10-09)

[~PE1-ospf-1] quit
# Configure PE2.
[~PE2] ospf 1
[~PE2-ospf-1] quit
# Configure PE3.
[~PE3] ospf 1
[~PE3-ospf-1] quit
# Configure the RR.

[~RR] ospf 1
[*RR-ospf-1] area 0
[~RR-ospf-1] quit
# Configure PE1.
[*PE1] mpls
[*PE1-mpls] quit
[*PE1] mpls ldp
# Configure PE2.
[*PE2] mpls
[*PE2-mpls] quit
[*PE2] mpls ldp
# Configure the RR.

[*RR] mpls

(2020-10-09)
[*RR-mpls] quit
[*RR] mpls ldp
[*RR-mpls-ldp] quit
# Configure PE3.
[*PE3] mpls
[*PE3-mpls] quit
[*PE3] mpls ldp
# Configure PE1.
[*PE1] interface Eth-Trunk1
[*PE1-Eth-Trunk1] esi 0001.0002.0003.0004.0005
[*PE1-GigabitEthernet 1/0/0] eth-trunk 1
[*PE1] interface Eth-Trunk1.1
[*PE1-Eth-Trunk1.1] vlan-type dot1q 1
[*PE1] commit
# Configure PE2.
[*PE2-Eth-Trunk1] esi 0001.0002.0003.0004.0005

(2020-10-09)

[*PE2-GigabitEthernet 1/0/0] eth-trunk 1
[*PE2] interface Eth-Trunk1.1
[*PE2-Eth-Trunk1.1] vlan-type dot1q 1
[*PE2] commit
# Configure PE3.
[*PE3-GigabitEthernet 2/0/0] evpl instance 1
[*PE2] commit

# Configure PE1.
[*PE1] commit
# Configure PE2.
[*PE2] commit
# Configure PE3.
[*PE3] commit
Step 6 Configure an E-Trunk on each PE to implement the EVPN single-active mode.

# Configure PE1.
[~PE1] evpn redundancy-mode single-active
[*PE1] lacp e-trunk system-id 00e0-fc00-0001
[*PE1] e-trunk 1
[*PE1] commit
# Configure PE2.
[~PE2] evpn redundancy-mode single-active
[*PE2] lacp e-trunk system-id 00e0-fc00-0001
[*PE2] e-trunk 1
[*PE2] commit

(2020-10-09)
Step 7 Establish BGP EVPN peer relationships between PEs and the RR, and configure the
PEs as RR clients.
# Configure PE1.
[~PE1] bgp 100
[*PE1-bgp] quit
[*PE1] commit
# Configure PE2.
[~PE2] bgp 100
[*PE2-bgp] quit
[*PE2] commit
# Configure PE3.
[~PE3] bgp 100
[*PE3-bgp] quit
[*PE3] commit
# Configure the RR.

[~RR] bgp 100
[*RR-bgp] quit
[*RR] commit


1.1.1.1 4 100 9 15 0 00:03:41 Established 1

(2020-10-09)
2.2.2.2 4 100 9 15 0 00:03:42 Established 1

4.4.4.4 4 100 8 15 0 00:03:42 Established 1
Step 8 Configure the local and remote FRR function for MAC routes on PEs.
# Configure PE1.
[*PE1] commit
# Configure PE2.
[*PE2] commit
# Configure PE3.
[*PE3-vpws-evpn-instance-evrf1] remote frr enable
[*PE3] commit

Run the display bgp evpn vpn-instance evrf1 routing-table ad-route
0001.0002.0003.0004.0005:100 command on PE3. The command output shows
detailed information about the EVPN Ethernet A-D routes sent by PE1 and PE2.
The route sent by PE1 is selected, and the route sent by PE2 is a backup route. In
addition, you can view the label information about the bypass tunnel after FRR is
configured.
[~PE3] display bgp evpn vpn-instance evrf1 routing-table ad-route 0001.0002.0003.0004.0005:100
Remote-Cross route
From: 3.3.3.3 (3.3.3.3)
Originator: 1.1.1.1

Remote-Cross route
From: 3.3.3.3 (3.3.3.3)

(2020-10-09)
AS-path Nil, origin incomplete, localpref 100, pref-val 0, valid, internal, backup, pre 255, IGP cost 2, not
preferred for L2 ext-community
Originator: 2.2.2.2
----End
Configuration Files
#
sysname PE1
#
#
#
e-trunk 1
priority 10
#
#
#
mpls lsr-id 1.1.1.1
#
mpls
#
mpls ldp
#
mode lacp-static
e-trunk 1
esi 0001.0002.0003.0004.0005
#
vlan-type dot1q 1
evpl instance 1
#
undo shutdown
eth-trunk 1
#
undo shutdown
ip address 10.1.1.1 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 1.1.1.1 255.255.255.255
#
bgp 100
#

(2020-10-09)
ipv4-family unicast
peer 3.3.3.3 enable
#
l2vpn-family evpn
policy vpn-target
peer 3.3.3.3 enable
#
ospf 1
area 0.0.0.0
network 1.1.1.1 0.0.0.0
network 10.1.1.0 0.0.0.255
#
#
return
#
sysname PE2
#
#
#
e-trunk 1
priority 20
security-key cipher %^%#GAG\Y-F%GY[GnwCkov7A<e(m/cl}m86`jd6z[79~%^%#
#
#
#
mpls lsr-id 2.2.2.2
#
mpls
#
mpls ldp
#
mode lacp-static
e-trunk 1
esi 0001.0002.0003.0004.0005
#
vlan-type dot1q 1
evpl instance 1
#
undo shutdown
eth-trunk 1
#
undo shutdown
ip address 10.2.1.1 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 2.2.2.2 255.255.255.255
#
bgp 100

(2020-10-09)

#
ipv4-family unicast
peer 3.3.3.3 enable
#
l2vpn-family evpn
policy vpn-target
peer 3.3.3.3 enable
#
ospf 1
area 0.0.0.0
network 2.2.2.2 0.0.0.0
network 10.2.1.0 0.0.0.255
#
#
return
#
sysname PE3
#
#
remote frr enable
#
#
mpls lsr-id 4.4.4.4
#
mpls
#
mpls ldp
#
undo shutdown
ip address 10.3.1.2 255.255.255.0
mpls
mpls ldp
#
undo shutdown
evpl instance 1
#
interface LoopBack1
ip address 4.4.4.4 255.255.255.255
#
bgp 100
#
ipv4-family unicast
peer 3.3.3.3 enable
#
l2vpn-family evpn
policy vpn-target
peer 3.3.3.3 enable
#
ospf 1
area 0.0.0.0
network 4.4.4.4 0.0.0.0

(2020-10-09)
network 10.3.1.0 0.0.0.255

#
#
return
#
sysname RR
#
mpls lsr-id 3.3.3.3
#
mpls
#
mpls ldp
#
undo shutdown
ip address 10.2.1.2 255.255.255.0
mpls
mpls ldp
#
undo shutdown
ip address 10.1.1.2 255.255.255.0
mpls
mpls ldp
#
undo shutdown
ip address 10.3.1.1 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 3.3.3.3 255.255.255.255
#
bgp 100
#
ipv4-family unicast
peer 1.1.1.1 enable
peer 2.2.2.2 enable
peer 4.4.4.4 enable
#
l2vpn-family evpn
peer 1.1.1.1 enable
peer 2.2.2.2 enable
peer 4.4.4.4 enable
#
ospf 1
area 0.0.0.0
network 3.3.3.3 0.0.0.0
network 10.1.1.0 0.0.0.255
network 10.2.1.0 0.0.0.255
network 10.3.1.0 0.0.0.255
#
return

(2020-10-09)
#
sysname CE1
#
mode lacp-static
#
undo shutdown
eth-trunk 1
#
undo shutdown
eth-trunk 1
#

#
sysname CE2
#
undo shutdown
#
3.2.36.5 Example for Setting a Redundancy Mode per ESI Instance

This section provides an example for setting a redundancy mode per ESI instance.
In scenarios where multiple CEs are dual-homed to PEs, if you want a remote PE
to send unicast traffic to different CEs in different modes (load balancing and
non-load balancing), you can set a redundancy mode per ESI instance.
On the network shown in Figure 3-160, a user wants to deploy an EVPN to
transmit services. In this case, you must configure an EVPN instance (BD-EVPN
instance in this example) on each PE and configure each PE to establish a BGP-
EVPN peer relationship with its neighboring PE. CE1 and CE2 are each dual-homed
to PE1 and PE2. The PE interfaces that connect CE1 use a dynamically generated
ESI (ESI1), and those that connect to CE2 use a statically configured ESI (ESI2). If
you want unicast traffic from CE3 -> CE1 and from CE3 -> CE2 to be transmitted
in load balancing and non-load balancing mode, respectively, you can set a
redundancy mode per ESI instance. Specifically, you can set the redundancy mode
of the ESI1 instance to all-active and that of the ESI2 instance to single-active.
Figure 3-160 Setting a redundancy mode per ESI instance

NOTE
respectively.

(2020-10-09)
Precautions
When you set a redundancy mode per ESI instance, note the following:
● For the same EVPN instance, the export VPN target list of one site shares VPN
targets with the import VPN target lists of the other sites. Conversely, the
import VPN target list of one site shares VPN targets with the export VPN
target lists of the other sites.
● Using the local loopback interface address of each PE as the source address is
recommended.
1. Assign an IP address to each PE interface, including the loopback interfaces.

2. Configure a routing protocol on each PE to ensure Layer 3 communication.
OSPF is used in this example.
3. Configure MPLS LDP on each PE.
4. Create a BD-EVPN instance and a BD on each PE, and bind the BD to the
EVPN instance.
5. Configure each PE interface that connects to a CE and configure an ESI on
each PE interface.
6. Configure a source address on each PE.
7. Configure a BGP-EVPN peer relationship between each PE and its neighboring
PE.
8. Set a redundancy mode per ESI instance on each PE.
Data Preparation

(2020-10-09)
● EVPN instance names: evrf1 and evrf2

● RDs of evrf1 on PE1, PE2, and PE3: 10:1, 10:2, and 10:3, respectively, RT of
evrf1: 11:1; RDs of evrf2 on PE1, PE2, and PE3: 20:1, 20:2, and 20:3,
respectively, RT of evrf2: 22:2
Procedure
Step 1 Assign an IP address to each PE interface, including the loopback interfaces.
For configuration details, see Configuration Files in this section.
Step 2 Configure a routing protocol on each PE to ensure Layer 3 communication. OSPF
is used in this example.
Step 3 Configure MPLS LDP on each PE.
Step 4 Create a BD-EVPN instance and a BD on each PE, and bind the BD to the EVPN
instance.
# Configure PE1.
[*PE1-bd10] quit
[*PE1-bd20] quit
[*PE1] commit
Repeat this step for PE2 and PE3. For configuration details, see Configuration
Step 5 Configure each PE interface that connects to a CE and configure an ESI on each PE
interface.
# Configure PE1.
[*PE1] e-trunk 1
[*PE1] e-trunk 2

(2020-10-09)
[*PE1] commit
# Configure PE2.
[*PE2] e-trunk 1
[*PE2] e-trunk 2
[*PE2] commit
# Configure PE3.
[*PE3] commit

(2020-10-09)

# Configure PE1.
[*PE1] commit
# Configure PE2.
[*PE2] commit
# Configure PE3.
[*PE3] commit
Step 7 Establish a BGP-EVPN peer relationship between each PE and its neighboring PE.
# Configure PE1.
[~PE1] bgp 100
[*PE1-bgp] quit
[*PE1] commit
Step 8 Set a redundancy mode per ESI instance on each PE.
# Configure PE1.
[~PE1] evpn
[*PE1-evpn] esi 0001.0002.0003.0004.0005
[*PE1-evpn-esi-0001.0002.0003.0004.0005] quit
[*PE1] esi dynamic-name esi1
[*PE1-esi-dynamic-esi1] evpn redundancy-mode all-active
[*PE1-esi-dynamic-esi1] quit
[*PE1-Eth-Trunk10] esi dynamic esi1
[*PE1] commit
Repeat this step for PE2. For configuration details, see Configuration Files in this
section.
Run the display bgp evpn all esi command on PE1. The command output shows
ESI information of the two EVPN instances and the redundancy modes of the ESI
instances.
[~PE1] display bgp evpn all esi
Number of ESI for EVPN address family: 2
ESI IFName/Bridge-domain MultiHoming-Mode

0001.0002.0003.0004.0005 Eth-Trunk20.1 single-active
0138.ba26.4b58.050a.2100 Eth-Trunk10.1 all-active

(2020-10-09)
Number of ESI for evpn-instance evrf1: 1

0138.ba26.4b58.050a.2100 Eth-Trunk10.1 all-active
Number of ESI for evpn-instance evrf2: 1

0001.0002.0003.0004.0005 Eth-Trunk20.1 single-active
----End
Configuration Files
#
sysname PE1
#
#
evpn
#
esi 0001.0002.0003.0004.0005
#
esi dynamic-name esi1
#
#
#
mpls lsr-id 1.1.1.1
#
mpls
#
bridge-domain 10
#
bridge-domain 20
#
mpls ldp
#
e-trunk 1
priority 10
#
e-trunk 2
priority 10
#
mode lacp-static
e-trunk 1
esi dynamic esi1
#
rewrite pop single
bridge-domain 10

(2020-10-09)
#
e-trunk 2
esi 0001.0002.0003.0004.0005
#
rewrite pop single
bridge-domain 20
#
undo shutdown
eth-trunk 10
#
undo shutdown
ip address 10.2.1.2 255.255.255.0
mpls
mpls ldp
#
undo shutdown
ip address 10.1.1.1 255.255.255.0
mpls
mpls ldp
#
undo shutdown
eth-trunk 20
#
interface LoopBack1
ip address 1.1.1.1 255.255.255.255
#
bgp 100
#
ipv4-family unicast
peer 2.2.2.2 enable
peer 3.3.3.3 enable
#
l2vpn-family evpn
peer 2.2.2.2 enable
peer 3.3.3.3 enable
#
ospf 1
area 0.0.0.0
network 1.1.1.1 0.0.0.0
network 10.1.1.0 0.0.0.255
network 10.2.1.0 0.0.0.255
#
#
return
#
sysname PE2
#
#
evpn
#
esi 0001.0002.0003.0004.0005
#

(2020-10-09)
esi dynamic-name esi1

#
#
#
mpls lsr-id 2.2.2.2
#
mpls
#
bridge-domain 10
#
bridge-domain 20
#
mpls ldp
#
e-trunk 1
priority 20
#
e-trunk 2
priority 20
#
mode lacp-static
e-trunk 1
esi dynamic esi1
#
rewrite pop single
bridge-domain 10
#
e-trunk 2
esi 0001.0002.0003.0004.0005
#
rewrite pop single
bridge-domain 20
#
undo shutdown
eth-trunk 20
#
undo shutdown
ip address 10.2.1.1 255.255.255.0
mpls
mpls ldp
#
undo shutdown
ip address 10.3.1.1 255.255.255.0
mpls
mpls ldp
#

(2020-10-09)
undo shutdown
eth-trunk 10
#
interface LoopBack1
ip address 2.2.2.2 255.255.255.255
#
bgp 100
#
ipv4-family unicast
peer 1.1.1.1 enable
peer 3.3.3.3 enable
#
l2vpn-family evpn
peer 1.1.1.1 enable
peer 3.3.3.3 enable
#
ospf 1
area 0.0.0.0
network 2.2.2.2 0.0.0.0
network 10.2.1.0 0.0.0.255
network 10.3.1.0 0.0.0.255
#
#
return
#
sysname PE3
#
#
#
mpls lsr-id 3.3.3.3
#
mpls
#
bridge-domain 10
#
bridge-domain 20
#
mpls ldp
#
undo shutdown
ip address 10.1.1.2 255.255.255.0
mpls
mpls ldp
#
undo shutdown
ip address 10.3.1.2 255.255.255.0
mpls
mpls ldp

(2020-10-09)
#
rewrite pop single
bridge-domain 10
#
rewrite pop single
bridge-domain 20
#
interface LoopBack1
ip address 3.3.3.3 255.255.255.255
#
bgp 100
#
ipv4-family unicast
peer 1.1.1.1 enable
peer 2.2.2.2 enable
#
l2vpn-family evpn
peer 1.1.1.1 enable
peer 2.2.2.2 enable
#
ospf 1
area 0.0.0.0
network 3.3.3.3 0.0.0.0
network 10.1.1.0 0.0.0.255
network 10.3.1.0 0.0.0.255
#
#
return
3.2.36.6 Example for Configuring EVPN E-Tree

This section provides an example for configuring EVPN E-Tree. This function
isolates traffic between different interfaces in the same broadcast domain.
A user wants to deploy an EVPN on the network shown in Figure 3-161 to
transmit services. Specifically, an EVPN instance (BD-EVPN instance in this
example) is configured on each PE, and a BGP EVPN peer relationship is
established between every two PEs. To improve network security, PE2 and PE3 can
only interact with PE1, and PE2 and PE3 cannot send traffic to each other. To
implement this function, the user can deploy EVPN E-Tree over the network.
Figure 3-161 Configuring EVPN E-Tree

NOTE

(2020-10-09)
Precautions
When you configure EVPN E-Tree, note the following:
recommended.

4. Create a BD-EVPN instance and a BD on each PE, and bind the BD to the
EVPN instance.
5. Configure each PE interface that connects to a CE.
7. Configure a BGP EVPN peer relationship between every two PEs.
8. Configure the AC interfaces on PE2 and PE3 as leaf AC interfaces.
Data Preparation

(2020-10-09)
● EVPN instance evrf1's RD (10:1) and RT (11:1) on each PE
Procedure

Step 4 Create a BD-EVPN instance and a BD on each PE, and bind the BD to the EVPN
instance.
# Configure PE1.
[*PE1-bd10] quit
[*PE1] commit
Step 5 Configure each PE interface that connects to a CE.
# Configure PE1.
[*PE1] commit
# Configure PE1.
[*PE1] commit
# Configure PE2.
[*PE2] commit
# Configure PE3.
[*PE3] commit

(2020-10-09)
Step 7 Establish a BGP EVPN peer relationship between every two PEs.
# Configure PE1.
[~PE1] bgp 100
[*PE1-bgp] quit
[*PE1] commit
Step 8 Configure the AC interfaces on PE2 and PE3 as leaf AC interfaces.
# Configure PE2.
[*PE2-evpn-instance-evrf1] etree enable
[*PE2-GigabitEthernet1/0/0.1] evpn e-tree-leaf
[*PE2] commit
# Configure PE3.
[*PE3-evpn-instance-evrf1] etree enable
[*PE3-GigabitEthernet3/0/0.1] evpn e-tree-leaf
[*PE3] commit

Run the display bgp evpn all routing-table command on PE1 to view the leaf
attribute in Ethernet auto-discovery and MAC routes.


*>i 0000.0000.0000.0000.0000:4294967295 2.2.2.2
*>i 0000.0000.0000.0000.0000:4294967295 3.3.3.3
*>i 0000.0000.0000.0000.0000:4294967295 2.2.2.2

(2020-10-09)
*i 3.3.3.3

*> 0:48:00e0-fc00-0001:0:0.0.0.0 0.0.0.0
*>i 0:48:00e0-fc00-0005:0:0.0.0.0 2.2.2.2
*>i 0:48:00e0-fc00-0004:0:0.0.0.0 3.3.3.3
*>i 0:48:00e0-fc00-0002:0:0.0.0.0 2.2.2.2
*>i 0:48:00e0-fc00-0003:0:0.0.0.0 3.3.3.3
*> 0:48:00e0-fc00-0006:0:0.0.0.0 0.0.0.0
*> 0:48:00e0-fc00-0001:0:0.0.0.0 0.0.0.0
*>i 0:48:00e0-fc00-0005:0:0.0.0.0 2.2.2.2
*>i 0:48:00e0-fc00-0004:0:0.0.0.0 3.3.3.3
*>i 0:48:00e0-fc00-0002:0:0.0.0.0 2.2.2.2
*>i 0:48:00e0-fc00-0003:0:0.0.0.0 3.3.3.3
*> 0:48:00e0-fc00-0006:0:0.0.0.0 0.0.0.0

*> 0:32:1.1.1.1 127.0.0.1
*>i 0:32:2.2.2.2 2.2.2.2
*>i 0:32:3.3.3.3 3.3.3.3
*> 0:32:1.1.1.1 127.0.0.1
*>i 0:32:2.2.2.2 2.2.2.2
*>i 0:32:3.3.3.3 3.3.3.3
From: 2.2.2.2 (2.2.2.2)
Ext-Community: RT <11 : 1>, E-Tree <0 : 0 : 32915>

From: 3.3.3.3 (3.3.3.3)

(2020-10-09)
Remote-Cross route
From: 2.2.2.2 (2.2.2.2)

Remote-Cross route
From: 3.3.3.3 (3.3.3.3)
for router ID
[~PE1] display bgp evpn all routing-table mac-route 0:48:00e0-fc00-0005:0:0.0.0.0
From: 2.2.2.2 (2.2.2.2)
0000.0000.0000.0000.0000
Remote-Cross route
From: 2.2.2.2 (2.2.2.2)

(2020-10-09)
0000.0000.0000.0000.0000
----End
Configuration Files
#
sysname PE1
#
#
mpls lsr-id 1.1.1.1
#
mpls
#
bridge-domain 10
#
mpls ldp
#
rewrite pop single
bridge-domain 10
#
undo shutdown
ip address 10.2.1.2 255.255.255.0
mpls
mpls ldp
#
undo shutdown
ip address 10.1.1.1 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 1.1.1.1 255.255.255.255
#
bgp 100
#
ipv4-family unicast
peer 2.2.2.2 enable
peer 3.3.3.3 enable
#
l2vpn-family evpn
peer 2.2.2.2 enable
peer 3.3.3.3 enable
#
ospf 1
area 0.0.0.0
network 1.1.1.1 0.0.0.0
network 10.1.1.0 0.0.0.255
network 10.2.1.0 0.0.0.255
#

(2020-10-09)
#
return

#
sysname PE2
#
etree enable
#
mpls lsr-id 2.2.2.2
#
mpls
#
bridge-domain 10
#
mpls ldp
#
rewrite pop single
bridge-domain 10
evpn e-tree-leaf
#
undo shutdown
ip address 10.2.1.1 255.255.255.0
mpls
mpls ldp
#
undo shutdown
ip address 10.3.1.1 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 2.2.2.2 255.255.255.255
#
bgp 100
#
ipv4-family unicast
peer 1.1.1.1 enable
peer 3.3.3.3 enable
#
l2vpn-family evpn
peer 1.1.1.1 enable
peer 3.3.3.3 enable
#
ospf 1
area 0.0.0.0
network 2.2.2.2 0.0.0.0
network 10.2.1.0 0.0.0.255
network 10.3.1.0 0.0.0.255
#
#
return

(2020-10-09)
#
sysname PE3
#
etree enable
#
mpls lsr-id 3.3.3.3
#
mpls
#
bridge-domain 10
#
mpls ldp
#
undo shutdown
ip address 10.1.1.2 255.255.255.0
mpls
mpls ldp
#
undo shutdown
ip address 10.3.1.2 255.255.255.0
mpls
mpls ldp
#
rewrite pop single
bridge-domain 10
evpn e-tree-leaf
#
interface LoopBack1
ip address 3.3.3.3 255.255.255.255
#
bgp 100
#
ipv4-family unicast
peer 1.1.1.1 enable
peer 2.2.2.2 enable
#
l2vpn-family evpn
peer 1.1.1.1 enable
peer 2.2.2.2 enable
#
ospf 1
area 0.0.0.0
network 3.3.3.3 0.0.0.0
network 10.1.1.0 0.0.0.255
network 10.3.1.0 0.0.0.255
#
#
return

(2020-10-09)
3.2.36.7 Example for Configuring EVPN ORF

This section provides an example for configuring EVPN ORF. This configuration
helps reduce the burden on receiving EVPN routes and save network resources.
On the network shown in Figure 3-162, to enable different sites to communicate
with each other over the backbone network, EVPN is deployed on the network so
that PEs can exchange EVPN routes to transmit service traffic. Two EVPN instances
named evrf1 and evrf2 are configured on PE1. The EVPN instance named evrf1 is
configured on PE2, and the EVPN instance named evrf2 is configured on PE3. To
allow each PE to receive only desired routes and minimize system resource
consumption in processing unwanted routes, EVPN ORF can be configured.
Figure 3-162 Configuring EVPN ORF

NOTE
Precautions
When you configure EVPN ORF, note the following:
● For the same EVPN instance, the export VPN target list of a site shares VPN
targets with the import VPN target lists of the other sites; the import VPN
other sites.
recommended.

(2020-10-09)

4. Configure EVPN instances on the PEs and bind each EVPN instance to a BD.
6. Configure each PE's sub-interface that connects to a CE.
7. Configure an ESI for each PE interface that connects to a CE.
8. Configure the CEs and PEs to communicate.
9. Configure BGP-EVPN peer relationships between the PEs and RR, and
configure the PEs as RR clients.
10. Configure EVPN ORF on each device.
Data Preparation
● PE1's EVPN instance names: evrf1 and evrf2; PE2's EVPN instance name: evrf1;
PE3's EVPN instance name: evrf2
● evrf1's RD (100:1) and RT (1:1); evrf2's RD (100:2) and RT (2:2)
Procedure
Step 4 Configure EVPN instances on the PEs and bind each EVPN instance to a BD.
# Configure PE1.
[~PE1] evpn vpn-instance evpn1 bd-mode
[*PE1-bd10] quit
[*PE1-bd20] quit
[*PE1] commit
# Configure PE2.

(2020-10-09)

[*PE2-bd10] quit
[*PE2] commit
# Configure PE3.
[*PE3-bd20] quit
[*PE3] commit

# Configure PE1.
[*PE1] commit
# Configure PE2.
[*PE2] commit
# Configure PE3.
[*PE3] commit
Step 6 Configure each PE's sub-interface that connects to a CE.

# Configure PE1.
[~PE1] interface gigabitethernet1/0/0.1 mode l2
[*PE1] commit
# Configure PE2.
[*PE2] commit
# Configure PE3.
[*PE3] commit

(2020-10-09)
Step 7 Configure an ESI for each PE interface that connects to a CE.

# Configure PE1.
[*PE1] commit
# Configure PE2.
[*PE2] commit
# Configure PE3.
[*PE3] commit
Step 8 Configure the CEs and PEs to communicate.

# Configure CE1.
[~CE1] interface gigabitethernet1/0/0.1 mode l2
[*CE1-GigabitEthernet1/0/0.1] bridge-domain 10
[*CE1] interface gigabitethernet1/0/0.2 mode l2
[*CE1] commit
# Configure CE2.
[*CE2] commit
# Configure CE3.
[*CE3] commit
Step 9 Configure BGP-EVPN peer relationships between the PEs and RR, and configure
# Configure PE1.
[~PE1] bgp 100
[*PE1-bgp] quit

(2020-10-09)
[*PE1] commit
# Configure PE2.
[~PE2] bgp 100
[*PE2-bgp] quit
[*PE2] commit
# Configure PE3.
[~PE3] bgp 100
[*PE3-bgp] quit
[*PE3] commit
# Configure the RR.

[~RR] bgp 100
[*RR-bgp] quit
[*RR] commit
# Run the display evn bgp peer command on the RR. The command output
shows that BGP peer relationships have been established between the PEs and RR
and are in the Established state.


1.1.1.1 4 100 10 33 0 00:00:19 Established 6
2.2.2.2 4 100 8 33 0 00:00:20 Established 4
4.4.4.4 4 100 8 33 0 00:00:21 Established 4
# Run the display bgp evpn all routing-table peer 2.2.2.2 advertised-routes
and display bgp evpn all routing-table peer 4.4.4.4 advertised-routes
commands on the RR to view routes advertised to PE2 and PE3.
[~RR] display bgp evpn all routing-table peer 2.2.2.2 advertised-routes


(2020-10-09)

*>i 0000.1111.1111.1111.1111:0 1.1.1.1
*>i 0000.1111.2222.2222.2222:0 2.2.2.2
*>i 0000.1111.1111.1111.1111:0 1.1.1.1
*>i 0000.1111.3333.3333.3333:0 4.4.4.4
*>i 0000.1111.1111.1111.1111:4294967295 1.1.1.1
*>i 0000.1111.2222.2222.2222:4294967295 2.2.2.2
*>i 0000.1111.3333.3333.3333:4294967295 4.4.4.4

*>i 0:32:1.1.1.1 1.1.1.1
*>i 0:32:2.2.2.2 2.2.2.2
*>i 0:32:1.1.1.1 1.1.1.1
*>i 0:32:4.4.4.4 4.4.4.4

*>i 0000.1111.1111.1111.1111 1.1.1.1
*>i 0000.1111.2222.2222.2222 2.2.2.2
*>i 0000.1111.3333.3333.3333 4.4.4.4


*>i 0000.1111.1111.1111.1111:0 1.1.1.1
*>i 0000.1111.2222.2222.2222:0 2.2.2.2
*>i 0000.1111.1111.1111.1111:0 1.1.1.1
*>i 0000.1111.3333.3333.3333:0 4.4.4.4
*>i 0000.1111.1111.1111.1111:4294967295 1.1.1.1

(2020-10-09)
*>i 0000.1111.2222.2222.2222:4294967295 2.2.2.2

*>i 0000.1111.3333.3333.3333:4294967295 4.4.4.4

*>i 0:32:1.1.1.1 1.1.1.1
*>i 0:32:2.2.2.2 2.2.2.2
*>i 0:32:1.1.1.1 1.1.1.1
*>i 0:32:4.4.4.4 4.4.4.4

*>i 0000.1111.1111.1111.1111 1.1.1.1
*>i 0000.1111.2222.2222.2222 2.2.2.2
*>i 0000.1111.3333.3333.3333 4.4.4.4
The command output shows that the RR reflects all routes to PE2 and PE3.
However, PE2 and PE3 do not have to receive all the routes. To resolve this
problem, configure EVPN ORF on each device.
Step 10 Configure EVPN ORF on each device.
# Configure PE1.
[~PE1] bgp 100
[*PE1-bgp] ipv4-family vpn-target
[*PE1-bgp-af-vpn-target] peer 3.3.3.3 enable
[*PE1-bgp-af-vpn-target] quit
[*PE1-bgp-af-evpn] vpn-orf enable
[*PE1-bgp] quit
[*PE1] commit
# Configure PE2.
[~PE2] bgp 100
[*PE2-bgp] quit
[*PE2] commit
# Configure PE3.
[~PE3] bgp 100
[*PE3-bgp] quit
[*PE3] commit

(2020-10-09)
# Configure the RR.

[~RR] bgp 100
[*RR-bgp] ipv4-family vpn-target
[*RR-bgp-af-vpn-target] peer 1.1.1.1 enable
[*RR-bgp-af-vpn-target] peer 1.1.1.1 reflect-client
[*RR-bgp-af-vpn-target] quit
[*RR-bgp-af-evpn] vpn-orf enable
[*RR-bgp] quit
[*RR] commit
Run the display bgp vpn-target routing-table command on the RR. The
command output shows that the RR has received ORF routes.
[~RR] display bgp vpn-target routing-table
Total number of routes from all PE: 7

Origin AS: 100

Network NextHop MED LocPrf PrefVal Path/Ogn
*>i RT <1 : 1> 1.1.1.1 0 100 0 ?
*i 2.2.2.2 0 100 0 ?
*>i RT <2 : 2> 1.1.1.1 0 100 0 ?
*i 4.4.4.4 0 100 0 ?
*>i RT <00e0-fc00-0001> 1.1.1.1 0 100 0 ?
*>i RT <00e0-fc00-0002> 2.2.2.2 0 100 0 ?
*>i RT <00e0-fc00-0003> 4.4.4.4 0 100 0 ?
Run the display bgp evpn all routing-table peer 2.2.2.2 advertised-routes and
display bgp evpn all routing-table peer 4.4.4.4 advertised-routes commands on
the RR again. The command output shows that the RR has advertised only
requested routes to PE2 and PE3.


*>i 0000.1111.1111.1111.1111:0 1.1.1.1
*>i 0000.1111.1111.1111.1111:4294967295 1.1.1.1

(2020-10-09)

*>i 0:32:1.1.1.1 1.1.1.1


*>i 0000.1111.1111.1111.1111:0 1.1.1.1
*>i 0000.1111.1111.1111.1111:4294967295 1.1.1.1

*>i 0:32:1.1.1.1 1.1.1.1
----End
Configuration Files
#
sysname PE1
#
#
#
mpls lsr-id 1.1.1.1
#
mpls
#
bridge-domain 10
#
bridge-domain 20
#
mpls ldp
#
undo shutdown
esi 0000.1111.1111.1111.1111
#
rewrite pop single
bridge-domain 10
#

(2020-10-09)

rewrite pop single
bridge-domain 20
#
undo shutdown
ip address 10.1.1.1 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 1.1.1.1 255.255.255.255
#
bgp 100
#
ipv4-family unicast
peer 3.3.3.3 enable
#
l2vpn-family evpn
vpn-orf enable
peer 3.3.3.3 enable
#
ipv4-family vpn-target
peer 3.3.3.3 enable
#
ospf 1
area 0.0.0.0
network 1.1.1.1 0.0.0.0
network 10.1.1.0 0.0.0.255
#
#
return
#
sysname PE2
#
#
mpls lsr-id 2.2.2.2
#
mpls
#
bridge-domain 10
#
mpls ldp
#
undo shutdown
esi 0000.1111.2222.2222.2222
#
rewrite pop single
bridge-domain 10
#
undo shutdown
ip address 10.2.1.1 255.255.255.0
mpls
mpls ldp

(2020-10-09)
#
interface LoopBack1
ip address 2.2.2.2 255.255.255.255
#
bgp 100
#
ipv4-family unicast
peer 3.3.3.3 enable
#
l2vpn-family evpn
vpn-orf enable
peer 3.3.3.3 enable
#
peer 3.3.3.3 enable
#
ospf 1
area 0.0.0.0
network 2.2.2.2 0.0.0.0
network 10.2.1.0 0.0.0.255
#
#
return
#
sysname PE3
#
#
mpls lsr-id 4.4.4.4
#
mpls
#
bridge-domain 20
#
mpls ldp
#
undo shutdown
ip address 10.3.1.2 255.255.255.0
mpls
mpls ldp
#
undo shutdown
esi 0000.1111.3333.3333.3333
#
rewrite pop single
bridge-domain 20
#
interface LoopBack1
ip address 4.4.4.4 255.255.255.255
#
bgp 100
#
ipv4-family unicast

(2020-10-09)
peer 3.3.3.3 enable
#
l2vpn-family evpn
vpn-orf enable
peer 3.3.3.3 enable
#
peer 3.3.3.3 enable
#
ospf 1
area 0.0.0.0
network 4.4.4.4 0.0.0.0
network 10.3.1.0 0.0.0.255
#
#
return
#
sysname RR
#
mpls lsr-id 3.3.3.3
#
mpls
#
mpls ldp
#
undo shutdown
ip address 10.1.1.2 255.255.255.0
mpls
mpls ldp
#
undo shutdown
ip address 10.2.1.2 255.255.255.0
mpls
mpls ldp
#
undo shutdown
ip address 10.3.1.1 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 3.3.3.3 255.255.255.255
#
bgp 100
#
ipv4-family unicast
peer 1.1.1.1 enable
peer 2.2.2.2 enable
peer 4.4.4.4 enable
#
l2vpn-family evpn
vpn-orf enable
peer 1.1.1.1 enable

(2020-10-09)
peer 2.2.2.2 enable

peer 4.4.4.4 enable
#
peer 1.1.1.1 enable
peer 2.2.2.2 enable
peer 4.4.4.4 enable
#
ospf 1
area 0.0.0.0
network 3.3.3.3 0.0.0.0
network 10.1.1.0 0.0.0.255
network 10.2.1.0 0.0.0.255
network 10.3.1.0 0.0.0.255
#
return
#
sysname CE1
#
bridge-domain 10
#
bridge-domain 20
#
undo shutdown
#
rewrite pop single
bridge-domain 10
#
rewrite pop single
bridge-domain 20
#
return
#
sysname CE2
#
bridge-domain 10
#
undo shutdown
#
rewrite pop single
bridge-domain 10
#
return
#
sysname CE3
#
bridge-domain 20
#
undo shutdown
#

(2020-10-09)

rewrite pop single
bridge-domain 20
#
return
3.2.36.8 Example for Configuring a DCI Scenario with an E2E VXLAN EVPN
Deployed
This section provides an example for configuring a DCI scenario with an E2E
VXLAN EVPN deployed. In this example, an E2E VXLAN tunnel is established
between DC gateways, and an L3VPN is deployed over the DCI backbone network
to transmit VXLAN packets.
On the network shown in Figure 3-163, an end-to-end VXLAN tunnel can be
established between Device1 and Device2 to implement communication between
DC A and DC B. For example, VMa1 and VMb2 need to communicate with each
other. To meet this requirement, establish a BGP EVPN peer relationship between
Device1 and Device2 so that they can learn MAC and IP routes from each other. In
addition, gateways GW1 and GW2 in the DCs are connected to DCI-PE1 and DCI-
PE2, respectively, on the backbone network. An L3VPN based on an MPLS TE
tunnel is established between DCI-PE1 and DCI-PE2 to transmit VXLAN packets
(which can be considered as common IP packets).
Figure 3-163 Configuring an E2E VXLAN EVPN

NOTE

(2020-10-09)
Table 3-13 Interface IP addresses
Device Interface Name IP Address

Name
GigabitEthernet 1/0/0 192.168.20.1/24
DCI-PE1 GigabitEthernet 2/0/0 192.168.1.1/24
LoopBack1 1.1.1.1/32
P GigabitEthernet 2/0/0 192.168.10.1/24
DCI-PE2 GigabitEthernet 2/0/0 192.168.10.2/24
GW1 GigabitEthernet 1/0/0 192.168.20.2/24
GW2 GigabitEthernet 1/0/0 192.168.30.2/24
Device1 GigabitEthernet 2/0/0 192.168.40.2/24
Device2 GigabitEthernet 2/0/0 192.168.50.2/24
1. Configure an IGP in the data centers and on the DCI backbone network.
2. Configure an MPLS TE tunnel on the DCI backbone network.
3. Configure a VPN instance on each DCI-PE and bind the interface connected to
a gateway to the VPN instance.
4. Establish an MP-IBGP peer relationship between DCI-PEs for them to
exchange VPNv4 routes.
5. Configure EBGP on DCI-PEs and gateways to exchange VPNv4 routes.
6. Establish a BGP EVPN peer relationship between Device1 and Device2.

(2020-10-09)
7. Configure an end-to-end VXLAN tunnel between Device1 and Device2.
Data Preparation
● VNIs on Device1 and Device2
● MPLS LSR IDs of the DCI-PEs and P
● Route distinguisher (RD) of a VPN instance
● RTs used for route acceptance and advertisement
Procedure
Step 1 Assign an IP address to each interface on each node, and configure loopback
interface addresses.
Step 2 Configure an IGP in the data centers and on the DCI backbone network. In this
example, OSPF is used.
For configuration details, see Configuration Files in this section. On GW1 and
GW2, import BGP routes to OSPF so that Device1 and Device2 can learn the IP
routes destined for each other's VTEP address.
Step 3 Configure an MPLS TE tunnel on the DCI backbone network.
Step 4 Configure VPN instances on DCI-PEs, connect gateways to the DCI-PEs individually,
and apply a tunnel policy.
# Configure DCI-PE1.
<DCI-PE1> system-view
[~DCI-PE1] tunnel-policy te-lsp1
[*DCI-PE1-tunnel-policy-te-lsp1] tunnel select-seq cr-lsp load-balance-number 1
[*DCI-PE1-tunnel-policy-te-lsp1] quit
[*DCI-PE1] ip vpn-instance vpn1
[*DCI-PE1-vpn-instance-vpn1] ipv4-family
[*DCI-PE1-vpn-instance-vpn1-af-ipv4] route-distinguisher 100:1
[*DCI-PE1-vpn-instance-vpn1-af-ipv4] tnl-policy te-lsp1
[*DCI-PE1-vpn-instance-vpn1-af-ipv4] vpn-target 111:1 both
[*DCI-PE1-vpn-instance-vpn1-af-ipv4] quit
[*DCI-PE1-vpn-instance-vpn1] quit
[*DCI-PE1] interface gigabitethernet 1/0/0
[*DCI-PE1-GigabitEthernet1/0/0] ip binding vpn-instance vpn1
[*DCI-PE1-GigabitEthernet1/0/0] ip address 192.168.20.1 24
[*DCI-PE1-GigabitEthernet1/0/0] quit
[*DCI-PE1] commit
<DCI-PE2> system-view

(2020-10-09)
[*DCI-PE2] interface gigabitethernet 1/0/0
[*DCI-PE2-GigabitEthernet1/0/0] ip binding vpn-instance vpn1
[*DCI-PE2-GigabitEthernet1/0/0] ip address 192.168.30.1 24
[*DCI-PE2-GigabitEthernet1/0/0] quit
[*DCI-PE2] commit
Step 5 Set up an EBGP peer relationship between each DCI-PE and its connected
gateway.
[~DCI-PE1] bgp 100
[*DCI-PE1-bgp] ipv4-family vpn-instance vpn1
[*DCI-PE1-bgp-vpn1] peer 192.168.20.2 as-number 65410
[*DCI-PE1-bgp-vpn1] quit
[*DCI-PE1] commit
[~DCI-PE2] bgp 100
[*DCI-PE2-bgp-vpn1] peer 192.168.30.2 as-number 65420
[*DCI-PE2] commit
Step 6 Set up an MP-IBGP peer relationship between DCI-PEs.

[~DCI-PE1] bgp 100
[*DCI-PE1-bgp] peer 3.3.3.3 as-number 100
[*DCI-PE1-bgp] peer 3.3.3.3 connect-interface loopback 1
[*DCI-PE1-bgp] ipv4-family vpnv4
[*DCI-PE1-bgp-af-vpnv4] peer 3.3.3.3 enable
[*DCI-PE1-bgp-af-vpnv4] quit
[*DCI-PE1-bgp] quit
[*DCI-PE1] commit
[~DCI-PE2] bgp 100
[*DCI-PE2-bgp] quit
[*DCI-PE2] commit
Step 7 Establish a BGP EVPN peer relationship between Device1 and Device2.
# Configure Device1.
<Device1> system-view
[~Device1] bgp 65410
[*Device1-bgp] peer 4.4.4.4 as-number 65410
[*Device1-bgp] peer 4.4.4.4 connect-interface LoopBack1
[*Device1-bgp] peer 6.6.6.6 ebgp-max-hop 255
[*Device1-bgp] l2vpn-family evpn
[*Device1-bgp-bgp-af-evpn] peer 6.6.6.6 enable
[*Device1-bgp-bgp-af-evpn] peer 6.6.6.6 next-hop-invariable
[*Device1-bgp-bgp-af-evpn] peer 6.6.6.6 advertise encap-type vxlan
[*Device1-bgp-bgp-af-evpn] quit
[*Device1-bgp] quit
[*Device1] commit

(2020-10-09)
<Device2> system-view
[~Device2] bgp 65420
[*Device2-bgp] peer 5.5.5.5 ebgp-max-hop 255
[*Device2-bgp] l2vpn-family evpn
[*Device2-bgp-bgp-af-evpn] peer 5.5.5.5 enable
[*Device2-bgp-bgp-af-evpn] peer 5.5.5.5 next-hop-invariable
[*Device2-bgp-bgp-af-evpn] peer 5.5.5.5 advertise encap-type vxlan
[*Device2-bgp-bgp-af-evpn] quit
[*Device2-bgp] quit
[*Device2] commit
# Configure GW1. To enable the remote Device2 to learn the IP route to the VTEP
address on the local Device1, GW1 needs to import the involved OSPF route into
BGP.
<GW1> system-view
[~GW1] bgp 65410
[*GW1-bgp] peer 5.5.5.5 as-number 65410
[*GW1-bgp] peer 5.5.5.5 connect-interface LoopBack1
[*GW1-bgp] network 4.4.4.4 32
[*GW1-bgp] import-route ospf 1
[*GW1-bgp] quit
[*GW1] commit
# Configure GW2. To enable the remote Device1 to learn the IP route to the VTEP
address on the local Device2, GW2 needs to import the involved OSPF route into
BGP.
<GW1> system-view
[~GW2] bgp 65420
[*GW2-bgp] peer 6.6.6.6 connect-interface LoopBack1
[*GW2-bgp] network 7.7.7.7 32
[*GW2-bgp] import-route ospf 1
[*GW2-bgp] quit
[*GW2] commit
Step 8 Configure an EVPN instance on Device1 and Device2.
[~Device1] evpn vpn-instance evrf1 bd-mode
[*Device1-evpn-instance-evrf1] route-distinguisher 10:1
[*Device1-evpn-instance-evrf1] vpn-target 11:1 both
[*Device1-evpn-instance-evrf1] quit
[*Device1] bridge-domain 10
[*Device1-bd10] vxlan vni 10 split-horizon-mode
[*Device1-bd10] evpn binding vpn-instance evrf1
[*Device1-bd10] quit
[*Device1] commit
[~Device2] evpn vpn-instance evrf1 bd-mode
[*Device2-evpn-instance-evrf1] route-distinguisher 20:1
[*Device2-evpn-instance-evrf1] vpn-target 11:1 both
[*Device2-evpn-instance-evrf1] quit
[*Device2] bridge-domain 10
[*Device2-bd10] vxlan vni 10 split-horizon-mode
[*Device2-bd10] evpn binding vpn-instance evrf1

(2020-10-09)
[*Device2-bd10] quit
[*Device2] commit
Step 9 Configure a VXLAN tunnel between Device1 and Device2.
[~Device1] interface nve 1
[*Device1-Nve1] source 5.5.5.5
[*Device1-Nve1] vni 10 head-end peer-list protocol bgp
[*Device1-Nve1] quit
[*Device1] commit
[~Device2] interface nve 1
[*Device2-Nve1] source 6.6.6.6
[*Device2-Nve1] vni 10 head-end peer-list protocol bgp
[*Device2-Nve1] quit
[*Device2] commit
Step 10 Configure service access points on Device1 and Device2 and connect them to VMs
through Layer 2 sub-interfaces.
[~Device1] interface gigabitethernet 1/0/0.1 mode l2
[*Device1-GigabitEthernet 1/0/0.1] encapsulation dot1q vid 10
[*Device1-GigabitEthernet 1/0/0.1] rewrite pop single
[*Device1-GigabitEthernet 1/0/0.1] bridge-domain 10
[*Device1-GigabitEthernet 1/0/0.1] quit
[*Device1] commit
[~Device2] interface gigabitethernet 1/0/0.1 mode l2
[*Device2-GigabitEthernet 1/0/0.1] encapsulation dot1q vid 10
[*Device2-GigabitEthernet 1/0/0.1] rewrite pop single
[*Device2-GigabitEthernet 1/0/0.1] bridge-domain 10
[*Device2-GigabitEthernet 1/0/0.1] quit
[*Device2] commit
Run the display bgp evpn peer command on Device1. The command output
shows that Device1 has established a BGP EVPN peer relationship with Device2.
[~Device1] display bgp evpn peer

6.6.6.6 4 65420 711 711 0 10:14:35 Established 2
Run the display vxlan tunnel command on Device1. The command output shows
that an end-to-end VXLAN tunnel has been established between Device1 and
Device2.
[~Device1] display vxlan tunnel
Number of vxlan tunnel : 1
Tunnel ID Source Destination State Type Uptime
-----------------------------------------------------------------------------------
4026531843 5.5.5.5 6.6.6.6 up dynamic 10:17:15
----End

(2020-10-09)
Configuration Files
● Device1 configuration file
#
sysname Device1
#
#
bridge-domain 10
vxlan vni 10 split-horizon-mode
#
undo shutdown
#
rewrite pop single
bridge-domain 10
#
undo shutdown
ip address 192.168.40.2 255.255.255.0
#
interface LoopBack1
ip address 5.5.5.5 255.255.255.255
#
interface Nve1
source 5.5.5.5
vni 10 head-end peer-list protocol bgp
#
bgp 65410
#
ipv4-family unicast
peer 4.4.4.4 enable
peer 6.6.6.6 enable
#
l2vpn-family evpn
policy vpn-target
peer 6.6.6.6 enable
peer 6.6.6.6 next-hop-invariable
peer 6.6.6.6 advertise encap-type vxlan
#
ospf 1
area 0.0.0.0
network 5.5.5.5 0.0.0.0
network 192.168.40.0 0.0.0.255
#
return
● Device2 configuration file
#
sysname Device2
#
#
bridge-domain 10

(2020-10-09)

#
undo shutdown
#
rewrite pop single
bridge-domain 10
#
undo shutdown
ip address 192.168.50.2 255.255.255.0
#
interface LoopBack1
ip address 6.6.6.6 255.255.255.255
#
interface Nve1
source 6.6.6.6
#
bgp 65420
#
ipv4-family unicast
peer 5.5.5.5 enable
peer 7.7.7.7 enable
#
l2vpn-family evpn
policy vpn-target
peer 5.5.5.5 enable
peer 5.5.5.5 next-hop-invariable
#
ospf 1
area 0.0.0.0
network 6.6.6.6 0.0.0.0
network 192.168.50.0 0.0.0.255
#
return
● GW1 configuration file

#
sysname GW1
#
undo shutdown
ip address 192.168.20.2 255.255.255.0
#
undo shutdown
ip address 192.168.40.1 255.255.255.0
#
interface LoopBack1
ip address 4.4.4.4 255.255.255.255
#
bgp 65410
peer 192.168.20.1 as-number 100
#
ipv4-family unicast
network 4.4.4.4 255.255.255.255
import-route ospf 1

(2020-10-09)
peer 5.5.5.5 enable

#
ospf 1
import-route bgp
area 0.0.0.0
network 4.4.4.4 0.0.0.0
network 192.168.40.0 0.0.0.255
#
return

#
sysname GW2
#
undo shutdown
ip address 192.168.30.2 255.255.255.0
#
undo shutdown
ip address 192.168.50.1 255.255.255.0
#
interface LoopBack1
ip address 7.7.7.7 255.255.255.255
#
bgp 65420
peer 192.168.30.1 as-number 100
#
ipv4-family unicast
network 7.7.7.7 255.255.255.255
import-route ospf 1
peer 6.6.6.6 enable
#
ospf 1
import-route bgp
area 0.0.0.0
network 7.7.7.7 0.0.0.0
network 192.168.50.0 0.0.0.255
#
return
● DCI-PE1 configuration file

#
sysname DCI-PE1
#
ipv4-family
tnl-policy te-lsp1
#
mpls lsr-id 1.1.1.1
#
mpls
mpls te
mpls te cspf
mpls rsvp-te
#
undo shutdown
ip address 192.168.20.1 255.255.255.0
#

(2020-10-09)
undo shutdown
ip address 192.168.1.1 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 1.1.1.1 255.255.255.255
#
interface Tunnel10
destination 3.3.3.3
#
bgp 100
#
ipv4-family unicast
peer 3.3.3.3 enable
#
ipv4-family vpnv4
policy vpn-target
peer 3.3.3.3 enable
#
peer 192.168.20.2 as-number 65410
#
ospf 1
area 0.0.0.0
network 1.1.1.1 0.0.0.0
network 192.168.1.0 0.0.0.255
mpls-te enable
#
tunnel-policy te-lsp1
tunnel select-seq cr-lsp load-balance-number 1
#
return
#
sysname P
#
mpls lsr-id 2.2.2.2
#
mpls
mpls te
mpls te cspf
mpls rsvp-te
#
undo shutdown
ip address 192.168.1.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
undo shutdown
ip address 192.168.10.1 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 2.2.2.2 255.255.255.255
#

(2020-10-09)
ospf 1
area 0.0.0.0
network 2.2.2.2 0.0.0.0
network 192.168.1.0 0.0.0.255
network 192.168.10.0 0.0.0.255
mpls-te enable
#
return
#
sysname DCI-PE2
#
ipv4-family
tnl-policy te-lsp1
#
mpls lsr-id 3.3.3.3
#
mpls
mpls te
mpls te cspf
mpls rsvp-te
#
undo shutdown
ip address 192.168.30.1 255.255.255.0
#
undo shutdown
ip address 192.168.10.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 3.3.3.3 255.255.255.255
#
interface Tunnel10
destination 1.1.1.1
#
bgp 100
#
ipv4-family unicast
peer 1.1.1.1 enable
#
ipv4-family vpnv4
policy vpn-target
peer 1.1.1.1 enable
#
peer 192.168.30.2 as-number 65420
#
ospf 1
area 0.0.0.0
network 3.3.3.3 0.0.0.0
network 192.168.10.0 0.0.0.255
mpls-te enable

(2020-10-09)
#
#
return
3.2.36.9 Example for Configuring a DCI Scenario with a VXLAN EVPN L3VPN
This section provides an example for configuring a DCI scenario with a VXLAN
EVPN L3VPN accessing a common L3VPN. In this example, a data center gateway
is connected to a PE on the DCI network through a VXLAN tunnel, and a common
L3VPN is deployed on the DCI network to implement data center interconnection.
In Figure 3-164, data center gateway devices GW1 and GW2 are connected to the
DCI backbone network. To allow inter-data center VM communication (for
example, VMa1 and VMb2 communication), BGP/MPLS IP VPN functions must be
deployed on the DCI backbone network, and EVPN and VXLAN tunnels must be
deployed between the GW and DCI-PE to transmit VM host IP route information.
Figure 3-164 Configuring a DCI scenario with a VXLAN EVPN L3VPN accessing a
common L3VPN
NOTE

(2020-10-09)
Device Interface Name IP Address

DCI-PE1
LoopBack2 11.11.11.11/32
RR GigabitEthernet 2/0/0 192.168.10.1/24

DCI-PE2
LoopBack2 33.33.33.33/32
1. Enable OSPF on the DCI backbone network for DCI-PEs to communicate with
each other.
3. Configure static routes on the DCI-PEs destined for the loopback interface
addresses of the DC-GWs.
4. Configure an EVPN instance and a BD on each DCI-PE.
5. Configure a source address on each DCI-PE.
6. Configure VXLAN tunnels between DCI-PEs and GWs.
7. Configure a VPN instance on each DCI-PE and bind the interface connected to
a GW to the VPN instance.
8. Configure an MP-IBGP peer relationship between each DCI-PE and RR to
exchange VPNv4 routes and configure RR in the figure as a route reflector.
9. Configure the route regeneration function on each DCI-PE-GW.
Data Preparation
● MPLS LSR IDs of the DCI-PEs and RR

● RD of a VPN instance
● VPN targets

(2020-10-09)
Procedure
Step 1 Assign an IP address to each interface on each node, and configure loopback
interface addresses.
Step 2 Configure an IGP on the DCI backbone network. OSPF is used as an IGP in this
example.
Step 4 On each DCI-PE, configure a static route destined for the loopback interface of the
connected DC-GW.
Step 5 Configure an EVPN instance and a BD on each DCI-PE.
[~DCI-PE1] evpn vpn-instance evrf1 bd-mode
[*DCI-PE1-evpn-instance-evrf1] route-distinguisher 10:1
[*DCI-PE1-evpn-instance-evrf1] vpn-target 11:1 both
[*DCI-PE1-evpn-instance-evrf1] quit
[*DCI-PE1] bridge-domain 10
[*DCI-PE1-bd10] vxlan vni 5010 split-horizon-mode
[*DCI-PE1-bd10] evpn binding vpn-instance evrf1
[*DCI-PE1-bd10] esi 0000.1111.1111.4444.5555
[*DCI-PE1-bd10] quit
[*DCI-PE1] interface GigabitEthernet 1/0/0.1 mode l2
[*DCI-PE1-GigabitEthernet1/0/0.1] encapsulation qinq
[*DCI-PE1-GigabitEthernet1/0/0.1] bridge-domain 10
[*DCI-PE1-GigabitEthernet1/0/0.1] quit
[*DCI-PE1] commit
[*DCI-PE2-bd10] esi 0000.1111.3333.4444.5555
[*DCI-PE2] commit
Step 6 Configure a source address on each DCI-PE.

[~DCI-PE1] evpn source-address 1.1.1.1
[*DCI-PE1] commit

(2020-10-09)
[*DCI-PE2] commit
Step 7 Establish a VXLAN tunnel.

1. Establish an EBGP EVPN peer relationship between each DCI-PE and its
connected GW.
[~DCI-PE1] bgp 100
[*DCI-PE1-bgp] peer 4.4.4.4 ebgp-max-hop 255
[*DCI-PE1-bgp] l2vpn-family evpn
[*DCI-PE1-bgp-af-evpn] peer 4.4.4.4 enable
[*DCI-PE1-bgp-af-evpn] peer 4.4.4.4 advertise encap-type vxlan
[*DCI-PE1-bgp-af-evpn] quit
[*DCI-PE1-bgp] quit
[*DCI-PE1] commit
[~DCI-PE2] bgp 100
[*DCI-PE2-bgp] quit
[*DCI-PE2] commit
2. Configure a VPN instance.

[~DCI-PE1] ip vpn-instance vpn1
[*DCI-PE1-vpn-instance-vpn1] vxlan vni 555
[*DCI-PE1-vpn-instance-vpn1-af-ipv4] vpn-target 11:1 both evpn
[*DCI-PE1] interface Vbdif10
[*DCI-PE1-Vbdif10] ip binding vpn-instance vpn1
[*DCI-PE1-Vbdif10] ip address 10.10.10.1 255.255.255.0
[*DCI-PE1-Vbdif10] arp collect host enable
[*DCI-PE1-Vbdif10] quit
[*DCI-PE1] commit
[*DCI-PE2] commit
3. Configure an IP address for the source VTEP.

(2020-10-09)
[~DCI-PE1] interface nve 1
[*DCI-PE1-Nve1] source 11.11.11.11
[*DCI-PE1-Nve1] quit
[*DCI-PE1] commit
[*DCI-PE2] commit
Step 8 Configure a VPN instance on each DCI-PE to apply a tunnel policy.

[*DCI-PE1] commit
[*DCI-PE2] commit
Step 9 Configure an MP-IBGP peer relationship between each DCI-PE and RR to exchange
VPNv4 routes and configure RR in the figure as a route reflector.
[~DCI-PE1] bgp 100
[*DCI-PE1-bgp] quit
[*DCI-PE1] commit
# Configure RR.
[~RR] bgp 100
[*RR-bgp] ipv4-family vpnv4
[*RR-bgp-af-vpnv4] peer 1.1.1.1 enable
[*RR-bgp-af-vpnv4] peer 1.1.1.1 reflect-client
[*RR-bgp-af-vpnv4] peer 3.3.3.3 enable
[*RR-bgp-af-vpnv4] peer 3.3.3.3 reflect-client
[*RR-bgp-af-vpnv4] quit
[*RR-bgp] quit
[*RR] commit

(2020-10-09)
[~DCI-PE2] bgp 100
[*DCI-PE2-bgp] quit
[*DCI-PE2] commit
Step 10 Configure each DCI-PE to send regenerated EVPN routes to VPNv4 peers and to
send regenerated VPNv4 routes to EVPN peers.
[~DCI-PE1] bgp 100
[*DCI-PE1-bgp-af-evpn] peer 4.4.4.4 import reoriginate
[*DCI-PE1-bgp-af-evpn] peer 4.4.4.4 advertise route-reoriginated vpnv4
[*DCI-PE1-bgp-af-vpnv4] peer 3.3.3.3 advertise route-reoriginated evpn mac-ip
[*DCI-PE1-bgp-af-vpnv4] peer 3.3.3.3 advertise route-reoriginated evpn ip
[*DCI-PE1-bgp-af-vpnv4] peer 3.3.3.3 import reoriginate
[*DCI-PE1-bgp-vpn1] advertise l2vpn evpn
[*DCI-PE1-bgp] quit
[*DCI-PE1] commit
[~DCI-PE1] bgp 100
[*DCI-PE1-bgp-af-evpn] peer 5.5.5.5 advertise route-reoriginated vpnv4
[*DCI-PE2-bgp-af-vpnv4] peer 1.1.1.1 import reoriginate
[*DCI-PE2-bgp-af-vpnv4] peer 1.1.1.1 advertise route-reoriginated evpn mac-ip
[*DCI-PE2-bgp-af-vpnv4] peer 1.1.1.1 advertise route-reoriginated evpn ip
[*DCI-PE2-bgp] quit
[*DCI-PE2] commit
Run the display ip routing-table vpn-instance command on DCI-PEs. The

following example uses the command output on DCI-PE1. The command output
shows that DCI-PE1 has a route to the loopback interface of GW1.
[~DCI-PE1] display ip routing-table vpn-instance vpn1
------------------------------------------------------------------------------
10.1.1.0/24 EBGP 255 0 RD 4.4.4.4 VXLAN

10.1.1.1/32 EBGP 255 0 RD 4.4.4.4 VXLAN
10.2.1.0/24 IBGP 255 0 RD 3.3.3.3 Tunnel10
10.2.1.1/32 IBGP 255 0 RD 3.3.3.3 Tunnel10

(2020-10-09)

Run the display vxlan tunnel command on DCI-PEs to check information about
the VXLAN tunnel. The following example uses the command output on DCI-PE1.
[~DCI-PE1] display vxlan tunnel
-----------------------------------------------------------------------------------
4026531843 11.11.11.11 4.4.4.4 up dynamic 00:51:23
----End
Configuration Files
#
sysname DCI-PE1
#
#
ipv4-family
tnl-policy te-lsp1
vxlan vni 555
#
mpls lsr-id 1.1.1.1
#
mpls
mpls te
mpls rsvp-te
mpls te cspf
#
bridge-domain 10
esi 0000.1111.1111.4444.5555
#
interface Vbdif10
ip address 10.10.10.1 255.255.255.0
#
undo shutdown
ip address 192.168.20.1 255.255.255.0
#
encapsulation qinq
bridge-domain 10
#
undo shutdown
ip address 192.168.1.1 255.255.255.0
mpls
mpls te
mpls rsvp-te
#

(2020-10-09)
interface LoopBack1
ip address 1.1.1.1 255.255.255.255
isis enable 1
#
interface LoopBack2
ip address 11.11.11.11 255.255.255.255
#
interface Nve1
source 11.11.11.11
#
interface Tunnel10
destination 3.3.3.3
#
bgp 100
#
ipv4-family unicast
peer 2.2.2.2 enable
peer 4.4.4.4 enable
#
ipv4-family vpnv4
policy vpn-target
peer 2.2.2.2 enable
peer 2.2.2.2 import reoriginate
peer 2.2.2.2 advertise route-reoriginated evpn mac-ip
peer 2.2.2.2 advertise route-reoriginated evpn ip
#
#
l2vpn-family evpn
peer 4.4.4.4 enable
peer 4.4.4.4 advertise route-reoriginated vpnv4
#
ospf 1
area 0.0.0.0
network 1.1.1.1 0.0.0.0
network 192.168.1.0 0.0.0.255
mpls-te enable
#
ip route-static 4.4.4.4 255.255.255.255 192.168.20.2
#
#
#
return
#
sysname RR
#
mpls lsr-id 2.2.2.2
#
mpls
mpls te
mpls rsvp-te

(2020-10-09)
mpls te cspf
#
undo shutdown
ip address 192.168.1.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
undo shutdown
ip address 192.168.10.1 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 2.2.2.2 255.255.255.255
#
bgp 100
#
ipv4-family unicast
peer 1.1.1.1 enable
peer 3.3.3.3 enable
#
ipv4-family vpnv4
peer 1.1.1.1 enable
peer 3.3.3.3 enable
#
ospf 1
area 0.0.0.0
network 2.2.2.2 0.0.0.0
network 192.168.1.0 0.0.0.255
network 192.168.10.0 0.0.0.255
mpls-te enable
#
return
#
sysname DCI-PE2
#
#
ipv4-family
tnl-policy te-lsp1
vxlan vni 555
#
mpls lsr-id 3.3.3.3
#
mpls
mpls te

(2020-10-09)
mpls rsvp-te
mpls te cspf
#
bridge-domain 10
esi 0000.1111.3333.4444.5555
#
interface Vbdif10
ip address 10.20.10.1 255.255.255.0
#
undo shutdown
ip address 192.168.30.1 255.255.255.0
#
encapsulation qinq
bridge-domain 10
#
undo shutdown
ip address 192.168.10.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 3.3.3.3 255.255.255.255
isis enable 1
#
interface LoopBack2
ip address 33.33.33.33 255.255.255.255
#
interface Nve1
source 33.33.33.33
#
interface Tunnel10
destination 1.1.1.1
#
bgp 100
#
ipv4-family unicast
peer 2.2.2.2 enable
peer 5.5.5.5 enable
#
ipv4-family vpnv4
policy vpn-target
peer 2.2.2.2 enable
#
#
l2vpn-family evpn
peer 5.5.5.5 enable

(2020-10-09)

#
ospf 1
area 0.0.0.0
network 3.3.3.3 0.0.0.0
network 192.168.10.0 0.0.0.255
mpls-te enable
#
ip route-static 5.5.5.5 255.255.255.255 192.168.30.2
#
#
#
return

See the data center device configuration file.
● Device 1 configuration file
3.2.36.10 Example for Configuring MPLS EVPN E-LAN Option B

This section provides an example for configuring inter-AS MPLS EVPN Option B. A
single-hop MP-EBGP peer relationship is established between ASBRs to exchange
EVPN routes.
Context
As shown in Figure 3-165, CE1 and CE2 belong to the same EVPN. CE1 is
connected to PE1 in AS 100, and CE2 is connected to PE2 in AS 200. It is required
that an MP-EBGP peer relationship be established between the ASBRs to transmit
EVPN routes, implementing inter-AS MPLS EVPN E-LAN Option B.
Figure 3-165 Configuring MPLS EVPN E-LAN Option B

NOTE

(2020-10-09)
Configuration Notes
When configuring MPLS EVPN E-LAN Option B, note the following:
● Configure an MP-EBGP peer relationship between ASBR1 and ASBR2, and

disable the ASBRs from filtering received EVPN routes based on RTs.
1. Configure an IGP on the MPLS backbone network to implement interworking

of the ASBRs and PEs in each AS, and establish an MPLS LDP LSP between the
ASBRs and PEs in each AS.
2. Configure the CE access function on the PE and establish an MP-IBGP peer
relationship between the PE and ASBR in each AS.
3. Configure EVPN instances on PEs (no EVPN instance needs to be configured
on ASBRs).
4. Enable MPLS on the ASBR interfaces connected to each other. Establish an
MP-EBGP peer relationship between ASBRs and configure ASBRs not to filter
VPNv6 routes based on RTs.
Data Preparation
● Interface names and IP address

● MPLS LSR IDs of the PEs and ASBRs
● Names, RDs, and RTs of the EVPN instances of the PEs
Procedure
Step 1 On the MPLS backbone networks in AS 100 and AS 200, configure an IGP to
interconnect the PEs on each network.

(2020-10-09)
In this example, OSPF is used as an IGP. For configuration details, see

NOTE
LSR IDs, where are 32-bit IP addresses of loopback interfaces, need to be advertised using
OSPF.
After completing the preceding configurations, run the display ospf peer
command on the ASBR and PE in each AS. The command output shows that the
OSPF neighbor relationship is in the Full state, which indicates that the OSPF
neighbor relationship has been established between the ASBR and PE in the same
AS.
The ASBR and PE in the same AS can learn the loopback interface address of each
other and successfully ping each other.
Step 2 Configure basic MPLS capabilities and MPLS LDP on the MPLS backbone networks
of AS 100 and AS 200 to establish LDP LSPs.
Step 3 Configure basic EVPN functions on PE1 and PE2.
NOTE
PE1's import and export RTs must match PE2's export and import RTs, respectively.

Step 4 Configuring inter-AS MPLS EVPN Option B
# Configure ASBR1. Enable MPLS on GE 2/0/0 connected to ASBR2.
[~ASBR1] interface GigabitEthernet 2/0/0
[~ASBR1-GigabitEthernet2/0/0] ip address 192.168.1.1 24
[*ASBR1] commit
On ASBR1, specify ASBR2 as an MP-EBGP peer, and disable ASBR1 from filtering
received EVPN routes based on RTs.
[~ASBR1] bgp 100
[*ASBR1-bgp] l2vpn-family evpn
[*ASBR1-bgp-af-EVPN] peer 192.168.1.2 enable
[*ASBR1-bgp-af-EVPN] undo policy vpn-target
[*ASBR1-bgp-af-EVPN] commit
[~ASBR1-bgp-af-EVPN] quit
[~ASBR1-bgp] quit
The configuration of ASBR2 is similar to that of ASBR1. For configuration details,

----End
Configuration Files
#
sysname PE1
#
evpn vpn-instance evrf_1 bd-mode

(2020-10-09)
#
mpls lsr-id 1.1.1.9
#
mpls
#
bridge-domain 10
evpn binding vpn-instance evrf_1
#
mpls ldp
#
ipv4-family
#
undo shutdown
ip address 172.21.1.2 255.255.255.0
mpls
mpls ldp
#
undo shutdown
#
rewrite pop single
bridge-domain 10
#
interface LoopBack1
ip address 1.1.1.9 255.255.255.255
#
bgp 100
#
ipv4-family unicast
peer 2.2.2.9 enable
#
l2vpn-family evpn
policy vpn-target
peer 2.2.2.9 enable
peer 2.2.2.9 esad-route-compatible enable
#
ospf 1
area 0.0.0.0
network 1.1.1.9 0.0.0.0
network 172.21.1.0 0.0.0.255
#
#
return
#
sysname ASBR1
#
mpls lsr-id 2.2.2.9
#
mpls
#
mpls ldp
#
ipv4-family
#
undo shutdown
ip address 172.21.1.1 255.255.255.0
mpls

(2020-10-09)
mpls ldp
#
undo shutdown
ip address 192.168.1.1 255.255.255.0
mpls
#
interface LoopBack1
ip address 2.2.2.9 255.255.255.255
#
bgp 100
#
ipv4-family unicast
peer 1.1.1.9 enable
#
l2vpn-family evpn
peer 1.1.1.9 enable
#
ospf 1
area 0.0.0.0
network 2.2.2.9 0.0.0.0
network 172.21.1.0 0.0.0.255
#
return
#
sysname ASBR2
#
mpls lsr-id 3.3.3.9
#
mpls
#
mpls ldp
#
ipv4-family
#
undo shutdown
ip address 172.22.1.1 255.255.255.0
mpls
mpls ldp
#
undo shutdown
ip address 192.168.1.2 255.255.255.0
mpls
#
interface LoopBack1
ip address 3.3.3.9 255.255.255.255
#
bgp 200
#
ipv4-family unicast
peer 4.4.4.9 enable
#

(2020-10-09)
l2vpn-family evpn
peer 4.4.4.9 enable
#
ospf 1
area 0.0.0.0
network 3.3.3.9 0.0.0.0
network 172.22.1.0 0.0.0.255
#
return
#
sysname PE2
#
evpn vpn-instance evrf_1 bd-mode
#
mpls lsr-id 4.4.4.9
#
mpls
#
bridge-domain 10
evpn binding vpn-instance evrf_1
#
mpls ldp
#
ipv4-family
#
undo shutdown
ip address 172.22.1.2 255.255.255.0
mpls
mpls ldp
#
undo shutdown
#
rewrite pop single
bridge-domain 10
#
interface LoopBack1
ip address 4.4.4.9 255.255.255.255
#
bgp 200
#
ipv4-family unicast
peer 3.3.3.9 enable
#
l2vpn-family evpn
policy vpn-target
peer 3.3.3.9 enable
#
#
ospf 1
area 0.0.0.0
network 4.4.4.9 0.0.0.0
network 172.22.1.0 0.0.0.255
#

(2020-10-09)

#
return
3.2.36.11 Example for Configuring MPLS EVPN L3VPN E-LAN Option B

This section describes how to configure MPLS EVPN L3VPN E-LAN Option B to
carry inter-AS Layer 3 service traffic.
Context
As shown in Figure 3-166, CE1 and CE2 belong to the same VPN. CE1 is
connected to PE1 in AS 100, and CE2 is connected to PE2 in AS 200. An EBGP
EVPN peer relationship is configured between ASBR1 and ASBR2 to exchange
EVPN routes so that an inter-AS Option B EVPN can carry Layer 3 service traffic.
Figure 3-166 Configuring MPLS EVPN L3VPN E-LAN Option B

NOTE
Configuration Notes
When configuring MPLS EVPN L3VPN E-LAN Option B, note the following:
● Establish an EBGP EVPN peer relationship between ASBR1 and ASBR2 and
configure ASBR1 not to filter received EVPN routes based on RTs.

(2020-10-09)
1. Configure an IGP on the MPLS backbone networks in AS 100 and AS 200 to
implement intra-AS communication.
2. Configure basic MPLS capabilities and MPLS LDP on the MPLS backbone
networks of AS 100 and AS 200 to establish LDP LSPs.
3. Configure an L3VPN instance on each PE.
4. Establish a BGP EVPN peer relationship between the PE and ASBR in each AS.
5. Configure a VPN BGP peer relationship between the PE and CE in each AS.
6. Enable MPLS on the ASBR interfaces connected to the other ASBR, establish
EBGP EVPN peer relationships between ASBRs, and configure ASBRs not to
filter received EVPN routes based on RTs.
Data Preparation
● Interface names and IP address
● MPLS LSR IDs of the PEs and ASBRs
● Names (vpn1), RDs (100:1 and 200:1), and VPN targets (1:1) of the L3VPN
instances created on PE1 and PE2
Procedure
Step 1 Configure an IGP on the MPLS backbone networks in AS 100 and AS 200 to
implement intra-AS communication.
In this example, OSPF is used in AS 100, and IS-IS is used in AS 200. For
Step 2 Configure basic MPLS capabilities and MPLS LDP on the MPLS backbone networks
of AS 100 and AS 200 to establish LDP LSPs.
Step 3 Configure an L3VPN instance on each PE.
# Configure PE1.
[*PE1] commit
section.
Step 4 Establish BGP EVPN peer relationships between PEs and ASBRs.
# Configure PE1.
[~PE1] bgp 100

(2020-10-09)
[*PE1-bgp] peer 2.2.2.9 connect-interface LoopBack1

[*PE1-bgp] commit
The configurations of ASBR1, ASBR2, and PE2 are similar to that of PE1. For
Step 5 Configure VPN BGP peer relationships between PEs and CEs.
# Configure PE1.
[*PE1-bgp] quit
[*PE1] commit
The configuration of PE2 is similar to that of PE1. For configuration details, see
# Configure CE1.
[~CE1] bgp 65410
[*CE1-bgp] quit
[*CE1] commit
The configuration of CE2 is similar to the configuration of CE1. For configuration

details, see Configuration Files in this section.
Step 6 Enable MPLS on the interfaces that connect ASBRs to each other, establish EBGP
EVPN peer relationships between ASBRs, and configure ASBRs not to filter
received EVPN routes based on RTs.
# Configure ASBR1.
[~ASBR1] bgp 100
[*ASBR1-bgp] l2vpn-family evpn
[*ASBR1-bgp-af-evpn] peer 10.2.1.2 enable
[*ASBR1-bgp-af-evpn] quit
[*ASBR1-bgp] quit
[*ASBR1] interface GigabitEthernet2/0/0
[*ASBR1] commit
The configuration of ASBR2 is similar to the configuration of ASBR1. For

# After completing the configuration, run the display ip routing-table command
on each CE to view the route to the remote CE. The command output on CE1 is
used as an example.
[~CE1] display ip routing-table
------------------------------------------------------------------------------

(2020-10-09)

----End
Configuration Files
#
sysname PE1
#
ipv4-family
#
mpls lsr-id 1.1.1.9
#
mpls
#
mpls ldp
#
undo shutdown
ip address 192.168.1.1 255.255.255.0
#
undo shutdown
ip address 10.1.1.2 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 1.1.1.9 255.255.255.255
#
bgp 100
#
ipv4-family unicast
peer 2.2.2.9 enable
#
import-route direct
peer 192.168.1.2 as-number 65410
#
l2vpn-family evpn
peer 2.2.2.9 enable
#
ospf 1
area 0.0.0.0
network 1.1.1.9 0.0.0.0

(2020-10-09)
network 10.1.1.0 0.0.0.255

#
#
return
#
sysname ASBR1
#
mpls lsr-id 2.2.2.9
#
mpls
#
mpls ldp
#
undo shutdown
ip address 10.1.1.1 255.255.255.0
mpls
mpls ldp
#
undo shutdown
ip address 10.2.1.1 255.255.255.0
mpls
#
interface LoopBack1
ip address 2.2.2.9 255.255.255.255
#
bgp 100
#
ipv4-family unicast
peer 1.1.1.9 enable
#
l2vpn-family evpn
peer 1.1.1.9 enable
#
ospf 1
area 0.0.0.0
network 2.2.2.9 0.0.0.0
network 10.1.1.0 0.0.0.255
#
return
#
sysname ASBR2
#
mpls lsr-id 3.3.3.9
#
mpls
#
mpls ldp
#
isis 1
network-entity 00.1111.1111.1111.00
#
undo shutdown
ip address 10.3.1.2 255.255.255.0
isis enable 1
mpls

(2020-10-09)
mpls ldp
#
undo shutdown
ip address 10.2.1.2 255.255.255.0
mpls
#
interface LoopBack1
ip address 3.3.3.9 255.255.255.255
isis enable 1
#
bgp 200
#
ipv4-family unicast
peer 4.4.4.9 enable
#
l2vpn-family evpn
peer 4.4.4.9 enable
#
return
#
sysname PE2
#
ipv4-family
#
mpls lsr-id 4.4.4.9
#
mpls
#
mpls ldp
#
isis 1
network-entity 00.1111.1111.2222.00
#
undo shutdown
ip address 10.3.1.1 255.255.255.0
isis enable 1
mpls
mpls ldp
#
undo shutdown
ip address 192.168.2.1 255.255.255.0
#
interface LoopBack1
ip address 4.4.4.9 255.255.255.255
isis enable 1
#
bgp 200
#
ipv4-family unicast

(2020-10-09)
peer 3.3.3.9 enable
#
import-route direct
peer 192.168.2.2 as-number 65420
#
l2vpn-family evpn
peer 3.3.3.9 enable
#
#
return

#
sysname CE1
#
undo shutdown
ip address 192.168.1.2 255.255.255.0
#
interface LoopBack1
ip address 10.10.10.10 255.255.255.255
#
bgp 65410
#
ipv4-family unicast
import-route direct
#
return

#
sysname CE2
#
undo shutdown
ip address 192.168.2.2 255.255.255.0
#
interface LoopBack1
ip address 10.20.20.20 255.255.255.255
#
bgp 65420
#
ipv4-family unicast
import-route direct
#
return
3.2.36.12 Example for Configuring Inter-AS EVPN Option C

This section provides an example for configuring inter-AS EVPN Option C when
multi-hop EBGP EVPN peer relationships are established between PEs in different
ASs.

(2020-10-09)
On the network shown in Figure 3-167, Site1 and Site2 belong to the same VPN.
Site1 accesses an MPLS backbone network over PE1 in AS100, and Site2 accesses
another MPLS backbone network over PE2 in AS200. Inter-AS EVPN Option C is
configured. Specifically, MPLS LDP and inter-AS BGP LSPs are configured to
construct a tunnel between PEs, and an EBGP EVPN peer relationship is
established between the PEs so that the PEs can carry Layer 2 and Layer 3 EVPN
services over the same tunnel.
Figure 3-167 Inter-AS EVPN Option C networking

NOTE
1. Configure IP addresses for all interfaces on the PEs and ASBRs as well as the
loopback interface address.
2. Configure an IGP on the MPLS backbone networks in AS100 and AS200 so
that the PE and ASBR on the same MPLS backbone network can
3. Configure basic MPLS functions and MPLS LDP on the MPLS backbone
networks in AS100 and AS200 to establish MPLS LDP LSPs.
4. Configure an IBGP peer relationship between PE1 and ASBR1 and between
PE2 and ASBR2. Configure an EBGP peer relationship between ASBRs. Enable
these devices to exchange labeled routes.
5. Configure and apply a Route-Policy on each ASBR.
6. Configure a VPN instance and an EVPN instance on each PE.

(2020-10-09)

8. Establish an EBGP EVPN peer relationship between PEs in different ASs.
9. Configure access-side interfaces on PEs.
Data Preparation
● MPLS LSR IDs of the PEs and ASBRs: 1.1.1.1, 2.2.2.2, 3.3.3.3, and 4.4.4.4
● Name (vpn1), RD (100:1), and export and import VPN targets (1:1) of the
VPN instance on each PE
● Name (evrf1), RD (200:1), and export and import VPN targets (2:2) of the
EVPN instance on each PE
● Name of the routing policy configured on ASBR1: policy1; name of the routing
policy configured on ASBR2: policy2
Procedure
Step 1 Configure IP addresses for all interfaces on the PEs and ASBRs as well as the
loopback interface address.
Step 2 Configure an IGP on the MPLS backbone networks in AS100 and AS200 so that
the PE and ASBR on the same MPLS backbone network can communicate with
each other.
NOTE
Configure OSPF to advertise the 32-bit loopback interface addresses used as LSR IDs.
Step 3 Configure basic MPLS functions and MPLS LDP on the MPLS backbone networks in
AS100 and AS200 to establish MPLS LDP LSPs.
Step 4 Configure an IBGP peer relationship between PE1 and ASBR1 and between PE2
and ASBR2. Configure an EBGP peer relationship between ASBRs. Enable these
devices to exchange labeled routes.
Step 5 Configure and apply a Route-Policy on each ASBR.
# Configure ASBR1: Enable MPLS on GE 2/0/0 connecting ASBR1 to ASBR2.
[~ASBR1] interface gigabitethernet 2/0/0
[*ASBR1] commit
# Configure ASBR1: Create a routing policy.

[~ASBR1] route-policy policy1 permit node 1
[*ASBR1-route-policy] apply mpls-label
[*ASBR1] route-policy policy2 permit node 1

(2020-10-09)
[*ASBR1-route-policy] if-match mpls-label

[*ASBR1-route-policy] apply mpls-label
[*ASBR1] commit
# Configure ASBR1: Apply the routing policy to the routes advertised to PE1 and
enable ASBR1 to exchange labeled IPv4 routes with PE1.
[~ASBR1] bgp 100
[*ASBR1-bgp] peer 1.1.1.1 route-policy policy2 export
# Configure ASBR1: Apply the routing policy to the routes advertised to ASBR2
and enable ASBR1 to exchange labeled IPv4 routes with ASBR2.
[*ASBR1-bgp] peer 10.2.1.2 route-policy policy1 export
# Configure ASBR1: Advertise the loopback routes from PE1 to ASBR2 and then to
PE2.
[*ASBR1-bgp] network 1.1.1.9 32
[*ASBR1-bgp] network 10.1.1.0 24
[*ASBR1-bgp] quit
[*ASBR1] commit
Repeat this step for PE2 and ASBR2. For configuration details, see Configuration
Step 6 Configure a VPN instance and an EVPN instance on each PE.
[*PE1-vpn-instance-vpn1-ipv4] route-distinguisher 100:1
[*PE1-vpn-instance-vpn1-ipv4] vpn-target 1:1
[*PE1-vpn-instance-vpn1-ipv4] quit
[*PE1] commit
section.
Step 7 Configure an EVPN source address on each PE.
# Configure PE1.
[*PE1] commit
# Configure PE2.
[*PE2] commit
Step 8 Establish an EBGP EVPN peer relationship between PEs in different ASs.
[~PE1] bgp 100
[*PE1-bgp] peer 4.4.4.4 ebgp-max-hop 255
[*PE1-bgp] commit
section.

(2020-10-09)
Step 9 Configure the access interfaces connecting PEs to CEs.

[*PE1-bgp] quit
[*PE1] interface GigabitEthernet2/0/0.1 mode l2
[*PE1-bd10] quit
[*PE1-Vbdif10] ip address 192.168.1.1 24
[*PE1-Vbdif10] quit
[*PE1] commit
section.
command to view the EVPN routes and IP private network routes sent from the
peer PE.


*> 0:48:00e0-fc12-3456:0:0.0.0.0 0.0.0.0
*> 0:48:00e0-fc12-3456:32:192.168.1.1 0.0.0.0
*> 0:48:00e0-fc12-7890:0:0.0.0.0 4.4.4.4
*> 0:48:00e0-fc12-3456:0:0.0.0.0 0.0.0.0
*> 0:48:00e0-fc12-3456:32:192.168.1.1 0.0.0.0
*> 0:48:00e0-fc12-7890:0:0.0.0.0 4.4.4.4

*> 0:32:1.1.1.1 127.0.0.1
*> 0:32:4.4.4.4 4.4.4.4
*> 0:32:1.1.1.1 127.0.0.1

(2020-10-09)
*> 0:32:4.4.4.4 4.4.4.4

*> 0:192.168.1.0:24 0.0.0.0
*> 0:192.168.2.0:24 4.4.4.4

------------------------------------------------------------------------------

192.168.1.0/24 Direct 0 0 D 192.168.1.1 Vbdif10
192.168.1.1/32 Direct 0 0 D 127.0.0.1 Vbdif10
192.168.1.255/32 Direct 0 0 D 127.0.0.1 Vbdif10
[~PE1] ping -vpn-instance vpn1 192.168.2.1


0.00% packet loss
----End
Configuration Files
#
sysname PE1
#
#
ipv4-family
#
mpls lsr-id 1.1.1.1
#
bridge-domain 10
#
mpls ldp
#
interface Vbdif10
ip address 192.168.1.1 255.255.255.0

(2020-10-09)

#
undo shutdown
ip address 10.1.1.2 255.255.255.0
mpls
mpls ldp
#
rewrite pop single
bridge-domain 10
#
interface LoopBack1
ip address 1.1.1.1 255.255.255.255
#
bgp 100
#
ipv4-family unicast
peer 2.2.2.2 enable
peer 4.4.4.4 enable
#
import-route direct
#
l2vpn-family evpn
peer 4.4.4.4 enable
#
ospf 1
area 0.0.0.0
network 1.1.1.1 0.0.0.0
network 10.1.1.0 0.0.0.255
#
#
return
#
sysname ASBR1
#
mpls lsr-id 2.2.2.2
#
mpls
#
mpls ldp
#
undo shutdown
ip address 10.1.1.1 255.255.255.0
mpls
mpls ldp
#
undo shutdown
ip address 10.2.1.1 255.255.255.0
mpls
#
interface LoopBack1
ip address 2.2.2.2 255.255.255.255
#

(2020-10-09)
bgp 100
#
ipv4-family unicast
network 1.1.1.1 255.255.255.255
network 10.1.1.0 255.255.255.0
peer 1.1.1.1 enable
peer 1.1.1.1 route-policy policy2 export
#
ospf 1
area 0.0.0.0
network 2.2.2.2 0.0.0.0
network 10.1.1.0 0.0.0.255
#
route-policy policy1 permit node 1
apply mpls-label
#
if-match mpls-label
apply mpls-label
#
return
#
sysname ASBR2
#
mpls lsr-id 3.3.3.3
#
mpls
#
mpls ldp
#
undo shutdown
ip address 10.3.1.1 255.255.255.0
mpls
mpls ldp
#
undo shutdown
ip address 10.2.1.2 255.255.255.0
mpls
#
interface LoopBack1
ip address 3.3.3.3 255.255.255.255
#
bgp 200
#
ipv4-family unicast
network 4.4.4.4 255.255.255.255
network 10.3.1.0 255.255.255.0
peer 4.4.4.4 enable
#

(2020-10-09)
ospf 2
area 0.0.0.0
network 3.3.3.3 0.0.0.0
network 10.3.1.0 0.0.0.255
#
apply mpls-label
#
if-match mpls-label
apply mpls-label
#
return
#
sysname PE2
#
#
ipv4-family
#
mpls lsr-id 4.4.4.4
#
mpls
#
bridge-domain 10
#
mpls ldp
#
interface Vbdif10
ip address 192.168.2.1 255.255.255.0
#
undo shutdown
ip address 10.3.1.2 255.255.255.0
mpls
mpls ldp
#
rewrite pop single
bridge-domain 10
#
interface LoopBack1
ip address 4.4.4.4 255.255.255.255
#
bgp 200
#
ipv4-family unicast
peer 1.1.1.1 enable
peer 3.3.3.3 enable

(2020-10-09)

#
import-route direct
#
l2vpn-family evpn
peer 1.1.1.1 enable
#
ospf 2
area 0.0.0.0
network 4.4.4.4 0.0.0.0
network 10.3.1.0 0.0.0.255
#
#
return
3.2.36.13 Example for Splicing a VXLAN EVPN with a VPLS

To implement interconnection between a DC and an enterprise network, splicing
VXLAN EVPN with VPLS must be configured.
On the network shown in Figure 3-168, PE3 and the TOR are each dual-homed to
PE1 and PE2. An MPLS L2VPN is deployed between the PEs, with PW connections
configured. An EVPN VXLAN is deployed in the DC, and PE1 and PE2 are the DC's
egress devices.
Figure 3-168 Splicing a VXLAN EVPN with a VPLS

NOTE

(2020-10-09)
Table 3-15 Mapping between interfaces and IP addresses
Device Interface Name IP Address and Mask
PE1 GigabitEthernet 1/0/1 10.1.1.1/24
Loopback 0 1.1.1.1/32
Loopback 100 1.1.1.100/32
PE2 GigabitEthernet 1/0/1 10.2.1.2/24
Loopback 0 2.2.2.2/32
Loopback 100 2.2.2.100/32
PE3 GigabitEthernet 1/0/0 -
Loopback 0 3.3.3.3/32
TOR GigabitEthernet 1/0/0 -
Loopback 100 4.4.4.100/32
1. Configure an IGP on each device to ensure Layer 3 connectivity.

2. Configure basic MPLS functions and MPLS LDP on PE1, PE2, and PE3.
Establish LDP LSPs between PE3 and PE1 and between PE3 and PE2.
3. Configure an EVPN instance on each of PE1, PE2, and the TOR.
4. Configure MPLS VPLS between PE3 and PE1 and between PE3 and PE2 for
interconnection.
5. Configure VXLAN between the TOR and PE1 and between the TOR and PE2
for interconnection.
6. Create an EVPN instance and a VSI and bind them to the same BD on each of
PE1 and PE2 to implement splicing VXLAN and VPLS.
Data Preparation

(2020-10-09)
● Interfaces and their IP addresses

● MPLS LSR IDs of PEs
● Names, RDs, and VPN targets of the EVPN instances of PE1, PE2, and the TOR
● Names and IDs of the VSIs on the PEs
● IP addresses of peers and tunnel policies used for setting up peer relationships
Procedure
Step 1 Configure IP addresses for interfaces on the PEs and TOR and configure an IGP.
Step 2 Configure basic MPLS functions and MPLS LDP on PE1, PE2, and PE3. Establish
LDP LSPs between PE3 and PE1 and between PE3 and PE2.
Step 3 Configure EVPN instances on PE1 and PE2.
# Configure PE1.
[~PE1] evpn vpn-instance tor bd-mode
[*PE1-evpn-instance-tor] route-distinguisher 1.1.1.100:10
[*PE1-evpn-instance-tor] vpn-target 10:10 export-extcommunity
[*PE1-evpn-instance-tor] vpn-target 10:10 import-extcommunity
[*PE1-evpn-instance-tor] quit
[*PE1] commit
Repeat this step for the TOR and PE2. For configuration details, see Configuration
Step 4 Configure a BGP-EVPN peer relationship between the TOR and each of PE1 and
PE2.
# Configure PE1.
[~PE1] bgp 100
[*PE1-bgp] peer 4.4.4.100 ebgp-max-hop 255
[*PE1-bgp-af-evpn] policy vpn-target
[*PE1-bgp-af-evpn] peer 4.4.4.100 advertise encap-type vxlan
[*PE1-bgp] quit
[*PE1] commit
Repeat this step for the TOR and PE2. For configuration details, see Configuration
Step 5 Configure a VSI on each of PE1, PE2, and PE3.
# Configure PE1.
[~PE1] vsi cpe bd-mode
[*PE1-vsi-cpe] pwsignal ldp
[*PE1-vsi-cpe-ldp] vsi-id 10
[*PE1-vsi-cpe-ldp] peer 3.3.3.3
[*PE1-vsi-cpe-ldp] quit
[*PE1-vsi-cpe] quit
[*PE1] commit

(2020-10-09)
# Configure PE2.
[*PE2-vsi-cpe] quit
[*PE2] commit
# Configure PE3.
[*PE3-vsi-cpe] pw-redundancy mac-withdraw rfc-compatible
[*PE3-vsi-cpe-ldp] protect-group 10
[*PE3-vsi-cpe-ldp-protect-group-10] protect-mode pw-redundancy master
[*PE3-vsi-cpe-ldp-protect-group-10] reroute delay 60
[*PE3-vsi-cpe-ldp-protect-group-10] peer 1.1.1.1 preference 1
[*PE3-vsi-cpe-ldp-protect-group-10] peer 2.2.2.2 preference 2
[*PE3-vsi-cpe-ldp-protect-group-10] quit
[*PE3-vsi-cpe] quit
[*PE3] commit
Step 6 Bind the VSI and EVPN instance to the same BD on each of PE1 and PE2.
# Configure PE1.
[~PE1] bridge-domain 10
[*PE1-bd10] vxlan vni 10 split-horizon-mode
[*PE1-bd10] evpn binding vpn-instance tor
[*PE1-bd10] l2 binding vsi cpe
[*PE1-bd10] quit
[*PE1] commit
section.
Run the display vsi name cpe verbose command on each PE to view the PW and
VSI status. The following example uses the command output on PE1.
[~PE1] display vsi name cpe verbose
***VSI Name : cpe
Work Mode : bd-mode
VSI Index :1
PW Signaling : ldp
Bridge-domain Mode : enable
PW MAC Learn Style : qualify
MTU : 1500
Service Class : --
Color : --
DomainId : 255
Domain Name :
P2P VSI : disable
VSI State : up

(2020-10-09)
VSI ID : 10
Negotiation-vc-id : 10
VC Label : 48123
Peer Type : dynamic
Session : up
Tunnel ID : 0x0000000001004c4b44
CKey :1
NKey : 16777348
Stp Enable :0
PwIndex :1
Access Bridge-domain : Bridge-domain 10

Vac State : down
Last Up Time : 0000/00/00 00:00:00
**PW Information:

PW State : up
Local VC Label : 48123
PW Type : label
Tunnel ID : 0x0000000001004c4b44
Ckey :1
Nkey : 16777348
Main PW Token : 0x0
Tnl Type : ldp
OutInterface : --
Stp Enable :0
Mac Flapping :0
PW Last Up Time : 2018/08/29 08:11:47
Run the display vxlan tunnel command on each PE. The command output shows
that the VXLAN tunnel is Up. The following example uses the command output on
PE1.
[~PE1] display vxlan tunnel
-----------------------------------------------------------------------------------
4026531841 1.1.1.100 4.4.4.100 up dynamic 00:18:05
----End
Configuration Files
#
sysname PE1

(2020-10-09)
#
evpn vpn-instance tor bd-mode
route-distinguisher 2.2.2.100:10
#
mpls lsr-id 1.1.1.1
#
mpls
#
mpls l2vpn
#
vsi cpe bd-mode
pwsignal ldp
vsi-id 10
peer 3.3.3.3
#
bridge-domain 10
evpn binding vpn-instance tor
esi 0000.1111.1111.1111.2222
l2 binding vsi cpe
#
mpls ldp
#
undo shutdown
ip address 10.1.1.1 255.255.255.0
mpls
mpls ldp
#
undo shutdown
ip address 192.168.14.1 255.255.255.0
#
interface LoopBack0
ip address 1.1.1.1 255.255.255.255
#
interface LoopBack100
ip address 1.1.1.100 255.255.255.255
#
interface Nve1
source 1.1.1.100
#
bgp 100
#
ipv4-family unicast
#
l2vpn-family evpn
policy vpn-target
#
ospf 1
area 0.0.0.0
network 1.1.1.1 0.0.0.0
network 10.1.1.0 0.0.0.255
#
ospf 100
area 0.0.0.1
network 1.1.1.100 0.0.0.0
network 192.168.14.0 0.0.0.255
#

(2020-10-09)

#
return
#
sysname PE2
#
#
mpls lsr-id 2.2.2.2
#
mpls
#
mpls l2vpn
#
vsi cpe bd-mode
pwsignal ldp
vsi-id 10
peer 3.3.3.3
#
bridge-domain 10
esi 0000.1111.1111.1111.3333
l2 binding vsi cpe
#
mpls ldp
#
undo shutdown
ip address 10.2.1.2 255.255.255.0
mpls
mpls ldp
#
undo shutdown
ip address 192.168.24.1 255.255.255.0
#
interface LoopBack0
ip address 2.2.2.2 255.255.255.255
#
ip address 2.2.2.100 255.255.255.255
#
interface Nve1
source 2.2.2.100
#
bgp 100
#
ipv4-family unicast
#
l2vpn-family evpn
policy vpn-target
#
ospf 1
area 0.0.0.0
network 2.2.2.2 0.0.0.0
network 10.2.1.0 0.0.0.255

(2020-10-09)
#
ospf 100
area 0.0.0.1
network 2.2.2.100 0.0.0.0
network 192.168.24.0 0.0.0.255
#
#
return
#
sysname PE3
#
mpls lsr-id 3.3.3.3
#
mpls
#
mpls l2vpn
#
vsi cpe bd-mode
pw-redundancy mac-withdraw rfc-compatible
pwsignal ldp
vsi-id 10
peer 1.1.1.1
peer 2.2.2.2
protect-group 10
protect-mode pw-redundancy master
reroute delay 60
peer 1.1.1.1 preference 1
#
bridge-domain 10
l2 binding vsi cpe
#
mpls ldp
#
undo shutdown
#
bridge-domain 10
#
undo shutdown
ip address 10.1.1.3 255.255.255.0
mpls
mpls ldp
#
undo shutdown
ip address 10.2.1.3 255.255.255.0
mpls
mpls ldp
#
interface LoopBack0
ip address 3.3.3.3 255.255.255.255
#
ospf 1
area 0.0.0.0
network 3.3.3.3 0.0.0.0
network 10.1.1.0 0.0.0.255
network 10.2.1.0 0.0.0.255
#
return
● TOR configuration file
#
sysname TOR
#

(2020-10-09)

#
bridge-domain 10
esi 0000.1111.1111.1111.1111
#
undo shutdown
#
#
undo shutdown
ip address 192.168.14.4 255.255.255.0
#
undo shutdown
ip address 192.168.24.4 255.255.255.0
#
interface LoopBack0
ip address 4.4.4.4 255.255.255.255
#
ip address 4.4.4.100 255.255.255.255
#
interface Nve1
source 4.4.4.100
#
interface NULL0
#
bgp 65001
#
ipv4-family unicast
#
l2vpn-family evpn
policy vpn-target
#
ospf 100
area 0.0.0.1
network 4.4.4.100 0.0.0.0
network 192.168.14.0 0.0.0.255
network 192.168.24.0 0.0.0.255
#
#
return

(2020-10-09)
3.2.36.14 Example for Configuring EVPN E-LAN over mLDP P2MP Tunnels
On a network where an EVPN carries multicast services, to reduce redundant
traffic and conserve bandwidth resources, configure an EVPN E-LAN over mLDP
P2MP tunnel for service transmission.
On the network shown in Figure 3-169, EVPN is configured on the PEs and used
to carry multicast services. PE1 is the root node, and PE2 and PE3 are leaf nodes.
The access side is the multicast source and the receiver. By default, an EVPN sends
multicast service traffic from PE1 to PE2 and PE3 by means of ingress replication.
Specifically, PE1 replicates a multicast packet into two copies and sends them to
the P functioning as an RR. The P then sends one copy to PE2 and the other copy
to PE3. For each additional receiver, an additional copy of the multicast packet is
sent. This increases the volume of traffic on the link between PE1 and the P,
consuming bandwidth resources. To conserve bandwidth resources, you can
configure EVPN to use an mLDP P2MP tunnel to transmit multicast services. After
the configuration is complete, PE1 sends only one copy of multicast traffic to the
P. The P replicates the multicast traffic into copies and sends them to the leaf
nodes, reducing the volume of traffic between PE1 and P.
Figure 3-169 Configuring EVPN E-LAN over mLDP P2MP tunnels

NOTE

(2020-10-09)
Precautions
When you configure EVPN to use an mLDP P2MP tunnel for service transmission,
note the following:
import VPN target list of a site shares VPN targets with the export VPN target
lists of the other sites.
recommended.
communicate.
2. Configure MPLS and mLDP P2MP both globally and per interface on each
node of the backbone network.
3. Create an EVPN instance in BD mode and a BD on each PE, and bind the BD
to the EVPN instance on each PE.
5. Configure each PE's sub-interface connecting to a CE.
7. Configure BGP EVPN peer relationships between the PEs and RR, and
8. Configure EVPN to use an mLDP P2MP tunnel for service transmission on
each PE.
Data Preparation
Procedure
# Configure PE1.
[~PE1] ospf 1
[~PE1-ospf-1] quit

(2020-10-09)
# Configure PE2.
[~PE2] ospf 1
[~PE2-ospf-1] quit
# Configure PE3.
[~PE3] ospf 1
[~PE3-ospf-1] quit
# Configure the RR.

[~RR] ospf 1
[*RR-ospf-1] area 0
[~RR-ospf-1] quit
Step 3 Configure MPLS and mLDP P2MP both globally and per interface on each node of
the backbone network and set up an mLDP P2MP tunnel.
# Configure PE1.
[*PE1] mpls
[*PE1-mpls] quit
[*PE1] mpls ldp
[*PE1-mpls-ldp] mldp p2mp
# Configure PE2.
[*PE2] mpls
[*PE2-mpls] quit
[*PE2] mpls ldp
# Configure the RR.

[*RR] mpls
[*RR-mpls] quit
[*RR] mpls ldp

(2020-10-09)
[*RR-mpls-ldp] mldp p2mp

[*RR-mpls-ldp] quit
# Configure PE3.
[*PE3] mpls
[*PE3-mpls] quit
[*PE3] mpls ldp

# Configure PE1.
[*PE1-bd10] quit
[*PE1] commit
# Configure PE2.
[*PE2-bd10] quit
[*PE2] commit
# Configure PE3.
[*PE3-bd10] quit
[*PE3] commit

# Configure PE1.

(2020-10-09)
[*PE1] commit
# Configure PE2.
[*PE2] commit
# Configure PE3.
[*PE3] commit
Step 6 Configure an Eth-Trunk sub-interface on each PE connecting to a CE.

# Configure PE1.
[*PE1] commit
# Configure PE2.
[*PE2] commit
# Configure PE3.
[*PE3] commit

# Configure PE1.
[*PE1-Eth-Trunk10] esi 0000.1111.1111.4444.5555
[*PE1] commit
# Configure PE2.
[*PE2-Eth-Trunk10] esi 0000.1111.2222.4444.5555
[*PE2] commit
# Configure PE3.

(2020-10-09)

[*PE3-Eth-Trunk10] esi 0000.1111.3333.4444.5555
[*PE3] commit
Step 8 Configure BGP EVPN peer relationships between the PEs and RR, and configure
# Configure PE1.
[~PE1] bgp 100
[*PE1-bgp] quit
[*PE1] commit
# Configure PE2.
[~PE2] bgp 100
[*PE2-bgp] quit
[*PE2] commit
# Configure PE3.
[~PE3] bgp 100
[*PE3-bgp] quit
[*PE3] commit
# Configure the RR.

[~RR] bgp 100
[*RR-bgp] quit
[*RR] commit
After the configurations are complete, run the display bgp evpn peer command
on the RR. The command output shows information about BGP peer relationships.
In the following example, the output shows that BGP peer relationships are
established between the PEs and RR and that they are in the Established state.

(2020-10-09)


1.1.1.1 4 100 231 253 0 03:07:26 Established 6
2.2.2.2 4 100 231 256 0 03:07:44 Established 6
4.4.4.4 4 100 232 254 0 03:07:54 Established 6
Step 9 Configure EVPN to use an mLDP P2MP tunnel for service transmission on each PE.
# Configure PE1.
[~PE1-evpn-instance-evrf1] inclusive-provider-tunnel
[*PE1-evpn-instance-evrf1-inclusive] root
[*PE1-evpn-instance-evrf1-inclusive-root] mldp p2mp
[*PE1-evpn-instance-evrf1-inclusive-root-mldpp2mp] root-ip 1.1.1.1
[*PE1-evpn-instance-evrf1-inclusive-root-mldpp2mp] quit
[*PE1-evpn-instance-evrf1-inclusive-root] quit
[*PE1-evpn-instance-evrf1-inclusive] quit
[*PE1] commit
# Configure PE2.
[*PE2-evpn-instance-evrf1-inclusive] leaf
[*PE2-evpn-instance-evrf1-inclusive-leaf] quit
[*PE2] commit
# Configure PE3.
[*PE3] commit
Run the display evpn vpn-instance name evrf1 inclusive-provider-tunnel

verbose command on PE1. The command output shows information related to the
root node.
[~PE1] display evpn vpn-instance name evrf1 inclusive-provider-tunnel verbose
VPN-Instance Name and ID : evrf1, 3
Address family bd-evpn
Route Distinguisher : 100:1
Label Policy : label per bridge-domain
Export VPN Targets : 1:1
Import VPN Targets : 1:1
Bridge-domain : 10
Ingress provider tunnel
PMSI type : P2MP mLDP
Root ip : 1.1.1.1
Opaque value : 01000400008001
State : up
Egress provider tunnel
Egress PMSI count: 0

verbose command on PE2 or PE3. The command output shows information
related to the leaf node. The following example uses the command output on PE2:

(2020-10-09)

Bridge-domain : 10
*PMSI type : P2MP mLDP
Root ip : 1.1.1.1
Opaque value : 01000400008001
State : up
----End
Configuration Files
#
sysname PE1
#
root
mldp p2mp
root-ip 1.1.1.1
#
mpls lsr-id 1.1.1.1
#
mpls
#
bridge-domain 10
#
mpls ldp
mldp p2mp
#
esi 0000.1111.1111.4444.5555
#
rewrite pop single
bridge-domain 10
#
undo shutdown
eth-trunk 10
#
undo shutdown
ip address 10.1.1.1 255.255.255.0
mpls
mpls ldp
#
interface LoopBack0
ip address 1.1.1.1 255.255.255.255
#
bgp 100
#
ipv4-family unicast

(2020-10-09)
peer 3.3.3.3 enable
#
l2vpn-family evpn
peer 3.3.3.3 enable
#
ospf 1
area 0.0.0.0
network 1.1.1.1 0.0.0.0
network 10.1.1.0 0.0.0.255
#
#
return
#
sysname PE2
#
leaf
#
mpls lsr-id 2.2.2.2
#
mpls
#
bridge-domain 10
#
mpls ldp
mldp p2mp
#
esi 0000.1111.2222.4444.5555
#
rewrite pop single
bridge-domain 10
#
undo shutdown
eth-trunk 10
#
undo shutdown
ip address 10.2.1.1 255.255.255.0
mpls
mpls ldp
#
interface LoopBack0
ip address 2.2.2.2 255.255.255.255
#
bgp 100
#
ipv4-family unicast
peer 3.3.3.3 enable
#
l2vpn-family evpn
peer 3.3.3.3 enable
#

(2020-10-09)
ospf 1
area 0.0.0.0
network 2.2.2.2 0.0.0.0
network 10.2.1.0 0.0.0.255
#
#
return

#
sysname PE3
#
leaf
#
mpls lsr-id 4.4.4.4
#
mpls
#
bridge-domain 10
#
mpls ldp
mldp p2mp
#
esi 0000.1111.3333.4444.5555
#
rewrite pop single
bridge-domain 10
#
undo shutdown
eth-trunk 10
#
undo shutdown
ip address 10.3.1.2 255.255.255.0
mpls
mpls ldp
#
interface LoopBack0
ip address 4.4.4.4 255.255.255.255
#
bgp 100
#
ipv4-family unicast
peer 3.3.3.3 enable
#
l2vpn-family evpn
peer 3.3.3.3 enable
#
ospf 1
area 0.0.0.0
network 4.4.4.4 0.0.0.0
network 10.3.1.0 0.0.0.255
#

(2020-10-09)
#
return
#
sysname RR
#
mpls lsr-id 3.3.3.3
#
mpls
#
mpls ldp
mldp p2mp
#
undo shutdown
ip address 10.1.1.2 255.255.255.0
mpls
mpls ldp
#
undo shutdown
ip address 10.2.1.2 255.255.255.0
mpls
mpls ldp
#
undo shutdown
ip address 10.3.1.1 255.255.255.0
mpls
mpls ldp
#
interface LoopBack0
ip address 3.3.3.3 255.255.255.255
#
bgp 100
#
ipv4-family unicast
peer 1.1.1.1 enable
peer 2.2.2.2 enable
peer 4.4.4.4 enable
#
l2vpn-family evpn
peer 1.1.1.1 enable
peer 2.2.2.2 enable
peer 4.4.4.4 enable
#
ospf 1
area 0.0.0.0
network 3.3.3.3 0.0.0.0
network 10.1.1.0 0.0.0.255
network 10.2.1.0 0.0.0.255
network 10.3.1.0 0.0.0.255
#
return
#
sysname CE1

(2020-10-09)
#
bridge-domain 10
#
#
bridge-domain 10
#
undo shutdown
eth-trunk 10
#
return
#
sysname CE2
#
bridge-domain 10
#
#
bridge-domain 10
#
undo shutdown
eth-trunk 10
#
return
#
sysname CE3
#
bridge-domain 10
#
#
bridge-domain 10
#
undo shutdown
eth-trunk 10
#
return
3.2.36.15 Example for Splicing a VLL with a Common EVPN E-LAN

Traditional VLL is still used at the aggregation layer of a network, whereas the
layers, VLL accessing EVPN must be configured. This section provides an example
for configuring this function.
On the network shown in the following figure, a VLL (or VPWS) network is
deployed between the UPE and NPE1, and an EVPN is deployed between NPE1
and NPE2. To implement VLL accessing EVPN, a PW-VE interface and its sub-
interface must be configured on NPE1. Specifically, the VLL configurations are
performed on the PW-VE interface, and the EVPN configurations are performed on

(2020-10-09)
the PW-VE sub-interface. The PW-VE sub-interface is configured as a QinQ VLAN

tag termination sub-interface.
Figure 3-170 Splicing a VLL with a common EVPN E-LAN

NOTE
Interfaces 0 through 2 in this example represent GigabitEthernet 1/0/0, GigabitEthernet 1/0/1 ,

and GigabitEthernet 1/0/2, respectively.
Device Name Interface Name IP Address and Mask
NPE1 GigabitEthernet 1/0/1 10.1.1.1/24
Loopback 0 1.1.1.1/32
Loopback 100 1.1.1.100/32
UPE GigabitEthernet 1/0/0 -
Loopback 0 2.2.2.2/32
NPE2 GigabitEthernet 1/0/0 -
Loopback 100 2.2.2.100/32
1. Configure an IGP on each device. Because the VLL network (between the UPE
and NPE1) and EVPN (between NPE1 and NPE2) reside at different layers, use
different IGP processes to implement route communication.
2. Configure basic MPLS functions on the UPE, NPE1, and NPE2.

(2020-10-09)
3. Configure VPWS connections on the UPE and NPE1.

4. Configure EVPN functions on NPE1 and NPE2 and establish an MPLS tunnel
between them.
5. On NPE1, bind the VSI to the PW-VE interface and the EVPN instance to PE-
VE sub-interface.
Data Preparation
● Interface names and IP addresses of the interfaces on NPE1, NPE2, and the
UPE
● MPLS LSR IDs on the UPE, NPE1, and NPE2
● Names, RDs, and VPN targets of the EVPN instances created on NPE1 and
NPE2
Procedure
Step 1 Configure IP addresses for interfaces on the UPE, NPE1, and NPE2 and configure
an IGP. OSPF is used in this example.
For configuration details, see "Configuration Files" in this section.
Step 2 Configure basic MPLS functions and MPLS LDP on the UPE and NPE1.
For detailed configurations, see "Configuration Files" in this section.
Step 3 Configure VPWS connections on the UPE and NPE1.
Step 4 Configure basic EVPN functions on NPE2.
Step 5 Configure BGP on NPE1 and NPE2 and establish an EVPN peer relationship
between them.
Step 6 Configure an EVPN instance on NPE1.
# Configure NPE1.
[~NPE1] evpn vpn-instance evpna
[*NPE1-evpn-instance-evpna] route-distinguisher 1.1.1.100:10
[*NPE1-evpn-instance-evpna] vpn-target 10:10 export-extcommunity
[*NPE1-evpn-instance-evpna] vpn-target 10:10 import-extcommunity
[*NPE1-evpn-instance-evpna] quit
[*NPE1] evpn source-address 1.1.1.100
[*NPE1] commit
Step 7 Configure a PW on the UPE that connects to NPE1.

[~UPE-GigabitEthernet1/0/0] mpls l2vc 1.1.1.1 1
[*UPE] commit
Step 8 On NPE1, bind the VSI to the PW-VE interface and the EVPN instance to the PW-
VE sub-interface.

(2020-10-09)
# Configure NPE1.
[~NPE1] mpls
[*NPE1-mpls] mpls l2vpn
[*NPE1-mpls] quit
[*NPE1] interface PW-VE 1
[*NPE1-PW-VE1] mpls l2vc 2.2.2.2 1
[*NPE1-PW-VE1] quit
[*NPE1] interface PW-VE 1.1
[*NPE1-PW-VE1.1] encapsulation qinq-termination
[*NPE1-PW-VE1.1] qinq termination pe-vid 100 ce-vid 1 to 2
[*NPE1-PW-VE1.1] evpn binding vpn-instance evpna
[*NPE1-PW-VE1.1] commit

Run display mpls l2vc, the PW-VE1 interface and LDP VC were UP.
[~NPE1] display mpls l2vc
Total LDP VC : 1 1 up 0 down
*client interface : PW-VE1 is up

Administrator PW : no
session state : up
AC status : up
Ignore AC state : disable
VC state : up
Label state :0
Token state :0
VC ID :2
VC type : Ethernet
destination : 2.2.2.2
local VC label : 33053 remote VC label :0
control word : disable
remote control word : none
forwarding entry : not exist
local group ID :0
remote group ID :0
local AC OAM State : up
local PSN OAM State : up
local forwarding state : forwarding
local status code : 0x0
VCCV State : up
manual fault : not set
active state : inactive
OAM Protocol : --
OAM Status : --
OAM Fault Type : --
PW APS ID : --
PW APS Status : --
TTL Value :1
link state : down
local VC MTU : 1500 remote VC MTU :0
local VCCV : alert ttl lsp-ping bfd
remote VCCV : none
tunnel policy name : --
PW template name : --
load balance type : flow
Access-port : false
Switchover Flag : false
VC tunnel info : 1 tunnels
NO.0 TNL type : ldp , TNL ID : 0x0000000001004c4bc1
create time : 0 days, 0 hours, 17 minutes, 58 seconds
up time : 0 days, 0 hours, 16 minutes, 50 seconds
last change time : 0 days, 0 hours, 16 minutes, 50 seconds
VC last up time : 2018/02/05 02:50:41
VC total up time : 0 days, 0 hours, 16 minutes, 50 seconds
CKey : 577

(2020-10-09)
NKey : 16777487
PW redundancy mode : frr
AdminPw interface : --
AdminPw link state : --
Forward state : send inactive, receive inactive
Service Class : --
Color : --
DomainId : --
Domain Name : --
----End
Configuration Files
● NPE1 configuration file
#
sysname NPE1
#
evpn vpn-instance evpna
#
mpls lsr-id 1.1.1.1
#
mpls
#
mpls l2vpn
#
mpls ldp
#
undo shutdown
ip address 10.1.1.1 255.255.255.0
mpls
mpls ldp
#
undo shutdown
ip address 192.168.14.1 255.255.255.0
mpls
mpls ldp
#
interface LoopBack0
ip address 1.1.1.1 255.255.255.255
#
ip address 1.1.1.100 255.255.255.255
#
interface PW-VE1
mpls l2vc 2.2.2.2 1
#
interface PW-VE1.1
encapsulation qinq-termination
qinq termination pe-vid 100 ce-vid 1 to 2
#
bgp 100
#
ipv4-family unicast
#
l2vpn-family evpn

(2020-10-09)

#
ospf 1
area 0.0.0.0
network 1.1.1.1 0.0.0.0
network 10.1.1.0 0.0.0.255
#
ospf 100
area 0.0.0.1
network 1.1.1.100 0.0.0.0
network 192.168.14.0 0.0.0.255
#
#
return
#
sysname UPE
#
mpls lsr-id 2.2.2.2
#
mpls
#
mpls l2vpn
#
mpls ldp
#
undo shutdown
mpls l2vc 1.1.1.1 1
#
undo shutdown
ip address 10.1.1.3 255.255.255.0
mpls
mpls ldp
#
interface LoopBack0
ip address 2.2.2.2 255.255.255.255
#
ospf 1
area 0.0.0.0
network 2.2.2.2 0.0.0.0
network 10.1.1.0 0.0.0.255
#
return
#
sysname NPE2
#
evpn vpn-instance evpna
#
#
mpls
#
mpls l2vpn
#
mpls ldp
#
undo shutdown
#

(2020-10-09)
undo portswitch
ip address 192.168.14.4 255.255.255.0
mpls
mpls ldp
#
ip address 2.2.2.100 255.255.255.255
#
bgp 65001
#
ipv4-family unicast
#
l2vpn-family evpn
#
ospf 100
area 0.0.0.1
network 2.2.2.100 0.0.0.0
network 192.168.14.0 0.0.0.255
#
#
return
3.2.36.16 Example for Splicing a VLL with an MPLS EVPN E-Line

The traditional VLL is still used at the aggregation layer of a network, whereas the
core network has evolved into EVPN. To allow services at different layers to run
properly on the entire network, a VLL must be spliced with an MPLS EVPN E-Line.
On the network shown in Figure 3-171, a VLL (or VPWS) network is deployed
between the UPE and NPE1, and an EVPN is deployed between NPE1 and NPE2.
To implement VLL accessing EVPN, a PW-VE interface and its sub-interface must
be configured on NPE1. Specifically, the VLL configurations are performed on the
PW-VE interface, and the EVPN configurations are performed on the PW-VE sub-
interface. An EVPL instance corresponding to an EVPN instance is bound to the
PW-VE sub-interface, which is configured as a QinQ VLAN tag termination sub-
interface.
Figure 3-171 Splicing a VLL with an MPLS EVPN E-Line

NOTE

(2020-10-09)
Device Name Interface Name IP Address and Mask
Loopback 0 1.1.1.1/32
Loopback 100 1.1.1.100/32
UPE GigabitEthernet 1/0/0 -
Loopback 0 2.2.2.2/32
NPE2 GigabitEthernet 1/0/0 -
Loopback 100 2.2.2.100/32
1. Configure an IGP on each device. Because the VLL network (between the UPE
and NPE1) and EVPN (between NPE1 and NPE2) reside at different layers, use
2. Configure basic MPLS LDP functions on the UPE, NPE1, and NPE2.
3. Configure VPWS connections on the UPE and NPE1.
4. Configure EVPN functions on NPE1 and NPE2, including creating EVPN
instances and establishing a BGP EVPN peer relationship between the devices.
5. Configure EVPL functions on NPE1 and NPE2.
6. Bind the VSI to the PW-VE interface on NPE1; bind the EVPL instances to the
PE-VE sub-interfaces of NPE1.

(2020-10-09)
Data Preparation
● Interface names and IP addresses of the interfaces on NPE1, NPE2, and the
UPE
● MPLS LSR IDs on the UPE, NPE1, and NPE2
● Names, RDs, and VPN targets of the EVPN instances created on NPE1 and
NPE2
Procedure
Step 1 Configure IP addresses for interfaces on the UPE, NPE1, and NPE2 and configure
an IGP. OSPF is used in this example.
Step 2 Configure basic MPLS functions and MPLS LDP on NPE1, NPE2, and the UPE.
Step 3 Configure VPWS connections on the UPE and NPE1.
Step 4 Configure an EVPN instance on NPE1.
# Configure NPE1.
[~NPE1] evpn vpn-instance evpna vpws
[*NPE1-vpws-evpn-instance-evpna] route-distinguisher 1:1
[*NPE1-vpws-evpn-instance-evpna] vpn-target 10:10 export-extcommunity
[*NPE1-vpws-evpn-instance-evpna] vpn-target 10:10 import-extcommunity
[*NPE1-vpws-evpn-instance-evpna] quit
[*NPE1] bgp 100
[*NPE1-bgp] peer 2.2.2.100 as-number 100
[*NPE1-bgp] peer 2.2.2.100 connect-interface LoopBack100
[*NPE1-bgp] l2vpn-family evpn
[*NPE1-bgp-af-evpn] peer 2.2.2.100 enable
[*NPE1-bgp-af-evpn] quit
[*NPE1-bgp] quit
[*NPE1] commit
The configuration on NPE2 is similar to that on NPE1 and is not provided here. For
configuration details, see "Configuration Files" in this section.
Step 5 Configure EVPL functions on NPE1 and NPE2.
# Configure NPE1.
[~NPE1] evpl instance 1 mpls-mode
[*NPE1-evpl-mpls1] evpn binding vpn-instance evpna
[*NPE1-evpl-mpls1] local-service-id 100 remote-service-id 200
[*NPE1-evpl-mpls1] quit
[*NPE1] commit
The configuration on NPE2 is similar to that on NPE1 and is not provided here. For
configuration details, see "Configuration Files" in this section.
Step 6 On NPE1, bind the VSI to the PW-VE interface and the EVPN instance to the PW-
VE sub-interface.
# Configure NPE1.

(2020-10-09)
[~NPE1] mpls
[*NPE1-mpls] mpls l2vpn
[*NPE1-l2vpn] quit
[*NPE1] interface PW-VE 1
[*NPE1-PW-VE1] esi 0011.1111.0000.0000.0000
[*NPE1-PW-VE1] mpls l2vc 2.2.2.2 1
[*NPE1-PW-VE1] quit
[*NPE1] interface PW-VE 1.1
[*NPE1-PW-VE1.1] encapsulation qinq-termination
[*NPE1-PW-VE1.1] qinq termination pe-vid 100 ce-vid 100
[*NPE1-PW-VE1.1] evpl instance 1
[*NPE1-PW-VE1.1] commit

Run the display bgp evpn all routing-table command on NPE2. The command
output shows the EVI AD routes received from NPE1.
[~NPE2] display bgp evpn all routing-table


*>i 0011.1111.0000.0000.0000:100 1.1.1.100
*>i 0011.1111.0000.0000.0000:4294967295 1.1.1.100
*> 0011.1111.0000.0000.1111:4294967295 127.0.0.1
*> 0011.1111.0000.0000.1111:200 127.0.0.1
i 0011.1111.0000.0000.0000:100 1.1.1.100
i 0011.1111.0000.0000.0000:4294967295 1.1.1.100
*> 0011.1111.0000.0000.1111:200 127.0.0.1

*>i 0011.1111.0000.0000.0000 1.1.1.100
*> 0011.1111.0000.0000.1111 127.0.0.1
i 0011.1111.0000.0000.0000 1.1.1.100
*> 0011.1111.0000.0000.1111 127.0.0.1
----End

(2020-10-09)
Configuration Files
#
sysname NPE1
#
evpn vpn-instance evpna vpws
#
#
mpls lsr-id 1.1.1.1
#
mpls
#
mpls l2vpn
#
mpls ldp
#
undo shutdown
ip address 10.1.1.1 255.255.255.0
mpls
mpls ldp
#
undo shutdown
ip address 192.168.14.1 255.255.255.0
mpls
mpls ldp
#
interface LoopBack0
ip address 1.1.1.1 255.255.255.255
#
ip address 1.1.1.100 255.255.255.255
#
interface PW-VE1
esi 0011.1111.0000.0000.0000
mpls l2vc 2.2.2.2 1
#
interface PW-VE1.1
encapsulation qinq-termination
qinq termination pe-vid 100 ce-vid 100
evpl instance 1
#
bgp 100
#
ipv4-family unicast
#
l2vpn-family evpn
#
ospf 1
area 0.0.0.0
network 1.1.1.1 0.0.0.0
network 10.1.1.0 0.0.0.255
#
ospf 100
area 0.0.0.1

(2020-10-09)
network 1.1.1.100 0.0.0.0

network 192.168.14.0 0.0.0.255
#
#
return
#
sysname UPE
#
mpls lsr-id 2.2.2.2
#
mpls
#
mpls l2vpn
#
mpls ldp
#
undo shutdown
mpls l2vc 1.1.1.1 1
#
undo shutdown
ip address 10.1.1.3 255.255.255.0
mpls
mpls ldp
#
interface LoopBack0
ip address 2.2.2.2 255.255.255.255
#
ospf 1
area 0.0.0.0
network 2.2.2.2 0.0.0.0
network 10.1.1.0 0.0.0.255
#
return
#
sysname NPE2
#
evpn vpn-instance evpna vpws
#
#
#
mpls
#
mpls l2vpn
#
mpls ldp
#
undo shutdown
esi 0011.1111.0000.0000.1111
#
encapsulation qinq vid 100 ce-vid 100
evpl instance 1
#
undo shutdown

(2020-10-09)
ip address 192.168.14.4 255.255.255.0

mpls
mpls ldp
#
ip address 2.2.2.100 255.255.255.255
#
bgp 100
#
ipv4-family unicast
#
l2vpn-family evpn
#
ospf 100
area 0.0.0.1
network 2.2.2.100 0.0.0.0
network 192.168.14.0 0.0.0.255
#
#
return
3.2.36.17 Example for Accessing a BD EVPN E-LAN over an MPLS Tunnel in

VLAN-Aware Mode
The VLAN-aware bundle access mode allows different VLANs configured on a
physical interface to access the same EVPN instance (EVI) and isolates the BDs to
which the VLAN-configured sub-interfaces belong.
On the network shown in Figure 3-172, Layer 2 traffic is transmitted within Site 1
and Site 2 separately. To allow Site 1 and Site 2 to communicate over the
backbone network, configure the EVPN function to transmit both Layer 2 and
Layer 3 traffic. If the sites belong to the same subnet, an EVPN instance is created
on each PE to store EVPN routes, which are used for Layer 2 forwarding by
matching MAC addresses. A route reflector (RR) is configured to reflect EVPN
routes. To balance unicast traffic along the links between CE1 and PE1 and
between CE1 and PE2, configure Eth-Trunk sub-interfaces on PE1 and PE2 to
connect to Site 1. To allow different VLANs configured on a physical interface to
access the same EVI and isolate the BDs to which the VLAN-configured sub-
interfaces belong, configure the VLAN-aware bundle mode for the access of a CE
to the PEs.
Figure 3-172 Accessing a BD EVPN E-LAN over MPLS tunnel in VLAN-Aware mode
NOTE

(2020-10-09)
Precautions
When you configure the VLAN-aware bundle access mode, note the following:
other sites.
recommended.

communicate.
2. Configure basic MPLS functions, enable MPLS LDP, and establish LDP LSPs on
the MPLS backbone network.
3. Create an EVPN instance in BD mode and a BD and bind the BD to the EVPN
instance with a BD tag set on each PE.
7. Configure BGP EVPN peer relationships between the PEs and RR, and
8. Configure CEs and PEs to communicate.
Data Preparation

(2020-10-09)

Procedure
# Configure PE1.
[~PE1] ospf 1
[~PE1-ospf-1] quit
# Configure PE2.
[~PE2] ospf 1
[~PE2-ospf-1] quit
# Configure PE3.
[~PE3] ospf 1
[~PE3-ospf-1] quit
# Configure the RR.

[~RR] ospf 1
[*RR-ospf-1] area 0
[~RR-ospf-1] quit
routes destined for each other's loopback interfaces.

(2020-10-09)

Neighbors

DR: 10.1.1.1 BDR: 10.1.1.2 MTU: 0
------------------------------------------------------------------------------

Step 3 Configure basic MPLS functions, enable MPLS LDP, and establish LDP LSPs on the
MPLS backbone network.
# Configure PE1.
[*PE1] mpls
[*PE1-mpls] quit
[*PE1] mpls ldp
# Configure PE2.
[*PE2] mpls
[*PE2-mpls] quit
[*PE2] mpls ldp
# Configure the RR.

[*RR] mpls
[*RR-mpls] quit
[*RR] mpls ldp
[*RR-mpls-ldp] quit

(2020-10-09)
# Configure PE3.
[*PE3] mpls
[*PE3-mpls] quit
[*PE3] mpls ldp
After the configurations are complete, LDP sessions are established between the
PEs and RR. Run the display mpls ldp session command. The command output
shows that Status is Operational. Run the display mpls ldp lsp command. The
command output shows LDP LSP configurations.

--------------------------------------------------------------------------
--------------------------------------------------------------------------
--------------------------------------------------------------------------
LDP LSP Information
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
1.1.1.1/32 3/NULL 3.3.3.3 127.0.0.1 Loop1
*1.1.1.1/32 Liberal/32828 DS/3.3.3.3
2.2.2.2/32 NULL/32829 - 10.1.1.2 GE2/0/0
2.2.2.2/32 32829/32829 3.3.3.3 10.1.1.2 GE2/0/0
3.3.3.3/32 NULL/3 - 10.1.1.2 GE2/0/0
3.3.3.3/32 32828/3 3.3.3.3 10.1.1.2 GE2/0/0
4.4.4.4/32 NULL/32830 - 10.1.1.2 GE2/0/0
4.4.4.4/32 32830/32830 3.3.3.3 10.1.1.2 GE2/0/0
-------------------------------------------------------------------------------

(2020-10-09)

# Configure PE1.
[*PE1-bd10] evpn binding vpn-instance evrf1 bd-tag 100
[*PE1-bd10] quit
[*PE1-bd20] quit
[*PE1] evpn
[*PE1-evpn] quit
[*PE1] commit
# Configure PE2.
[*PE2-bd10] quit
[*PE2-bd20] quit
[*PE2] evpn
[*PE2-evpn] quit
[*PE2] commit
# Configure PE3.
[*PE3-bd10] quit
[*PE3-bd20] quit
[*PE3] commit

# Configure PE1.
[*PE1] commit
# Configure PE2.
[*PE2] commit
# Configure PE3.
[*PE3] commit

(2020-10-09)

# Configure PE1.
[~PE1] e-trunk 1
[*PE1] commit
# Configure PE2.
[~PE2] e-trunk 1
[*PE2] commit
# Configure PE3.
[*PE3] commit

# Configure PE1.
[*PE1-Eth-Trunk10] esi 0000.1111.2222.1111.1111

(2020-10-09)
[*PE1] commit
# Configure PE2.
[*PE2-Eth-Trunk10] esi 0000.1111.2222.1111.1111
[*PE2] commit
# Configure PE3.
[*PE3-Eth-Trunk10] esi 0000.1111.3333.4444.5555
[*PE3] commit
Step 8 Configure BGP EVPN peer relationships between the PEs and RR, and configure
# Configure PE1.
[~PE1] bgp 100
[*PE1-bgp] quit
[*PE1] commit
# Configure PE2.
[~PE2] bgp 100
[*PE2-bgp] quit
[*PE2] commit
# Configure PE3.
[~PE3] bgp 100
[*PE3-bgp] quit
[*PE3] commit
# Configure the RR.

[~RR] bgp 100
[*RR-bgp] quit

(2020-10-09)
[*RR] commit
on the RR. The command output shows that BGP peer relationships are


1.1.1.1 4 100 231 253 0 03:07:26 Established 6
2.2.2.2 4 100 231 256 0 03:07:44 Established 6
4.4.4.4 4 100 232 254 0 03:07:54 Established 6
Step 9 Configure CEs and PEs to communicate.

# Configure CE1.
[*CE1] bridge-domain 10
[*CE1-bd10] quit
[*CE1-bd20] quit
[*CE1] interface Eth-Trunk20.1 mode l2
[*CE1-Eth-Trunk20.1] encapsulation dot1q vid 100
[*CE1-Eth-Trunk20.1] bridge-domain 10
[*CE1] interface Eth-Trunk20.2 mode l2
[*CE1] commit
# Configure CE2.
[~CE2] interface Eth-Trunk 10
[*CE2-bd10] quit
[*CE2] interface Eth-Trunk 10.1 mode l2
[*CE2] interface Eth-Trunk 10.2 mode l2
[*CE2] commit

Run the display bgp evpn all routing-table command on PE3. The command
output shows that EVPN routes carrying Ethernet tag IDs are received from the
remote PEs.

(2020-10-09)


*>i 0000.1111.2222.1111.1111:100 1.1.1.1
*>i 0000.1111.2222.1111.1111:200 1.1.1.1
*> 0000.1111.3333.4444.5555:100 127.0.0.1
*> 0000.1111.3333.4444.5555:200 127.0.0.1
*>i 0000.1111.2222.1111.1111:4294967295 1.1.1.1
*>i 0000.1111.2222.1111.1111:4294967295 2.2.2.2
*> 0000.1111.3333.4444.5555:4294967295 127.0.0.1
*>i 0000.1111.2222.1111.1111:100 1.1.1.1
*>i 0000.1111.2222.1111.1111:200 1.1.1.1
*>i 0000.1111.2222.1111.1111:4294967295 1.1.1.1
*i 2.2.2.2
*> 0000.1111.3333.4444.5555:100 127.0.0.1
*> 0000.1111.3333.4444.5555:200 127.0.0.1

*>i 100:32:1.1.1.1 1.1.1.1
*>i 100:32:2.2.2.2 2.2.2.2
*> 100:32:4.4.4.4 127.0.0.1
*>i 200:32:1.1.1.1 1.1.1.1
*>i 200:32:2.2.2.2 2.2.2.2
*> 200:32:4.4.4.4 127.0.0.1
*>i 100:32:1.1.1.1 1.1.1.1
*>i 100:32:2.2.2.2 2.2.2.2
*> 100:32:4.4.4.4 127.0.0.1
*>i 200:32:1.1.1.1 1.1.1.1
*>i 200:32:2.2.2.2 2.2.2.2
*> 200:32:4.4.4.4 127.0.0.1

*>i 0000.1111.2222.1111.1111 1.1.1.1
*>i 0000.1111.2222.1111.1111 2.2.2.2

(2020-10-09)
*> 0000.1111.3333.4444.5555 127.0.0.1
*> 0000.1111.3333.4444.5555 127.0.0.1
----End
Configuration Files
#
sysname PE1
#
evpn
#
#
mpls lsr-id 1.1.1.1
#
mpls
#
bridge-domain 10
evpn binding vpn-instance evrf1 bd-tag 100
#
bridge-domain 20
#
mpls ldp
#
e-trunk 1
#
e-trunk 1
esi 0000.1111.2222.1111.1111
#
bridge-domain 10
#
bridge-domain 20
#
undo shutdown
eth-trunk 10
#
undo shutdown
ip address 10.1.1.1 255.255.255.0
mpls
mpls ldp
#
interface LoopBack0
ip address 1.1.1.1 255.255.255.255
#
bgp 100

(2020-10-09)

#
ipv4-family unicast
peer 3.3.3.3 enable
#
l2vpn-family evpn
peer 3.3.3.3 enable
#
ospf 1
area 0.0.0.0
network 1.1.1.1 0.0.0.0
network 10.1.1.0 0.0.0.255
#
return
#
sysname PE2
#
evpn
#
#
mpls lsr-id 2.2.2.2
#
mpls
#
bridge-domain 10
#
bridge-domain 20
#
mpls ldp
#
e-trunk 1
#
e-trunk 1
esi 0000.1111.2222.1111.1111
#
bridge-domain 10
#
bridge-domain 20
#
undo shutdown
eth-trunk 10
#
undo shutdown
ip address 10.2.1.1 255.255.255.0
mpls
mpls ldp
#

(2020-10-09)
interface LoopBack0
ip address 2.2.2.2 255.255.255.0
#
interface NULL0
#
bgp 100
#
ipv4-family unicast
peer 3.3.3.3 enable
#
l2vpn-family evpn
peer 3.3.3.3 enable
#
ospf 1
area 0.0.0.0
network 2.2.2.2 0.0.0.0
network 10.2.1.0 0.0.0.255
#
return
#
sysname PE3
#
#
mpls lsr-id 4.4.4.4
#
mpls
#
bridge-domain 10
#
bridge-domain 20
#
mpls ldp
#
esi 0000.1111.3333.4444.5555
#
bridge-domain 10
#
bridge-domain 20
#
undo shutdown
ip address 10.3.1.2 255.255.255.0
mpls
mpls ldp
#
undo shutdown
eth-trunk 10
#
interface LoopBack0
ip address 4.4.4.4 255.255.255.255
#
bgp 100

(2020-10-09)

#
ipv4-family unicast
peer 3.3.3.3 enable
#
l2vpn-family evpn
peer 3.3.3.3 enable
#
ospf 1
area 0.0.0.0
network 4.4.4.4 0.0.0.0
network 10.3.1.0 0.0.0.255
#
return
#
sysname RR
#
mpls lsr-id 3.3.3.3
#
mpls
#
mpls ldp
#
undo shutdown
ip address 10.1.1.2 255.255.255.0
mpls
mpls ldp
#
undo shutdown
ip address 10.2.1.2 255.255.255.0
mpls
mpls ldp
#
undo shutdown
ip address 10.3.1.1 255.255.255.0
mpls
mpls ldp
#
interface LoopBack0
ip address 3.3.3.3 255.255.255.255
#
bgp 100
#
ipv4-family unicast
peer 1.1.1.1 enable
peer 2.2.2.2 enable
peer 4.4.4.4 enable
#
l2vpn-family evpn
peer 1.1.1.1 enable
peer 2.2.2.2 enable
peer 4.4.4.4 enable

(2020-10-09)

#
ospf 1
area 0.0.0.0
network 3.3.3.3 0.0.0.0
network 10.1.1.0 0.0.0.255
network 10.2.1.0 0.0.0.255
network 10.3.1.0 0.0.0.255
#
return
#
sysname CE1
#
bridge-domain 10
#
bridge-domain 20
#
#
bridge-domain 10
#
bridge-domain 20
#
undo shutdown
eth-trunk 20
#
undo shutdown
eth-trunk 20
#
return
#
sysname CE2
#
bridge-domain 10
#
bridge-domain 20
#
#
bridge-domain 10
#
bridge-domain 20
#
undo shutdown
eth-trunk 10
#
return
3.2.36.18 Example for Splicing VPLS with MPLS EVPN E-LAN

VPLS is still used at the access layer of a network, whereas the aggregation
network has evolved to EVPN. To allow communication between the access layer
and aggregation layer, VPLS splicing with MPLS EVPN E-LAN needs to be

(2020-10-09)
configured. This section provides an example for splicing VPLS with MPLS EVPN E-
LAN.
As shown in the following figure, a VPLS network is deployed between the CSG
and ASGs, and an EVPN is deployed between the RSG and ASGs. Access-side PW
interfaces can be configured on ASGs to implement the VPLS splicing with MPLS
EVPN E-LAN function
Figure 3-173 Networking of configuring VPLS splicing with MPLS EVPN E-LAN
NOTE
Table 3-18 IP address planning
Device Interface IP Address
CSG GigabitEthernet 1/0/1 10.1.2.1/24
GigabitEthernet 1/0/3 -
Loopback 1 1.1.1.1/32
ASG1 GigabitEthernet 1/0/1 10.1.2.2/24
Loopback 1 2.2.2.2/32
ASG2 GigabitEthernet 1/0/1 10.1.3.2/24
Loopback 1 3.3.3.3/32

(2020-10-09)
Device Interface IP Address
RSG GigabitEthernet 1/0/0 10.2.4.2/24
GigabitEthernet 1/0/3 -
Loopback 1 4.4.4.4/32
1. Configure an IGP on each device. Because the VPLS network (between the
CSG and ASGs) and EVPN (between the RSG and ASGs) reside at different
layers, use different IGP processes to implement route communication.
2. Configure basic MPLS LDP functions on the CSG, RSG, and ASGs.
3. Configure the EVPN function on the RSG and ASGs.
4. Configure PW connections between the CSG and ASGs.
Data Preparation
● IP addresses of device interfaces
● MPLS LSR IDs of devices
● Names, RDs, and VPN targets of the EVPN instances created on the RSG and
ASGs
Procedure
Step 1 Configure an IGP on each device. Because the VPLS network (between the CSG
and ASGs) and EVPN (between the RSG and ASGs) reside at different layers, use
Step 2 Configure basic MPLS LDP functions on the CSG, RSG, and ASGs.
Step 3 Configure the EVPN function on the RSG and ASGs.
# Configure ASG1.
[~ASG1] evpn vpn-instance evrf1 bd-mode
[*ASG1-evpn-instance-evrf1] route-distinguisher 100:1
[*ASG1-evpn-instance-evrf1] vpn-target 1:1
[*ASG1-evpn-instance-evrf1] quit
[*ASG1] evpn source-address 2.2.2.2
[*ASG1] bgp 100
[*ASG1-bgp] peer 3.3.3.3 as-number 100
[*ASG1-bgp] peer 3.3.3.3 connect-interface LoopBack 1
[*ASG1-bgp] peer 4.4.4.4 as-number 100
[*ASG1-bgp] peer 4.4.4.4 connect-interface LoopBack 1

(2020-10-09)
[*ASG1-bgp] l2vpn-family evpn

[*ASG1-bgp-af-evpn] peer 3.3.3.3 enable
[*ASG1-bgp-af-evpn] peer 4.4.4.4 enable
[*ASG1-bgp-af-evpn] quit
[*ASG1-bgp] quit
[*ASG1] bridge-domain 10
[*ASG1-bd10] evpn binding vpn-instance evrf1
[*ASG1-bd10] quit
[*ASG1] commit
Repeat this step for ASG2. For configuration details, see Configuration Files in
this section.
# Configure the RSG.

[~RSG] evpn vpn-instance evrf1 bd-mode
[*RSG-evpn-instance-evrf1] route-distinguisher 100:3
[*RSG-evpn-instance-evrf1] vpn-target 1:1
[*RSG-evpn-instance-evrf1] quit
[*RSG] evpn source-address 4.4.4.4
[*RSG] bgp 100
[*RSG-bgp] peer 2.2.2.2 as-number 100
[*RSG-bgp] peer 2.2.2.2 connect-interface LoopBack 1
[*RSG-bgp] peer 3.3.3.3 as-number 100
[*RSG-bgp] peer 3.3.3.3 connect-interface LoopBack 1
[*RSG-bgp] l2vpn-family evpn
[*RSG-bgp-af-evpn] peer 2.2.2.2 enable
[*RSG-bgp-af-evpn] peer 3.3.3.3 enable
[*RSG-bgp-af-evpn] quit
[*RSG-bgp] quit
[*RSG] bridge-domain 10
[*RSG-bd10] evpn binding vpn-instance evrf1
[*RSG-bd10] quit
[*RSG] interface GigabitEthernet 1/0/3.1 mode l2
[*RSG-GigabitEthernet1/0/3.1] encapsulation dot1q vid 100
[*RSG-GigabitEthernet1/0/3.1] bridge-domain 10
[*RSG-GigabitEthernet1/0/3.1] quit
[*RSG] commit
Step 4 Configure PW connections between the CSG and ASGs.
# Configure the CSG.

[~CSG] mpls l2vpn
[*CSG-l2vpn] quit
[*CSG] vsi vsi1 bd-mode
[*CSG-vsi-vsi1] pwsignal ldp
[*CSG-vsi-vsi1-ldp] vsi-id 1
[*CSG-vsi-vsi1-ldp] peer 2.2.2.2
[*CSG-vsi-vsi1-ldp] peer 3.3.3.3
[*CSG-vsi-vsi1-ldp] protect-group vsi1
[*CSG-vsi-vsi1-ldp-protect-group-vsi1] protect-mode pw-redundancy master
[*CSG-vsi-vsi1-ldp-protect-group-vsi1] peer 2.2.2.2 preference 1
[*CSG-vsi-vsi1-ldp-protect-group-vsi1] peer 3.3.3.3 preference 2
[*CSG-vsi-vsi1-ldp-protect-group-vsi1] quit
[*CSG-vsi-vsi1-ldp] quit
[*CSG-vsi-vsi1] quit
[*CSG] bridge-domain 10
[*CSG-bd10] l2 binding vsi vsi1
[*CSG-bd10] quit
[*CSG] interface GigabitEthernet 1/0/3.1 mode l2
[*CSG-GigabitEthernet1/0/3.1] encapsulation dot1q vid 100
[*CSG-GigabitEthernet1/0/3.1] bridge-domain 10
[*CSG-GigabitEthernet1/0/3.1] quit
[*CSG] commit
# Configure ASG1.
[~ASG1] mpls l2vpn

(2020-10-09)
[*ASG1-l2vpn] quit
[*ASG1] evpn
[*ASG1-evpn] esi 0000.1111.1111.1111.1111
[*ASG1-evpn-esi-0000.1111.1111.1111.1111] evpn redundancy-mode single-active
[*ASG1-evpn-esi-0000.1111.1111.1111.1111] quit
[*ASG1-evpn] quit
[*ASG1] vsi vsi1 bd-mode
[*ASG1-vsi-vsi1] pwsignal ldp
[*ASG1-vsi-vsi1-ldp] vsi-id 1
[*ASG1-vsi-vsi1-ldp] peer 1.1.1.1 upe
[*ASG1-vsi-vsi1-ldp] peer 1.1.1.1 pw pw1
[*ASG1-vsi-vsi1-ldp-pw-pw1] esi 0000.1111.1111.1111.1111
[*ASG1-vsi-vsi1-ldp-pw-pw1] quit
[*ASG1-vsi-vsi1-ldp] quit
[*ASG1-vsi-vsi1] quit
[*ASG1-bd10] l2 binding vsi vsi1
[*ASG1-bd10] quit
[*ASG1] commit
# Configure ASG2.
[~ASG2] mpls l2vpn
[*ASG2-l2vpn] quit
[*ASG2] evpn
[*ASG2-evpn] esi 0000.1111.1111.1111.1111
[*ASG2-evpn-esi-0000.1111.1111.1111.1111] evpn redundancy-mode single-active
[*ASG2-evpn-esi-0000.1111.1111.1111.1111] quit
[*ASG2-evpn] quit
[*ASG2] vsi vsi1 bd-mode
[*ASG2-vsi-vsi1] pwsignal ldp
[*ASG2-vsi-vsi1-ldp] vsi-id 1
[*ASG2-vsi-vsi1-ldp] peer 1.1.1.1 upe
[*ASG2-vsi-vsi1-ldp] peer 1.1.1.1 pw pw1
[*ASG2-vsi-vsi1-ldp-pw-pw1] esi 0000.1111.1111.1111.1111
[*ASG2-vsi-vsi1-ldp-pw-pw1] quit
[*ASG2-vsi-vsi1-ldp] quit
[*ASG2-vsi-vsi1] quit
[*ASG2-bd10] l2 binding vsi vsi1
[*ASG2-bd10] quit
[*ASG2] commit

After completing the configurations, run the display vsi name vsi1 verbose
command on ASG1 to check that both the VSI and PW are in the Up state.
[~ASG1] display vsi name vsi1 verbose
***VSI Name : vsi1
Work Mode : bd-mode
VSI Index :1
PW Signaling : ldp
MTU : 1500
Service Class : --
Color : --
DomainId : 255
Domain Name :
P2P VSI : disable
VSI State : up

(2020-10-09)
VSI ID :1
Negotiation-vc-id :1
VC Label : 48123
Peer Type : dynamic
Session : up
Tunnel ID : 0x0000000001004c4b42
CKey :1
NKey : 16777393
Stp Enable :0
PwIndex :1

Vac State : down
Last Up Time : 0000/00/00 00:00:00
**PW Information:

PW State : up
PW Type : MEHVPLS
Tunnel ID : 0x0000000001004c4b42
Ckey :1
Nkey : 16777393
Main PW Token : 0x0
Tnl Type : ldp
OutInterface : --
Stp Enable :0
Mac Flapping :0
Monitor Group Name : --
PW Last Up Time : 2019/01/03 12:22:30
Run the display bgp evpn all routing-table command on ASG1 to view EVPN
routes. The command output contains information about the MAC routes on
VPLS-side interfaces and the ES routes and ES-AD routes corresponding to the ESI
on the PW.
[~ASG1] display bgp evpn all routing-table



(2020-10-09)
*> 0000.1111.1111.1111.1111:0 127.0.0.1
*>i 0000.1111.1111.1111.1111:0 3.3.3.3
*> 0000.1111.1111.1111.1111:4294967295 127.0.0.1
*>i 0000.1111.1111.1111.1111:4294967295 3.3.3.3
*> 0000.1111.1111.1111.1111:0 127.0.0.1
*i 3.3.3.3
*>i 0000.1111.1111.1111.1111:4294967295 3.3.3.3

*> 0:48:00e0-fc12-3456:0:0.0.0.0 0.0.0.0
*> 0:48:00e0-fc12-3456:0:0.0.0.0 0.0.0.0

*> 0:32:2.2.2.2 127.0.0.1
*>i 0:32:3.3.3.3 3.3.3.3
*>i 0:32:4.4.4.4 4.4.4.4
*> 0:32:2.2.2.2 127.0.0.1
*>i 0:32:3.3.3.3 3.3.3.3
*>i 0:32:4.4.4.4 4.4.4.4

*> 0000.1111.1111.1111.1111 127.0.0.1
*>i 0000.1111.1111.1111.1111 3.3.3.3
*> 0000.1111.1111.1111.1111 127.0.0.1
*i 3.3.3.3

(2020-10-09)
The route details include information about the associated PW. The command
output of MAC routes is used as an example.
[~ASG1] display bgp evpn all routing-table mac-route 0:48:00e0-fc12-3456:0:0.0.0.0
Imported route.
From: 0.0.0.0 (0.0.0.0)
AS-path Nil, origin incomplete, pref-val 0, valid, local, best, select, pre 255
0000.1111.1111.1111.1111
3.3.3.3
4.4.4.4
Imported route.
From: 0.0.0.0 (0.0.0.0)
Direct Out-interface: PW<peerip:1.1.1.1 vcid:1 vctype:vlan>
AS-path Nil, origin incomplete, pref-val 0, valid, local, best, select, pre 255
0000.1111.1111.1111.1111
----End
Configuration Files
● CSG configuration file
#
sysname CSG
#
mpls lsr-id 1.1.1.1
#
mpls
#
mpls l2vpn
#
vsi vsi1 bd-mode
pwsignal ldp
vsi-id 1
peer 2.2.2.2
peer 3.3.3.3
protect-group vsi1
#
bridge-domain 10
l2 binding vsi vsi1
#
mpls ldp

(2020-10-09)
#
undo shutdown
ip address 10.1.2.1 255.255.255.0
mpls
mpls ldp
#
undo shutdown
ip address 10.1.3.1 255.255.255.0
mpls
mpls ldp
#
bridge-domain 10
#
interface LoopBack1
ip address 1.1.1.1 255.255.255.255
#
ospf 100
area 0.0.0.0
network 1.1.1.1 0.0.0.0
network 10.1.2.0 0.0.0.255
network 10.1.3.0 0.0.0.255
#
return
● ASG1 configuration file
#
sysname ASG1
#
evpn
#
mac-duplication
#
esi 0000.1111.1111.1111.1111
#
#
mpls lsr-id 2.2.2.2
#
mpls
#
mpls l2vpn
#
vsi vsi1 bd-mode
pwsignal ldp
vsi-id 1
peer 1.1.1.1 upe
peer 1.1.1.1 pw pw1
esi 0000.1111.1111.1111.1111
#
bridge-domain 10
l2 binding vsi vsi1
#
mpls ldp
#
isis 1
is-level level-1
network-entity 10.0000.0000.0002.00
#
undo shutdown
ip address 10.1.2.2 255.255.255.0

(2020-10-09)
mpls
mpls ldp
#
undo shutdown
ip address 10.2.3.1 255.255.255.0
isis enable 1
mpls
mpls ldp
#
undo shutdown
ip address 10.2.4.1 255.255.255.0
isis enable 1
mpls
mpls ldp
#
interface LoopBack1
ip address 2.2.2.2 255.255.255.255
isis enable 1
#
bgp 100
#
ipv4-family unicast
peer 3.3.3.3 enable
peer 4.4.4.4 enable
#
l2vpn-family evpn
peer 3.3.3.3 enable
peer 4.4.4.4 enable
#
ospf 100
area 0.0.0.0
network 2.2.2.2 0.0.0.0
network 10.1.2.0 0.0.0.255
#
#
return
● ASG2 configuration file
#
sysname ASG2
#
evpn
#
mac-duplication
#
esi 0000.1111.1111.1111.1111
#
#
mpls lsr-id 3.3.3.3
#
mpls
#
mpls l2vpn
#
vsi vsi1 bd-mode
pwsignal ldp

(2020-10-09)
vsi-id 1
peer 1.1.1.1 upe
peer 1.1.1.1 pw pw1
esi 0000.1111.1111.1111.1111
#
bridge-domain 10
l2 binding vsi vsi1
#
mpls ldp
#
isis 1
is-level level-1
network-entity 10.0000.0000.0003.00
#
undo shutdown
ip address 10.1.3.2 255.255.255.0
mpls
mpls ldp
#
undo shutdown
ip address 10.2.3.2 255.255.255.0
isis enable 1
mpls
mpls ldp
#
undo shutdown
ip address 10.3.4.1 255.255.255.0
isis enable 1
mpls
mpls ldp
#
interface LoopBack1
ip address 3.3.3.3 255.255.255.255
isis enable 1
#
bgp 100
#
ipv4-family unicast
peer 2.2.2.2 enable
peer 4.4.4.4 enable
#
l2vpn-family evpn
peer 2.2.2.2 enable
peer 4.4.4.4 enable
#
ospf 100
area 0.0.0.0
network 3.3.3.3 0.0.0.0
network 10.1.3.0 0.0.0.255
#
#
return
● RSG configuration file
#
sysname RSG
#

(2020-10-09)

#
mpls lsr-id 4.4.4.4
#
mpls
#
bridge-domain 10
#
mpls ldp
#
isis 1
is-level level-1
network-entity 10.0000.0000.0004.00
#
undo shutdown
ip address 10.2.4.2 255.255.255.0
isis enable 1
mpls
mpls ldp
#
undo shutdown
ip address 10.3.4.2 255.255.255.0
isis enable 1
mpls
mpls ldp
#
bridge-domain 10
#
interface LoopBack1
ip address 4.4.4.4 255.255.255.255
isis enable 1
#
bgp 100
#
ipv4-family unicast
peer 2.2.2.2 enable
peer 3.3.3.3 enable
#
l2vpn-family evpn
peer 2.2.2.2 enable
peer 3.3.3.3 enable
#
#
return
3.2.36.19 Example for Configuring Co-Existence of a VPLS and an EVPN

When a VPLS network evolves towards an EVPN, to prevent a service interruption,
you must configure co-existence of the VPLS and EVPN.
On the network shown in Figure 3-174, a VPLS service is deployed. A user wants
to deploy EVPN on PE1 and PE3, that is, to use a BGP EVPN to transmit the PE1-

(2020-10-09)
PE3 service. To meet this requirement, an EVPN instance has to be configured on

each of PE1 and PE3 and be bound to the bridge domain (BD) on each of the PEs.
Then a BGP EVPN peer relationship has to be established between PE1 and PE3.
Figure 3-174 Configuring co-existence of a VPLS and an EVPN

NOTE
Precautions
When you configure co-existence of VPLS and EVPN, note the following:
other sites.
recommended.
1. Create an EVPN instance in BD mode and a BD on each of PE1 and PE3, and
bind the BD to the EVPN instance on each PE.
2. Configure a source address on each of PE1 and PE3.
3. Establish a BGP EVPN peer relationship between PE1 and PE3.
Data Preparation

(2020-10-09)

Procedure
Step 1 Ensure that an EVC has been configured to carry a VPLS service. For configuration
details, see Configuration Files in this section.
Run the display vsi name e1 verbose command on PE1. The command output
shows that VSI e1 has PWs to PE2 and PE3 established separately, and the VSI
status and the PW status are both Up.
[~PE1] display vsi name e1 verbose
***VSI Name : e1
Work Mode : bd-mode
VSI Index :2
PW Signaling : bgp
MTU : 1500
Service Class : --
Color : --
DomainId : 255
Domain Name :
P2P VSI : disable
VSI State : up
BGP RD : 100:1
SiteID/Range/Offset : 1/10/0
Import vpn target : 1:1
Export vpn target : 1:1
Remote Label Block : 294928/8/0 294928/8/0
Local Label Block : 0/294928/8/0

Vac State : up
Last Up Time : 2018/03/23 11:01:50
**PW Information:

PW State : up
PW Type : label
Tunnel ID : 0x0000000001004c4bc1
Ckey : 129
Nkey : 16777346
Main PW Token : 0x0
Tnl Type : ldp
OutInterface : --
Stp Enable :0

(2020-10-09)
Mac Flapping :0
PW Last Up Time : 2018/03/23 11:38:42
PW State : up
PW Type : label
Tunnel ID : 0x0000000001004c4b42
Ckey : 130
Nkey : 16777347
Main PW Token : 0x0
Tnl Type : ldp
OutInterface : --
Stp Enable :0
Mac Flapping :0
PW Last Up Time : 2018/03/23 11:39:10
# Configure PE1.
[*PE1-bd10] quit
[*PE1] commit
# Configure PE3.
[*PE3-bd10] quit
[*PE3] commit
# Configure PE1.
[*PE1] commit
# Configure PE3.
[*PE3] commit
Step 4 Establish a BGP EVPN peer relationship between PE1 and PE3.
# Configure PE1.
[~PE1] bgp 100
[~PE1-bgp] l2vpn-family evpn
[*PE1-bgp] quit
[*PE1] commit

(2020-10-09)
# Configure PE3.
[~PE3] bgp 100
[~PE3-bgp] l2vpn-family evpn
[*PE3-bgp] quit
[*PE3] commit

on PE1. The command output shows that the BGP EVPN peer relationship is
established between the PEs and is in Established state.


3.3.3.3 4 100 7 9 0 00:00:07 Established 1
Run the display bgp evpn all routing-table command on PE1. The command
output shows the inclusive multicast route received from PE3.


*> 0:32:1.1.1.1 127.0.0.1
*>i 0:32:3.3.3.3 3.3.3.3
m
*> 0:32:1.1.1.1 127.0.0.1
*>i 0:32:3.3.3.3 3.3.3.3
Run the display alarm active root verbose command on PE1. The command
output shows information about the alarm triggered when the VPLS VC on PE1
goes Down. The value of HWL2VpnStateChangeReason (alarm cause parameter)
is 98, indicating that the establishment of an EVPN connection causes the VPLS VC
to go Down.
[~PE1] display alarm active root verbose
Sequence : 46
AlarmId : 0xD4D0001 AlarmName : hwVplsVcDown
AlarmType : communication Severity : Major State : active
RootKindFlag: Independent
StartTime : 2018-03-26 02:42:23
Description : The status of the VPLS VC turned DOWN. (VsiName=e1, PwId=3, RemoteIp=3.3.3.3, PwType=1,
HWL2VpnStateChangeReason=98, SysUpTime=23691243, TunnelPolicyName=-)
Run the display vsi name e1 verbose command on PE1. The command output
shows that only the PW to PE2 is available and the PW status is Up.

(2020-10-09)
[~PE1] display vsi name e1 verbose

***VSI Name : e1
Work Mode : bd-mode
VSI Index :2
PW Signaling : bgp
MTU : 1500
Service Class : --
Color : --
DomainId : 255
Domain Name :
P2P VSI : disable
VSI State : up
BGP RD : 100:1
SiteID/Range/Offset : 1/10/0
Import vpn target : 1:1
Export vpn target : 1:1
Remote Label Block : 294928/8/0 294928/8/0
Local Label Block : 0/294928/8/0

Vac State : up
Last Up Time : 2018/03/23 11:01:50
**PW Information:

PW State : up
PW Type : label
Tunnel ID : 0x0000000001004c4bc1
Ckey : 129
Nkey : 16777346
Main PW Token : 0x0
Tnl Type : ldp
OutInterface : --
Stp Enable :0
Mac Flapping :0
PW Last Up Time : 2018/03/23 11:38:42
----End
Configuration Files
#
sysname PE1
#

(2020-10-09)

#
mpls lsr-id 1.1.1.1
#
mpls
#
mpls l2vpn
#
vsi e1 bd-mode
pwsignal bgp
site 1 range 10 default-offset 0
#
bridge-domain 10
l2 binding vsi e1
#
mpls ldp
#
undo shutdown
#
bridge-domain 10
#
undo shutdown
ip address 10.1.1.1 255.255.255.0
mpls
mpls ldp
#
undo shutdown
ip address 10.2.1.2 255.255.255.0
mpls
mpls ldp
#
interface LoopBack0
ip address 1.1.1.1 255.255.255.255
#
bgp 100
#
ipv4-family unicast
peer 2.2.2.2 enable
peer 3.3.3.3 enable
#
l2vpn-ad-family
policy vpn-target
signaling vpls
peer 2.2.2.2 enable
peer 3.3.3.3 enable
#
l2vpn-family evpn
peer 3.3.3.3 enable
#
ospf 1
area 0.0.0.0
network 1.1.1.1 0.0.0.0
network 10.1.1.0 0.0.0.255
network 10.2.1.0 0.0.0.255

(2020-10-09)
#
#
return
#
sysname PE2
#
mpls lsr-id 2.2.2.2
#
mpls
#
mpls l2vpn
#
vsi e1 bd-mode
pwsignal bgp
#
bridge-domain 10
l2 binding vsi e1
#
mpls ldp
#
undo shutdown
#
rewrite pop single
bridge-domain 10
#
undo shutdown
ip address 10.2.1.1 255.255.255.0
mpls
mpls ldp
#
undo shutdown
ip address 10.3.1.1 255.255.255.0
mpls
mpls ldp
#
interface LoopBack0
ip address 2.2.2.2 255.255.255.255
#
bgp 100
#
ipv4-family unicast
peer 1.1.1.1 enable
peer 3.3.3.3 enable
#
l2vpn-ad-family
policy vpn-target
signaling vpls
peer 1.1.1.1 enable
peer 3.3.3.3 enable
#
ospf 1
area 0.0.0.0
network 2.2.2.2 0.0.0.0

(2020-10-09)
network 10.2.1.0 0.0.0.255

network 10.3.1.0 0.0.0.255
#
return
#
sysname PE3
#
#
mpls lsr-id 3.3.3.3
#
mpls
#
mpls l2vpn
#
vsi e1 bd-mode
pwsignal bgp
#
bridge-domain 10
l2 binding vsi e1
#
mpls ldp
#
undo shutdown
ip address 10.1.1.2 255.255.255.0
mpls
mpls ldp
#
undo shutdown
ip address 10.3.1.2 255.255.255.0
mpls
mpls ldp
#
undo shutdown
#
rewrite pop single
bridge-domain 10
#
interface LoopBack0
ip address 3.3.3.3 255.255.255.255
#
bgp 100
#
ipv4-family unicast
peer 1.1.1.1 enable
peer 2.2.2.2 enable
#
l2vpn-ad-family
policy vpn-target
signaling vpls

(2020-10-09)
peer 1.1.1.1 enable

peer 2.2.2.2 enable
#
l2vpn-family evpn
peer 1.1.1.1 enable
#
ospf 1
area 0.0.0.0
network 3.3.3.3 0.0.0.0
network 10.1.1.0 0.0.0.255
network 10.3.1.0 0.0.0.255
#
#
return
#
sysname CE1
#
portswitch
undo shutdown
#
return
#
sysname CE2
#
portswitch
undo shutdown
#
return
#
sysname CE3
#
portswitch
undo shutdown
#
return
3.2.36.20 Example for Configuring a DCI Scenario with a VXLAN EVPN

Accessing an MPLS EVPN IRB
This section provides an example for configuring a DCI scenario with a VXLAN
EVPN accessing an MPLS EVPN IRB. In this example, a data center gateway is
connected to the DCI backbone network through a VXLAN tunnel, and BGP EVPN
is deployed on the DCI backbone network to implement data center
interconnection.
On the network shown in Figure 3-175, the DC-GWs GW1 and GW2 are
connected to the DCI backbone network with BGP EVPN configured. After BGP

(2020-10-09)
EVPN peer relationships and VXLAN tunnels are established between the DC-GWs
and the DCI-PEs, host IP routes can be exchanged between different DCs,
implementing communication between DC A and DC B (for example,
communication between VMa1 and VMb2).
Figure 3-175 Configuring a DCI scenario with a VXLAN EVPN accessing an MPLS
EVPN IRB
NOTE
Interfaces 1 and 2 in this example represent GigabitEthernet 1/0/0 and GigabitEthernet


Name
GigabitEthernet 1/0/0 192.168.20.1

DCI-PE1
Loopback 1 1.1.1.1/32
Loopback 2 11.11.11.11/32

P

(2020-10-09)

Name
Loopback 1 2.2.2.2/32
GigabitEthernet 1/0/0 192.168.30.1

DCI-PE2
Loopback1 3.3.3.3/32
Loopback2 33.33.33.33/32
1. Configure OSPF on the DCI backbone network to implement communication
between DCI-PEs.
3. Configure static routes on the DCI-PEs destined for the loopback interface
addresses of the DC-GWs.
4. Configure an EVPN instance and a BD on each DCI-PE.
5. Configure a source address on each DCI-PE.
6. Configure the DCI-PEs to establish a BGP EVPN peer relationship with each
other and BGP EVPN peer relationships with the DC-GWs.
7. Configure a VPN instance on each DCI-PE.
8. Configure VXLAN tunnels between the DCI-PEs and DC-GWs.
9. Apply a tunnel policy.
10. Configure route regeneration on each of the DCI-PEs.
Data Preparation
● MPLS LSR IDs of the DCI-PEs and P
● RDs of the VPN and EVPN instances
● Import and export VPN targets of the VPN and EVPN instances
Procedure
Step 1 Assign an IP address to each node interface, including the loopback interfaces.
Step 2 Configure an IGP on the DCI backbone network. OSPF is used in this example.

(2020-10-09)
Step 4 On each DCI-PE, configure a static route destined for the loopback interface of the
connected DC-GW.
Step 5 Configure an EVPN instance and a BD on each DCI-PE.
[*DCI-PE1-bd10] esi 0000.1111.1111.4444.5555
[*DCI-PE1] commit
[*DCI-PE2-bd10] esi 0000.1111.3333.4444.5555
[*DCI-PE2] commit
Step 6 Configure a source address on each DCI-PE.

[*DCI-PE1] commit
[*DCI-PE2] commit
Step 7 Configure the DCI-PEs to establish a BGP EVPN peer relationship with each other
and BGP EVPN peer relationships with the DC-GWs.
[~DCI-PE1] bgp 100

(2020-10-09)
[*DCI-PE1-bgp] quit
[*DCI-PE1] commit
[~DCI-PE2] bgp 100
[*DCI-PE2-bgp] quit
[*DCI-PE2] commit
Step 8 Configure a VPN instance.

[*DCI-PE1-vpn-instance-vpn1-af-ipv4] evpn mpls routing-enable
[*DCI-PE1] commit
[*DCI-PE2-vpn-instance-vpn1-af-ipv4] evpn mpls routing-enable
[*DCI-PE2] commit
Step 9 Configure VXLAN tunnels between the DCI-PEs and DC-GWs.

[*DCI-PE1] commit

(2020-10-09)
[*DCI-PE2] commit
Step 10 Apply a tunnel policy.

[*DCI-PE1-vpn-instance-vpn1-af-ipv4] tnl-policy te-lsp1 evpn
[*DCI-PE1] evpn vpn-instance evrf1 bd-mode
[*DCI-PE1-evpn-instance-evrf1] tnl-policy te-lsp1
[*DCI-PE1] commit
[*DCI-PE2-vpn-instance-vpn1-af-ipv4] tnl-policy te-lsp1 evpn
[*DCI-PE2] evpn vpn-instance evrf1 bd-mode
[*DCI-PE2-evpn-instance-evrf1] tnl-policy te-lsp1
[*DCI-PE2] commit
Step 11 Enable each DCI-PE to advertise regenerated routes to each BGP EVPN peer.
[~DCI-PE1] bgp 100
[*DCI-PE1-bgp-vpn1] import-route direct
[*DCI-PE1-bgp-af-evpn] peer 3.3.3.3 advertise route-reoriginated evpn mac-ip
[*DCI-PE1-bgp-af-evpn] peer 3.3.3.3 advertise route-reoriginated evpn mac
[*DCI-PE1-bgp-af-evpn] peer 3.3.3.3 advertise route-reoriginated evpn ip
[*DCI-PE1-bgp-af-evpn] peer 3.3.3.3 advertise irb
[*DCI-PE1-bgp] quit
[*DCI-PE1] commit
[~DCI-PE2] bgp 100
[*DCI-PE2-bgp-vpn1] import-route direct
[*DCI-PE2-bgp-af-evpn] peer 1.1.1.1 advertise route-reoriginated evpn mac

(2020-10-09)

[*DCI-PE2-bgp] quit
[*DCI-PE2] commit

Run the display ip routing-table vpn-instance vpn1 command on a DCI-PE to
check VPN routes. The command output shows that routes received from the
connected DC-GW recurse to the VXLAN tunnel and routes received from the
remote DCI-PE recurse to the MPLS TE tunnel. The following uses the command
output on DCI-PE1 as an example.
[~DCI-PE1] display ip routing-table vpn-instance vpn1
------------------------------------------------------------------------------
10.1.1.0/24 EBGP 255 0 RD 4.4.4.4 VXLAN

10.2.1.0/24 IBGP 255 0 RD 3.3.3.3 Tunnel1
----End
Configuration Files
#
sysname DCI-PE1
#
tnl-policy te-lsp1
#
ipv4-family
tnl-policy te-lsp1 evpn
vxlan vni 555
#
mpls lsr-id 1.1.1.1
#
mpls
mpls te
mpls rsvp-te
mpls te cspf
#
bridge-domain 10
#

(2020-10-09)
interface Vbdif10
ip address 10.10.10.1 255.255.255.0
#
undo shutdown
ip address 192.168.20.1 255.255.255.0
#
encapsulation qinq
bridge-domain 10
#
undo shutdown
ip address 192.168.1.1 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 1.1.1.1 255.255.255.255
#
interface LoopBack2
ip address 11.11.11.11 255.255.255.255
#
interface Nve1
source 11.11.11.11
#
interface Tunnel1
destination 3.3.3.3
#
bgp 100
#
ipv4-family unicast
peer 3.3.3.3 enable
peer 4.4.4.4 enable
#
import-route direct
#
l2vpn-family evpn
peer 3.3.3.3 enable
peer 3.3.3.3 advertise route-reoriginated evpn mac
peer 4.4.4.4 enable
#
ospf 1
area 0.0.0.0

(2020-10-09)
network 1.1.1.1 0.0.0.0

network 192.168.1.0 0.0.0.255
mpls-te enable
#
ip route-static 4.4.4.4 255.255.255.255 192.168.20.2
#
#
#
return
#
sysname P
#
mpls lsr-id 2.2.2.2
#
mpls
mpls te
mpls rsvp-te
mpls te cspf
#
undo shutdown
ip address 192.168.1.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
undo shutdown
ip address 192.168.10.1 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 2.2.2.2 255.255.255.255
#
ospf 1
area 0.0.0.0
network 2.2.2.2 0.0.0.0
network 192.168.1.0 0.0.0.255
network 192.168.10.0 0.0.0.255
mpls-te enable
#
return
#
sysname DCI-PE2
#
tnl-policy te-lsp1
#
ipv4-family

(2020-10-09)

vxlan vni 555
#
mpls lsr-id 3.3.3.3
#
mpls
mpls te
mpls rsvp-te
mpls te cspf
#
bridge-domain 10
#
interface Vbdif10
ip address 10.20.10.1 255.255.255.0
#
undo shutdown
ip address 192.168.30.1 255.255.255.0
#
encapsulation qinq
bridge-domain 10
#
undo shutdown
ip address 192.168.10.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 3.3.3.3 255.255.255.255
#
interface LoopBack2
ip address 33.33.33.33 255.255.255.255
#
interface Nve1
source 33.33.33.33
#
interface Tunnel1
destination 1.1.1.1
#
bgp 100
#
ipv4-family unicast
peer 1.1.1.1 enable
peer 5.5.5.5 enable
#
import-route direct
#
l2vpn-family evpn
peer 1.1.1.1 enable

(2020-10-09)

peer 1.1.1.1 advertise route-reoriginated evpn mac
peer 5.5.5.5 enable
#
ospf 1
area 0.0.0.0
network 3.3.3.3 0.0.0.0
network 192.168.10.0 0.0.0.255
mpls-te enable
#
ip route-static 5.5.5.5 255.255.255.255 192.168.30.2
#
#
#
return

See the configuration file of a DC device.
3.2.36.21 Example for Configuring a DCI Scenario with a VLAN Base

Accessing an MPLS EVPN IRB (Using EVPN-MPLS as the Bearer and PE as a
GW)
The underlay VLAN access to DCI uses different cloud management platforms, and
an Ethernet sub-interface is associated with a VLAN to access the DCI backbone
network, with integrated deployment of DCI-PEs and DC-GWs (DCI-PE1-GW1 and
DCI-PE2-GW2). A BGP EVPN peer relationship is established between the DCI-PE-
GWs.
A DC-GW and a DCI-PE are the same device, which is directly connected to a DC
device. On the network shown in Figure 3-176, a DC-PE-GW functions as both a
DC-GW and a DCI-PE. The DC-PE-GW is connected to the P on the DCI backbone
network on one side and directly connected to a DC device on the other side. A

(2020-10-09)
VXLAN tunnel is established in each DC to implement intra-DC VM

communication. To implement inter-DC VM communication, create L3VPN
instances and EVPN instances on the DCI-PE-GWs and establish a BGP EVPN peer
relationship between the DCI-PE-GWs.
Figure 3-176 Configuring underlay VLAN access to DCI (using EVPN-MPLS as the
bearer and PE as a GW)
NOTE
Interface 1, interface 2, and sub-interface 1.1 in this example represent GE 1/0/0, GE 2/0/0,
and GE 1/0/0.1, respectively.

Name
GE 1/0/0.1 -
DCI-
PE1- GE 2/0/0 192.168.1.1/24
GW1
Loopback 1 1.1.1.1/32
GE 1/0/0 192.168.1.2/24
P GE 2/0/0 192.168.10.1/24
GE 1/0/0.1 -
DCI-
PE2- GE 2/0/0 192.168.10.2/24
GW2

(2020-10-09)
1. Configure OSPF on the DCI backbone network to implement communication
between DCI-PEs.
3. Configure a VPN instance on each DCI-PE-GW and apply a tunnel policy to
the VPN instance.
4. Create a VBDIF interface on each DCI-PE-GW and bind the VPN instance to
the VBDIF interface.
5. Configure each DCI-PE-GW to advertise IP prefix routes.
6. Configure an EVPN instance on each DCI-PE-GW and establish a BGP EVPN
peer relationship between the DCI-PE-GWs, and configure each DCI-PE-GW to
advertise IRB routes.
7. Configure a source address on each DCI-PE-GW.
Data Preparation
● MPLS LSR IDs of the DCI-PE-GWs and P
● RD of a VPN instance
● Import and export VPN targets of the VPN instance
Procedure
Step 1 Assign an IP address to each node interface, including the loopback interfaces.
Step 2 Configure an IGP on the DCI backbone network. OSPF is used in this example.
Step 4 Configure a VPN instance on each DCI-PE-GW and apply a tunnel policy to the
VPN instance.
# Configure DCI-PE1-GW1.
[~DCI-PE1-GW1] tunnel-policy te-lsp1
[*DCI-PE1-GW1-tunnel-policy-te-lsp1] tunnel select-seq cr-lsp load-balance-number 1
[*DCI-PE1-GW1-tunnel-policy-te-lsp1] quit
[*DCI-PE1-GW1] ip vpn-instance vpn1
[*DCI-PE1-GW1-vpn-instance-vpn1] ipv4-family
[*DCI-PE1-GW1-vpn-instance-vpn1-af-ipv4] route-distinguisher 11:11
[*DCI-PE1-GW1-vpn-instance-vpn1-af-ipv4] tnl-policy te-lsp1 evpn
[*DCI-PE1-GW1-vpn-instance-vpn1-af-ipv4] vpn-target 11:1 both evpn
[*DCI-PE1-GW1-vpn-instance-vpn1-af-ipv4] evpn mpls routing-enable
[*DCI-PE1-GW1-vpn-instance-vpn1-af-ipv4] quit

(2020-10-09)
[*DCI-PE1-GW1-vpn-instance-vpn1] quit
[*DCI-PE1-GW1] commit
[~DCI-PE2-GW2] tunnel-policy te-lsp1
[*DCI-PE2-GW2-tunnel-policy-te-lsp1] tunnel select-seq cr-lsp load-balance-number 1
[*DCI-PE2-GW2-tunnel-policy-te-lsp1] quit
[*DCI-PE2-GW2] ip vpn-instance vpn1
[*DCI-PE2-GW2-vpn-instance-vpn1] ipv4-family
[*DCI-PE2-GW2-vpn-instance-vpn1-af-ipv4] route-distinguisher 11:11
[*DCI-PE2-GW2-vpn-instance-vpn1-af-ipv4] tnl-policy te-lsp1 evpn
[*DCI-PE2-GW2-vpn-instance-vpn1-af-ipv4] vpn-target 11:1 both evpn
[*DCI-PE2-GW2-vpn-instance-vpn1-af-ipv4] evpn mpls routing-enable
[*DCI-PE2-GW2-vpn-instance-vpn1-af-ipv4] quit
[*DCI-PE2-GW2-vpn-instance-vpn1] quit
Step 5 Configure each DCI-PE-GW to advertise IP prefix routes.

[~DCI-PE1-GW1] bgp 100
[*DCI-PE1-GW1-bgp] ipv4-family vpn-instance vpn1
[*DCI-PE1-GW1-bgp-vpn1] import-route direct
[*DCI-PE1-GW1-bgp-vpn1] advertise l2vpn evpn
[*DCI-PE1-GW1-bgp-vpn1] quit
[~DCI-PE2-GW2] bgp 100
[*DCI-PE2-GW2-bgp] ipv4-family vpn-instance vpn1
[*DCI-PE2-GW2-bgp-vpn1] import-route direct
[*DCI-PE2-GW2-bgp-vpn1] advertise l2vpn evpn
[*DCI-PE2-GW2-bgp-vpn1] quit
Step 6 Configure an EVPN instance on each DCI-PE-GW and establish a BGP EVPN peer
relationship between the DCI-PE-GWs, and configure each DCI-PE-GW to advertise
IRB routes.
[~DCI-PE1-GW1] evpn vpn-instance evrf1 bd-mode
[*DCI-PE1-GW1-evpn-instance-evrf1] route-distinguisher 10:1
[*DCI-PE1-GW1-evpn-instance-evrf1] vpn-target 11:1
[*DCI-PE1-GW1-evpn-instance-evrf1] tnl-policy te-lsp1
[*DCI-PE1-GW1-evpn-instance-evrf1] quit
[*DCI-PE1-GW1] bridge-domain 10
[*DCI-PE1-GW1-bd10] evpn binding vpn-instance evrf1
[*DCI-PE1-GW1-bd10] quit
[*DCI-PE1-GW1] bgp 100
[*DCI-PE1-GW1-bgp] peer 3.3.3.3 as-number 100
[*DCI-PE1-GW1-bgp] peer 3.3.3.3 connect-interface loopback 1
[*DCI-PE1-GW1-bgp] l2vpn-family evpn
[*DCI-PE1-GW1-bgp-af-evpn] peer 3.3.3.3 enable
[*DCI-PE1-GW1-bgp-af-evpn] peer 3.3.3.3 advertise irb
[*DCI-PE1-GW1-bgp-af-evpn] quit
[*DCI-PE1-GW1-bgp] quit
[~DCI-PE2-GW2] evpn vpn-instance evrf1 bd-mode
[*DCI-PE2-GW2-evpn-instance-evrf1] route-distinguisher 10:1
[*DCI-PE2-GW2-evpn-instance-evrf1] vpn-target 11:1
[*DCI-PE2-GW1-evpn-instance-evrf1] tnl-policy te-lsp1
[*DCI-PE2-GW2-evpn-instance-evrf1] quit

(2020-10-09)
[*DCI-PE2-GW2] bridge-domain 10
[*DCI-PE2-GW2-bd10] evpn binding vpn-instance evrf1
[*DCI-PE2-GW2-bd10] quit
[*DCI-PE2-GW2] bgp 100
[*DCI-PE2-GW2-bgp] peer 1.1.1.1 as-number 100
[*DCI-PE2-GW2-bgp] peer 1.1.1.1 connect-interface loopback 1
[*DCI-PE2-GW2-bgp] l2vpn-family evpn
[*DCI-PE2-GW2-bgp-af-evpn] peer 1.1.1.1 enable
[*DCI-PE2-GW2-bgp-af-evpn] peer 1.1.1.1 advertise irb
[*DCI-PE2-GW2-bgp-af-evpn] quit
[*DCI-PE2-GW2-bgp] quit
Step 7 Create a VBDIF interface on each DCI-PE-GW.

[~DCI-PE1-GW1] interface gigabitethernet 1/0/0.1 mode l2
[*DCI-PE1-GW1-GigabitEthernet1/0/0.1] encapsulation dot1q vid 10
[*DCI-PE1-GW1-GigabitEthernet1/0/0.1] rewrite pop single
[*DCI-PE1-GW1-GigabitEthernet1/0/0.1] bridge-domain 10
[*DCI-PE1-GW1-GigabitEthernet1/0/0.1] quit
[*DCI-PE1-GW1] interface Vbdif10
[*DCI-PE1-GW1-Vbdif10] ip binding vpn-instance vpn1
[*DCI-PE1-GW1-Vbdif10] ip address 10.1.1.1 255.255.255.0
[*DCI-PE1-GW1-Vbdif10] arp collect host enable
[*DCI-PE1-GW1-Vbdif10] quit
[~DCI-PE2-GW2] interface gigabitethernet 1/0/0.1 mode l2
[*DCI-PE2-GW2-GigabitEthernet1/0/0.1] encapsulation dot1q vid 10
[*DCI-PE2-GW2-GigabitEthernet1/0/0.1] rewrite pop single
[*DCI-PE2-GW2-GigabitEthernet1/0/0.1] bridge-domain 10
[*DCI-PE2-GW2-GigabitEthernet1/0/0.1] quit
[*DCI-PE2-GW2] interface Vbdif10
[*DCI-PE2-GW2-Vbdif10] ip binding vpn-instance vpn1
[*DCI-PE2-GW2-Vbdif10] ip address 10.2.1.1 255.255.255.0
[*DCI-PE2-GW2-Vbdif10] arp collect host enable
[*DCI-PE2-GW2-Vbdif10] quit
Step 8 Configure a source address on each DCI-PE-GW.

# Configure DCI-PE-GW1.
[~DCI-PE-GW1] evpn source-address 1.1.1.1
[*DCI-PE-GW1] commit
# Configure DCI-PE-GW2.
[~DCI-PE-GW2] evpn source-address 3.3.3.3
[*DCI-PE-GW2] commit

Run the display bgp evpn all routing-table command on a DCI-PE-GW. The
command output shows EVPN IRB routes received from the connected DCI-PE-GW
and the remote DCI-PE-GW. The following uses the command output on DCI-PE1-
GW1 as an example.
[~DCI-PE1-GW1] display bgp evpn all routing-table


(2020-10-09)

*>i 0:48:00e0-fc12-3456:0:0.0.0.0 3.3.3.3
*>i 0:48:00e0-fc12-3456:32:20.1.1.1 3.3.3.3
*> 0:48:00e0-fc12-7890:0:0.0.0.0 0.0.0.0
*> 0:48:00e0-fc12-7890:32:10.1.1.1 0.0.0.0
*>i 0:48:00e0-fc12-3456:0:0.0.0.0 3.3.3.3
*>i 0:48:00e0-fc12-3456:32:20.1.1.1 3.3.3.3
*> 0:48:00e0-fc12-7890:0:0.0.0.0 0.0.0.0
*> 0:48:00e0-fc12-7890:32:10.1.1.1 0.0.0.0

*> 0:32:1.1.1.1 127.0.0.1
*>i 0:32:3.3.3.3 3.3.3.3
*> 0:32:1.1.1.1 127.0.0.1
*>i 0:32:3.3.3.3 3.3.3.3

*> 0:10.1.1.0:24 0.0.0.0
*>i 0:10.2.1.0:24 3.3.3.3
Run the display ip routing-table vpn-instance command on a DC-PE-GW. The

command output shows the VPN routes received from the remote DC-PE-GW. The
following uses the command output on DCI-PE1-GW1 as an example.
[~DCI-PE1-GW1] display ip routing-table vpn-instance vpn1
------------------------------------------------------------------------------
10.1.1.0/24 Direct 0 0 D 10.1.1.1 Vbdif10

10.1.1.1/32 Direct 0 0 D 127.0.0.1 Vbdif10
10.1.1.255/32 Direct 0 0 D 127.0.0.1 Vbdif10
10.2.1.0/24 IBGP 255 0 RD 3.3.3.3 Tunnel1
10.2.1.1/32 IBGP 255 0 RD 3.3.3.3 Tunnel1
----End
Configuration Files
● DCI-PE1-GW1 configuration file

(2020-10-09)
#
sysname DCI-PE1-GW1
#
tnl-policy te-lsp1
#
ipv4-family
#
mpls lsr-id 1.1.1.1
#
mpls
mpls te
mpls rsvp-te
mpls te cspf
#
bridge-domain 10
#
interface Vbdif10
ip address 10.1.1.1 255.255.255.0
#
undo shutdown
#
rewrite pop single
bridge-domain 10
#
undo shutdown
ip address 192.168.1.1 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 1.1.1.1 255.255.255.255
#
interface Tunnel1
destination 3.3.3.3
#
bgp 100
#
ipv4-family unicast
peer 3.3.3.3 enable
#
import-route direct
#

(2020-10-09)
l2vpn-family evpn
peer 3.3.3.3 enable
#
ospf 1
area 0.0.0.0
network 1.1.1.1 0.0.0.0
network 192.168.1.0 0.0.0.255
mpls-te enable
#
#
#
return
#
sysname P
#
mpls lsr-id 2.2.2.2
#
mpls
mpls te
mpls rsvp-te
mpls te cspf
#
undo shutdown
ip address 192.168.1.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
undo shutdown
ip address 192.168.10.1 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 2.2.2.2 255.255.255.255
#
ospf 1
area 0.0.0.0
network 2.2.2.2 0.0.0.0
network 192.168.1.0 0.0.0.255
network 192.168.10.0 0.0.0.255
mpls-te enable
#
return
● DCI-PE2-GW2 configuration file
#
sysname DCI-PE2-GW2
#
tnl-policy te-lsp1
#
ipv4-family

(2020-10-09)
#
mpls lsr-id 3.3.3.3
#
mpls
mpls te
mpls rsvp-te
mpls te cspf
#
bridge-domain 10
#
interface Vbdif10
ip address 10.2.1.1 255.255.255.0
#
undo shutdown
#
rewrite pop single
bridge-domain 10
#
undo shutdown
ip address 192.168.10.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
interface Pos3/1/3
link-protocol ppp
undo shutdown
#
interface LoopBack1
ip address 3.3.3.3 255.255.255.255
#
interface Tunnel1
destination 1.1.1.1
#
bgp 100
#
ipv4-family unicast
peer 1.1.1.1 enable
#
import-route direct
#
l2vpn-family evpn
peer 1.1.1.1 enable
#
ospf 1
area 0.0.0.0

(2020-10-09)
network 3.3.3.3 0.0.0.0

network 192.168.10.0 0.0.0.255
mpls-te enable
#
#
#
return

3.2.36.22 Example for Splicing a Common L3VPN with an EVPN L3VPN

This section provides an example for splicing a common L3VPN with an EVPN
L3VPN to implement communication between the two networks.
An L3VPN is deployed over the MAN and is being replaced with an EVPN. If a lot
of devices are deployed on the MAN, end-to-end replacement may not be
implemented at a time. Therefore, co-existence of the L3VPN and EVPN occurs
during the network reconstruction. On the network shown in Figure 3-177, an
L3VPN is deployed between the UPE and NPE1, and an EVPN is deployed between
NPE1 and NPE2. To allow communication between the L3VPN and EVPN,
configure the border device NPE1 between the two networks.
Figure 3-177 Splicing a Common L3VPN with an EVPN L3VPN

NOTE
Interfaces 1 and 2 in this example represent GigabitEthernet 1/0/0 and GigabitEthernet


(2020-10-09)

Name
UPE GigabitEthernet 2/0/0 192.168.20.1/24
Loopback 1 1.1.1.1/32
Loopback 1 2.2.2.2/32
Loopback 1 3.3.3.3/32
1. Deploy IGPs on the UPE, NPE1, and NPE2. In this example, OSPF runs
between the UPE and NPE1, and IS-IS runs between NPE1 and NPE2.
2. Configure MPLS LDP on the UPE, NPE1, and NPE2.
3. Configure L3VPN instances on the UPE and NPE1, and establish a BGP VPNv4
connection between them.
4. Establish a BGP EVPN connection between NPE1 and NPE2.
5. Configure an L3VPN instance and binding it to an interface on NPE2 to access
Layer 3 services.
6. Enable NPE1 to regenerate routes.
Data Preparation
● MPLS LSR IDs of the UPE and NPEs
● RDs of the L3VPN instances
● Import and export VPN targets for the L3VPN instances
Procedure
Step 1 Assign an IP address to each device interface, including the loopback interfaces.
Step 2 Deploy IGPs on the UPE, NPE1, and NPE2. In this example, OSPF runs between the
UPE and NPE1, and IS-IS runs between NPE1 and NPE2.

(2020-10-09)

Step 3 Configure MPLS LDP on the UPE, NPE1, and NPE2.
Step 4 Configure L3VPN instances on the UPE and NPE1, and establish a BGP VPNv4
connection between them.
[~UPE] ip vpn-instance vpn1
[*UPE-vpn-instance-vpn1] ipv4-family
[*UPE-vpn-instance-vpn1-af-ipv4] route-distinguisher 10:1
[*UPE-vpn-instance-vpn1-af-ipv4] vpn-target 1:1 both
[*UPE-vpn-instance-vpn1-af-ipv4] quit
[*UPE-vpn-instance-vpn1] quit
[*UPE-GigabitEthernet2/0/0] ip binding vpn-instance vpn1
[*UPE-GigabitEthernet2/0/0] ip address 192.168.20.1 255.255.255.0
[*UPE] bgp 100
[*UPE-bgp] peer 2.2.2.2 as-number 100
[*UPE-bgp] peer 2.2.2.2 connect-interface LoopBack1
[*UPE-bgp] ipv4-family vpn-instance vpn1
[*UPE-bgp-vpn1] import-route direct
[*UPE-bgp-vpn1] quit
[*UPE] commit
# Configure NPE1.
[~NPE1] ip vpn-instance vpn1
[*NPE1-vpn-instance-vpn1] ipv4-family
[*NPE1-vpn-instance-vpn1-af-ipv4] route-distinguisher 11:11
[*NPE1-vpn-instance-vpn1-af-ipv4] vpn-target 1:1 both
[*NPE1-vpn-instance-vpn1-af-ipv4] quit
[*NPE1-vpn-instance-vpn1] quit
[*NPE1] bgp 100
[*NPE1-bgp] ipv4-family vpnv4
[*NPE1-bgp-af-vpnv4] peer 1.1.1.1 enable
[*NPE1-bgp-af-vpnv4] quit
[*NPE1] commit
Step 5 Establish a BGP EVPN connection between NPE1 and NPE2.

# Configure NPE1.
[~NPE1] bgp 100
[*NPE1-bgp] ipv4-family vpn-instance vpn1
[*NPE1-bgp-vpn1] advertise l2vpn evpn
[*NPE1] commit
# Configure NPE2.
[~NPE2] bgp 100

(2020-10-09)
[*NPE2] commit
Step 6 Configure an L3VPN instance and binding it to an interface on NPE2 to access

Layer 3 services.
[*NPE2-vpn-instance-vpn1-af-ipv4] route-distinguisher 20:2
[*NPE2-vpn-instance-vpn1-af-ipv4] vpn-target 2:2 both evpn
[*NPE2-vpn-instance-vpn1-af-ipv4] evpn mpls routing-enable
[*NPE2-vpn-instance-vpn1-af-ipv4] quit
[*NPE2] interface GigabitEthernet 2/0/0
[*NPE2-GigabitEthernet2/0/0] ip binding vpn-instance vpn1
[*NPE2-GigabitEthernet2/0/0] ip address 192.168.30.1 24
[*NPE2-GigabitEthernet2/0/0] quit
[*NPE2] bgp 100
[*NPE2-bgp] ipv4-family vpn-instance vpn1
[*NPE2-bgp-vpn1] advertise l2vpn evpn
[*NPE2-bgp-vpn1] import-route direct
[*NPE2-bgp-vpn1] quit
[*NPE2-bgp] quit
[*NPE2] commit
Step 7 Enable NPE1 to regenerate routes.

[*NPE1-vpn-instance-vpn1-af-ipv4] vpn-target 2:2 both evpn
[*NPE1-vpn-instance-vpn1-af-ipv4] evpn mpls routing-enable
[*NPE1-pn-instance-vpn1-af-ipv4] quit
[*NPE1] bgp 100
[*NPE1-bgp] ipv4-family vpnv4
[*NPE1-bgp-af-vpnv4] peer 1.1.1.1 reflect-client
[*NPE1-bgp-af-vpnv4] peer 1.1.1.1 import reoriginate
[*NPE1-bgp-af-vpnv4] peer 1.1.1.1 advertise route-reoriginated evpn mac-ip
[*NPE1-bgp-af-vpnv4] peer 1.1.1.1 advertise route-reoriginated evpn ip
[*NPE1-bgp-af-vpnv4] quit
[*NPE1-bgp-af-evpn] peer 3.3.3.3 advertise irb
[*NPE1-bgp-af-evpn] peer 3.3.3.3 reflect-client
[*NPE1-bgp-af-evpn] peer 3.3.3.3 import reoriginate
[*NPE1-bgp-af-evpn] peer 3.3.3.3 advertise route-reoriginated vpnv4
[*NPE1-bgp] quit
[*NPE1] commit
Run the display bgp evpn all routing-table command on NPE2. The command
output shows EVPN routes received from the UPE.
[~NPE2] display bgp evpn all routing-table


*> 0:48:00e0-fc12-3456:0:0.0.0.0 0.0.0.0
* 0.0.0.0
*> 0:48:00e0-fc12-3456:32:192.168.30.2 0.0.0.0

(2020-10-09)
*> 0:48:00e0-fc12-7890:0:0.0.0.0 0.0.0.0

*> 0:48:00e0-fc12-7890:32:192.168.30.1 0.0.0.0
*> 0:48:00e0-fc12-3456:0:0.0.0.0 0.0.0.0
* 0.0.0.0
*> 0:48:00e0-fc12-3456:32:192.168.30.2 0.0.0.0
*> 0:48:00e0-fc12-7890:0:0.0.0.0 0.0.0.0
*> 0:48:00e0-fc12-7890:32:192.168.30.1 0.0.0.0

*>i 0:192.168.20.0:24 2.2.2.2
*>i 0:192.168.20.0:24 2.2.2.2
*> 0:192.168.30.0:24 0.0.0.0
*> 0:192.168.30.1:32 0.0.0.0
Run the display ip routing-table vpn-instance vpn1 command on NPE2. The

command output shows the VPN route.
[~NPE2] display ip routing-table vpn-instance vpn1
------------------------------------------------------------------------------

192.168.30.0/24 Direct 0 0 D 192.168.30.1 Vbdif10
192.168.30.1/32 Direct 0 0 D 127.0.0.1 Vbdif10
192.168.30.255/32 Direct 0 0 D 127.0.0.1 Vbdif10
----End
Configuration Files
#
sysname UPE
#
ipv4-family
#
mpls lsr-id 1.1.1.1
#
mpls
#
mpls ldp
#
undo shutdown
ip address 10.1.1.1 255.255.255.0
mpls
mpls ldp
#

(2020-10-09)
undo shutdown
ip address 192.168.20.1 255.255.255.0
#
interface LoopBack1
ip address 1.1.1.1 255.255.255.255
#
bgp 100
#
ipv4-family unicast
peer 2.2.2.2 enable
#
ipv4-family vpnv4
policy vpn-target
peer 2.2.2.2 enable
#
import-route direct
peer 192.168.20.2 as-number 65410
#
ospf 1
area 0.0.0.0
network 1.1.1.1 0.0.0.0
network 10.1.1.0 0.0.0.255
#
return
#
sysname NPE1
#
ipv4-family
#
mpls lsr-id 2.2.2.2
#
mpls
#
mpls ldp
#
isis 1
network-entity 10.0000.0000.0002.00
#
undo shutdown
ip address 10.1.1.2 255.255.255.0
mpls
mpls ldp
#
undo shutdown
ip address 10.2.1.1 255.255.255.0
isis enable 1
mpls
mpls ldp
#
interface LoopBack1
ip address 2.2.2.2 255.255.255.255
isis enable 1

(2020-10-09)
#
bgp 100
#
ipv4-family unicast
peer 1.1.1.1 enable
peer 3.3.3.3 enable
#
ipv4-family vpnv4
policy vpn-target
peer 1.1.1.1 enable
#
#
l2vpn-family evpn
peer 3.3.3.3 enable
#
ospf 1
area 0.0.0.0
network 2.2.2.2 0.0.0.0
network 10.1.1.0 0.0.0.255
#
return
#
sysname NPE2
#
ipv4-family
#
mpls lsr-id 3.3.3.3
#
mpls
#
mpls ldp
#
isis 1
network-entity 10.0000.0000.0003.00
#
undo shutdown
ip address 10.2.1.2 255.255.255.0
isis enable 1
mpls
mpls ldp
#
undo shutdown
ip address 192.168.30.1 255.255.255.0

(2020-10-09)
#
interface LoopBack1
ip address 3.3.3.3 255.255.255.255
isis enable 1
#
bgp 100
#
ipv4-family unicast
peer 2.2.2.2 enable
#
import-route direct
#
l2vpn-family evpn
peer 2.2.2.2 enable
#
return
3.2.36.23 Example for Splicing a VPLS in PW Redundancy Mode with an

Anycast VXLAN in an EVPN Active-Active Scenario
This section provides an example for splicing a VPLS in PW redundancy mode with
an anycast VXLAN in an EVPN active-active scenario.
On the network shown in Figure 3-178, PE1 and PE2 are egress devices of the
data center network. PE1 and PE2 work in active-active mode with a bypass
VXLAN tunnel deployed between them. They use an anycast VTEP address to
establish a VXLAN tunnel with the TOR. In this manner, PE1, PE2, and the TOR can
communicate with each other. PE1 and PE2 communicate with the external
network through the VPLS network, on which PW redundancy is configured.
Specifically, the PE-AGG connects to PE1 and PE2 through primary and secondary
PWs, respectively.
Figure 3-178 Splicing a VPLS in PW redundancy mode with an anycast VXLAN in

an EVPN active-active scenario
NOTE

respectively.

(2020-10-09)
Device Interface IP Address and Mask

Name
GigabitEhernet 1/0/1 10.1.14.1/24

PE1
Loopback 1 1.1.1.1/32
Loopback 2 1.1.1.100/32
Loopback 3 1.1.1.20/32
PE2 GigabitEhernet 1/0/1 10.2.14.1/24

(2020-10-09)
Device Interface IP Address and Mask

Name
Loopback 1 2.2.2.2/32
Loopback 2 2.2.2.100/32
Loopback 3 1.1.1.20/32
PE-AGG GigabitEhernet 1/0/1 10.1.13.3/24
Loopback 1 3.3.3.3/32
TOR GigabitEhernet 1/0/1 10.1.14.4/24
Loopback 1 4.4.4.100/32
1. Configure interface IP addresses, an IGP, and MPLS functions on each device.
2. Configure BGP EVPN on PE1 and PE2.
3. Configure a VXLAN tunnel between PE1 and PE2.
4. Configure primary and secondary PWs on the PE-AGG.
5. Configure PWs on PE1 and PE2 and set the PWs to AC mode.
Data Preparation
● Interfaces and their IP addresses
● EVPN instance name
Procedure
Step 1 Configure interface IP addresses, an IGP, and MPLS functions on each device.
Step 2 Configure BGP EVPN on PE1 and PE2.
# Configure PE1.
[~PE1] evpn
[*PE1-evpn] bypass-vxlan enable
[*PE1-evpn] quit
[*PE1] bgp 100

(2020-10-09)

[*PE1-bgp] peer 2.2.2.100 connect-interface LoopBack 2
[*PE1-bgp] peer 4.4.4.100 connect-interface LoopBack 2
[*PE1-bgp] quit
[*PE1] commit
section.
Step 3 Configure a VXLAN tunnel between PE1 and PE2.
1. Configure an EVPN instance and bind it to a BD on each PE.
# Configure PE1.
[~PE1] evpn vpn-instance evpn1 bd-mode
[*PE1-evpn-instance-evpn1] route-distinguisher 11:11
[*PE1-evpn-instance-evpn1] vpn-target 1:1 export-extcommunity
[*PE1-evpn-instance-evpn1] vpn-target 1:1 import-extcommunity
[*PE1-evpn-instance-evpn1] quit
[*PE1-bd10] vxlan vni 10 split-horizon-mode
[*PE1-bd10] evpn binding vpn-instance evpn1
[*PE1-bd10] quit
[*PE1] commit
Repeat this step for PE2. For configuration details, see Configuration Files in
this section.
2. Configure an ingress replication list on each PE.
# Configure PE1.
[~PE1] interface nve 1
[*PE1-Nve1] source 1.1.1.20
[*PE1-Nve1] bypass source 1.1.1.100
[*PE1-Nve1] mac-address 00e0-fc12-3456
[*PE1-Nve1] vni 10 head-end peer-list protocol bgp
[*PE1-Nve1] quit
[*PE1] commit
Repeat this step for PE2. For configuration details, see Configuration Files in
this section.
Step 4 Configure primary and secondary PWs on the PE-AGG.
# Configure the PE-AGG.
[~PE-AGG] mpls l2vpn
[*PE-AGG-l2vpn] quit
[*PE-AGG] vsi vsi1 bd-mode
[*PE-AGG-vsi1] pwsignal ldp
[*PE-AGG-vsi1-ldp] vsi-id 1
[*PE-AGG-vsi1-ldp] peer 1.1.1.1
[*PE-AGG-vsi1-ldp] peer 2.2.2.2
[*PE-AGG-vsi1-ldp] protect-group 10
[*PE-AGG-vsi1-ldp-protect-group-10] protect-mode pw-redundancy master
[*PE-AGG-vsi1-ldp-protect-group-10] peer 1.1.1.1 preference 1
[*PE-AGG-vsi1-ldp-protect-group-10] peer 2.2.2.2 preference 2
[*PE-AGG-vsi1-ldp-protect-group-10] quit
[*PE-AGG-vsi1-ldp] quit
[*PE-AGG-vsi1] quit

(2020-10-09)
[*PE-AGG] bridge-domain 10
[*PE-AGG-bd10] l2 binding vsi vsi1
[*PE-AGG-bd10] quit
[*PE-AGG] commit
Step 5 Configure PWs on PE1 and PE2 and set the PWs to AC mode.
# Configure PE1.
[~PE1] mpls l2vpn
[*PE1-l2vpn] quit
[*PE1] vsi vsi1 bd-mode
[*PE1-vsi1] pwsignal ldp
[*PE1-vsi1-ldp] vsi-id 1
[*PE1-vsi1-ldp] peer 3.3.3.3 ac-mode
[*PE1-vsi1-ldp] quit
[*PE1-vsi1] quit
[*PE1-bd10] l2 binding vsi vsi1
[*PE1-bd10] quit
[*PE1] commit
section.
Run the display vxlan tunnel command on PE1 and check information about the
VXLAN tunnels.
[~PE1] display vxlan tunnel
-----------------------------------------------------------------------------------
4026531842 1.1.1.100 2.2.2.100 up dynamic 01:31:05
4026531843 1.1.1.20 4.4.4.100 up dynamic 00:32:51
Run the display vsi command on PE1 and check the VSI status.
[~PE1] display vsi
Total VSI number is 1, 1 is up, 0 is down, 1 is LDP mode, 0 is BGP mode, 0 is BGPAD mode, 0 is mixed
mode, 0 is unspecified mode
--------------------------------------------------------------------------
Vsi Mem PW Mac Encap Mtu Vsi
Name Disc Type Learn Type Value State
--------------------------------------------------------------------------
vsi1 -- ldp qualify vlan 1500 up
Run the display vsi name vsi1 protect-group 10 command on the PE-AGG and
check information about the PW protection group in the VSI.
[~PE-AGG] display vsi name vsi1 protect-group 10
Protect-group: 10
-------------------------------------------------------------------------------
PeerIp:VcId Pref Active
-------------------------------------------------------------------------------
1.1.1.1:1 1 Active
2.2.2.2:1 2 Inactive
----End
Configuration Files
#
sysname PE1
#

(2020-10-09)
evpn
bypass-vxlan enable
#
evpn vpn-instance evpn1 bd-mode
#
mpls lsr-id 1.1.1.1
#
mpls
#
mpls l2vpn
#
vsi vsi1 bd-mode
pwsignal ldp
vsi-id 1
peer 3.3.3.3 ac-mode
#
bridge-domain 10
evpn binding vpn-instance evpn1
l2 binding vsi vsi1
#
mpls ldp
#
isis 1
network-entity 10.0000.0000.0001.00
#
undo shutdown
ip address 10.1.14.1 255.255.255.0
isis enable 1
#
undo shutdown
ip address 10.1.13.1 255.255.255.0
mpls
mpls ldp
#
undo shutdown
ip address 10.1.1.1 255.255.255.0
isis enable 1
#
interface LoopBack1
ip address 1.1.1.1 255.255.255.255
#
interface LoopBack2
ip address 1.1.1.100 255.255.255.255
isis enable 1
#
interface LoopBack3
ip address 1.1.1.20 255.255.255.255
isis enable 1
#
interface Nve1
source 1.1.1.20
bypass source 1.1.1.100
mac-address 00e0-fc12-3456
#
bgp 100
#
ipv4-family unicast

(2020-10-09)
#
l2vpn-family evpn
#
ospf 1
area 0.0.0.0
network 1.1.1.1 0.0.0.0
network 10.1.13.0 0.0.0.255
#
return
#
sysname PE2
#
evpn
bypass-vxlan enable
#
evpn vpn-instance evpn1 bd-mode
#
mpls lsr-id 2.2.2.2
#
mpls
#
mpls l2vpn
#
vsi vsi1 bd-mode
pwsignal ldp
vsi-id 1
peer 3.3.3.3 ac-mode
#
bridge-domain 10
evpn binding vpn-instance evpn1
l2 binding vsi vsi1
#
mpls ldp
#
isis 1
network-entity 10.0000.0000.0002.00
#
undo shutdown
ip address 10.2.14.1 255.255.255.0
isis enable 1
#
undo shutdown
ip address 10.2.13.1 255.255.255.0
mpls
mpls ldp
#
undo shutdown
ip address 10.1.1.2 255.255.255.0
isis enable 1
#
interface LoopBack1
ip address 2.2.2.2 255.255.255.255
#

(2020-10-09)
interface LoopBack2
ip address 2.2.2.100 255.255.255.255
isis enable 1
#
interface LoopBack3
ip address 1.1.1.20 255.255.255.255
isis enable 1
#
interface Nve1
source 1.1.1.20
bypass source 2.2.2.100
mac-address 00e0-fc12-3456
#
bgp 100
#
ipv4-family unicast
network 1.1.1.20 255.255.255.255
#
l2vpn-family evpn
#
ospf 1
area 0.0.0.0
network 2.2.2.2 0.0.0.0
network 10.2.13.0 0.0.0.255
#
return
● PE-AGG configuration file
#
sysname PE-AGG
#
mpls lsr-id 3.3.3.3
#
mpls
#
mpls l2vpn
#
vsi vsi1 bd-mode
pwsignal ldp
vsi-id 1
peer 1.1.1.1
peer 2.2.2.2
protect-group 10
#
bridge-domain 10
l2 binding vsi vsi1
#
mpls ldp
#
undo shutdown
ip address 10.1.13.3 255.255.255.0
mpls
mpls ldp

(2020-10-09)
#
undo shutdown
ip address 10.2.13.3 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 3.3.3.3 255.255.255.255
#
ospf 1
area 0.0.0.0
network 3.3.3.3 0.0.0.0
network 10.1.13.0 0.0.0.255
network 10.2.13.0 0.0.0.255
#
return
● TOR configuration file

3.2.36.24 Example for Configuring an EVPN L3VPN HoVPN

This section provides an example for configuring an EVPN L3VPN HoVPN to
implement network interworking.
services, needs to evolve to EVPN L3VPN HVPN. On the network shown in Figure
3-179, the UPE and SPE are connected at the access layer, and the SPE and NPE
are connected at the aggregation layer. Before an EVPN L3VPN HoVPN is deployed
to implement E2E interworking, separate IGPs must be deployed at the access and
aggregation layers to implement interworking at the different layers. On an EVPN
L3VPN HoVPN, a UPE does not have specific routes to NPEs and can only send
implemented. An EVPN L3VPN HoVPN can use devices with relatively poor route
management capabilities as UPEs, reducing network deployment costs.
Figure 3-179 EVPN L3VPN HoVPN

NOTE

(2020-10-09)
1. Deploy IGPs on the UPE, SPE, and NPE. In this example, OSPF runs between
the UPE and SPE, and IS-IS runs between the SPE and NPE.
2. Configure MPLS LDP on the UPE, SPE, and NPE.
3. Create a VPN instance on each of the UPE, SPE, and NPE.
4. Bind the VPN instances to the AC interfaces on the UPE and NPE.
5. Configure a default static route for the VPN instance on the SPE.
6. Configure a route policy on the NPE to prevent the NPE from receiving default
routes.
7. Configure BGP-EVPN peer relationships between the UPE and SPE, and
between the SPE and NPE, and specify the UPE as a lower-level PE of the SPE.
Data Preparation
● MPLS LSR IDs of the UPE (1.1.1.1), SPE (2.2.2.2), and NPE (3.3.3.3)
● VPN instance name (vpn1) and RD (100:1)
● VPN targets 2:2 for EVPN
Procedure
Step 2 Deploy IGPs on the UPE, SPE, and NPE. In this example, OSPF runs between the
UPE and SPE, and IS-IS runs between the SPE and NPE.
Step 3 Configure MPLS LDP on the UPE, SPE, and NPE.

(2020-10-09)
Step 4 Create a VPN instance on each of the UPE, SPE, and NPE.
[*UPE-vpn-instance-vpn1-af-ipv4] vpn-target 2:2 both evpn
[*UPE-vpn-instance-vpn1-af-ipv4] evpn mpls routing-enable
[*UPE] commit

[~SPE] ip vpn-instance vpn1
[*SPE-vpn-instance-vpn1] ipv4-family
[*SPE-vpn-instance-vpn1-af-ipv4] route-distinguisher 100:1
[*SPE-vpn-instance-vpn1-af-ipv4] vpn-target 2:2 both evpn
[*SPE-vpn-instance-vpn1-af-ipv4] evpn mpls routing-enable
[*SPE-vpn-instance-vpn1-af-ipv4] quit
[*SPE-vpn-instance-vpn1] quit
[*SPE] commit

[~NPE] ip vpn-instance vpn1
[*NPE-vpn-instance-vpn1] ipv4-family
[*NPE-vpn-instance-vpn1-af-ipv4] route-distinguisher 100:1
[*NPE-vpn-instance-vpn1-af-ipv4] vpn-target 2:2 both evpn
[*NPE-vpn-instance-vpn1-af-ipv4] evpn mpls routing-enable
[*NPE-vpn-instance-vpn1-af-ipv4] quit
[*NPE-vpn-instance-vpn1] quit
[*NPE] commit
Step 5 Bind the VPN instances to the AC interfaces on the UPE and NPE.
[*UPE] commit

[~NPE] interface GigabitEthernet 2/0/0
[*NPE-GigabitEthernet2/0/0] ip binding vpn-instance vpn1
[*NPE-GigabitEthernet2/0/0] ip address 192.168.30.1 255.255.255.0
[*NPE] commit
Step 6 Configure a default static route on the SPE.

[~SPE] ip route-static vpn-instance vpn1 0.0.0.0 0.0.0.0 NULL0
[*SPE] commit
Step 7 Configure a route policy on the NPE to prevent the NPE from receiving default
routes.
[~NPE] ip ip-prefix default index 10 permit 0.0.0.0 0
[*NPE] route-policy SPE deny node 10
[*NPE-route-policy] if-match ip-prefix default
[*NPE] route-policy SPE permit node 20
[*NPE] ip vpn-instance vpn1
[*NPE-vpn-instance-vpn1-af-ipv4] import route-policy SPE evpn

(2020-10-09)
[*NPE] commit
Step 8 Configure BGP-EVPN peer relationships between the UPE and SPE, and between
the SPE and NPE, and specify the UPE as a lower-level PE of the SPE.
[~UPE] bgp 100
[*UPE-bgp] l2vpn-family evpn
[*UPE-bgp-af-evpn] peer 2.2.2.2 enable
[*UPE-bgp-af-evpn] quit
[*UPE-bgp-vpn1] advertise l2vpn evpn
[*UPE-bgp] quit
[*UPE] commit

[~SPE] bgp 100
[*SPE-bgp] peer 1.1.1.1 as-number 100
[*SPE-bgp] peer 1.1.1.1 connect-interface LoopBack1
[*SPE-bgp] l2vpn-family evpn
[*SPE-bgp-af-evpn] undo policy vpn-target
[*SPE-bgp-af-evpn] peer 1.1.1.1 enable
[*SPE-bgp-af-evpn] peer 1.1.1.1 upe
[*SPE-bgp-af-evpn] quit
[*SPE-bgp] ipv4-family vpn-instance vpn1
[*SPE-bgp-vpn1] advertise l2vpn evpn
[*SPE-bgp-vpn1] network 0.0.0.0 0
[*SPE-bgp-vpn1] quit
[*SPE-bgp] quit
[*SPE] commit

[~NPE] bgp 100
[*NPE-bgp] peer 2.2.2.2 as-number 100
[*NPE-bgp] peer 2.2.2.2 connect-interface LoopBack1
[*NPE-bgp] l2vpn-family evpn
[*NPE-bgp-af-evpn] peer 2.2.2.2 enable
[*NPE-bgp-af-evpn] quit
[*NPE-bgp] ipv4-family vpn-instance vpn1
[*NPE-bgp-vpn1] advertise l2vpn evpn
[*NPE-bgp-vpn1] import-route direct
[*NPE-bgp-vpn1] quit
[*NPE-bgp] quit
[*NPE] commit

Run the display bgp evpn all routing-table command on the NPE. The command
output shows the EVPN routes received from the UPE.
[~NPE] display bgp evpn all routing-table


(2020-10-09)

*>i 0:0.0.0.0:0 2.2.2.2
*>i 0:192.168.20.0:24 2.2.2.2
*> 0:192.168.30.0:24 0.0.0.0
Run the display ip routing-table vpn-instance vpn1 command on the NPE. The
command output shows the VPN routes.
[~NPE] display ip routing-table vpn-instance vpn1
------------------------------------------------------------------------------

192.168.30.0/24 Direct 0 0 RD 192.168.30.1 GigabitEthernet2/0/0
Run the display bgp evpn all routing-table command on the UPE. The command
output shows the default EVPN routes received from the SPE.
[~UPE] display bgp evpn all routing-table


*>i 0:0.0.0.0:0 2.2.2.2
*> 0:192.168.20.0:24 0.0.0.0
Run the display ip routing-table vpn-instance vpn1 command on the UPE. The
command output shows the default VPN routes.
[~UPE] display ip routing-table vpn-instance vpn1
------------------------------------------------------------------------------

----End

(2020-10-09)
Configuration Files
#
sysname UPE
#
ipv4-family
#
mpls lsr-id 1.1.1.1
#
mpls
#
mpls ldp
#
undo shutdown
ip address 10.1.1.1 255.255.255.0
mpls
mpls ldp
#
undo shutdown
ip address 192.168.20.1 255.255.255.0
#
interface LoopBack1
ip address 1.1.1.1 255.255.255.255
#
bgp 100
#
ipv4-family unicast
peer 2.2.2.2 enable
#
import-route direct
#
l2vpn-family evpn
policy vpn-target
peer 2.2.2.2 enable
#
ospf 1
area 0.0.0.0
network 1.1.1.1 0.0.0.0
network 10.1.1.0 0.0.0.255
#
return

#
sysname SPE
#
ipv4-family
#

(2020-10-09)
mpls lsr-id 2.2.2.2

#
mpls
#
mpls ldp
#
isis 1
network-entity 10.0000.0000.0002.00
#
undo shutdown
ip address 10.1.1.2 255.255.255.0
mpls
mpls ldp
#
undo shutdown
ip address 10.2.1.1 255.255.255.0
isis enable 1
mpls
mpls ldp
#
interface LoopBack1
ip address 2.2.2.2 255.255.255.255
isis enable 1
#
bgp 100
#
ipv4-family unicast
peer 1.1.1.1 enable
peer 3.3.3.3 enable
#
network 0.0.0.0
#
l2vpn-family evpn
peer 1.1.1.1 enable
peer 1.1.1.1 upe
peer 3.3.3.3 enable
#
ospf 1
area 0.0.0.0
network 2.2.2.2 0.0.0.0
network 10.1.1.0 0.0.0.255
#
ip route-static vpn-instance vpn1 0.0.0.0 0.0.0.0 NULL0
#
return
#
sysname NPE
#
ipv4-family
import route-policy SPE evpn
#
mpls lsr-id 3.3.3.3

(2020-10-09)
#
mpls
#
mpls ldp
#
isis 1
network-entity 10.0000.0000.0003.00
#
undo shutdown
ip address 10.2.1.2 255.255.255.0
isis enable 1
mpls
mpls ldp
#
undo shutdown
ip address 192.168.30.1 255.255.255.0
#
interface LoopBack1
ip address 3.3.3.3 255.255.255.255
isis enable 1
#
bgp 100
#
ipv4-family unicast
peer 2.2.2.2 enable
#
import-route direct
#
l2vpn-family evpn
policy vpn-target
peer 2.2.2.2 enable
#
route-policy SPE deny node 10
if-match ip-prefix default
#
route-policy SPE permit node 20
#
ip ip-prefix default index 10 permit 0.0.0.0 0
#
return
3.2.36.25 Example for Configuring an EVPN L3VPN H-VPN

This section provides an example for configuring an EVPN L3VPN H-VPN to
implement network interworking.
services, needs to evolve to EVPN L3VPN HVPN. On the network shown in Figure
3-180, the UPE and SPE are connected at the access layer, and the SPE and NPE
are connected at the aggregation layer. Before an EVPN L3VPN H-VPN is deployed
to implement E2E interworking, separate IGPs must be deployed at the access and
aggregation layers to implement interworking at the different layers. On an EVPN

(2020-10-09)
L3VPN H-VPN, UPEs function as RR clients to receive the specific routes reflected
by SPEs functioning as RRs. This mechanism facilitates route management and
traffic forwarding control.
Figure 3-180 EVPN L3VPN H-VPN

NOTE
3. Create a VPN instance on each of the UPE and NPE.
5. Configure BGP-EVPN peer relationships between the UPE and SPE, and
6. On the SPE, specify the UPE as the BGP-EVPN RR client, and configure the
SPE to use its own IP address as the next hop of BGP EVPN routes being
advertised to the peer.
Data Preparation
● VPN targets 2:2 for EVPN

(2020-10-09)
Procedure
Step 4 Create a VPN instance on each of the UPE and NPE.
[*UPE] commit

[*NPE] commit
[*UPE] commit

[*NPE] commit
Step 6 Configure BGP-EVPN peer relationships between the UPE and SPE, and between
the SPE and NPE.
[~UPE] bgp 100

(2020-10-09)
[*UPE-bgp] quit
[*UPE] commit

[~SPE] bgp 100
[*SPE-bgp] quit
[*SPE] commit

[~NPE] bgp 100
[*NPE-bgp] quit
[*NPE] commit
Step 7 On the SPE, specify the UPE as the BGP-EVPN RR client, and configure the SPE to
use its own IP address as the next hop of BGP EVPN routes being advertised to the
peer.
[~SPE] bgp 100
[*SPE-bgp-af-evpn] peer 1.1.1.1 reflect-client
[*SPE-bgp-af-evpn] peer 1.1.1.1 next-hop-local
[*SPE-bgp-af-evpn] peer 3.3.3.3 reflect-client
[*SPE-bgp-af-evpn] peer 3.3.3.3 next-hop-local
[*SPE-bgp] quit
[*SPE] commit

Run the display bgp evpn all routing-table command on the NPE and UPE. The
command output shows the EVPN routes received from the remote end. The
following example uses the command output on the NPE.


(2020-10-09)

*>i 0:192.168.20.0:24 2.2.2.2
*> 0:192.168.30.0:24 0.0.0.0
Run the display ip routing-table vpn-instance vpn1 command on the NPE and
UPE. The command output shows the VPN routes received from the remote end.
The following example uses the command output on the NPE.
------------------------------------------------------------------------------

----End
Configuration Files
#
sysname UPE
#
ipv4-family
#
mpls lsr-id 1.1.1.1
#
mpls
#
mpls ldp
#
undo shutdown
ip address 10.1.1.1 255.255.255.0
mpls
mpls ldp
#
undo shutdown
ip address 192.168.20.1 255.255.255.0
#
interface LoopBack1
ip address 1.1.1.1 255.255.255.255
#
bgp 100
#
ipv4-family unicast

(2020-10-09)
peer 2.2.2.2 enable

#
import-route direct
#
l2vpn-family evpn
policy vpn-target
peer 2.2.2.2 enable
#
ospf 1
area 0.0.0.0
network 1.1.1.1 0.0.0.0
network 10.1.1.0 0.0.0.255
#
return
#
sysname SPE
#
mpls lsr-id 2.2.2.2
#
mpls
#
mpls ldp
#
isis 1
network-entity 10.0000.0000.0002.00
#
undo shutdown
ip address 10.1.1.2 255.255.255.0
mpls
mpls ldp
#
undo shutdown
ip address 10.2.1.1 255.255.255.0
isis enable 1
mpls
mpls ldp
#
interface LoopBack1
ip address 2.2.2.2 255.255.255.255
isis enable 1
#
bgp 100
#
ipv4-family unicast
peer 1.1.1.1 enable
peer 3.3.3.3 enable
#
l2vpn-family evpn
peer 1.1.1.1 enable
peer 1.1.1.1 next-hop-local
peer 3.3.3.3 enable
peer 3.3.3.3 next-hop-local
#
ospf 1
area 0.0.0.0
network 2.2.2.2 0.0.0.0

(2020-10-09)
network 10.1.1.0 0.0.0.255

#
return

#
sysname NPE
#
ipv4-family
#
mpls lsr-id 3.3.3.3
#
mpls
#
mpls ldp
#
isis 1
network-entity 10.0000.0000.0003.00
#
undo shutdown
ip address 10.2.1.2 255.255.255.0
isis enable 1
mpls
mpls ldp
#
undo shutdown
ip address 192.168.30.1 255.255.255.0
#
interface LoopBack1
ip address 3.3.3.3 255.255.255.255
isis enable 1
#
bgp 100
#
ipv4-family unicast
peer 2.2.2.2 enable
#
import-route direct
#
l2vpn-family evpn
policy vpn-target
peer 2.2.2.2 enable
#
return
3.2.36.26 Example for Splicing an EVPN L3VPN HoVPN with a Common

L3VPN
This section provides an example for splicing an EVPN L3VPN HoVPN with a
common L3VPN to implement network interworking.

(2020-10-09)
services, needs to evolve to EVPN L3VPN HVPN. During evolution, if a lot of
devices are deployed on the network, end-to-end evolution may not be
implemented at a time. As a result, co-existence of the L3VPN and EVPN occurs.
On the network shown in Figure 3-181, the UPE and SPE are connected at the
access layer, and the SPE and NPE are connected at the aggregation layer.
Separate IGPs are deployed at the access and aggregation layers to implement
interworking at the different layers. An EVPN L3VPN HoVPN is deployed between
the UPE and SPE, and a common L3VPN is deployed between the SPE and NPE.
The SPE advertises only default EVPN routes to the UPE. After receiving specific
routes (EVPN routes) from the UPE, the SPE encapsulates these routes into VPNv4
routes and advertises them to the NPE.
Figure 3-181 Splicing between an EVPN L3VPN HoVPN and a common L3VPN
NOTE
routes.

(2020-10-09)
7. Configure a BGP-VPNv4 peer relationship between the SPE and NPE.

8. Configure a BGP-EVPN peer relationship between the UPE and SPE, specify
the UPE as a lower-level PE of the SPE and configure the UPE to import the
default VPN route.
9. Configure route regeneration on the SPE.
Data Preparation
● VPN targets 1:1 (import and export) of vpn1 and 2:2 for EVPN
Procedure
[*UPE] commit

[*SPE-vpn-instance-vpn1-af-ipv4] vpn-target 1:1 both
[*SPE] commit

[*NPE-vpn-instance-vpn1-af-ipv4] vpn-target 1:1 both

(2020-10-09)
[*NPE] commit

[*UPE] commit

[*NPE] commit

[*SPE] commit
routes.
[*NPE-vpn-instance-vpn1-af-ipv4] import route-policy SPE
[*NPE] commit
Step 8 Configure a BGP-VPNv4 peer relationship between the SPE and NPE.

[~SPE] bgp 100
[*SPE-bgp] quit
[*SPE] commit

[~NPE] bgp 100
[*NPE-bgp-af-vpnv4] peer 2.2.2.2 enable
[*NPE-bgp] quit
[*NPE] commit

(2020-10-09)
Step 9 Configure a BGP-EVPN peer relationship between the UPE and SPE, specify the
UPE as a lower-level PE of the SPE and configure the UPE to import the default
VPN route.

[~UPE] bgp 100
[*UPE-bgp] quit
[*UPE] commit

[~SPE] bgp 100
[*SPE-bgp-af-evpn] peer 1.1.1.1 upe
[*SPE-bgp] quit
[*SPE] commit
Step 10 Configure route regeneration on the SPE.

[~SPE] bgp 100
[*SPE-bgp-af-vpnv4] peer 3.3.3.3 advertise route-reoriginated evpn ip
[*SPE-bgp-af-evpn] peer 1.1.1.1 import reoriginate
[*SPE-bgp] quit
[*SPE] commit
command output shows the VPN routes.
------------------------------------------------------------------------------


(2020-10-09)
Run the display bgp evpn all routing-table command on the UPE. The command
output shows the default EVPN routes received from the SPE.
[~UPE] display bgp evpn all routing-table


*>i 0:0.0.0.0:0 2.2.2.2
*> 0:192.168.20.0:24 0.0.0.0
command output shows the default VPN routes received from the SPE.
------------------------------------------------------------------------------

----End
Configuration Files
#
sysname UPE
#
ipv4-family
#
mpls lsr-id 1.1.1.1
#
mpls
#
mpls ldp
#
undo shutdown
ip address 10.1.1.1 255.255.255.0
mpls
mpls ldp
#

(2020-10-09)
undo shutdown
ip address 192.168.20.1 255.255.255.0
#
interface LoopBack1
ip address 1.1.1.1 255.255.255.255
#
bgp 100
#
ipv4-family unicast
peer 2.2.2.2 enable
#
import-route direct
#
l2vpn-family evpn
policy vpn-target
peer 2.2.2.2 enable
#
ospf 1
area 0.0.0.0
network 1.1.1.1 0.0.0.0
network 10.1.1.0 0.0.0.255
#
return
#
sysname SPE
#
ipv4-family
#
mpls lsr-id 2.2.2.2
#
mpls
#
mpls ldp
#
isis 1
network-entity 10.0000.0000.0002.00
#
undo shutdown
ip address 10.1.1.2 255.255.255.0
mpls
mpls ldp
#
undo shutdown
ip address 10.2.1.1 255.255.255.0
isis enable 1
mpls
mpls ldp
#
interface LoopBack1
ip address 2.2.2.2 255.255.255.255
isis enable 1
#

(2020-10-09)
bgp 100
#
ipv4-family unicast
peer 1.1.1.1 enable
peer 3.3.3.3 enable
#
ipv4-family vpnv4
peer 3.3.3.3 enable
#
network 0.0.0.0
#
l2vpn-family evpn
peer 1.1.1.1 enable
peer 1.1.1.1 upe
#
ospf 1
area 0.0.0.0
network 2.2.2.2 0.0.0.0
network 10.1.1.0 0.0.0.255
#
#
return
#
sysname NPE
#
ipv4-family
import route-policy SPE
#
mpls lsr-id 3.3.3.3
#
mpls
#
mpls ldp
#
isis 1
network-entity 10.0000.0000.0003.00
#
undo shutdown
ip address 10.2.1.2 255.255.255.0
isis enable 1
mpls
mpls ldp
#
undo shutdown
ip address 192.168.30.1 255.255.255.0
#
interface LoopBack1
ip address 3.3.3.3 255.255.255.255

(2020-10-09)
isis enable 1
#
bgp 100
#
ipv4-family unicast
peer 2.2.2.2 enable
#
ipv4-family vpnv4
policy vpn-target
peer 2.2.2.2 enable
#
import-route direct
#
#
#
#
return
3.2.36.27 Example for Splicing an L3VPN HoVPN with an EVPN L3VPN

This section provides an example for splicing an L3VPN HoVPN with an EVPN
L3VPN to implement network interworking.
services, needs to evolve to EVPN L3VPN HVPN. During evolution, if a lot of
devices are deployed on the network, end-to-end evolution may not be
implemented at a time. As a result, co-existence of the L3VPN and BD EVPN
L3VPN occurs. On the network shown in Figure 3-182, the UPE and SPE are
connected at the access layer, and the SPE and NPE are connected at the
aggregation layer. Separate IGPs are deployed at the access and aggregation
layers to implement interworking at the different layers. An L3VPN HoVPN is
deployed between the UPE and SPE, and an EVPN L3VPN is deployed between the
SPE and NPE. The SPE advertises only default L3VPN routes to the UPE. After
receiving specific routes (L3VPN routes) from the UPE, the SPE encapsulates these
routes into EVPN routes and advertises them to the NPE.
Figure 3-182 Splicing between an L3VPN HoVPN and an EVPN L3VPN

NOTE

(2020-10-09)
routes.
7. Configure a BGP-EVPN peer relationship between the SPE and NPE.
8. Configure a BGP-VPNv4 peer relationship between the UPE and SPE, specify
the UPE as the lower-level PE of the SPE, and configure the UPE to import the
default VPN route.
9. Configure route regeneration on the SPE.
Data Preparation
● VPN targets 1:1 (import and export) of vpn1 and 2:2 for EVPN
Procedure

(2020-10-09)

[*UPE] commit

[*SPE-vpn-instance-vpn1-af-ipv4] vpn-target 1:1 both
[*SPE] commit

[*NPE-vpn-instance-vpn1-af-ipv4] vpn-target 1:1 both
[*NPE] commit
[*UPE] commit

[*NPE] commit

[*SPE] commit
routes.

(2020-10-09)

[*NPE-vpn-instance-vpn1-af-ipv4] import route-policy SPE evpn
[*NPE] commit
Step 8 Configure a BGP-EVPN peer relationship between the SPE and NPE.
[~SPE] bgp 100
[*SPE-bgp] quit
[*SPE] commit

[~NPE] bgp 100
[*NPE-bgp] quit
[*NPE] commit
Step 9 Configure a BGP-VPNv4 peer relationship between the UPE and SPE, specify the
UPE as the lower-level PE of the SPE, and configure the SPE to import default VPN
routes.
[~UPE] bgp 100
[*UPE-bgp] quit
[*UPE] commit

[~SPE] bgp 100
[*SPE-bgp-af-vpnv4] peer 1.1.1.1 upe

(2020-10-09)

[*SPE-bgp] quit
[*SPE] commit
Step 10 Configure route regeneration on the SPE.

[~SPE] bgp 100
[*SPE-bgp-af-vpnv4] peer 1.1.1.1 import reoriginate
[*SPE-bgp-af-evpn] peer 3.3.3.3 advertise route-reoriginated vpnv4
[*SPE-bgp] quit
[*SPE] commit

Run the display bgp evpn all routing-table command on the NPE. The command
output shows the EVPN routes received from the UPE.


*>i 0:0.0.0.0:0 2.2.2.2
*>i 0:192.168.20.0:24 2.2.2.2
*> 0:192.168.30.0:24 0.0.0.0
command output shows the VPN routes received from the UPE.
------------------------------------------------------------------------------

command output shows the default VPN routes.
------------------------------------------------------------------------------

(2020-10-09)

----End
Configuration Files
#
sysname UPE
#
ipv4-family
#
mpls lsr-id 1.1.1.1
#
mpls
#
mpls ldp
#
undo shutdown
ip address 10.1.1.1 255.255.255.0
mpls
mpls ldp
#
undo shutdown
ip address 192.168.20.1 255.255.255.0
#
interface LoopBack1
ip address 1.1.1.1 255.255.255.255
#
bgp 100
#
ipv4-family unicast
peer 2.2.2.2 enable
#
ipv4-family vpnv4
policy vpn-target
peer 2.2.2.2 enable
#
import-route direct
#
ospf 1
area 0.0.0.0
network 1.1.1.1 0.0.0.0
network 10.1.1.0 0.0.0.255
#
return

#
sysname SPE
#

(2020-10-09)
ipv4-family
#
mpls lsr-id 2.2.2.2
#
mpls
#
mpls ldp
#
isis 1
network-entity 10.0000.0000.0002.00
#
undo shutdown
ip address 10.1.1.2 255.255.255.0
mpls
mpls ldp
#
undo shutdown
ip address 10.2.1.1 255.255.255.0
isis enable 1
mpls
mpls ldp
#
interface LoopBack1
ip address 2.2.2.2 255.255.255.255
isis enable 1
#
bgp 100
#
ipv4-family unicast
peer 1.1.1.1 enable
peer 3.3.3.3 enable
#
ipv4-family vpnv4
peer 1.1.1.1 enable
peer 1.1.1.1 upe
#
network 0.0.0.0
#
l2vpn-family evpn
peer 3.3.3.3 enable
#
ospf 1
area 0.0.0.0
network 2.2.2.2 0.0.0.0
network 10.1.1.0 0.0.0.255
#

(2020-10-09)
#
return

#
sysname NPE
#
ipv4-family
import route-policy SPE evpn
#
mpls lsr-id 3.3.3.3
#
mpls
#
mpls ldp
#
isis 1
network-entity 10.0000.0000.0003.00
#
undo shutdown
ip address 10.2.1.2 255.255.255.0
isis enable 1
mpls
mpls ldp
#
undo shutdown
ip address 192.168.30.1 255.255.255.0
#
interface LoopBack1
ip address 3.3.3.3 255.255.255.255
isis enable 1
#
bgp 100
#
ipv4-family unicast
peer 2.2.2.2 enable
#
import-route direct
#
l2vpn-family evpn
policy vpn-target
peer 2.2.2.2 enable
#
#
#
#
return

(2020-10-09)
3.2.36.28 Example for Configuring IGMP Snooping over EVPN MPLS

On a network where an EVPN carries multicast services, to reduce redundant
traffic and conserve bandwidth resources, configure EVPN to use an mLDP P2MP
Context
On the network shown in Figure 3-183, EVPN is deployed on PEs to carry Layer 2
multicast services. PE1 is the root node, and PE2 and PE3 are leaf nodes. The
multicast source and the receiver are on the access side. By default, when the
EVPN function is deployed on a network to carry Layer 2 multicast services,
multicast data packets are broadcast on the network. The devices that do not
need to receive the multicast data packets also receive these packets, which
wastes network bandwidth resources. To resolve this issue, deploy IGMP snooping
over EVPN MPLS. After IGMP snooping over EVPN MPLS is deployed, IGMP
snooping packets are transmitted on the network through EVPN routes, and
multicast forwarding entries are generated on devices. Multicast data packets
from a multicast source are advertised only to the devices that need these packets,
conserving network bandwidth resources.
Figure 3-183 Configuring IGMP snooping over EVPN MPLS

NOTE

(2020-10-09)
Configuration Notes
When configuring IGMP snooping over EVPN MPLS, note the following:
communicate.
2. Configure MPLS and mLDP P2MP on the backbone network and set up an
mLDP P2MP tunnel.
3. Create an EVPN instance in BD mode and a BD on each PE, and bind the BD
to the EVPN instance on each PE.
7. Configure BGP EVPN peer relationships between the PEs and RR, and on the
RR, specify the PEs as RR clients.
8. Configure EVPN to use an mLDP P2MP tunnel for service transmission on
each PE.
9. Configure IGMP snooping over EVPN MPLS on each PE.
Data Preparation
Procedure
# Configure PE1.
[~PE1] ospf 1
[~PE1-ospf-1] quit

(2020-10-09)
# Configure PE2.
[~PE2] ospf 1
[~PE2-ospf-1] quit
# Configure PE3.
[~PE3] ospf 1
[~PE3-ospf-1] quit
# Configure the RR.

[~RR] ospf 1
[*RR-ospf-1] area 0
[~RR-ospf-1] quit
Step 3 Configure MPLS and mLDP P2MP on the backbone network and set up an mLDP
P2MP tunnel.
# Configure PE1.
[*PE1] mpls
[*PE1-mpls] quit
[*PE1] mpls ldp
# Configure PE2.
[*PE2] mpls
[*PE2-mpls] quit
[*PE2] mpls ldp
# Configure the RR.

[*RR] mpls
[*RR-mpls] quit
[*RR] mpls ldp

(2020-10-09)
[*RR-mpls-ldp] mldp p2mp

[*RR-mpls-ldp] quit
# Configure PE3.
[*PE3] mpls
[*PE3-mpls] quit
[*PE3] mpls ldp

# Configure PE1.
[*PE1-bd10] quit
[*PE1] commit
# Configure PE2.
[*PE2-bd10] quit
[*PE2] commit
# Configure PE3.
[*PE3-bd10] quit
[*PE3] commit

# Configure PE1.

(2020-10-09)
[*PE1] commit
# Configure PE2.
[*PE2] commit
# Configure PE3.
[*PE3] commit

# Configure PE1.
[*PE1] commit
# Configure PE2.
[*PE2] e-trunk 1
[*PE2] commit
# Configure PE3.
[*PE3] e-trunk 1

(2020-10-09)

[*PE3] commit

# Configure PE2.
[*PE2-Eth-Trunk10] esi 0000.1111.2222.4444.5555
[*PE2-Eth-Trunk20] esi 0000.2222.2222.3333.4444
[*PE2] commit
# Configure PE3.
[*PE3-Eth-Trunk10] esi 0000.1111.3333.4444.5555
[*PE3-Eth-Trunk20] esi 0000.2222.3333.3333.4444
[*PE3] commit
Step 8 Configure BGP EVPN peer relationships between the PEs and RR, and on the RR,
specify the PEs as RR clients.
# Configure PE1.
[~PE1] bgp 100
[*PE1-bgp] quit
[*PE1] commit
# Configure PE2.
[~PE2] bgp 100
[*PE2-bgp] quit
[*PE2] commit
# Configure PE3.
[~PE3] bgp 100

(2020-10-09)

[*PE3-bgp] quit
[*PE3] commit
# Configure the RR.

[~RR] bgp 100
[*RR-bgp] quit
[*RR] commit


1.1.1.1 4 100 231 253 0 03:07:26 Established 6
2.2.2.2 4 100 231 256 0 03:07:44 Established 6
4.4.4.4 4 100 232 254 0 03:07:54 Established 6
Step 9 Configure EVPN to use an mLDP P2MP tunnel for service transmission on each PE.
# Configure PE1.
[*PE1-evpn-instance-evrf1-inclusive] root
[*PE1-evpn-instance-evrf1-inclusive-root] mldp p2mp
[*PE1-evpn-instance-evrf1-inclusive-root-mldpp2mp] root-ip 1.1.1.1
[*PE1-evpn-instance-evrf1-inclusive-root-mldpp2mp] quit
[*PE1-evpn-instance-evrf1-inclusive-root] quit
[*PE1-evpn-instance-evrf1-inclusive] quit
[*PE1] commit
# Configure PE2.
[*PE2] commit
# Configure PE3.

(2020-10-09)
[*PE3] commit
Step 10 Configure IGMP snooping over EVPN MPLS on each PE.

# Configure PE1.
[~PE1] igmp-snooping enable
[*PE1-bd10] igmp-snooping enable
[*PE1-bd10] igmp-snooping proxy
[*PE1-bd10] igmp-snooping signal-synch enable
[*PE1-bd10] evi vpn-target 100:1
[*PE1-bd10] quit
[*PE1] commit
# Configure PE2.
[*PE2-bd10] quit
[*PE2] commit
# Configure PE3.
[*PE3-bd10] quit
[*PE3] commit

verbose command on PE1. The command output shows information related to the
root node.
Bridge-domain : 10
PMSI type : P2MP mLDP
Root ip : 1.1.1.1
Opaque value : 01000400008001
State : up

verbose command on PE2 or PE3. The command output shows information
related to the leaf node. The command output on PE2 is used as an example.

(2020-10-09)

Bridge-domain : 10
*PMSI type : P2MP mLDP
Root ip : 1.1.1.1
Opaque value : 01000400008001
State : up
Run the display bgp evpn all routing-table join-route command on each PE.
The command output shows Join route information. The command output on PE1
is used as an example.
[~PE1] display bgp evpn all routing-table join-route


Number of IGMP Join Synch Routes: 2
Network(ESI/EthTagId/IpAddrLen/SAddr/IpAddrLen/GAddr/IpAddrLen/OAddr)
NextHop
*> 0000.1111.2222.4444.5555:0:0:0.0.0.0:32:225.0.0.1:32:1.1.1.1 127.0.0.1
*> 0000.1111.3333.4444.5555:0:0:0.0.0.0:32:225.0.0.1:32:1.1.1.1 127.0.0.1
Number of IGMP Join Synch Routes: 1
Network(ESI/EthTagId/IpAddrLen/SAddr/IpAddrLen/GAddr/IpAddrLen/OAddr)
NextHop
*> 0000.1111.2222.4444.5555:0:0:0.0.0.0:32:225.0.0.1:32:1.1.1.1 127.0.0.1
*> 0000.1111.3333.4444.5555:0:0:0.0.0.0:32:225.0.0.1:32:1.1.1.1 127.0.0.1
----End
Configuration Files
#
sysname PE1
#
igmp-snooping enable
#
root
mldp p2mp
root-ip 1.1.1.1
#
mpls lsr-id 1.1.1.1
#
mpls
#
bridge-domain 10
igmp-snooping proxy

(2020-10-09)
igmp-snooping signal-synch enable

evi vpn-target 100:1 export-extcommunity
evi vpn-target 100:1 import-extcommunity
#
mpls ldp
mldp p2mp
#
#
rewrite pop single
bridge-domain 10
#
undo shutdown
eth-trunk 10
#
undo shutdown
ip address 10.1.1.1 255.255.255.0
mpls
mpls ldp
#
interface LoopBack0
ip address 1.1.1.1 255.255.255.255
#
bgp 100
#
ipv4-family unicast
peer 3.3.3.3 enable
#
l2vpn-family evpn
peer 3.3.3.3 enable
#
ospf 1
area 0.0.0.0
network 1.1.1.1 0.0.0.0
network 10.1.1.0 0.0.0.255
#
#
return
#
sysname PE2
#
#
leaf
#
mpls lsr-id 2.2.2.2
#
mpls
#
bridge-domain 10
igmp-snooping proxy

(2020-10-09)

#
mpls ldp
mldp p2mp
#
e-trunk 1
#
esi 0000.1111.2222.4444.5555
#
rewrite pop single
bridge-domain 10
#
esi 0000.2222.2222.3333.4444
e-trunk 1
#
rewrite pop single
bridge-domain 10
#
undo shutdown
ip address 10.2.1.1 255.255.255.0
mpls
mpls ldp
#
undo shutdown
eth-trunk 10
#
interface gigabitethernet 3/0/0
undo shutdown
eth-trunk 20
#
interface LoopBack0
ip address 2.2.2.2 255.255.255.255
#
bgp 100
#
ipv4-family unicast
peer 3.3.3.3 enable
#
l2vpn-family evpn
peer 3.3.3.3 enable
#
ospf 1
area 0.0.0.0
network 2.2.2.2 0.0.0.0
network 10.2.1.0 0.0.0.255
#
#
return
#
sysname PE3
#

(2020-10-09)
#
leaf
#
mpls lsr-id 4.4.4.4
#
mpls
#
bridge-domain 10
igmp-snooping proxy
#
mpls ldp
mldp p2mp
#
e-trunk 1
#
esi 0000.1111.3333.4444.5555
#
rewrite pop single
bridge-domain 10
#
esi 0000.2222.3333.3333.4444
e-trunk 1
#
rewrite pop single
bridge-domain 10
#
undo shutdown
ip address 10.3.1.1 255.255.255.0
mpls
mpls ldp
#
undo shutdown
eth-trunk 10
#
interface gigabitethernet 3/0/0
undo shutdown
eth-trunk 20
#
interface LoopBack0
ip address 4.4.4.4 255.255.255.255
#
bgp 100
#
ipv4-family unicast
peer 3.3.3.3 enable
#

(2020-10-09)
l2vpn-family evpn
peer 3.3.3.3 enable
#
ospf 1
area 0.0.0.0
network 4.4.4.4 0.0.0.0
network 10.3.1.0 0.0.0.255
#
#
return
#
sysname RR
#
mpls lsr-id 3.3.3.3
#
mpls
#
mpls ldp
mldp p2mp
#
undo shutdown
ip address 10.1.1.2 255.255.255.0
mpls
mpls ldp
#
undo shutdown
ip address 10.2.1.2 255.255.255.0
mpls
mpls ldp
#
undo shutdown
ip address 10.3.1.2 255.255.255.0
mpls
mpls ldp
#
interface LoopBack0
ip address 3.3.3.3 255.255.255.255
#
bgp 100
#
ipv4-family unicast
peer 1.1.1.1 enable
peer 2.2.2.2 enable
peer 4.4.4.4 enable
#
l2vpn-family evpn
peer 1.1.1.1 enable
peer 2.2.2.2 enable
peer 4.4.4.4 enable
#
ospf 1
area 0.0.0.0

(2020-10-09)
network 3.3.3.3 0.0.0.0

network 10.1.1.0 0.0.0.255
network 10.2.1.0 0.0.0.255
network 10.3.1.0 0.0.0.255
#
return
#
sysname CE1
#
bridge-domain 10
#
#
bridge-domain 10
#
undo shutdown
eth-trunk 10
#
undo shutdown
#
bridge-domain 10
#
return
#
sysname CE2
#
bridge-domain 10
#
#
bridge-domain 10
#
undo shutdown
eth-trunk 10
#
undo shutdown
#
bridge-domain 10
#
return
#
sysname CE3
#
bridge-domain 10
#
#
bridge-domain 10
#

(2020-10-09)
undo shutdown
eth-trunk 10
#
undo shutdown
#
bridge-domain 10
#
return
3.2.36.29 Example for Configuring BD EVPN IRB over SR-MPLS TE

This section provides an example for configuring BD EVPN IRB over SR-MPLS TE.
On the network shown in Figure 3-184, the EVPN and VPN functions are
configured to transmit Layer 2 and Layer 3 traffic to allow communication
between different sites on the backbone network. If Site 1 and Site 2 are
connected through the same subnet, create an EVPN instance on each PE to store
EVPN routes. Layer 2 forwarding is based on an EVPN route that matches a MAC
address. If Site 1 and Site 2 are connected through different subnets, create a VPN
instance on each PE to store VPN routes. In this situation, Layer 2 traffic is
terminated, and Layer 3 traffic is forwarded through a Layer 3 gateway. In this
Figure 3-184 Networking of BD EVPN IRB over SR-MPLS TE

NOTE
Interface 1, interface 2, and sub-interface 1.1 in this example represent GE 1/0/0, GE 2/0/0, and
GE 1/0/0.1, respectively.

(2020-10-09)
Configuration Notes
When configuring BD EVPN IRB over SR-MPLS TE, note the following:
● On the same EVPN instance, the export VPN target list of a site shares VPN
other sites.
is recommended.
3. Configure an EVPN instance and a VPN instance on each PE.
5. Configure the Layer 2 Ethernet sub-interfaces connecting PEs and CEs.
6. Configure a vBDIF interface on each PE and bind the vBDIF interface to a VPN
instance.
7. Configure and apply a tunnel policy so that EVPN can recurse to SR-MPLS TE
tunnels.
9. Configure CEs to communicate with PEs.
Data Preparation
● EVPN instance name (evrf1) and VPN instance name (vpn1)
● EVPN instance evrf1's RD (100:1) and RT (1:1) on PE1, EVPN instance evrf1's
RD (200:1) and RT (1:1) on PE2, VPN instance vpn1's RD (100:2) and RT (2:2)
on PE1, and VPN instance vpn1's

New IP Technologies PDF

Uploaded by

Copyright:

Available Formats

You might also like

New IP Technologies PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

New IP Technologies PDF

Uploaded by

Copyright:

Available Formats

New IP Technologies

HUAWEI TECHNOLOGIES CO., LTD.

Trademarks and Permissions

Huawei Technologies Co., Ltd.

Issue draft 07 Copyright © Huawei Technologies Co., Ltd. i

1 Segment Routing MPLS......................................................................................................... 1

Issue draft 07 Copyright © Huawei Technologies Co., Ltd. ii

1.1.2.10.2 Traffic Steering into an SR-MPLS TE Policy.................................................................................................... 87

Issue draft 07 Copyright © Huawei Technologies Co., Ltd. iii

1.2.7.1 Enabling MPLS TE........................................................................................................................................................158

Issue draft 07 Copyright © Huawei Technologies Co., Ltd. iv

1.2.13.1 Setting a Binding SID............................................................................................................................................... 193

Issue draft 07 Copyright © Huawei Technologies Co., Ltd. v

1.2.38 Redirecting a Public IPv4 BGP FlowSpec Route to an SR-MPLS TE Policy................................................273

2 Segment Routing IPv6....................................................................................................... 600

Issue draft 07 Copyright © Huawei Technologies Co., Ltd. vi

2.1.1 Overview of Segment Routing IPv6..........................................................................................................................600

Issue draft 07 Copyright © Huawei Technologies Co., Ltd. vii

2.2.4.6 Configuring Public IPv6 over SRv6 BE.................................................................................................................. 722

Issue draft 07 Copyright © Huawei Technologies Co., Ltd. viii

2.2.19.1 Configuring Basic SRv6 SFC Functions............................................................................................................... 809

Issue draft 07 Copyright © Huawei Technologies Co., Ltd. ix

3.1.1 Overview of EVPN........................................................................................................................................................ 1146

Issue draft 07 Copyright © Huawei Technologies Co., Ltd. x

Issue draft 07 Copyright © Huawei Technologies Co., Ltd. xi

3.2.20 Splicing a VLL with an MPLS EVPN E-Line........................................................................................................ 1389

Issue draft 07 Copyright © Huawei Technologies Co., Ltd. xii

3.2.31.4 Associating an L2VE Interface with a BD....................................................................................................... 1439

Issue draft 07 Copyright © Huawei Technologies Co., Ltd. xiii

Issue draft 07 Copyright © Huawei Technologies Co., Ltd. xiv

4.1.2 VXLAN Basics..................................................................................................................................................................2035

Issue draft 07 Copyright © Huawei Technologies Co., Ltd. xv

Issue draft 07 Copyright © Huawei Technologies Co., Ltd. xvi

4.2.16.4 Checking Statistics about MAC Address Entries in a BD........................................................................... 2248

5 Multicast VPN.................................................................................................................... 2428

Issue draft 07 Copyright © Huawei Technologies Co., Ltd. xvii

5.2.2.2.1 PIM (S, G) Join/Prune........................................................................................................................................... 2466

Issue draft 07 Copyright © Huawei Technologies Co., Ltd. xviii

5.4.6.1 Deleting IPv4 Multicast VPN Statistics.............................................................................................................. 2558

Issue draft 07 Copyright © Huawei Technologies Co., Ltd. xix

5.5.5.1.8 Configuring a P2MP LSP to Carry Multicast Traffic...................................................................................2676

Issue draft 07 Copyright © Huawei Technologies Co., Ltd. xx

5.5.5.5.3 Configuring Route Reflection on an ABR...................................................................................................... 2726

Issue draft 07 Copyright © Huawei Technologies Co., Ltd. xxi

5.6.1 Overview of BIER.......................................................................................................................................................... 3059

Issue draft 07 Copyright © Huawei Technologies Co., Ltd. xxii

6.2.7 Configuring Dynamic Telemetry Subscription (IPv6 Collector).................................................................... 3144

Issue draft 07 Copyright © Huawei Technologies Co., Ltd. xxiii

1 Segment Routing MPLS

1.1 Segment Routing MPLS Description

1.1.1 Overview of Segment Routing MPLS

SR encapsulates segment list information that identifies a forwarding path into a

Issue draft 07 Copyright © Huawei Technologies Co., Ltd. 1

Figure 1-1 Service-driven network

Issue draft 07 Copyright © Huawei Technologies Co., Ltd. 2

1.1.2 Understanding Segment Routing MPLS

1.1.2.1 Segment Routing MPLS Fundamentals

Issue draft 07 Copyright © Huawei Technologies Co., Ltd. 3