New IP Technologies PDF

New IP Technologies
Issue draft 05
Date 2020-04-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 05 Copyright © Huawei Technologies Co., Ltd. i

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

1.1 Segment Routing MPLS........................................................................................................................................................ 1
1.1.1 Introduction 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 SR-MPLS BE........................................................................................................................................................................ 7
1.1.2.2.1 SR and LDP Communication...................................................................................................................................11
1.1.2.3 IS-IS for SR........................................................................................................................................................................ 14
1.1.2.4 OSPF for SR...................................................................................................................................................................... 24
1.1.2.5 SR-MPLS TE...................................................................................................................................................................... 32
1.1.2.5.1 Topology Collection and Label Allocation..........................................................................................................33
1.1.2.5.2 SR-MPLS TE Tunnel Establishment....................................................................................................................... 35
1.1.2.5.3 SR-MPLS TE Data Forwarding................................................................................................................................ 37
1.1.2.5.4 SR-MPLS TE Tunnel Reliability............................................................................................................................... 40
1.1.2.5.5 BFD for SR-MPLS TE.................................................................................................................................................. 40
1.1.2.5.6 SR-MPLS TE Load Balancing................................................................................................................................... 42
1.1.2.5.7 DSCP-based Tunneling for IP Packets to Enter SR-MPLS TE Tunnels....................................................... 43
1.1.2.6 BGP for SR........................................................................................................................................................................ 45
1.1.2.7 Inter-AS E2E SR-MPLS TE............................................................................................................................................ 50
1.1.2.7.1 Binding SID................................................................................................................................................................... 50
1.1.2.7.2 E2E SR-MPLS TE Tunnel Creation......................................................................................................................... 51
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............................................................................................................... 55
1.1.2.7.5 One-Arm BFD for E2E SR-MPLS TE...................................................................................................................... 57
1.1.2.7.6 Cross-Multi-AS E2E SR-MPLS TE........................................................................................................................... 59
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.........................................................................................................................65
1.1.2.8.3 L2VPN Recursive to an SR Tunnel.........................................................................................................................69
1.1.2.8.4 EVPN Recursive to an SR Tunnel........................................................................................................................... 71
1.1.2.9 SBFD for SR...................................................................................................................................................................... 73
1.1.2.10 TI-LFA FRR...................................................................................................................................................................... 77
1.1.2.11 Anycast FRR................................................................................................................................................................... 83
Issue draft 05 Copyright © Huawei Technologies Co., Ltd. ii

(2020-04-09)
1.1.2.12 SR Microloop Avoidance........................................................................................................................................... 85

1.1.2.13 SR OAM........................................................................................................................................................................... 86
1.1.2.14 SR-MPLS TE Policy....................................................................................................................................................... 90
1.1.2.14.1 SR-MPLS TE Policy Creation................................................................................................................................. 97
1.1.2.14.2 Traffic Steering into an SR-MPLS TE Policy.................................................................................................... 99
1.1.2.14.3 SR-MPLS TE Policy-based Data Forwarding................................................................................................. 101
1.1.2.14.4 SBFD for SR-MPLS TE Policy.............................................................................................................................. 105
1.1.2.14.5 SR-MPLS TE Policy Failover................................................................................................................................ 106
1.1.2.14.6 SR-MPLS TE Policy OAM..................................................................................................................................... 108
1.1.2.15 MPLS in UDP............................................................................................................................................................... 110
1.1.2.16 SR-MPLS TTL............................................................................................................................................................... 112
1.1.3 Application Scenarios for Segment Routing MPLS..............................................................................................114
1.1.3.1 Single-AS SR-MPLS TE............................................................................................................................................... 114
1.1.3.2 Inter-AS E2E SR-MPLS TE.......................................................................................................................................... 115
1.1.3.3 SR-MPLS TE Policy Application............................................................................................................................... 117
1.1.4 Terminology for Segment Routing MPLS............................................................................................................... 117
1.2 Segment Routing MPLS Configuration....................................................................................................................... 118
1.2.1 Overview of Segment Routing MPLS....................................................................................................................... 118
1.2.2 Segment Routing MPLS Licensing Requirements and Configuration Precautions................................... 119
1.2.3 Configuring an IS-IS SR-MPLS BE Tunnel............................................................................................................... 129
1.2.3.1 Enabling MPLS.............................................................................................................................................................. 130
1.2.3.2 Configuring Basic SR-MPLS BE Functions........................................................................................................... 130
1.2.3.3 (Optional) Configuring a Policy for Triggering SR-LSP Establishment..................................................... 131
1.2.3.4 (Optional) Configuring a Policy for Preferentially Selecting an SR-MPLS BE Tunnel.......................... 132
1.2.3.5 Verifying the IS-IS SR-MPLS BE Tunnel Configuration....................................................................................133
1.2.4 Configuring an OSPF SR-MPLS BE Tunnel..............................................................................................................133
1.2.4.1 Enabling MPLS.............................................................................................................................................................. 133
1.2.4.2 Configuring Basic SR-MPLS BE Functions........................................................................................................... 134
1.2.4.3 (Optional) Configuring a Policy for Triggering SR-LSP Establishment..................................................... 135
1.2.4.4 Configuring a Policy for Preferentially Selectingan SR-MPLS BE Tunnel................................................. 136
1.2.4.5 Verifying the OSPF SR-MPLS BE Tunnel Configuration.................................................................................. 136
1.2.5 Configuring an IS-IS SR-MPLS TE Tunnel (Path Computation on the Controller)................................... 137
1.2.5.1 Enabling MPLS TE........................................................................................................................................................137
1.2.5.2 Globally Enabling the Segment Routing Capability........................................................................................ 138
1.2.5.3 Configuring the IS-IS SR-MPLS TE Capability and Topology Report Function....................................... 139
1.2.5.4 Configuring an SR-MPLS TE Tunnel Interface................................................................................................... 140
1.2.5.5 Configuring the UCMP Function of the SR-MPLS TE Tunnel....................................................................... 142
1.2.5.6 (Optional) Configuring SR on a PCC.................................................................................................................... 142
1.2.5.7 (Optional) Enabling a Device to Simulate an SR-MPLS TE Transit Node to Perform Link Label-
based Forwarding...................................................................................................................................................................... 143
1.2.5.8 Verifying the IS-IS SR-MPLS TE Tunnel Configuration....................................................................................143
1.2.6 Configuring an OSPF SR-MPLS TE Tunnel (Path Computation on the Controller)..................................144
1.2.6.1 Enabling MPLS TE........................................................................................................................................................145
Issue draft 05 Copyright © Huawei Technologies Co., Ltd. iii

(2020-04-09)

1.2.6.3 Configuring the OSPF SR-MPLS TE Capability and Topology Report Function......................................146
1.2.6.5 (Optional) Configuring the UCMP Function of theSR-MPLS TE Tunnel...................................................149
1.2.6.6 (Optional) Configuring SR on a PCC.................................................................................................................... 150
1.2.6.7 (Optional) Enabling a Device to Simulate an SR-MPLS TE Transit Node to Perform Link Label-
based Forwarding...................................................................................................................................................................... 150
1.2.6.8 Verifying the OSPF SR-MPLS TE Tunnel Configuration.................................................................................. 151
1.2.7 Configuring an IS-IS SR-MPLS TE Tunnel (Explicit Path Used)....................................................................... 152
1.2.7.1 Enabling MPLS TE........................................................................................................................................................152
1.2.7.2 Enabling MPLS TE........................................................................................................................................................153
1.2.7.3 Configuring Basic SR-MPLS TE Functions........................................................................................................... 153
1.2.7.4 Configuring an SR-MPLS TE Explicit Path........................................................................................................... 155
1.2.7.6 (Optional) Configuring the UCMP Function of the SR-MPLS TE Tunnel................................................. 158
1.2.7.7 Checking the Configurations................................................................................................................................... 158
1.2.8 Configuring an OSPF SR-MPLS TE Tunnel (Explicit Path Used)..................................................................... 159
1.2.8.1 Enabling MPLS TE........................................................................................................................................................159
1.2.8.2 Globally Enabling the SR Capability......................................................................................................................160
1.2.8.4 Configuring an SR-MPLS TE Explicit Path........................................................................................................... 162
1.2.9 Configuring an IS-IS SR-MPLS TE Tunnel (Path Computation on a Forwarder).......................................166
1.2.9.1 Enabling MPLS TE........................................................................................................................................................166
1.2.9.4 Enabling the Ingress to Compute a Path............................................................................................................ 169
1.2.10 Configuring an OSPF SR-MPLS TE Tunnel (Path Computation on a Forwarder)...................................172
1.2.10.1 Enabling MPLS TE..................................................................................................................................................... 172
1.2.10.2 Globally Enabling the SR Capability................................................................................................................... 173
1.2.10.3 Configuring Basic SR-MPLS TE Functions......................................................................................................... 174
1.2.10.4 Enabling the Ingress to Compute a Path.......................................................................................................... 175
1.2.10.5 Configuring an SR-MPLS TE Tunnel Interface................................................................................................. 175
1.2.10.6 (Optional) Configuring the UCMP Function of the SR-MPLS TE Tunnel...............................................177
1.2.10.7 Checking the Configurations................................................................................................................................. 177
1.2.11 Configuring BGP SR..................................................................................................................................................... 178
1.2.12 Configuring an Inter-AS E2E SR-MPLS TE Tunnel (Path Computation on the Controller)................. 180
1.2.12.1 Setting a Binding SID............................................................................................................................................... 181
Issue draft 05 Copyright © Huawei Technologies Co., Ltd. iv

(2020-04-09)
1.2.12.2 Configuring an E2E SR-MPLS TE Tunnel Interface........................................................................................ 182

1.2.12.3 (Optional) Configuring SR on a PCC.................................................................................................................. 183
1.2.12.4 Verifying the Configuration of an Inter-AS E2E SR-MPLS TE Tunnel...................................................... 184
1.2.13 Configuring an Inter-AS E2E SR-MPLS TE Tunnel (Explicit Path Used)..................................................... 185
1.2.13.1 Setting a Binding SID............................................................................................................................................... 186
1.2.13.2 Configuring an SR-MPLS TE Explicit Path......................................................................................................... 186
1.2.13.3 Configuring an E2E SR-MPLS TE Tunnel Interface........................................................................................ 187
1.2.13.4 Verifying the Configuration of an Inter-AS E2E SR-MPLS TE Tunnel...................................................... 189
1.2.14 Configuring Traffic Steering into SR-MPLS BE Tunnels................................................................................... 189
1.2.15 Configuring Traffic Steering into SR-MPLS TE Tunnels................................................................................... 194
1.2.16 Configuring IS-IS SR to Communicate with LDP............................................................................................... 199
1.2.17 Configuring OSPF SR to Communicate with LDP..............................................................................................201
1.2.18 Configuring IS-IS TI-LFA FRR.................................................................................................................................... 203
1.2.19 Configuring OSPF TI-LFA FRR...................................................................................................................................205
1.2.20 Configuring SBFD for SR-MPLS BE Tunnel...........................................................................................................207
1.2.21 Configuring SBFD for SR-MPLS TE LSP................................................................................................................. 209
1.2.22 Configuring SBFD for SR-MPLS TE Tunnel........................................................................................................... 210
1.2.23 Configuring BFD for SR-MPLS BE............................................................................................................................212
1.2.24 Configuring BFD for SR-MPLS BE (SR and LDP Interworking Scenario)................................................... 213
1.2.25 Configuring Static BFD for SR-MPLS TE............................................................................................................... 215
1.2.26 Configuring Static BFD for SR-MPLS TE LSP....................................................................................................... 219
1.2.27 Configuring Dynamic BFD for SR-MPLS TE LSP.................................................................................................223
1.2.28 Configuring One-Arm BFD for E2E SR-MPLS TE Tunnel................................................................................. 226
1.2.29 Configuring One-Arm BFD for E2E SR-MPLS TE LSP....................................................................................... 229
1.2.30 Configuring a Device as the Egress of an MPLS-in-UDP Tunnel..................................................................231
1.2.31 Configuring SR-MPLS BE Traffic Statistics Collection...................................................................................... 232
1.2.32 Configuring an SR-MPLS TE Policy (Manual Configuration).........................................................................233
1.2.32.1 Configuring IGP SR................................................................................................................................................... 234
1.2.32.2 Configuring an SR-MPLS TE Policy......................................................................................................................235
1.2.32.3 Configuring a BGP Extended Community.........................................................................................................237
1.2.32.4 Configuring Traffic Steering.................................................................................................................................. 240
1.2.32.5 Verifying the SR-MPLS TE Policy Configuration............................................................................................. 246
1.2.33 Configuring an SR-MPLS TE Policy (Dynamic Delivery by a Controller)...................................................247
1.2.33.1 Configuring IGP SR................................................................................................................................................... 248
1.2.33.2 Configuring BGP Peer Relationships Between the Controller and Forwarder..................................... 250
1.2.33.5 Verifying the SR-MPLS TE Policy Configuration............................................................................................. 261
1.2.34 Configuring SBFD for SR-MPLS TE Policy.............................................................................................................261
1.2.35 Configuring HSB for SR-MPLS TE Policy............................................................................................................... 263
1.2.36 Configuring SR-MPLS TE Policy-related Alarm Thresholds............................................................................ 264
1.2.37 Configuring SR-MPLS TE Policy Traffic Statistics Collection..........................................................................265
Issue draft 05 Copyright © Huawei Technologies Co., Ltd. v

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

1.2.38.1 Redirecting a Public IPv4 BGP FlowSpec Route to an SR-MPLS TE Policy (Manual Configuration)
......................................................................................................................................................................................................... 266
1.2.38.2 Redirecting a Public IPv4 BGP FlowSpec Route to an SR-MPLS TE Policy (Dynamic Delivery by a
Controller).................................................................................................................................................................................... 268
1.2.39 Configuring Examples for SR-MPLS BE................................................................................................................. 270
1.2.39.1 Example for Configuring L3VPN over IS-IS SR-MPLS BE............................................................................. 270
1.2.39.2 Example for Configuring L3VPN over OSPF SR-MPLS BE........................................................................... 282
1.2.39.3 Example for Configuring Non-Labeled Public BGP Routes to Recurse to an SR-MPLS BE tunnel295
1.2.39.4 Example for Configuring IS-IS SR to Communicate with LDP................................................................... 301
1.2.39.5 Example for Configuring IS-IS Anycast FRR..................................................................................................... 307
1.2.39.6 Example for Configuring SBFD to Monitor SR-MPLS BE Tunnels.............................................................313
1.2.39.7 Example for Configuring TI-LFA FRR for an SR-MPLS BE Tunnel............................................................. 321
1.2.40 Configuring Examples for SR-MPLS TE................................................................................................................. 331
1.2.40.1 Example for Configuring L3VPN over SR-MPLS TE....................................................................................... 331
1.2.40.2 Example for Configuring LDP VPLS over SR-MPLS TE................................................................................. 342
1.2.40.3 Example for Configuring BD EVPN IRB over SR-MPLS TE...........................................................................352
1.2.40.4 Example for Configuring EVPN L3VPNv6 over SR-MPLS TE...................................................................... 367
1.2.40.5 Example for Configuring the Controller to Run NETCONF to Deliver Configurations to Create an
SR-MPLS TE Tunnel................................................................................................................................................................... 381
1.2.40.6 Example for Configuring Static BFD for SR-MPLS TE................................................................................... 388
1.2.40.7 Example for Configuring Dynamic BFD for SR-MPLS TE LSP.................................................................... 395
1.2.40.8 Example for Configuring TI-LFA FRR for a Loose SR-MPLS TE Tunnel................................................... 404
1.2.40.9 Example for Configuring an E2E SR-MPLS TE Tunnel (Explicit Path Used).......................................... 416
1.2.40.10 Example for Configuring CBTS in an L3VPN over SR-MPLS TE Scenario............................................ 431
1.2.40.11 Example for Configuring CBTS in an L3VPN over LDP over SR-MPLS TE Scenario......................... 446
1.2.40.12 Example for Configuring DSCP-Based IP Service Recursion to SR-MPLS TE Tunnels......................464
1.2.41 Configuration Examples for SR-MPLS TE Policy................................................................................................ 477
1.2.41.1 Example for Configuring L3VPN Routes to Be Recursed to Manually Configured SR-MPLS TE
Policies (Color-Based).............................................................................................................................................................. 477
1.2.41.2 Example for Configuring L3VPN Routes to Be Recursed to Manually Configured SR-MPLS TE
Policies (DSCP-Based).............................................................................................................................................................. 492
1.2.41.3 Example for Configuring L3VPN Routes to Be Recursed to Dynamically Delivered SR-MPLS TE
Policies (Color-Based).............................................................................................................................................................. 507
1.2.41.4 Example for Configuring L3VPNv6 Routes to Be Recursed to Manually Configured SR-MPLS TE
Policies........................................................................................................................................................................................... 523
1.2.41.5 Example for Configuring Non-labeled Public BGP Routes to Be Recursed to Manually Configured
SR-MPLS TE Policies.................................................................................................................................................................. 538
1.2.41.6 Example for Configuring BGP4+ 6PE Routes to Be Recursed to Manually Configured SR-MPLS TE
Policies........................................................................................................................................................................................... 549
1.2.41.7 Example for Configuring EVPN Route Recursion Based on an SR-MPLS TE Policy............................564
1.2.41.8 Example for Redirecting Public IPv4 BGP FlowSpec Routes to SR-MPLS TE Policies.........................579
2 Segment Routing IPv6....................................................................................................... 590

2.1 Segment Routing IPv6...................................................................................................................................................... 590
Issue draft 05 Copyright © Huawei Technologies Co., Ltd. vi

(2020-04-09)
2.1.1 Overview of Segment Routing IPv6..........................................................................................................................590

2.1.2 Understanding Segment Routing IPv6.................................................................................................................... 591
2.1.2.1 SRv6 Fundamentals.................................................................................................................................................... 591
2.1.2.2 SRv6 Segments............................................................................................................................................................. 594
2.1.2.3 SRv6 Nodes.................................................................................................................................................................... 599
2.1.2.4 SRv6 BE........................................................................................................................................................................... 601
2.1.2.4.1 L3VPNv4 over SRv6 BE........................................................................................................................................... 601
2.1.2.4.2 EVPN L3VPNv4 over SRv6 BE............................................................................................................................... 605
2.1.2.4.3 EVPN L3VPNv6 over SRv6 BE............................................................................................................................... 607
2.1.2.4.4 EVPN VPWS over SRv6 BE..................................................................................................................................... 609
2.1.2.4.5 EVPN VPLS over SRv6 BE....................................................................................................................................... 614
2.1.2.5 IS-IS for SRv6................................................................................................................................................................. 619
2.1.2.6 BGP for SRv6................................................................................................................................................................. 626
2.1.2.7 SRv6 TE Policy............................................................................................................................................................... 631
2.1.2.7.1 SRv6 TE Policy Creation......................................................................................................................................... 632
2.1.2.7.2 Traffic Steering into an SRv6 TE Policy............................................................................................................ 634
2.1.2.7.3 SRv6 TE Policy-based Data Forwarding............................................................................................................635
2.1.2.7.4 SBFD for SRv6 TE Policy......................................................................................................................................... 636
2.1.2.7.5 SRv6 TE Policy Failover...........................................................................................................................................639
2.1.2.7.6 TTL Processing by an SRv6 TE Policy.................................................................................................................642
2.1.2.8 SRv6 TI-LFA FRR........................................................................................................................................................... 642
2.1.2.9 SRv6 Microloop Avoidance....................................................................................................................................... 644
2.1.2.10 SRv6 OAM.................................................................................................................................................................... 646
2.1.2.10.1 SRv6 OAM Extensions.......................................................................................................................................... 646
2.1.2.10.2 SRv6 SID Ping and Tracert.................................................................................................................................. 647
2.1.2.10.3 SRv6 TE Policy Ping/Tracert................................................................................................................................ 650
2.1.3 Terminology for Segment Routing IPv6.................................................................................................................. 652
2.2 Segment Routing IPv6 Configuration.......................................................................................................................... 653
2.2.1 Overview of Segment Routing IPv6..........................................................................................................................653
2.2.2 Segment Routing IPv6 Licensing Requirements and Configuration Precautions......................................653
2.2.3 Activating SRv6 Port Licenses for a Board..............................................................................................................665
2.2.4 Configuring L3VPNv4 over SRv6 BE......................................................................................................................... 665
2.2.5 Configuring EVPN L3VPN over SRv6 BE..................................................................................................................669
2.2.6 Configuring EVPN VPWS over SRv6 BE................................................................................................................... 675
2.2.7 Configuring EVPN VPLS over SRv6 BE..................................................................................................................... 681
2.2.8 Configuring IS-IS SRv6 TI-LFA FRR............................................................................................................................ 684
2.2.9 Configuring an SRv6 TE Policy (Manual Configuration)................................................................................... 686
2.2.9.1 Configuring SRv6 SIDs............................................................................................................................................... 687
2.2.9.2 Configuring an SRv6 TE Policy................................................................................................................................ 689
2.2.9.3 Configuring a BGP Extended Community........................................................................................................... 690
2.2.9.4 Configuring Traffic Steering.....................................................................................................................................693
2.2.9.5 Verifying the SRv6 TE Policy Configuration........................................................................................................ 696
Issue draft 05 Copyright © Huawei Technologies Co., Ltd. vii

(2020-04-09)
2.2.10 Configuring an SRv6 TE Policy (Dynamic Delivery by a Controller)...........................................................697

2.2.10.1 Configuring SRv6 SIDs............................................................................................................................................. 697
2.2.10.2 Configuring TE Attributes....................................................................................................................................... 699
2.2.10.3 Configuring IS-IS Topology Advertisement to BGP-LS................................................................................. 702
2.2.10.4 Configuring BGP Peer Relationships Between the Controller and Forwarder..................................... 703
2.2.10.5 Configuring SRv6 TE Policy Status Advertisement to BGP-LS................................................................... 704
2.2.10.8 Verifying the SRv6 TE Policy Configuration..................................................................................................... 710
2.2.11 Configuring L3VPNv4 over SRv6 TE Policy.......................................................................................................... 711
2.2.12 Configuring EVPN L3VPNv4 over SRv6 TE Policy.............................................................................................. 716
2.2.13 Configuring EVPN L3VPNv6 over SRv6 TE Policy.............................................................................................. 720
2.2.14 Configuring EVPN VPWS over SRv6 TE Policy.................................................................................................... 723
2.2.15 Configuring EVPN VPLS over SRv6 TE Policy...................................................................................................... 728
2.2.16 Redirecting a Public IPv4 BGP FlowSpec Route to an SRv6 TE Policy........................................................731
2.2.16.1 Redirecting a Public IPv4 BGP FlowSpec Route to an SRv6 TE Policy (Manual Configuration).... 731
2.2.16.2 Redirecting a Public IPv4 BGP FlowSpec Route to an SRv6 TE Policy (Dynamic Delivery by a
Controller).................................................................................................................................................................................... 733
2.2.17 Configuring SRv6 Egress Protection....................................................................................................................... 735
2.2.18 Configuring a TTL Processing Mode for an SRv6 TE Policy........................................................................... 738
2.2.19 Configuring SRv6 TE Policy-related Alarm Thresholds.................................................................................... 739
2.2.20 Configuring an SRv6 Path MTU............................................................................................................................... 739
2.2.21 Configuring SRv6 TE Policy Traffic Statistics Collection.................................................................................. 740
2.2.22 Configuring BGP SRv6................................................................................................................................................. 741
2.2.23 Using Ping/Tracert to Test an SRv6 Network...................................................................................................... 746
2.2.23.1 Using Ping to Test the Connectivity of an SRv6 Network........................................................................... 746
2.2.23.2 Using Tracert to Test the Path Information of an SRv6 Network.............................................................747
2.2.24 Configuration Examples for SRv6 BE..................................................................................................................... 748
2.2.24.1 Example for Configuring L3VPNv4 over SRv6 BE...........................................................................................748
2.2.24.2 Example for Configuring L3VPNv4 over SRv6 BE ECMP.............................................................................. 759
2.2.24.3 Example for Configuring VPN FRR for L3VPNv4 over SRv6 BE................................................................. 770
2.2.24.4 Example for Configuring EVPN L3VPNv4 over SRv6 BE.............................................................................. 782
2.2.24.5 Example for Configuring EVPN L3VPNv6 over SRv6 BE.............................................................................. 791
2.2.24.6 Example for Configuring EVPN L3VPNv6 over SRv6 BE ECMP..................................................................798
2.2.24.7 Example for Configuring VPN FRR for EVPN L3VPNv6 over SRv6 BE.....................................................810
2.2.24.8 Example for Configuring EVPN VPWS over SRv6 BE.................................................................................... 822
2.2.24.9 Example for Configuring EVPN VPLS over SRv6 BE...................................................................................... 830
2.2.24.10 Example for Configuring Inter-AS L3VPNv4 over SRv6 BE....................................................................... 838
2.2.25 Configuration Examples for SRv6 TE Policy.........................................................................................................849
2.2.25.1 Example for Configuring L3VPNv4 over SRv6 TE Policy (Manual Configuration)............................. 849
2.2.25.2 Example for Configuring EVPN L3VPNv4 over SRv6 TE Policy (Manual Configuration)................. 862
2.2.25.3 Example for Configuring EVPN L3VPNv6 over SRv6 TE Policy (Manual Configuration)................. 874
2.2.25.4 Example for Configuring EVPN VPWS over SRv6 TE Policy (Manual Configuration)....................... 887
Issue draft 05 Copyright © Huawei Technologies Co., Ltd. viii

(2020-04-09)
2.2.25.5 Example for Configuring EVPN VPLS over SRv6 TE Policy (Manual Configuration)......................... 900
2.2.25.6 Example for Configuring L3VPNv4 over SRv6 TE Policy Egress Protection...........................................913
2.2.25.7 Example for Configuring Inter-AS L3VPNv4 over SRv6 TE Policy.............................................................930
3 EVPN.......................................................................................................................................946
3.1 EVPN....................................................................................................................................................................................... 946
3.1.1 Overview of EVPN...........................................................................................................................................................946
3.1.2 Understanding EVPN..................................................................................................................................................... 947
3.1.3 EVPN-MPLS....................................................................................................................................................................... 955
3.1.3.1 EVPN Multi-Homing Technology........................................................................................................................... 955
3.1.3.2 EVPN Seamless MPLS Fundamentals................................................................................................................... 958
3.1.3.3 EVPN's Service Modes................................................................................................................................................ 972
3.1.4 EVPN-VXLAN..................................................................................................................................................................... 975
3.1.4.1 EVPN VXLAN Fundamentals.................................................................................................................................... 975
3.1.5 EVPN VPWS....................................................................................................................................................................... 980
3.1.5.1 EVPN VPWS Fundamentals...................................................................................................................................... 980
3.1.6 PBB-EVPN.......................................................................................................................................................................... 987
3.1.6.1 PBB-EVPN Fundamentals..........................................................................................................................................987
3.1.6.2 Migration from an HVPLS Network to a PBB-EVPN....................................................................................... 996
3.1.7 EVPN E-Tree.......................................................................................................................................................................997
3.1.8 MAC Duplication Suppression for EVPN................................................................................................................. 999
3.1.9 EVPN ORF........................................................................................................................................................................ 1002
3.1.10 IGMP Snooping over EVPN MPLS.........................................................................................................................1004
3.1.11 Application Scenarios for EVPN............................................................................................................................ 1011
3.1.11.1 Using EVPN to Interconnect Other Networks...............................................................................................1011
3.1.11.2 EVPN L3VPN HVPN................................................................................................................................................ 1012
3.1.11.3 EVPN 6VPE................................................................................................................................................................ 1017
3.1.11.4 EVPN Splicing........................................................................................................................................................... 1020
3.1.11.5 Inter-AS EVPN Option C....................................................................................................................................... 1025
3.1.11.6 DCI Scenarios........................................................................................................................................................... 1027
3.1.11.7 NFVI Distributed Gateway (SR Tunnels).........................................................................................................1042
3.1.11.8 NFVI Distributed Gateway Function (BGP VPNv4/v6 over E2E SR Tunnels)......................................1056
3.1.11.9 NFVI Distributed Gateway Function (BGP EVPN over E2E SR Tunnels).............................................. 1067
3.1.11.10 Application Scenarios for EVPN E-LAN Accessing L3VPN...................................................................... 1078
3.2 EVPN Configuration........................................................................................................................................................ 1079
3.2.1 Overview of EVPN........................................................................................................................................................ 1080
3.2.2 EVPN Licensing Requirements and Configuration Precautions.................................................................... 1081
3.2.3 Activating EVPN Interface Licenses on a Board................................................................................................. 1104
3.2.4 Configuring Common EVPN Functions................................................................................................................. 1105
3.2.4.1 Configuring an EVPN Instance............................................................................................................................. 1106
3.2.4.2 Configuring an EVPN Source Address................................................................................................................ 1108
3.2.4.3 Binding an Interface to an EVPN Instance....................................................................................................... 1109
3.2.4.4 Configuring an ESI.................................................................................................................................................... 1109
Issue draft 05 Copyright © Huawei Technologies Co., Ltd. ix

(2020-04-09)
3.2.4.5 Configuring a BGP EVPN Peer Relationship.....................................................................................................1112

3.2.4.6 (Optional) Configuring a PE's Global Redundancy Mode.......................................................................... 1113
3.2.4.7 (Optional) Configuring a BGP EVPN RR........................................................................................................... 1114
3.2.4.8 (Optional) Configuring the Redundancy Mode and DF Precedence by ESI......................................... 1115
3.2.4.9 (Optional) Associating DF with BFD.................................................................................................................. 1117
3.2.4.10 (Optional) Board Selection for Internal Loopback on a Main Control Board................................... 1118
3.2.4.11 Verifying the EVPN Configuration.................................................................................................................... 1119
3.2.5 Configuring BD-EVPN Functions............................................................................................................................. 1120
3.2.5.1 Configuring an EVPN Instance in BD Mode.....................................................................................................1120
3.2.5.2 Configuring an EVPN Source Address................................................................................................................ 1122
3.2.5.3 Configuring an ESI.................................................................................................................................................... 1123
3.2.5.4 Configuring a BD and Binding an EVPN Instance to the BD..................................................................... 1125
3.2.5.5 Creating an L3VPN Instance and Binding It to a VBDIF Interface........................................................... 1127
3.2.5.6 Configuring a BGP EVPN Peer Relationship.....................................................................................................1129
3.2.5.7 (Optional)Configuring a PE's Global Redundancy Mode............................................................................ 1132
3.2.5.8 (Optional) Configuring the Redundancy Mode by ESI................................................................................ 1132
3.2.5.9 (Optional) Configuring a BGP EVPN RR........................................................................................................... 1134
3.2.5.10 (Optional) Configuring Proxy ARP.................................................................................................................... 1135
3.2.5.11 Checking the Configurations.............................................................................................................................. 1137
3.2.6 Configuring EVPN VPWS over MPLS Functions................................................................................................. 1138
3.2.6.1 Configuring EVPN Functions................................................................................................................................. 1139
3.2.6.2 Configuring an EVPL Instance...............................................................................................................................1139
3.2.6.3 Configuring an AC Interface.................................................................................................................................. 1141
3.2.6.4 Configuring an MPLS LDP Tunnel....................................................................................................................... 1142
3.2.6.5 (Optional) Configuring DF Election.................................................................................................................... 1143
3.2.6.6 (Optional) Configuring FRR...................................................................................................................................1144
3.2.6.7 Verifying the Configuration of EVPN VPWS over MPLS Functions.......................................................... 1145
3.2.7 Configuring an EVPN to Carry Layer 3 Services.................................................................................................1146
3.2.7.1 Configuring an L3VPN Instance........................................................................................................................... 1148
3.2.7.2 Configuring BGP EVPN Peer Relationships.......................................................................................................1150
3.2.7.3 Configuring Route Exchange Between a PE and an Access-side Device................................................1152
3.2.7.4 (Optional) Re-Encapsulating IRB (v6) Routes into the desired Routes................................................. 1152
3.2.7.5 Verifying the Configuration of an EVPN to Carry Layer 3 Services......................................................... 1153
3.2.8 Splicing a Common L3VPN with an EVPN L3VPN............................................................................................ 1153
3.2.9 Splicing a VPLS in PW Redundancy Mode with an Anycast VXLAN in an EVPN Active-Active Scenario
....................................................................................................................................................................................................... 1157
3.2.10 Configuring EVPN E-LAN over mLDP P2MP Tunnels.................................................................................... 1159
3.2.11 Configuring an EVPN Route-Policy...................................................................................................................... 1161
3.2.12 Configuring BGP EVPN Soft Reset........................................................................................................................ 1166
3.2.13 Configuring VLAN-based DF Election................................................................................................................. 1167
3.2.14 Configuring EVPN Reliability Functions..............................................................................................................1168
3.2.15 Configuring MAC Duplication Suppression for EVPN.................................................................................... 1173
3.2.16 Configuring EVPN E-Tree......................................................................................................................................... 1176
Issue draft 05 Copyright © Huawei Technologies Co., Ltd. x

(2020-04-09)
3.2.17 Configuring EVPN ORF............................................................................................................................................. 1178

3.2.18 Setting a Delay in Releasing an Obtained Label in a BGP EVPN FRR Switchover Scenario............ 1179
3.2.19 Splicing a VLL with a Common EVPN E-LAN................................................................................................... 1181
3.2.20 Splicing a VLL with an MPLS EVPN E-Line........................................................................................................ 1183
3.2.21 Splicing VPLS and MPLS EVPN E-LAN................................................................................................................ 1186
3.2.22 Configuring EVPN E-LAN Accessing L3VPN...................................................................................................... 1188
3.2.22.1 Creating an L2VE Interface..................................................................................................................................1189
3.2.22.2 Creating an L3VE Interface..................................................................................................................................1190
3.2.22.3 (Optional) Configuring MAC Addresses for L2VE and L3VE Interfaces............................................... 1191
3.2.22.4 Adding an L2VE Interface to a BD.................................................................................................................... 1191
3.2.22.5 Associating an L3VE Interface with a VPN Instance...................................................................................1192
3.2.22.6 Verifying the configuration of EVPN E-LAN accessing L3VPN................................................................1193
3.2.23 Configuring EVPN HVPN to Carry Layer 2 Services....................................................................................... 1193
3.2.24 Configuring MPLS EVPN Splicing with Static VXLAN.................................................................................... 1195
3.2.25 Splicing a VXLAN EVPN with a VPLS................................................................................................................... 1199
3.2.25.1 Creating VSIs and Configuring PW Connections..........................................................................................1199
3.2.25.2 Configuring a VXLAN EVPN................................................................................................................................ 1201
3.2.25.3 Establishing BGP Peer Relationships................................................................................................................ 1202
3.2.25.4 Binding EVPN Instances and VSIs to BDs....................................................................................................... 1203
3.2.25.5 (Optional) Configuring BFD for VPLS PW......................................................................................................1204
3.2.25.6 Verifying the Configuration of Splicing a VXLAN EVPN with a VPLS................................................... 1205
3.2.26 Configuring MPLS EVPN E-LAN Option B......................................................................................................... 1206
3.2.26.1 Configuring MP-IBGP Between a PE and an ASBR in the Same AS......................................................1207
3.2.26.2 Configuring MP-EBGP Between ASBRs in Different ASs........................................................................... 1208
3.2.26.3 Configuring ASBRs Not to Filter EVPN Routes Based on VPN Targets................................................ 1209
3.2.26.4 (Optional) Configuring One-Label-per-Next-Hop Label Distribution on an ASBR......................... 1210
3.2.26.5 (Optional) Configuring the Protection Switching Function..................................................................... 1210
3.2.26.6 (Optional) Configuring BGP-EVPN Route Reflection on an ASBR.........................................................1211
3.2.26.7 Verifying the Configuration MPLS EVPN E-Lan OptionB.......................................................................... 1213
3.2.27 Configuring an EVPN L3VPN HVPN.................................................................................................................... 1213
3.2.27.1 Configuring an EVPN L3VPN HoVPN...............................................................................................................1215
3.2.27.2 Configuring an EVPN L3VPN H-VPN................................................................................................................1217
3.2.27.3 Splicing an EVPN L3VPN HoVPN with a Common L3VPN.......................................................................1218
3.2.27.4 Splicing an L3VPN HoVPN with an EVPN L3VPN........................................................................................1220
3.2.27.5 Verifying the EVPN L3VPN HVPN Configuration......................................................................................... 1221
3.2.28 Configuring IGMP Snooping over EVPN MPLS................................................................................................ 1222
3.2.28.1 Configuring IGMP Snooping and Proxy.......................................................................................................... 1222
3.2.28.2 Configuring the Access Side................................................................................................................................ 1223
3.2.28.3 Verifying the Configuration................................................................................................................................. 1225
3.2.29 Splicing an EVPN L3VPN over SRv6 with a Common L3VPN over MPLS............................................... 1226
3.2.30 Configuring a Border Leaf Node to Splice an EVPN L3VPN over SRv6 TE Policy with a Common
L3VPN over MPLS .................................................................................................................................................................. 1228
3.2.31 Configuring DCI Functions...................................................................................................................................... 1231
Issue draft 05 Copyright © Huawei Technologies Co., Ltd. xi

(2020-04-09)
3.2.31.1 Configuring a DCI Scenario with an E2E VXLAN EVPN Deployed on a Gateway............................ 1232
3.2.31.2 Configuring a DCI Scenario with a VLAN Layer 3 Sub-interface Accessing a Common L3VPN. 1233
3.2.31.3 Configuring a DCI Scenario with a VXLAN EVPN L3VPN Accessing a Common L3VPN................1235
3.2.31.4 Configuring a DCI Scenario with a VLAN Base Accessing an MPLS EVPN IRB................................. 1237
3.2.31.5 Configuring a DCI Scenario with a VXLAN EVPN Accessing an MPLS EVPN IRB............................. 1245
3.2.31.6 Verifying the Configuration of DCI Functions...............................................................................................1249
3.2.32 Configuring the NFVI Distributed Gateway Function (SR Tunnels)......................................................... 1250
3.2.32.1 Configuring Route Recursion over SR Tunnels............................................................................................. 1252
3.2.32.2 Configuring Route Advertisement on DC-GWs............................................................................................ 1253
3.2.32.3 Configuring Route Advertisement on L2GW/L3GWs................................................................................. 1256
3.2.32.4 (Optional) Configuring the Load Balancing Function............................................................................... 1259
3.2.32.5 Verifying the Configurations of the NFVI Distributed Gateway Function...........................................1261
3.2.33 Configuring the NFVI Distributed Gateway Function (BGP VPNv4/VPNv6 over E2E SR Tunnels) 1267
3.2.33.2 Configuring Route Advertisement on PEs...................................................................................................... 1270
3.2.33.5 Configuring the Load Balancing Function......................................................................................................1277
3.2.34 Configuring the NFVI Distributed Gateway Function (BGP EVPN over E2E SR Tunnels)................. 1285
3.2.34.2 Configuring Route Advertisement on PEs...................................................................................................... 1288
3.2.34.5 Configuring the Load Balancing Function......................................................................................................1295
3.2.35 Configuration Examples for EVPN........................................................................................................................1303
3.2.35.1 Example for Configuring a VPN to Access a Common EVPN E-LAN.................................................... 1303
3.2.35.2 Example for Configuring Eth-Trunk Sub-interfaces to Access a Common EVPN E-LAN in Active-
Active Mode.............................................................................................................................................................................. 1316
3.2.35.3 Example for Configuring Eth-Trunk Sub-interfaces to Access a BD EVPN IRB in Active-Active
Mode............................................................................................................................................................................................ 1333
3.2.35.4 Example for Configuring EVPN VPWS over MPLS.......................................................................................1349
3.2.35.5 Example for Setting a Redundancy Mode per ESI Instance..................................................................... 1359
3.2.35.6 Example for Configuring EVPN E-Tree............................................................................................................. 1368
3.2.35.7 Example for Configuring EVPN ORF................................................................................................................ 1377
3.2.35.8 Example for Configuring a DCI Scenario with an E2E VXLAN EVPN Deployed on a Gateway... 1390
3.2.35.9 Example for Configuring a DCI Scenario with a VLAN Layer 3 Sub-Interface Accessing a Common
L3VPN.......................................................................................................................................................................................... 1400
3.2.35.10 Example for Configuring a DCI Scenario with a VXLAN EVPN L3VPN Accessing a Common
L3VPN.......................................................................................................................................................................................... 1407
3.2.35.11 Example for Configuring MPLS EVPN E-LAN Option B.......................................................................... 1417
3.2.35.12 Example for Configuring an MPLS EVPN L3VPN in E-LAN Option B Mode.................................... 1422
Issue draft 05 Copyright © Huawei Technologies Co., Ltd. xii

(2020-04-09)
3.2.35.13 Example for Configuring Inter-AS EVPN Option C................................................................................... 1429

3.2.35.14 Example for Splicing a VXLAN EVPN with a VPLS.................................................................................... 1438
3.2.35.15 Example for Configuring EVPN E-LAN over mLDP P2MP Tunnels......................................................1446
3.2.35.16 Example for Splicing a VLL with a Common EVPN E-LAN.................................................................... 1458
3.2.35.17 Example for Splicing a VLL with an MPLS EVPN E-Line......................................................................... 1464
3.2.35.18 Example for Accessing a BD EVPN E-LAN over an MPLS Tunnel in VLAN-Aware Mode............1470
3.2.35.19 Example for Accessing an EVPN E-LAN over a VXLAN Tunnel in VLAN-Aware Mode................ 1484
3.2.35.20 Example for Splicing VPLS with MPLS EVPN E-LAN................................................................................ 1498
3.2.35.21 Example for Configuring Co-Existence of a VPLS and an EVPN.......................................................... 1509
3.2.35.22 Example for Configuring a DCI Scenario with a VXLAN EVPN Accessing an MPLS EVPN IRB..1518
3.2.35.23 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)................................................................................................................. 1528
3.2.35.24 Example for Splicing a Common L3VPN with an EVPN L3VPN........................................................... 1536
3.2.35.25 Example for Splicing a VPLS in PW Redundancy Mode with an Anycast VXLAN in an EVPN
Active-Active Scenario........................................................................................................................................................... 1543
3.2.35.26 Example for Configuring an EVPN L3VPN HoVPN................................................................................... 1551
3.2.35.27 Example for Configuring an EVPN L3VPN H-VPN.................................................................................... 1558
3.2.35.28 Example for Splicing an EVPN L3VPN HoVPN with a Common L3VPN........................................... 1564
3.2.35.29 Example for Splicing an L3VPN HoVPN with an EVPN L3VPN............................................................ 1572
3.2.35.30 Example for Configuring IGMP Snooping over EVPN MPLS................................................................. 1580
3.2.35.31 Example for Configuring BD EVPN IRB over SR-MPLS TE......................................................................1593
3.2.35.32 Example for Configuring the IPv4 NFVI Distributed Gateway Function (SR Tunnels).................1608
3.2.35.33 Example for Configuring the IPv6 NFVI Distributed Gateway Function (SR Tunnels).................1639
3.2.35.34 Example for Configuring the IPv4 NFVI Distributed Gateway Function (BGP VPNv4 over E2E SR
Tunnels)...................................................................................................................................................................................... 1672
3.2.35.35 Example for Configuring the IPv6 NFVI Distributed Gateway Function (BGP VPNv6 over E2E SR
Tunnels)...................................................................................................................................................................................... 1701
3.2.35.36 Example for Configuring the IPv4 NFVI Distributed Gateway Function (BGP EVPN over E2E SR
Tunnels)...................................................................................................................................................................................... 1733
3.2.35.37 Example for Configuring the IPv6 NFVI Distributed Gateway Function (BGP EVPN over E2E SR
Tunnels)...................................................................................................................................................................................... 1763
3.2.35.38 Example for Configuring EVPN L3VPNv6 over SR-MPLS TE..................................................................1794
3.2.35.39 Example for Configuring an EVPN L3VPNv6 HoVPN...............................................................................1808
3.2.35.40 Example for Configuring an EVPN L3VPNv6 H-VPN................................................................................1815
3.2.35.41 Example for Splicing an EVPN L3VPNv6 HoVPN with a Common L3VPNv6.................................. 1822
3.2.35.42 Example for Configuring a DCI Scenario of VXLAN EVPN L3VPNv6 Accessing Common L3VPNv6
....................................................................................................................................................................................................... 1830
3.2.35.43 Example for Configuring a DCI Scenario with a VLAN Base Accessing MPLS EVPN IRBv6 (with a
PE Functioning as a DC-GW).............................................................................................................................................. 1841
3.2.35.44 Example for Configuring a DCI Scenario with a VXLAN EVPN Accessing MPLS EVPN IRBv6... 1850
4 VXLAN..................................................................................................................................1860
4.1 VXLAN.................................................................................................................................................................................. 1860
4.1.1 VXLAN Introduction..................................................................................................................................................... 1860
4.1.2 VXLAN Basics..................................................................................................................................................................1862
Issue draft 05 Copyright © Huawei Technologies Co., Ltd. xiii

(2020-04-09)
4.1.2.1 VXLAN Basic Concepts............................................................................................................................................. 1862

4.1.2.2 Combinations of Underlay and Overlay Networks....................................................................................... 1865
4.1.2.3 VXLAN Packet Format............................................................................................................................................. 1866
4.1.2.4 EVPN VXLAN Fundamentals..................................................................................................................................1868
4.1.2.5 VXLAN Gateway Deployment............................................................................................................................... 1873
4.1.3 Functional Scenarios.................................................................................................................................................... 1875
4.1.3.1 Centralized VXLAN Gateway Deployment in Static Mode..........................................................................1875
4.1.3.2 Centralized VXLAN Gateway Deployment Using BGP EVPN..................................................................... 1884
4.1.3.3 Distributed VXLAN Gateway Deployment Using BGP EVPN......................................................................1895
4.1.4 Function Enhancements............................................................................................................................................. 1912
4.1.4.1 Using Three-Segment VXLAN to Implement Layer 3 Interconnection Between DCs........................1912
4.1.4.2 Using Three-Segment VXLAN to Implement Layer 2 Interconnection Between DCs........................1916
4.1.4.3 VXLAN Active-Active Reliability............................................................................................................................1920
4.1.4.4 NFVI Distributed Gateway..................................................................................................................................... 1926
4.1.5 Application Scenarios for VXLAN............................................................................................................................ 1939
4.1.5.1 Application for Communication Between Terminal Users on a VXLAN................................................. 1939
4.1.5.2 Application for Communication Between Terminal Users on a VXLAN and Legacy Network.......1940
4.1.5.3 Application in VM Migration Scenarios............................................................................................................. 1942
4.1.5.4 Application for BRAS Access Through VXLAN................................................................................................. 1943
4.1.6 Terminology for VXLAN.............................................................................................................................................. 1945
4.2 VXLAN Configuration......................................................................................................................................................1946
4.2.1 Overview of VXLAN..................................................................................................................................................... 1946
4.2.2 VXLAN Licensing Requirements and Configuration Precautions................................................................. 1952
4.2.3 Activating VXLAN Interface Licenses..................................................................................................................... 1956
4.2.4 Configuring VXLAN in Centralized Gateway Mode for Static Tunnel Establishment............................1956
4.2.4.1 Configuring a VXLAN Service Access Point...................................................................................................... 1958
4.2.4.2 Configuring a VXLAN Tunnel................................................................................................................................ 1961
4.2.4.3 Configuring a Layer 3 VXLAN Gateway.............................................................................................................1962
4.2.4.4 (Optional) Configuring Static MAC Address Entries and MAC Address Limiting............................... 1963
4.2.4.5 Verifying the Configuration of VXLAN in Centralized Gateway Mode................................................... 1964
4.2.5 Configuring VXLAN in Centralized Gateway Mode Using BGP EVPN........................................................ 1965
4.2.5.5 Verifying the Configuration of VXLAN in Centralized Gateway Mode Using BGP EVPN.................1977
4.2.6 Configuring VXLAN in Distributed Gateway Mode Using BGP EVPN........................................................ 1978
4.2.6.5 Verifying the Configuration of VXLAN in Distributed Gateway Mode Using BGP EVPN................. 1997
Issue draft 05 Copyright © Huawei Technologies Co., Ltd. xiv

(2020-04-09)
4.2.7 Configuring Three-Segment VXLAN to Implement DCI.................................................................................. 1998

4.2.7.1 Configuring Three-Segment VXLAN to Implement Layer 3 Interworking.............................................1998
4.2.7.2 Configuring Three-Segment VXLAN to Implement Layer 2 Interworking.............................................2000
4.2.7.3 Verifying the Configuration of Using Three-Segment VXLAN to Implement DCI.............................. 2002
4.2.8 Configuring the Static VXLAN Active-Active Scenario..................................................................................... 2002
4.2.9 Configuring the Dynamic VXLAN Active-Active Scenario...............................................................................2006
4.2.10 Configuring BRAS Access Through a PW and a VXLAN Tunnel................................................................. 2010
4.2.11 Configuring NFVI Distributed Gateway.............................................................................................................. 2013
4.2.11.1 Configuring an L3VPN Instance on a DCGW................................................................................................ 2016
4.2.11.2 Configuring Route Advertisement on a DC-GW.......................................................................................... 2018
4.2.11.3 Configuring Route Advertisement on an L2GW/L3GW............................................................................. 2021
4.2.11.4 Configuring Load Balancing................................................................................................................................ 2023
4.2.11.5 Verifying the NFVI Distributed Gateway Configuration............................................................................ 2024
4.2.12 Maintaining VXLAN................................................................................................................................................... 2025
4.2.12.1 Configuring the VXLAN Alarm Function......................................................................................................... 2025
4.2.12.2 Collecting and Checking VXLAN Packet Statistics....................................................................................... 2026
4.2.12.3 Clearing VXLAN Packet Statistics...................................................................................................................... 2027
4.2.12.4 Checking Statistics about MAC Address Entries in a BD........................................................................... 2028
4.2.12.5 Clearing Statistics about Dynamic MAC Address Entries in a BD..........................................................2028
4.2.13 Configuration Examples for VXLAN..................................................................................................................... 2028
4.2.13.1 Example for Configuring Users on the Same Network Segment to Communicate Through a
VXLAN Tunnel........................................................................................................................................................................... 2028
4.2.13.2 Example for Configuring Users on Different Network Segments to Communicate Through a
VXLAN Layer 3 Gateway....................................................................................................................................................... 2033
4.2.13.3 Example for Configuring VXLAN in Centralized Gateway Mode Using BGP EVPN......................... 2038
4.2.13.4 Example for Configuring VXLAN in Distributed Gateway Mode Using BGP EVPN..........................2045
4.2.13.5 Example for Configuring Three-Segment VXLAN to Implement Layer 3 Interworking................. 2053
4.2.13.6 Example for Configuring Three-Segment VXLAN to Implement Layer 2 Interworking................. 2065
4.2.13.7 Example for Configuring Static VXLAN in an Active-Active Scenario (Layer 2 Communication)
....................................................................................................................................................................................................... 2073
4.2.13.8 Example for Configuring Dynamic VXLAN in an Active-Active Scenario (Layer 3 Communication)
....................................................................................................................................................................................................... 2081
4.2.13.9 Example for Configuring VXLAN over IPsec in an Active-Active Scenario.......................................... 2092
4.2.13.10 Example for Configuring the Static VXLAN Active-Active Scenario (in VLAN-Aware Bundle
Mode).......................................................................................................................................................................................... 2104
4.2.13.11 Example for Configuring IPv4 NFVI Distributed Gateway..................................................................... 2113
4.2.13.12 Example for Configuring IPv6 NFVI Distributed Gateway..................................................................... 2132
4.2.13.13 Example for Configuring the NFVI Distributed Gateway Function (Quad-Active DC-GWs)..... 2154
4.2.13.14 Example for Configuring Three-Segment VXLAN to Implement Layer 3 Interworking (IPv6
Services)..................................................................................................................................................................................... 2187
5 Multicast VPN.................................................................................................................... 2200

5.1 Multicast VPN in Rosen Mode..................................................................................................................................... 2200
5.1.1 Overview of Rosen MVPN......................................................................................................................................... 2200
5.1.2 Understanding Rosen MVPN.................................................................................................................................... 2200
Issue draft 05 Copyright © Huawei Technologies Co., Ltd. xv

(2020-04-09)
5.1.2.1 Concepts Related to Rosen MVPN...................................................................................................................... 2200

5.1.2.2 Inter-domain Multicast Implemented by MVPN............................................................................................ 2201
5.1.2.3 PIM Neighbor Relationships Between CEs, PEs, and Ps............................................................................... 2203
5.1.2.4 Share-MDT Setup Process...................................................................................................................................... 2205
5.1.2.5 MT Transmission Along a Share-MDT............................................................................................................... 2206
5.1.2.6 Switch-MDT Switchover.......................................................................................................................................... 2209
5.1.2.7 Multicast VPN Extranet........................................................................................................................................... 2211
5.1.2.8 BGP A-D MVPN.......................................................................................................................................................... 2217
5.1.3 Application Scenarios for Rosen MVPN................................................................................................................ 2219
5.1.3.1 Single-AS MD VPN....................................................................................................................................................2219
5.1.4 Terminology for Rosen MVPN.................................................................................................................................. 2220
5.2 Multicast VPN in NG MVPN Mode............................................................................................................................ 2221
5.2.1 Overview of NG MVPN............................................................................................................................................... 2221
5.2.2 Understanding NG MVPN......................................................................................................................................... 2224
5.2.2.1 NG MVPN Control Messages................................................................................................................................ 2224
5.2.2.2 NG MVPN Private Multicast Routing................................................................................................................. 2240
5.2.2.2.1 PIM (S, G) Join/Prune........................................................................................................................................... 2242
5.2.2.2.2 PIM (*, G) Join/Prune............................................................................................................................................2246
5.2.2.3 NG MVPN Public Network Tunnel Principle.................................................................................................... 2257
5.2.2.3.1 MVPN Membership Autodiscovery.................................................................................................................. 2260
5.2.2.3.2 I-PMSI Tunnel Establishment............................................................................................................................. 2261
5.2.2.3.3 Switching Between I-PMSI and S-PMSI Tunnels......................................................................................... 2268
5.2.2.3.4 Transmitting multicast traffic on an NG MVPN.......................................................................................... 2273
5.2.2.3.5 NG MVPN Typical Deployment Scenarios on the Public Network....................................................... 2275
5.2.2.4 NG MVPN Extranet................................................................................................................................................... 2278
5.2.2.5 UMH Route Selection Fundamentals................................................................................................................. 2282
5.2.2.6 NG MVPN Reliability................................................................................................................................................ 2283
5.2.3 Application Scenarios for NG MVPN......................................................................................................................2294
5.2.3.1 Application of NG MVPN to IPTV Services....................................................................................................... 2294
5.2.4 Terminology for NG MVPN....................................................................................................................................... 2296
5.3 BIER....................................................................................................................................................................................... 2299
5.3.1 Overview of BIER.......................................................................................................................................................... 2299
5.3.2 Understanding BIER..................................................................................................................................................... 2300
5.3.2.1 IS-IS for BIER............................................................................................................................................................... 2300
5.3.2.2 BIER Forwarding Plane Fundamentals............................................................................................................... 2302
5.3.2.3 NG MVPN over BIER................................................................................................................................................ 2304
5.3.2.3.1 Introduction to NG MVPN over BIER.............................................................................................................. 2304
5.3.2.3.2 NG MVPN over BIER Control Message...........................................................................................................2305
5.3.2.3.3 Public Network Tunnels of NG MVPN over BIER ...................................................................................... 2306
1. BIER I-PMSI Tunnel Establishment............................................................................................................................... 2306
2. BIER S-PMSI Tunnel Establishment.............................................................................................................................. 2309
5.3.2.3.4 MVPN Traffic Forwarding Through NG MVPN over BIER........................................................................2313
Issue draft 05 Copyright © Huawei Technologies Co., Ltd. xvi

(2020-04-09)
5.3.2.4 Application Scenarios for BIER..............................................................................................................................2315

5.3.2.4.1 BIER Application to MVPN Services.................................................................................................................2315
5.3.3 Terminology for BIER................................................................................................................................................... 2316
5.4 IPv4 Multicast VPN Configuration in Rosen Mode...............................................................................................2317
5.4.1 Overview of IPv4 Multicast VPNs........................................................................................................................... 2317
5.4.2 IPv4 Multicast VPN in Rosen mode Licensing Requirements and Configuration Precautions.......... 2319
5.4.3 Configuring an MD VPN............................................................................................................................................ 2320
5.4.3.1 (Optional) Enabling IP Multicast VPN............................................................................................................... 2320
5.4.3.2 Enabling IP Multicast Routing.............................................................................................................................. 2321
5.4.3.3 Configuring a Share-Group and Binding it to an MTI..................................................................................2322
5.4.3.4 Configuring an MTI.................................................................................................................................................. 2323
5.4.3.5 (Optional) Configuring a Switch-MDT.............................................................................................................. 2325
5.4.3.6 Verifying the MD VPN Configuration................................................................................................................. 2326
5.4.4 Configuring BGP A-D Multicast VPN..................................................................................................................... 2327
5.4.5 Configuring MVPN Extranet......................................................................................................................................2328
5.4.6 Maintaining an IPv4 Multicast VPN....................................................................................................................... 2332
5.4.6.1 Deleting IPv4 Multicast VPN Statistics.............................................................................................................. 2332
5.4.6.2 Monitoring the Running Status of an IPv4 Multicast VPN......................................................................... 2332
5.4.6.3 Controlling the Generation of Logs.................................................................................................................... 2333
5.4.7 Configuration Examples for an IPv4 Multicast VPN......................................................................................... 2334
5.4.7.1 Example for Configuring Single-AS MD VPNs................................................................................................ 2334
5.4.7.2 Example for Configuring Multicast VPN in MDT-SAFI A-D Mode............................................................2357
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.......................................................................................... 2370
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............................................................................................. 2383
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..................................................................................................2396
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.......................................................................................................... 2408
5.5 IPv4 Multicast VPN Configuration in NG MVPN Mode...................................................................................... 2417
5.5.1 Overview of NG MVPN............................................................................................................................................... 2417
5.5.2 IPv4 Multicast VPN in NG MVPN mode Licensing Requirements and Configuration Precautions.. 2418
5.5.3 Configuring an Intra-AS NG MVPN........................................................................................................................ 2421
5.5.3.1 Configuring BGP MVPN Peers.............................................................................................................................. 2422
5.5.3.2 Configuring a P2MP LSP to Carry Multicast Traffic...................................................................................... 2423
5.5.3.3 Configuring PIM......................................................................................................................................................... 2427
5.5.3.4 (Optional) Configuring IGMP............................................................................................................................... 2427
5.5.3.5 (Optional) Configuring Switching Between I-PMSI and S-PMSI Tunnels..............................................2428
5.5.3.6 (Optional) Configuring NG MVPN ORF............................................................................................................ 2430
5.5.3.7 Verifying the Intra-AS NG MVPN Configuration............................................................................................ 2431
5.5.4 Configuring Intra-AS Segmented NG MVPN...................................................................................................... 2431
5.5.4.1 Configuring Route Reflection on an ABR..........................................................................................................2432
Issue draft 05 Copyright © Huawei Technologies Co., Ltd. xvii

(2020-04-09)
5.5.4.2 Establishing BGP MVPN Peer Relationships.................................................................................................... 2434

5.5.4.3 Configuring P2MP Tunnels to Bear Multicast Traffic................................................................................... 2434
5.5.4.4 Configuring the Support for Segmented Tunnels in an AS........................................................................ 2438
5.5.4.6 Configuring PIM......................................................................................................................................................... 2441
5.5.4.8 Verifying the Configuration of Intra-AS Segmented NG MVPN............................................................... 2442
5.5.5 Configuring an Inter-AS or Inter-Area NG MVPN............................................................................................. 2443
5.5.5.1 Configuring Inter-AS NG MVPN Option B........................................................................................................ 2443
5.5.5.1.1 Configuring Global MPLS LDP Functions and Enabling MPLS LDP on Interfaces.......................... 2444
5.5.5.1.2 Configuring an Automatic mLDP P2MP Tunnel..........................................................................................2445
5.5.5.1.3 Configuring a Static RP........................................................................................................................................ 2446
5.5.5.1.4 Configuring MP-IBGP Between a PE and an ASBR in the Same AS.....................................................2447
5.5.5.1.5 Configuring MP-EBGP Between ASBRs in Different ASs.......................................................................... 2448
5.5.5.1.6 Configuring BGP MVPN Peers........................................................................................................................... 2448
5.5.5.1.7 (Optional) Configuring Intra-AS MSDP Peers............................................................................................. 2449
5.5.5.1.8 Configuring a P2MP LSP to Carry Multicast Traffic...................................................................................2450
5.5.5.1.9 (Optional) Configuring Switching Between I-PMSI and S-PMSI Tunnels.......................................... 2453
5.5.5.1.10 Configuring PIM................................................................................................................................................... 2454
5.5.5.1.11 Configuring Route Exchange Between PEs and CEs................................................................................2455
5.5.5.2 Configuring Inter-AS NG MVPN Option C........................................................................................................ 2465
5.5.5.2.4 Configuring MP-IBGP Between a PE and an ASBR in the Same AS.....................................................2467
5.5.5.2.5 Configuring MP-EBGP for PEs and ASBRs in Different ASs.....................................................................2468
5.5.5.2.6 Configuring a Routing Policy to Control Label Distribution on ASBRs............................................... 2469
5.5.5.2.10 Configuring PIM................................................................................................................................................... 2474
5.5.5.2.11 Configuring Route Exchange Between PEs and CEs................................................................................2475
5.5.5.3 Configuring NG MVPN Option B in an Inter-AS Seamless MPLS Scenario...........................................2475
5.5.5.3.4 Configuring MP-IBGP Among PEs, ABRs, and ASBRs in the Same AS................................................ 2477
5.5.5.3.5 Configuring MP-EBGP Between ASBRs in Different ASs.......................................................................... 2478
5.5.5.3.6 Configuring a Routing Policy to Control Label Distribution on ASBRs............................................... 2479
5.5.5.3.7 Configuring Route Reflection on an ABR...................................................................................................... 2479
Issue draft 05 Copyright © Huawei Technologies Co., Ltd. xviii

(2020-04-09)
5.5.5.3.10 (Optional) Configuring Switching Between I-PMSI and S-PMSI Tunnels........................................ 2483
5.5.5.4 Configuring NG MVPN Option C in Inter-AS Seamless MPLS Scenarios............................................... 2485
5.5.5.4.4 Configuring MP-IBGP Among PEs, ABRs, and ASBRs in the Same AS................................................ 2487
5.5.5.4.5 Configuring MP-EBGP for PEs and ASBRs in Different ASs.....................................................................2487
5.5.5.4.6 Configuring a Routing Policy to Control Label Distribution................................................................... 2488
5.5.5.4.10 (Optional) Configuring Switching Between I-PMSI and S-PMSI Tunnels........................................ 2494
5.5.5.4.11 Configuring PIM................................................................................................................................................... 2496
5.5.5.5 Configuring Inter-Area Seamless NG MVPN................................................................................................... 2497
5.5.5.5.7 Configuring PIM..................................................................................................................................................... 2504
5.5.5.5.8 Configuring Route Exchange Between PEs and CEs.................................................................................. 2504
5.5.6 Configuring NG MVPN Extranet.............................................................................................................................. 2505
5.5.7 Configuring UMH Route Selection Rules............................................................................................................. 2507
5.5.8 Configuring Dual-Root 1+1 Protection................................................................................................................. 2508
5.5.9 Configuration Examples for NG MVPN.................................................................................................................2511
5.5.9.1 Example for Configuring an Intra-AS NG MVPN with an mLDP P2MP LSP.........................................2511
5.5.9.2 Example for Configuring an Intra-AS NG MVPN with an RSVP-TE P2MP LSP.................................... 2527
5.5.9.3 Example for Configuring Dual-Root 1+1 Protection for RSVP-TE P2MP LSPs......................................2544
5.5.9.4 Example for Configuring Dual-Root 1+1 Protection for mLDP P2MP LSPs.......................................... 2561
5.5.9.5 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.................................................................................... 2576
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 RSVP-TE P2MP LSP............................................................................... 2590
5.5.9.7 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.............................................................................. 2605
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 RSVP-TE P2MP LSP..........................................................................2616
5.5.9.9 Example for Configuring an Intra-AS NG MVPN with Segmented Tunnels......................................... 2627
5.5.9.10 Example for Configuring Dual-Root 1+1 Protection for Intra-AS Segmented Tunnels.................. 2642
5.5.9.11 Example for Configuring an Inter-AS NG MVPN Option B...................................................................... 2664
5.5.9.12 Example for Configuring an Inter-AS NG MVPN in Option C................................................................. 2678
5.5.9.13 Example for Configuring an Inter-AS Seamless MPLS NG MVPN Option B...................................... 2689
Issue draft 05 Copyright © Huawei Technologies Co., Ltd. xix

(2020-04-09)
5.5.9.14 Example for Configuring an Inter-AS Seamless MPLS NG MVPN Option C...................................... 2702
5.5.9.15 Example for Configuring an Inter-Area Seamless MPLS NG MVPN..................................................... 2715
5.5.9.16 Example for Configuring an Inter-area NG MVPN......................................................................................2730
5.5.9.17 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............................................................................2742
5.5.9.18 Example for Configuring NG MVPN Extranet in the Remote Route Leaking Scenario (BAS
Multicast)................................................................................................................................................................................... 2753
5.5.9.19 Example for Configuring NG MVPN Extranet in the Local Cross Scenario Where the Source and
Receiver VPN Instances Reside on the Same PE.......................................................................................................... 2764
5.5.9.20 Example for Enabling the Highest IP Address to Be Selected as the UMH on an NG MVPN..... 2773
5.6 BIER Configuration.......................................................................................................................................................... 2784
5.6.1 Overview of BIER.......................................................................................................................................................... 2784
5.6.2 BIER Licensing Requirements and Configuration Precautions...................................................................... 2786
5.6.3 Configuring NG MVPN over BIER........................................................................................................................... 2788
5.6.3.1 Configuring BIER on the Public Network.......................................................................................................... 2789
5.6.3.2 Enabling BIER for an IGP........................................................................................................................................ 2790
5.6.3.3 Configuring BGP MVPN Peer Relationships..................................................................................................... 2791
5.6.3.4 Configuring a BIER Tunnel to Carry Multicast Traffic.................................................................................. 2792
5.6.3.6 Configuring PIM......................................................................................................................................................... 2796
5.6.3.8 Verifying the NG MVPN over BIER Configuration......................................................................................... 2797
5.6.4 Configuring the BIER Loopback Board Enhancement Function................................................................... 2798
5.6.5 Configuring a Mode for BIER-MPLS to Process and Adjust TTLs................................................................. 2798
5.6.6 Configuration Examples for NG MVPN over BIER.............................................................................................2799
5.6.6.1 Example for Configuring NG MVPN over BIER............................................................................................... 2799
5.6.6.2 Example for Configuring NG MVPN over BIER Dual-Root 1+1 Protection........................................... 2812
6 Telemetry............................................................................................................................ 2824
6.1 Telemetry............................................................................................................................................................................ 2824
6.1.1 Overview of Telemetry................................................................................................................................................2824
6.1.2 Understanding Telemetry.......................................................................................................................................... 2825
6.1.2.1 Service Process of Telemetry Static Subscription........................................................................................... 2825
6.1.2.2 Service Process of Telemetry Dynamic Subscription..................................................................................... 2827
6.1.2.3 Key Telemetry Technologies.................................................................................................................................. 2829
6.1.3 Application Scenarios for Telemetry...................................................................................................................... 2841
6.1.3.1 Telemetry Applications in a Traffic Adjustment Scenario........................................................................... 2841
6.1.3.2 Telemetry Application in a Microburst Traffic Detection Scenario.......................................................... 2842
6.1.4 Terminology for Telemetry........................................................................................................................................ 2843
6.2 Telemetry Configuration................................................................................................................................................ 2844
6.2.1 Overview of Telemetry................................................................................................................................................2844
6.2.2 Telemetry Licensing Requirements and Configuration Precautions............................................................2845
6.2.3 Configuring Static Telemetry Subscription (IPv4 Collector).......................................................................... 2852
6.2.3.1 Configuring a Destination Collector................................................................................................................... 2853
Issue draft 05 Copyright © Huawei Technologies Co., Ltd. xx

(2020-04-09)
6.2.3.2 Configuring the Data to Be Sampled or a Customized Event................................................................... 2853

6.2.3.3 Creating a Subscription........................................................................................................................................... 2856
6.2.3.4 Verifying the Telemetry Configuration.............................................................................................................. 2859
6.2.4 Configuring Dynamic Telemetry Subscription (IPv4 Collector).................................................................... 2860
6.2.5 Configuring Static Telemetry Subscription (IPv6 Collector).......................................................................... 2862
6.2.5.1 Configuring an IPv6 Destination Collector....................................................................................................... 2862
6.2.5.2 Configuring the Data to Be Sampled or a Customized Event................................................................... 2863
6.2.5.3 Creating a Subscription........................................................................................................................................... 2865
6.2.5.4 Verifying the Telemetry Configuration.............................................................................................................. 2869
6.2.6 Configuring Dynamic Telemetry Subscription (IPv6 Collector).................................................................... 2869
6.2.7 Configuration Examples for Telemetry..................................................................................................................2871
6.2.7.1 Example for Configuring Static Telemetry Subscription Based on gRPC............................................... 2871
6.2.7.2 Example for Configuring Static Telemetry Subscription Based on UDP.................................................2874
6.2.7.3 Example for Configuring Dynamic Telemetry Subscription Based on gRPC (IPv4 Collector).........2876
6.2.7.4 Example for Configuring Dynamic Telemetry Subscription Based on gRPC (IPv6 Collector).........2878
Issue draft 05 Copyright © Huawei Technologies Co., Ltd. xxi

(2020-04-09)
New IP Technologies 1 Segment Routing MPLS
1 Segment Routing MPLS
1.1 Segment Routing MPLS
1.1.1 Introduction of Segment Routing MPLS
Definition
Segment Routing (SR) is a protocol designed to forward data packets on a
network based on source routes. Segment Routing MPLS is Segment Routing
based on the MPLS forwarding plane, which is Segment Routing for short
hereafter. Segment Routing divides a network path into several segments and
assigns a segment ID to each segment and network forwarding node. The
segments and nodes are sequentially arranged (segment list) to form a
forwarding path.
Segment Routing encodes the segment list identifying a forwarding path into a
data packet header. The segment ID is transmitted along with the packet. After
receiving the data packet, the receive end parses the segment list. If the top
segment ID in the segment list identifies the local node, the node removes the
segment ID and proceeds with the follow-up procedure. If the top segment ID
does not identify the local node, the node uses the Equal Cost Multiple Path
(ECMP) algorithm to forward the packet to a next node.
Purpose
With the progress of the times, more and more types of services pose a variety of
network requirements. For example, real-time UC&C applications prefer to paths
of low delay and low jitter, and big data applications prefer to high bandwidth
tunnels with a low packet loss rate. In this situation, the rule helping the network
adapt to service growth cannot catch up with the rapid service development and
even makes network deployment more complex and difficult to maintain.
The solution is to allow services to drive network development and to define the
network architecture. Specifically, an application raises requirements (on the delay,
bandwidth, and packet loss rate). A controller collects information, such as
Issue draft 05 Copyright © Huawei Technologies Co., Ltd. 1

(2020-04-09)
network topology, bandwidth usage, and delay information and computes an

explicit path that satisfies the service requirements.
Figure 1-1 Service-driven network
Segment Routing emerges in this context. Segment Routing is used to simply

define an explicit path. Nodes need to merely maintain the Segment Routing
information to adapt to rapid service growth in real time. Segment Routing has
the following characteristics:
● Extends existing protocols such as IGP to allow for better smooth evolution of
live networks.
● The SR supports both the controller's centralized control mode and
forwarder's distributed control mode, providing a balance between centralized
control and the distributed control.
● Uses the source routing technique to provide capabilities of rapid interaction
between networks and upper-layer applications.
Benefits
Segment Routing offers the following benefits:
● The control plane of MPLS network is simplified.
A controller or an IGP is used to uniformly compute paths and distribute
labels, without using RSVP-TE or LDP. Segment Routing can be directly applied
to the MPLS architecture without any change in the forwarding plane.
● Provides efficient topology independent-loop-free alternate (TI-LFA) FRR
protection for fast path failure recovery.
Based on the Segment Routing technology, combined with the RLFA (Remote
Loop-free Alternate) FRR algorithm, an efficient TI-LFA FRR algorithm is
formed. TI-LFA FRR supports node and link protection of any topology and
overcomes drawbacks in conventional tunnel protection.

(2020-04-09)
● Provides higher network capacity expansion capabilities.

MPLS TE is a connection-oriented technique. To maintain connections, nodes
need to send and process a large number of Keepalive packets, posing heavy
burdens on the control plane. Segment Routing controls any service paths by
merely operating labels on the ingress, and transit node do not have to
maintain path information, which reduces the burdens on the control plane.
In addition, Segment Routing labels equal to the sum of the number of
network-wide nodes and the number of local adjacencies. The label quantity
is related only to the network scale, not to the number of tunnels or the
service volume.
● Implements smoother evolution to SDN network.
Segment Routing is designed based on the source routing concept. Using the
source node alone can control forwarding paths over which packets are
transmitted across a network. The Segment Routing technique and the
centralized path computing module are used together to flexibly and
conveniently control and adjust paths.
Segment Routing supports both traditional and SDN networks. It is
compatible with existing equipment and ensures smooth evolution of existing
networks 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 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.
● SRGB: A segment routing global block (SRGB) is a set of local labels reserved
for segment routing of users.

(2020-04-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 segment indicates a destination address, and an

adjacency segment indicates a link over which data packets travel. The prefix and

(2020-04-09)
adjacency segments are 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 segment, adjacency segment, and node segment
can be used independently or in combinations. The following three main cases are
involved.
Prefix Segment
A prefix segment-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 segment-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 segment-based forwarding
paths are not fixed, and the ingress cannot control the whole forwarding path.
Adjacency Segment
In Figure 1-4, an adjacency segment is assigned to each adjacency. The adjacency

segments 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-04-09)
Figure 1-4 Adjacency segment-based forwarding path
Adjacency Segment + Node Segment

In Figure 1-5, adjacency and node segments are combined to forcibly include a
specific adjacency into a path. Nodes can use node segments 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 segment + node segment-based forwarding path
SR Forwarding Mechanism
SR can be used directly in the MPLS architecture, where the forwarding
mechanism remains. 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.

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

Prefix segments are manually configured. They may conflict on different devices.
Label conflicts are as follows:
● Prefix conflict: The same prefix is associated with two different SIDs.
● SID conflict: 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 SR-MPLS BE
SR LSPs are established using the segment routing technique, and uses prefix or
node segments 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 a tunnel) and are assigned labels.

(2020-04-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-6 Prefix label-based LSP establishment
Table 1-2 describes the process of using prefix labels to create an LSP shown in
Figure 1-6.
Table 1-2 LSP creation process
St Devi Operation
e ce
p
1 D An SRGB and a prefix SID are configured on a loopback interface of

D. D generates forwarding entries, encapsulates the 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
whole network through an IGP.
After the other devices receive the LSP, they parse the LSP, obtain the
prefix SID advertised by device D, and use the prefix to compute
labels based on local SRGBs. They run an IGP to compute a label
switched path and find next-hop devices and outgoing labels.
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).

(2020-04-09)
St Devi Operation
e ce
p
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
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-7 Prefix label-based data forwarding
Table 1-3 describes the data forwarding process on the network shown in Figure
1-7.

(2020-04-09)
Table 1-3 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
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-7, 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.
Enabling PHP affects both the MPLS QoS and TTL functions on the egress. For
details, see Table 1-4.
Table 1-4 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-04-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
removes 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.2.1 SR and LDP Communication

(2020-04-09)
Users are gravitating to segment routing (SR), a new tunneling technique that is a
substitute for MPLS. SR is introduced to simplify network deployment and
management and reduce capital expenditure (CAPEX).
MPLS LDP is a mainstream tunneling technique that is widely used on bearer

networks. When SR is edging out LDP, LSP and SR coexist for a long term, which
poses a challenge to the interworking between LDP and SR networks.
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.
To implement the interworking between the LDP and SR networks, the SR

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 and LDP interworking involves two directions: SR
to LDP and LDP to SR.
SR to LDP
Figure 1-8 describes the process of creating an E2E SR-to-LDP LSP.
Figure 1-8 Process of creating an E2E SR-to-LDP LSP
The process of creating an E2E SR-to-LDP LSP is as follows:

(2020-04-09)
1. 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.
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 label destined for PE2 and encapsulates an
SR label to an LDP label based on the mapping between the prefix and SID.
LDP to SR
Figure 1-9 describes the process of creating an E2E LDP-to-SR LSP.
Figure 1-9 Process of creating an E2E LDP-to-SR LSP
The process of creating an E2E LDP-to-SR LSP is as follows:

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

(2020-04-09)
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.
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 label based on the mapping between the prefix and SID.
1.1.2.3 IS-IS for SR

Segment routing 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 that enable SID and NE SR capabilities, as shown in
Table 1-5.
Table 1-5 IS-IS Sub-TLV extension for SID and NE SR capabilities

Item Function Position
Prefix-SID Sub- Advertises the SR prefix ● IS-IS Extended IPv4

TLV 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
● ...
Adj-SID Sub-TLV Advertises SR Adjacency ● IS-IS Extended IS reachability

SIDs on a P2P network. TLV-22
● 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

(2020-04-09)
Item Function Position
LAN-Adj-SID Advertises SR Adjacency ● IS-IS Extended IS reachability

Sub-TLV 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 SID or SR-Capabilities Sub-TLV and SR

TLV 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 IS-IS Router Capability TLV-242

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

Sub-TLV algorithm.
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-10 shows the
format of the Prefix-SID sub-TLV.
Figure 1-10 Prefix-SID Sub-TLV format
Table 1-6 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-04-09)

Name
Flags 8 bits Flags field. Figure 1-11 shows its format.
Figure 1-11 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-04-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 rightmost 20 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-12 shows its format.
Figure 1-12 Adj-SID Sub-TLV format
Table 1-7 Meanings of fields in the Adj-SID Sub-TLV

Name

(2020-04-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 rightmost 20 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-04-09)
Figure 1-14 shows the format of the LAN-Adj-SID Sub-TLV.
Figure 1-14 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-15 shows the format of the SID/Label Sub-TLV.
Figure 1-15 SID/Label Sub-TLV format
Table 1-8 Meanings of fields in the SID/Label Sub-TLV

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

(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-16 shows the SID/Label Binding TLV format.
Figure 1-16 SID/Label Binding TLV format

(2020-04-09)
Table 1-9 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-17 shows the format of the SR-Capabilities Sub-TLV.
Figure 1-17 SR-Capabilities Sub-TLV format
Table 1-10 Meanings of fields in the SR-Capabilities Sub-TLV

Name

(2020-04-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-19 shows the format of the SR-Algorithm Sub-TLV.

(2020-04-09)
Figure 1-19 SR-Algorithm Sub-TLV format
Table 1-11 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-20 shows the format of the SR Local Block Sub-TLV.
Figure 1-20 SR Local Block Sub-TLV format
Table 1-12 Meanings of fields in the SR Local Block Sub-TLV

Name
Flags 8 bits Flags field. This field is not defined.
Range 8 bits SRLG range.
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.

(2020-04-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.
IS-IS SR LSP Creation

An intra-IGP-area SR LSP is created.
In Figure 1-21, devices run IS-IS. Segment routing is used and requires each device
to advertise the SR capability and supported SRGB. In addition, the advertising end
advertises a prefix SID offset within the SRGB range. The receive end computes an
effective label value to generate a forwarding entry.
Figure 1-21 IS-IS SR LSP creation
Devices A through F are deployed in areas of the same level. All Devices run IS-IS.
An SR tunnel originates from Device A and is terminated at Device D.
An SRGB is configured on Device D. A prefix SID is set on the loopback interface of
Device D. Device D encapsulates the SRGB and prefix SID into a link state protocol
data unit (LSP) (for example, IS-IS Router Capability TLV-242 containing SR-
Capability Sub-TLV) and floods the LSP across the network. After another device
receives the SRGB and prefix SID, it uses them to compute a forwarding label, uses
the IS-IS topology information, and runs the Dijkstra algorithm to calculate an LSP
and LSP forwarding entries.
An inter-IGP area SR LSP is created
In Figure 1-22, 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.

(2020-04-09)
Figure 1-22 Inter-IGP area SR LSP
Devices A and D are deployed in different areas, and all devices run IS-IS. An SR
tunnel originates from Device A and is terminated at Device D.
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
SRGB and prefix SID into an LSP (for example, IS-IS Router Capability TLV-242
containing SR-Capability 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.
1.1.2.4 OSPF for SR
Segment routing 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 that enable SID and NE SR capabilities. Table 1-13
describes TLVs of the OSPF SR extension.
Table 1-13 TLVs of the OSPF SR extension
Type Item Function Position
TLV SR-Algorithm Advertises the used Type 10 Opaque LSA

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

Range TLV or SRGB scope.
SRMS Advertises the priority Type 10 Opaque LSA

Preference of SR mapping server
TLV as which a local NE
functions

(2020-04-09)
Type Item Function Position
Sub-TLV SID/Label Advertises SR SIDs or ● SID/Label Range TLV

Sub-TLV 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 prefix SID. Opaque LSA's OSPFv2
Extended Prefix TLV and
OSPF Extended Prefix
Range TLV
Adj-SID Sub- Advertises SR OSPFv2 Extended Link

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

Sub-TLV Adjacency SIDs on a Opaque LSA's OSPFv2
LAN. Extended Link TLV
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-23 shows the format of the SR-Algorithm TLV.
Figure 1-23 SR-Algorithm TLV format
Table 1-14 Fields in the SR-Algorithm TLV

Name
Type 16 bits TLV type value.
Algorithm 8 bits Algorithm.

(2020-04-09)
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-24 shows the format of the SID/Label Range TLV.
Figure 1-24 SID/Label Range TLV format
Table 1-15 Fields in the SID/Label Range TLV

Name
Range Size 24 bits SRLG range.
Reserved 8 bits Reserved field.
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-25 shows the format of the SRMS Preference TLV.
Figure 1-25 SRMS Preference TLV format
Table 1-16 Fields in the SRMS Preference TLV

Name

(2020-04-09)

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-26 shows the
format of the SID/Label Sub-TLV.
Figure 1-26 SID/Label Sub-TLV format
Table 1-17 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-27.
Figure 1-27 Prefix-SID Sub-TLV format

(2020-04-09)
Table 1-18 Fields in the Prefix-SID Sub-TLV

Name

(2020-04-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.
● 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 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-04-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-29 shows its format.
Figure 1-29 Adj-SID Sub-TLV format
Table 1-19 Field in the Adj-SID Sub-TLV

Name

(2020-04-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.
Figure 1-31 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.

(2020-04-09)
Figure 1-31 LAN-Adj-SID Sub-TLV format
1.1.2.5 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-20 describes the
comparison between SR-MPLS TE and RSVP-TE.
Table 1-20 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-04-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.5.1 Topology Collection and Label Allocation
Network Topology Collection Modes

Network topology information is collected in either of the following modes:
● A forwarder runs IGP to collect network topology information and uses BGP-
LS to report the information to the controller.
● Both the controller and forwarders run IGP. Each forwarder floods network
topology information to one another. Each forwarder reports the information
to the controller.

(2020-04-09)
Label Allocation Modes

A forwarder runs an IGP to assign labels and runs a BGP-LS to report label
information to a controller. SR-MPLS TE mainly uses adjacency labels (adjacency
segment), and node labels can also be used. Adjacency labels are assigned by the
ingress. They are valid locally and unidirectional. The node labels are manually
configured and globally valid. Adjacency labels and node labels are advertised
using IGP. In Figure 1-32, adjacency label 9003 identifies the PE1-to-P3 adjacency
and is assigned by PE1. Adjacency label 9004 identifies the P3-to-PE1 adjacency
and is assigned by P3.
Figure 1-32 IGP label assignment
IGP SR is enabled on PE1, PE2, and P1 through P4 to establish IGP neighbor

relationships between each pair of directly connected nodes. In SR-capable IGP
instances, each outbound IGP interface is assigned an SR Adjacency Segment
label. SR IGP advertises the Adjacency Segment labels across a network. P3 is used
as an example. In Figure 1-32, IGP-based label allocation is as follows:
1. P3 runs IGP to apply for a local dynamic label for an adjacency. For example,
P3 assigns adjacency label 9002 to the P3-to-P4 adjacency.
2. P3 runs IGP to advertise the adjacency label and flood it across the network.
3. P3 uses the label to generate a label forwarding table.
4. After the other nodes on the network run IGP to learn the Adjacency Segment
label advertised by P3, the nodes do not generate local forwarding tables.
PE1, P1, P2, P3, and P4 assign and advertise adjacency labels in the same way as
P3 does. The label forwarding table is then generated on each node. A node
establishes a BGP-LS neighbor relationship with the controller, generates topology

(2020-04-09)
information, including SR labels, and reports topology information to the

controller.
1.1.2.5.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-33 SR-MPLS TE Tunnel
In Figure 1-33, 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-34). The forwarder runs PCEP to delegate the tunnel to the
controller for management.
● An SR-MPLS TE tunnel is manually configured on a forwarder.

(2020-04-09)
The forwarder delegates LSPs to the controller for management.
SR-MPLS TE Tunnel Establishment

If a service (for example, VPN) is 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-34.
Figure 1-34 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 and combines adjacency labels 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-34, 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-34, the process of delivering label stacks on the controller is as
follows:

(2020-04-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.
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.5.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-35, an example is provided to describe the process of forwarding SR-
MPLS TE data with manually specified adjacency labels.
Figure 1-35 SR-MPLS TE data packet forwarding (based on adjacency labels)

(2020-04-09)
In Figure 1-35, 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 strips off label 1003
from the label stack {1003, 1006, 100} and forwards the packet downstream
through A-B 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.5 SR-MPLS TE.
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.

(2020-04-09)
Figure 1-36 SR-MPLS TE forwarding principles (node+adjacency)
On the network shown in Figure 1-36, 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.
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 1006 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.

(2020-04-09)
1.1.2.5.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-37, 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.
Figure 1-37 SR-MPLS TE HSB networking
1.1.2.5.5 BFD for SR-MPLS TE

SR-MPLS TE does not use a protocol. 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 the label stack
is withdrawn. Therefore, BFD must be used to monitor faults in the SR-MPLS TE
LSP. A fault detected by BFD triggers a primary/backup SR-MPLS TE LSP
switchover. BFD for SR-MPLS TE is an E2E rapid detection mechanism that rapidly
detects faults in links of an SR-MPLS TE tunnel. BFD for SR-MPLS TE modes are as
follows:
● BFD for SR-MPLS TE LSP: SR-MPLS TE LSPs rely on BFD for link detection. To
prevent traffic loss in the case of a primary SR-MPLS TE LSP failure, BFD for
SR-MPLS TE LSP can be configured, but a backup LSP must be available. BFD
for SR-MPLS TE LSP supports both static and dynamic BFD sessions:

(2020-04-09)
– Static BFD session: The local and remote discriminators are manually
specified. The local discriminator of the local node must be equal to the
remote discriminator of the remote node. The remote discriminator of
the local node must be equal to the local discriminator of the remote
node. A discriminator inconsistency causes a failure to establish a BFD
session. After the BFD session is established, the interval at which BFD
packets are received and the interval at which BFD packets are sent can
be modified.
– Dynamic BFD session: The local and remote discriminators do not need to
be manually specified. After the SR-MPLS TE tunnel goes Up, a BFD
session is triggered. The devices on both ends of a BFD session to be
established negotiate the local discriminator, remote discriminator,
interval at which BFD packets are received, and interval at which BFD
packets are sent.
A BFD session is bound to an SR-MPLS TE LSP. This means that a BFD session
is established between the ingress and egress. A BFD packet is sent by the
ingress and forwarded to the egress through an LSP. The egress responds to
the BFD packet. A BFD session on the ingress can rapidly detect the status of
the path through which the LSP passes.
If a link fault is detected, the BFD module notifies the forwarding plane of the
fault. The forwarding plane searches for a backup SR-MPLS TE LSP and
switches traffic to the backup SR-MPLS TE LSP.
● BFD for SR-MPLS TE tunnel: BFD for SR-MPLS TE tunnel must be used with
BFD for SR-MPLS TE LSP.
– BFD for SR-MPLS TE LSP controls the status of the primary/backup LSP
switchover. BFD for SR-MPLS TE tunnel checks actual status of tunnels.
▪ If BFD for SR-MPLS TE tunnel is not configured, the default tunnel

status keeps Up, and the effective status cannot be determined.
▪ If BFD for SR-MPLS TE tunnel is configured and the BFD status is set
to administrative Down, the BFD session does not work, and the
tunnel interface status is unknown.
▪ BFD for SR-MPLS TE tunnel is configured and the BFD status is not
set to administrative Down, the tunnel interface status is inconsistent
with the BFD status.
– The interface status of an SR-MPLS TE tunnel keeps consistent with the
status of BFD for SR-MPLS TE tunnel. The BFD session goes Up slowly
because of BFD negotiation. If a new label stack is delivered for a tunnel
in the Down state and the BFD for this tunnel goes Up, the process takes
10 to 20 seconds. As a result, hard tunnel convergence is delayed if no
protection is enabled for the tunnel.
● BFD for SR-MPLS TE (one-arm mode): A Huawei device on the ingress
cannot use BFD for SR-MPLS TE LSP to communicate with a non-Huawei
device on the egress. In this situation, no BFD session can be established. In
this case, one-arm BFD for SR-MPLS TE can be used.
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 the
forwarding plane receives BFD packets, it removes MPLS labels and searches
for a route matching the destination IP address of the ingress. The forwarding

(2020-04-09)
plane on the egress loops back the BFD packets to the ingress. The ingress
processes the BFD packets. This process is the one-arm detection mechanism.
In the following example, VPN traffic recurses to an SR-MPLS TE LSP, in the
scenario where BFD for SR-MPLS TE LSP is used.
Figure 1-38 BFD for SR-MPLS TE
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. Configure BFD to monitor the SR-
MPLS TE tunnel. If BFD enters the DetectDown state, the VPN recurses to another
SR-MPLS TE tunnel.
1.1.2.5.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.
In Figure 1-39, 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

(2020-04-09)
Figure 1-39) 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-39 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.5.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: AF1, AF2, AF3, AF4, BE, CS6, CS7, and EF. 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-
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.

(2020-04-09)
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-40 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 TE1 and voice traffic to SR-MPLS TE2.
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 TE3.
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-40 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.
● This function is not supported on a P.

(2020-04-09)
1.1.2.6 BGP for SR
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 SR 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 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-41, 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.
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.
● 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-04-09)
Figure 1-41 BGP EPE networking
On the network shown in Figure 1-41, 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-41,
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. For multi-hop EBGP peers, they must be directly
connected through physical links. This is because transit nodes do not have BGP
peer SID information, resulting in forwarding failures.
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 and SR-MPLS TE tunnels.
● 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.

(2020-04-09)
● 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.
Fault Association
On the network shown in Figure 1-42, 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.
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-42 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

(2020-04-09)
network layer reachability information (NLRI) field and reports it to the controller.
Figure 1-43 and Figure 1-44 show Link NLRI formats.
Figure 1-43 Link NLRI format for Peer-Node and Peer-Adj SIDs advertised by BGP-
LS
Figure 1-44 Link NLRI format for Peer-Set SIDs advertised by BGP-LS

(2020-04-09)
Table 1-21 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, as shown in
Figure 1-45.
Figure 1-45 Peer SID TLV format
Table 1-22 Fields in a peer SID TLV
Type 16 bits TLV type.

(2020-04-09)
Flags 8 bits Flags field used in a Peer-Adj SID TLV. Figure 1-46
shows the format of this field.
In this field:
● V: value flag. If set, the Adj-SID carries a value. By
default, the flag is set.
● L: local flag. If set, the value or index carried by the
Adj-SID has local significance. By default, the flag
is set.
Weight 8 bits Weight of the Adj-SID, used for load balancing

purposes.

(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.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-47, 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.

(2020-04-09)
● 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-47, 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}.
Figure 1-47 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 BIDs 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

(2020-04-09)
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-48). 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
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-48. In the following example, the tunnel configuration on the
controller is described.

(2020-04-09)
Figure 1-48 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.
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.
3. The controller runs NETCONF and PCEP to deliver tunnel configurations and
the label stack to the forwarder.
In Figure 1-48, 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.

(2020-04-09)
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-49, 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.
Figure 1-49 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

(2020-04-09)
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.
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-50, 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
twoLSPs. 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.

(2020-04-09)
Figure 1-50 E2E SR-MPLS TE HSB networking
In Figure 1-50, 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,
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-51, 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

(2020-04-09)
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-51 E2E SR-MPLS TE tunnel protection networking
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

(2020-04-09)
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. If a new label stack is delivered for a
tunnel in the Down state and BFD for this tunnel goes Up, the process
takes more than 10 seconds. As a result, hardware-based tunnel
convergence is delayed if no protection is enabled for the tunnel.
In Figure 1-52, 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.
Figure 1-52 One-arm BFD for E2E SR-MPLS TE (BFD loopback packets are
forwarded through a tunnel.)

(2020-04-09)
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-53.
Figure 1-53 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-54, 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

(2020-04-09)
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.
Figure 1-54 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 z to generate BGP

(2020-04-09)
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
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

(2020-04-09)
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:
● 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.
● 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

(2020-04-09)
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
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-55, 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-55 Public network BGP route recursive to an SR LSP
In Figure 1-56, 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-04-09)
Figure 1-56 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-57, 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-57 Static route recursive to an SR LSP

(2020-04-09)
In Figure 1-58, 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-58 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-59 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-04-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-59 Basic VPN recursive to an SR LSP
The network shown in Figure 1-60 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-04-09)
Figure 1-60 Basic VPN recursive to an SR-MPLS TE tunnel
HVPN
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-61 HVPN recursive to an SR LSP
In Figure 1-61, the deployment is as follows:

(2020-04-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 SPE 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 NPE.
2. After receiving the packet, the NPE searches its VPN forwarding table for an
LSP to forward the packet based on the destination address of the packet.
Then, the NPE 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-62, 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-62 VPN FRR networking

(2020-04-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-62.
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-62.
1.1.2.8.3 L2VPN Recursive to an SR Tunnel

Figure 1-63 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-63, 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-04-09)
Figure 1-63 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-64, 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-04-09)
Figure 1-64 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-65, 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-04-09)
Figure 1-65 Unicast traffic transmission in EVPN recursive to an SR LSP scenario
EVPN Recursive to an SR-MPLS TE Tunnel

In Figure 1-66, 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-66 Unicast traffic transmission in EVPN recursive to an SR-MPLS TE

tunnel scenario

(2020-04-09)
1.1.2.9 SBFD for SR
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-67 shows SBFD principles. 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.
The initiator first sends an SBFD packet with the initial state of Down and
destination port number 7784 to the reflector.
● 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 SBFD packets 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 packets are discarded. If they
match and the reflector is in the working state, the reflector constructs looped
SBFD packets. If they match and the reflector is not in the working state, the
reflector sets the status to Admin Down in packets.
Figure 1-67 SBFD principles

(2020-04-09)
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-68 shows the SBFD state machine
running on the initiator.
Figure 1-68 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. When SBFD monitors SR tunnels, the initiator-to-
reflector path uses MPLS label forwarding, and the reflector-to-initiator path uses
multi-hop IP forwarding.
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-69.
Assume that the SRGB scope [16000-16100] is set on each PE and P on the
network shown in Figure 1-69. 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.

(2020-04-09)
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-69 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-04-09)
Figure 1-70 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.
● SBFD for SR-MPLS TE tunnel is configured and the SBFD status is not set to
administrative Down, the tunnel interface status is inconsistent with the SBFD
status.

(2020-04-09)
1.1.2.10 TI-LFA FRR

Topology-independent loop-free alternate (TI-LFA) fast reroute (FRR) protects
links and nodes on segment routing tunnels. If a link or node fails, TI-LFA FRR
rapidly switches traffic to a backup path, minimizing traffic loss.
Related Concepts
Table 1-25 TI-LFA FRR related concepts

Concep Definition
t
P space The P space contains a set of nodes reachable to the root node on
links, not the protected link, along the SPF tree that originates from
the protected link's source node functioning as the root node.
Extende The extended P space contains nodes reachable to the root nodes on
dP links, not the protected link, along the SPF trees originating from the
space root nodes that are neighbors of protected link's source node.
Q space The Q space contains nodes reachable to the root node on links, not
the protected link, along the reverse SPF tree originating from the
protected link's destination node functioning as the root node.
PQ A PQ node resides in both the extended P space and Q space. The PQ

node node functions as the destination node of a protected tunnel.
LFA The loop-free alternate (LFA) algorithm computes a standby link. A

root node that can provide a standby link runs the Shortest Path First
(SPF) protocol to compute the shortest path to a destination node.
The root node then computes a loop-free standby link with the
smallest cost. For more information about LFA, see IS-IS Auto FRR.
RLFA Remote LFA (RLFA) computes a PQ node based on a protected path

and establishes a tunnel between the source and PQ nodes to provide
next hop protection. If the protected link fails, traffic automatically
switches to the backup path, which improves network reliability. For
more information about RLFA, see IS-IS Auto FRR.
TI-LFA In some LFA or RLFA scenarios, the P space and Q space do not share
nodes or have directly connected neighbors. Consequently, no backup
path can be calculated, which does not meet reliability requirements.
In this situation, TI-LFA can be used. The TI-LFA algorithm computes
the P space and Q space based on a protected path, a shortest path
tree (also called a post-convergence tree), and a repair list. The
algorithm establishes a segment routing tunnel between the source
node and PQ node to provide backup next hop protection. If the
protected link fails, traffic automatically switches to the backup path,
which improves network reliability.
Background
Conventional LFA requires that at least one neighbor be a loop-free next hop to a
destination. RLFA requires that there be at least one node that connects to the

(2020-04-09)
source and destination nodes along links without passing through any faulty node.
Unlike LFA or RLFA, TI-LFA uses an explicit path to represent a backup path, which
poses no requirements on topology constraints and provides more reliable FRR.
In Figure 1-71, there are packets that need to be sent from Device A to Device F. If
the P space and Q space do not intersect, RLFA requirements fail to be fulfilled,
and RLFA cannot compute a backup path, that is, the Remote LDP LSP. If a fault
occurs on the link between Device B and Device E, Device B forwards data packets
to Device C. Device C is not a Q node and cannot forward packets to the
destination IP address directly. In this situation, Device C has to recompute a path.
The cost of the link between Device C and Device D is 1000. Device C considers
that the optimal path to Device F passes through Device B. Device C loops the
packet to Device B, leading to a loop and resulting in a forwarding failure.
Figure 1-71 RLFA networking
TI-LFA can be used to solve this problem. In Figure 1-72, if a fault occurs on the
link between Device B and Device E, Device B enables TI-LFA FRR backup entries
and adds new path information (node label of Device C and adjacency label for
the C-D adjacency) to the packets to ensure that the data packets can be
forwarded along the backup path.

(2020-04-09)
Figure 1-72 TI-LFA networking
Benefits
Segment routing-based TI-LFA FRR has the following advantages:
1. Meets basic requirements of IP FRR rapid convergence.
2. Theoretically supports all protection scenarios.
3. Uses an algorithm with moderate complexity.
4. Selects a backup path over a converged route and has no intermediate state,
compared with the other FRR techniques.
TI-LFA FRR Principles

In Figure 1-73, PE1 is a source node, P1 is a faulty node, and PE3 is a destination
node. Link costs are marked.
TI-LFA traffic protection involves link and node protection.
● Link protection: protects traffic passing through a specific link.
● Node protection: protects traffic passing through a specific node. Node
protection takes precedence over link protection.

(2020-04-09)
Figure 1-73 Typical TI-LFA networking
In the following example, the process of node protection is as follows. In Figure

1-73, traffic travels along a path PE1->P1->P5->PE3. If P1 fails, TI-LFA computes
the P space, Q space, SPF tree (also called the post-convergence tree), backup
outbound interface, and repair list. Traffic is forwarded along the backup path to
the destination PE3, which implements rapid protection to prevent traffic loss.
TI-LFA FRR computation is as follows:
1. Computes the P space. It contains the set of nodes reachable to the root node
on links, not the protected link, along the SPF tree that originates from the
protected link's source node functioning as the root node.
2. Computes the space Q. It contains the set of nodes reachable to the root node
on links, not the protected link, along the reverse SPF tree that originates
from the protected link's destination node functioning as the root node.
3. Computes the post-convergence SPF tree. It excludes the primary next hop.
4. Computes a backup outbound interface and a repair list.
– Backup outbound interface: In some scenarios, if the P space and Q space
do not share nodes or have directly connected neighbors, the post-
convergence next-hop outbound interface functions as a backup
outbound interface.
– Repair list: a constrained path that directs traffic to the Q node. The
repair list consists of a P node label and adjacency labels of the P-to-Q
path. In Figure 1-73, the repair list consists of P3's node label 100, and
P3-to-P4 adjacency label 9304.
Rules for selecting a SID on a repair node are as follows:
● A node SID advertised by the repair node is preferentially selected.
A prefix SID advertised by the repair node is preferentially selected. The
smaller the SID, the higher the priority.

(2020-04-09)
● A node that does not support segment routing or a node that does not
advertise a prefix or node SID cannot function as a repair node.
TI-LFA FRR Backup Path Forwarding

After a TI-LFA backup path is computed, if the primary path fails, traffic switches
to the backup path, preventing packet loss.
In Figure 1-74, Device F is a P node, and Device H is a Q node. The primary next-
hop B fails, which triggers FRR switching. Traffic switches to the backup path.
Figure 1-74 TI-LFA FRR backup path forwarding
Table 1-26 TI-LFA FRR backup path forwarding process
Device TI-LFA FRR Backup Path Forwarding Process
Device Device A encapsulates a label stack to a packet based on the repair

A list from outer to inner: Node label of the P node (Device F) = Start
label in next-hop Device D's SRGB + Label offset of the P node = 720
P-to-Q adjacency labels of 130 and 240 Destination node label = Start
label of the Q node's SRGB + Label offset of the destination node
(Device C) = 310
Device Upon receipt of the packet, Device D searches the label forwarding
D table based on the outgoing label and finds a matching entry with
the outgoing label of 120 and next hop at Device F. Device D swaps
the outgoing label for 120 and forwards the packet to Device F.

(2020-04-09)
Device TI-LFA FRR Backup Path Forwarding Process
Device Upon receipt of the packet, Device F searches the label forwarding
F table based on the outgoing label. Device F is the egress so that it
removes the label. It finds a matching entry with a routed path label
of 130, the outgoing label as empty, and the next hop at Device G.
Device F removes label 130 and forwards the packet to Device G.
Device Upon receipt of the packet, Device G searches the label forwarding
G table based on the outgoing label, removes label 240, and forwards
the packet to Device H.
Device Upon receipt of the packet, Device H searches the label forwarding
H table based on the outgoing label and finds a matching entry with
the outgoing label of 510 and the next hop at Device E. Device H
swaps the outer label for 510 and forwards the packet to Device E.
Device E forwards the packet to Device C. The packet travels along
the shortest path.
TI-LFA FRR Protection Usage Scenarios
Table 1-27 TI-LFA FRR protection usage scenarios

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

protects IP over an IP routed relationship between each
forwarding. primary path, and a TI- pair of directly connected
LFA FRR backup path is nodes on a network. Enable
computed. segment routing on all nodes.
Set a prefix SID on the 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 on over a primary segment relationship between each
a segment routing tunnel, and a pair of directly connected
routing tunnel. TI-LFA FRR backup path nodes on a network. Enable
is computed. segment routing on all nodes.
Set a prefix SID on each of the
P and destination nodes.
2. Enable TI-LFA FRR on the
source node.

(2020-04-09)
1.1.2.11 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-75, 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-
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-75 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

(2020-04-09)
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.
Figure 1-76 IGP FRR networking in a scenario where multiple nodes advertise the
same route
As shown in Figure 1-76 (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-76 (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-76 (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.

(2020-04-09)
1.1.2.12 SR Microloop Avoidance
Anti-Micro-Loop Switchover
In Figure 1-77, if Device B fails, traffic is switched to a TI-LFA FRR backup path.
After Device A completes route convergence, traffic is switched from the TI-LFA
FRR backup path to a converged path. If Devices D and F do not complete route
convergence, they transmit traffic over the path established before convergence is
performed. As a result, a loop emerges between Devices A and F and is broken
after route convergence finishes on Devices D and F.
To prevent the loop-induced problem, the implementation is modified. After

Device B fails, traffic is switched to the TI-LFA backup path. Device A delays
convergence. After Devices F and D finish path convergence, Device A starts path
convergence. After path convergence is complete, traffic is switched from the TI-
LFA backup path to the converged path.
Figure 1-77 Anti-micro-loop switchover
Configure the anti-micro-loop switchover function on the source node.
The delayed route switchover must meet the following conditions:

● The interface directly connected to the local interface fails, or local BFD goes
Down.
● No network topology change occurs during the delay time.
● A backup next hop for a route is available.
● The primary next hop of the route is the faulty interface.

(2020-04-09)
● During the multi-node route convergence delay, if the source of the route
advertisement is changed, the delay stops.
Anti-Micro-Loop Switchback
In Figure 1-78:
1. Data is transmitted along the backup path before the link between Device B
and Device C recovers.
2. After the link between Device B and Device C recovers, if Device A converges
earlier than Device B, Device A forwards traffic to Device B that does not
finish convergence. Upon receipt of the traffic, Device B forwards traffic along
the original path to Device A, causing a loop.
3. To prevent a micro loop, after a traffic switchback is performed on Device A,
configure an explicit path to forward packets. Device A adds E2E path
information (for example, a B-to-C adjacency label) to data packets. Upon
receipt of the data packets, Device B forwards packets to Device A, C based on
the carried path information.
Figure 1-78 Anti-micro-loop switchback
After Device B finishes convergence, Device A deletes explicit path information

from data packets so that the data packets can be forwarded to Device C using
normal SR.
1.1.2.13 SR OAM
SR Operation, Administration, and Maintenance (OAM) monitors LSP connectivity

and rapidly detects faults. SR OAM is implemented using ping and tracert.
SR ping and tracert send MPLS Echo Request packets during forward detection
based on MPLS label forwarding. The SR ping and tracert backhaul MPLS Echo

(2020-04-09)
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-79, PE1, P1, P2, and PE2 are all capable of SR.
An SR LSP is established between PE1 and PE2.
Figure 1-79 SR-MPLS BE ping/tracert
The process of initiating an SR IPv4 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.

(2020-04-09)
SR-MPLS BE Tracert
On the network shown in Figure 1-79, the process of initiating an SR-MPLS
BEIPv4 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.
– 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 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. 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-80, PE1, P1, and P2all support SR. 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.

(2020-04-09)
Figure 1-80 SR-MPLS TE ping and tracert
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-80, 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.

(2020-04-09)
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.
5. P2 forwards the packet to PE2, and PE2 returns an MPLS Echo Reply packet to
PE1.
1.1.2.14 SR-MPLS TE Policy

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-81 shows the SR-MPLS TE Policy model. One SR-MPLS TE Policy may
contain multiple candidate paths with Preference attribute. The valid candidate

(2020-04-09)
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. A
segment list is an explicit label stack that instructs a network device to forward
packets, and multiple segment lists can work in load balancing mode.
Figure 1-81 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

(2020-04-09)
+------------------+
| 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
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-82 shows the format of the Preference sub-TLV.
Figure 1-82 Preference Sub-TLV

(2020-04-09)
Table 1-28 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.
Binding SID Sub-TLV

Figure 1-83 shows the format of the Binding SID sub-TLV.
Figure 1-83 Binding SID sub-TLV
Table 1-29 Fields in the Binding SID sub-TLV

Length 8 bits Packet length that 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.
● S: S-Flag encoding the Specified-BSID-only

behavior
● I: I-Flag encoding the Drop Upon Invalid behavior

(2020-04-09)
Binding SID 32 bits Binding SID of the SR-MPLS TE Policy.
Figure 1-85 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

Figure 1-86 shows the format of the Segment List sub-TLV.
Figure 1-86 Segment List sub-TLV
Table 1-30 Fields in the Segment List sub-TLV


(2020-04-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-87 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-88 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-89 shows the format of the Policy Priority sub-TLV.
Figure 1-89 Policy Priority sub-TLV

(2020-04-09)
Table 1-31 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-90 shows the format of the Extended Color Community.
Figure 1-90 Extended Color Community
Table 1-32 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-04-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 Policies as needed.
MBB and Delayed Deletion for SR Policies

SR-MPLS TE Policies support make-before-break (MBB), allowing a forwarder to
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.14.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
label, so that the forwarding plane can use this label to search the local
forwarding table for the corresponding forwarding entry.

(2020-04-09)
Figure 1-91 Manually configured SR-MPLS TE Policy
SR-MPLS TE Policy Delivery by a Controller

Figure 1-92 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-04-09)
Figure 1-92 Controller-delivered SR-MPLS TE Policy
1.1.2.14.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-93 shows the traffic steering process.

(2020-04-09)
Figure 1-93 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-94 shows the DSCP-based traffic steering
process.

(2020-04-09)
Figure 1-94 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.14.3 SR-MPLS TE Policy-based Data Forwarding

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

Intra-AS data forwarding depends on the establishment of intra-AS SR-MPLS TE
Policy forwarding entries. Figure 1-95 shows the process of establishing intra-AS
SR-MPLS TE Policy forwarding entries.
Figure 1-95 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 device A. After receiving the BGP route,
device A recurses the route to the 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
<20003,20005,20007,20002>.
Figure 1-96 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-04-09)
E, and G all remove 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-96 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-97 shows the process of establishing inter-AS
SR-MPLS TE Policy forwarding entries.
Figure 1-97 Establishment of inter-AS SR-MPLS TE Policy forwarding entries

(2020-04-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-98 shows the inter-AS data forwarding process.
Figure 1-98 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-04-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.14.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-99 shows the SBFD for SR-MPLS TE Policy detection process.
Figure 1-99 SBFD for SR-MPLS TE Policy

(2020-04-09)
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.
1.1.2.14.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-100 and Figure 1-101, 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.

(2020-04-09)
Figure 1-100 SR-MPLS TE Policy failover
Figure 1-101 SR-MPLS TE Policy label stack
In Figure 1-100:
● 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.

(2020-04-09)
● 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.14.6 SR-MPLS TE Policy OAM
SR-MPLS TE Policy operation, 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 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.
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-102, 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.

(2020-04-09)
Figure 1-102 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.
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-102, the process of initiating a tracert test on the SR-
MPLS TE Policy from PE1 is as follows:

(2020-04-09)
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.
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.15 MPLS in UDP
MPLS in UDP Fundamentals

In Figure 1-103, the controller manages both the DCN and DCI WAN. A DCN
gateway (GW) sends a request to establish an E2E optimal path to the controller,
and the controller returns path computation results to the DCN 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.

(2020-04-09)
Figure 1-103 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-103, 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:
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

(2020-04-09)
addresses are successfully verified. Otherwise, the packets are discarded. In Figure
1-103, 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-104 shows the MPLS-in-UDP packet format.
Figure 1-104 Format of an MPLS-in-UDP packet
Table 1-33 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
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:

(2020-04-09)
● 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-105 shows how the TTL is processed in uniform
mode.
Figure 1-105 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
ingress and egress no matter how many hops exist between the ingress and
egress on an SR-MPLS network. Figure 1-106 shows how the TTL is processed
in pipe mode.
Figure 1-106 TTL processing in pipe mode

(2020-04-09)
1.1.3 Application Scenarios for Segment Routing MPLS
1.1.3.1 Single-AS SR-MPLS TE
Single-AS Strict Explicit Path

In Figure 1-107, labels are assigned on the device side. An IGP extension supports
SR to advertise label information. BGP-LS collects network topology and label
information. 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 delivers label stack information to instruct forwarders to
forward data.
Figure 1-107 Single-AS strict explicit path
Single-AS Loose Explicit Path

In Figure 1-108, labels are assigned on the device side. An IGP extension supports
SR to advertise label information. BGP-LS collects network topology and label
information and sends the information to the controller. The controller computes a
path for an SR tunnel and runs NETCONF to deliver label stack information to
forwarders to forward data.

(2020-04-09)
Figure 1-108 Single-AS loose explicit path
An L3VPN within the network carries DCI services in per tenant per VPN mode.
Within a data center (DC), tenants are isolated, and the DC gateway accesses the
L3VPN through a VLAN sub-interface. Tenant VPNs are carried over the primary
and backup SR tunnels.
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-109 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-04-09)
Figure 1-109 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
and HSB TE LSPs. Inter-AS E2E SR-MPLS TE tunnels are monitored by one-arm

(2020-04-09)
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-110, 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-110 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-04-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
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 on a
network based on source routes. Segment Routing MPLS is Segment Routing
based on the MPLS forwarding plane, which is Segment Routing for short
hereafter. Segment Routing divides a network path into several segments and
assigns a segment ID to each segment and network forwarding node. The
segments and nodes are sequentially arranged (segment list) to form a
forwarding path.
Segment Routing encodes the segment list identifying a forwarding path into a
data packet header. The segment ID is transmitted along with the packet. After

(2020-04-09)
receiving the data packet, the receive end parses the segment list. If the top
segment ID in the segment list identifies the local node, the node removes the
segment ID and proceeds with the follow-up procedure. If the top segment ID
does not identify the local node, the node uses the Equal Cost Multiple Path
(ECMP) algorithm to forward the packet to a next node.
Segment Routing offers the following benefits:
● The control plane of MPLS network is simplified.
A controller or an IGP is used to uniformly compute paths and distribute
labels, without using RSVP-TE or LDP. Segment Routing can be directly applied
to the MPLS architecture without any change in the forwarding plane.
● Provides efficient topology independent-loop-free alternate (TI-LFA) FRR
protection for fast path failure recovery.
Based on the Segment Routing technology, combined with the RLFA (Remote
Loop-free Alternate) FRR algorithm, an efficient TI-LFA FRR algorithm is
formed. TI-LFA FRR supports node and link protection of any topology and
overcomes drawbacks in conventional tunnel protection.
● Provides higher network capacity expansion capabilities.
MPLS TE is a connection-oriented technique. To maintain connections, nodes
need to send and process a large number of Keepalive packets, posing heavy
burdens on the control plane. Segment Routing controls any service paths by
merely operating labels on the ingress, and transit node do not have to
maintain path information, which reduces the burdens on the control plane.
In addition, Segment Routing labels equal to the sum of the number of
network-wide nodes and the number of local adjacencies. The label quantity
is related only to the network scale, not to the number of tunnels or the
service volume.
● Implements smoother evolution to SDN network.
Segment Routing is designed based on the source routing concept. Using the
source node alone can control forwarding paths over which packets are
transmitted across a network. The Segment Routing technique and the
centralized path computing module are used together to flexibly and
conveniently control and adjust paths.
Segment Routing supports both traditional and SDN networks. It is
compatible with existing equipment and ensures smooth evolution of existing
networks 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-04-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-04-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-04-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-04-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-04-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-04-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-04-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-04-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-04-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-04-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 a SR-MPLS BE tunnel.
Usage Scenario
Creating an SR-MPLS BE tunnel involves the following operations:
Pre-configuration Tasks
Before configuring a manual SR-MPLS TE tunnel, complete the following tasks:

(2020-04-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 all SR-
MPLS BE features.
Procedure
Step 1 Run system-view
The system view is displayed.
Step 2 Run mpls lsr-id lsr-id
The LSR ID is set for the local node.
Note the following issues when setting an 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.
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 the 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.
3. Run commit

(2020-04-09)
Step 2 Configure an SRGB.

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 is configured in an existing IS-IS instance.
7. Run commit
Step 3 Set an 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 prefix SID is set on the loopback interface.
6. Run commit
----End
1.2.3.3 (Optional) Configuring a Policy for Triggering SR-LSP Establishment

A policy can be configured to allow the ingress to establish SR-LSPs based on
eligible routes.
Context
After Segment Routing is enabled, a great number of devices establish excessive
E2E LSPs, leading to resource wastes. To prevent resource wastes, a policy for

(2020-04-09)
establishing LSPs can be configured. The policy allows the ingress to use only
allowed routes to establish SR-LSPs.
Procedure
Step 2 Run isis
Step 3 Run segment-routing lsp-trigger { none | host | ip-prefix ip-prefix-name }
A policy for establishing LSPs can be configured.
Configure one of the following parameters:
● none: does not allow the ingress to use any routes to establish SR-LSPs.
● host: allows the ingress to use host routes with 32-bit masks to establish SR-
LSPs.
● ip-prefix: allows the ingress to use the routes that match an IP prefix list to
establish SR-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
Step 2 Run segment-routing
The segment routing view is displayed.
Step 3 Run tunnel-prefer segment-routing
SR-MPLS BE tunnels are configured to take precedence over LDP tunnels.

(2020-04-09)
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 command 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 table 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 SR-MPLS BE tunnel involves the following operations:
Before configuring an SR-MPLS BE tunnel, complete the following tasks:
● Configure OSPF to implement the connectivity of NEs at the network layer.
1.2.4.1 Enabling MPLS

Enabling MPLS on each node in an SR MPLS domain is the prerequisites for all SR-
MPLS BE features.
Procedure

(2020-04-09)

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 the 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


displayed.
3. Run commit

1. Run system-view

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

3. Run opaque-capability enable
The Opaque capability is enabled.

(2020-04-09)
The OSPF segment routing function is enabled.

A global OSPF SR label range is set.

6. Run commit
Step 3 Set a SID.

1. Run system-view


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


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

6. Run commit
----End
1.2.4.3 (Optional) Configuring a Policy for Triggering SR-LSP Establishment

A policy can be configured to allow the ingress to establish SR-LSPs based on
eligible routes.
Context
After segment routing is enabled, a great number of devices establish excessive
E2E LSPs, leading to resource wastes. To prevent resource wastes, a policy for
establishing LSPs can be configured. The policy allows the ingress to use only
allowed routes to establish SR-LSPs.
Procedure
Step 2 Run ospf [ process-id ]

(2020-04-09)
Step 3 Run segment-routing lsp-trigger { none | host | ip-prefix ip-prefix-name }

A policy for establishing LSPs is configured.
● host: allows the ingress to use host routes with 32-bit masks to establish SR-
LSPs.
● ip-prefix: allows the ingress to use the routes that match an IP prefix list to
establish SR-LSPs.
● none: does not allow the ingress to use any routes to establish SR-LSPs.
Step 4 Run commit
----End
1.2.4.4 Configuring a Policy for Preferentially Selectingan 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
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.4.5 Verifying the OSPF SR-MPLS BE Tunnel Configuration

After successfully configure SR-MPLS BE, verify SR-MPLS BE configurations.
Prerequisites
All SR-MPLS BE functions have been configured.

(2020-04-09)
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 segment routing label forwarding table
information.
1.2.5 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
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 IS-IS Process and Enabling an IS-IS Interface.
A controller must be configured to generate labels and calculate an LSP path for an SR-
MPLS TE tunnel to be established.
1.2.5.1 Enabling MPLS TE

Enabling MPLS TE on each node in an SR MPLS domain is the prerequisites for all
SR-MPLS TE features.
Procedure

(2020-04-09)

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 the scenario where the controller or the head node calculates the tunnel path,
the MPLS TE capability of the interface must be configured. In a static explicit
path scenario, this step can be ignored.
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.5.2 Globally Enabling the Segment Routing Capability

SR must be enabled before a forwarder obtains the segment routing (SR) function
and assigns a label to each route.
Context
SR enables a forwarder to assign a label to each route, which reduces resource
consumption on the forwarder. SR must be enabled globally before using the SR
function.
Procedure

(2020-04-09)

SR is enabled globally.
Step 3 Run commit
----End
1.2.5.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
path. SR-MPLS TE labels can be assigned by the controller or the extended IS-IS
protocol on forwarders. After IS-IS collects network topology information
(including labels assigned by IS-IS), IS-IS floods the information to or BGP-LS
advertises routes to the controller.
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
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.
5. Run segment-routing mpls [ level-1 | level-2 | level-1-2 ]
IS-IS SR-MPLS TE is enabled.
After segment routing 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.

(2020-04-09)
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:
● If a controller is directly connected to a forwarder, IS-IS, not BGP-LS, is used to report

the configured labels and network topology information to the controller.
If the controller is indirectly connected to a forwarder, BGP-LS must be configured on
the forwarder and controller so that the forwarder reports topology information to the
controller.
● A forwarder can report network-wide topology information to the controller after they
establish an IS-IS neighbor relationship or BGP-LS peer relationship. Perform the
following steps on one or more nodes:
1. Run system-view
3. Run bgp-ls enable [ level-1 | level-2 | level-1-2 ]
IS-IS is enabled to advertise network topology information to BGP-LS.
4. Run quit
Return to the system view.
5. Configure the BGP-LS route advertisement capability.
a. Run bgp { as-number-plain | as-number-dot }
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 ability to exchange BGP-LS routes with the specified BGP peer is
enabled.
----End
1.2.5.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.

(2020-04-09)
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
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.
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
The segment routing capability is enabled.
Step 8 Run mpls te pce delegate
PCE 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 that enter an SR-MPLS TE tunnel.
The DSCP setting on an SR-MPLS TE tunnel interface is mutually exclusive with

the service-class command. If both of them are configured, an error message is
displayed.

(2020-04-09)
Step 11 Run commit

----End
1.2.5.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
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
Sets a weight for an SR-MPLS TE tunnel before UCMP is carried out among
tunnels.
Step 5 Run commit
----End
1.2.5.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). The PCC delegates LSPs to a controller for
path calculation. After the controller calculates a path, the controller sends a PCEP
message to deliver path information to the PCC (forwarder).
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 following operation can
be skipped.
Procedure

(2020-04-09)
Step 2 Run pce-client

A PCC is configured, and the PCE client view is displayed.
Step 3 Run capability segment-routing
The Segment Routing capability is enabled.
Step 4 Run connect-server ip-address
A candidate server is specified for the PCC.
Step 5 Run commit
----End
1.2.5.7 (Optional) Enabling a Device to Simulate an SR-MPLS TE Transit

Node to Perform Link 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 link 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 link 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 link label-
based forwarding.
To modify parameters, except for lsp-name, run the sr-te-simulate static-cr-lsp
transit command. There is no need to run the undo sr-te-simulate static-cr-lsp
transit command before modifying a setting. These parameters can be
dynamically updated.
Step 3 Run commit
----End
1.2.5.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.

(2020-04-09)
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 [ { level-1 | level-2 | level-1-2 } |
{ lsp-id | local } ] * [ process-id | [ vpn-instance vpn-instance-name ] ]
– display isis traffic-eng statistics [ process-id | [ vpn-instance vpn-
instance-name ] ]
● 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.6 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:

(2020-04-09)
● Configure OSPF to implement LSR connectivity at the network layer.

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

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

(2020-04-09)
Step 6 Run commit

----End

Context
function.
Procedure
Step 3 Run commit
----End
1.2.6.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. After OSPF collects network topology information
(including labels assigned by OSPF), OSPF floods the information to or BGP-LS
advertises routes to the controller.
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:

(2020-04-09)
1. Run system-view


The OSPF Opaque capability is enabled.

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
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:
● If a controller is directly connected to a forwarder, OSPF, not BGP-LS, is used to report

the configured labels and network topology information to the controller.
If the controller is indirectly connected to a forwarder, BGP-LS must be configured on
the forwarder and controller so that the forwarder reports topology information to the
controller.
● A forwarder can report network-wide topology information to the controller after they
establish an OSPF neighbor relationship or BGP-LS peer relationship. Perform the
following steps on one or more nodes:
1. Run system-view


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

4. Run quit

5. Configure the BGP-LS route advertisement capability.
b. Run peer ipv4-address as-number as-number-plain
A BGP peer group is created.

(2020-04-09)
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 ability to exchange BGP-LS routes with the specified BGP peer is
enabled.
6. Run commit
----End

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

egress.


(2020-04-09)

A tunnel ID is set.
The segment routing capability is enabled.
value2 ] } &<1-32> }
displayed.
Step 11 Run commit
----End
1.2.6.5 (Optional) Configuring the UCMP Function of theSR-MPLS TE Tunnel

Procedure
tunnels.

(2020-04-09)
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
be skipped.
Procedure
A PCC is configured, and the PCE client view is displayed.
A candidate server is specified for the PCC.
Step 5 Run commit
----End
1.2.6.7 (Optional) Enabling a Device to Simulate an SR-MPLS TE Transit

Node to Perform Link 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 link 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 link label-based forwarding. The
function resolves the forwarding issue on the SR-MPLS TE-incapable device.

(2020-04-09)
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 link label-

based forwarding.
To modify parameters, except for lsp-name, run the sr-te-simulate static-cr-lsp

transit command. There is no need to run the undo sr-te-simulate static-cr-lsp
transit command before modifying a setting. These parameters can be
dynamically updated.
Step 3 Run commit
----End
1.2.6.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

(2020-04-09)
1.2.7 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
SE-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.

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

(2020-04-09)

displayed.
3. Run mpls

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

Context
function.
Procedure
Step 3 Run commit
----End
1.2.7.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.

(2020-04-09)
Procedure
1. Run system-view
8. Run commit
Step 2 Configure an SR prefix label.
1. Run system-view
6. Run commit
Step 3 (Optional) Configure an adjacency SID.
After IS-IS SR is enabled, an adjacency SID can be automatically generated. To
disable the adjacency SID function, run the segment-routing auto-adj-sid
disable command. After a device is restarted, the adjacency SID may change. If an
explicit path uses an adjacency SID, this adjacency SID must be reconfigured. You
can also manually configure an adjacency SID for an explicit path.

(2020-04-09)
1. Run system-view
3. 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.
4. Run commit
----End
1.2.7.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.
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.
● To specify a next-hop address for the explicit path, perform the following
operations:
a. Run the next hop ip-address [ include[ [ strict | loose ] | [ incoming |
outgoing ] ] *| exclude ] command to specify a next-hop node for the
explicit path.
The include parameter indicates that a tunnel must pass through a
specified node. The exclude parameter indicates that a tunnel does not
pass through a specified node.
b. (Optional) Run the add hop ip-address1 [ include [ [ strict | loose ] |
[ incoming | outgoing ] ] * | exclude ] { after | before } ip-address2
command to add a node to the explicit path.

(2020-04-09)
c. (Optional) Run the modify hop ip-address1 ip-address2 [ 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 ip-address 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.
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

(2020-04-09)
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.

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> }

(2020-04-09)

displayed.
Step 11 Run commit
----End
1.2.7.6 (Optional) Configuring the UCMP Function of the SR-MPLS TE Tunnel

Procedure
tunnels.
Step 5 Run commit
----End
1.2.7.7 Checking the Configurations

Prerequisites
Procedure
instance-name ] ]

(2020-04-09)

tunnel information.
----End
1.2.8 Configuring an OSPF SR-MPLS TE Tunnel (Explicit Path

Used)
If no controller is deployed to compute paths, an explicit path can be manually
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


(2020-04-09)

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
1.2.8.2 Globally Enabling the SR Capability

Context
function.
Procedure

(2020-04-09)
Step 3 Run commit

----End

Context
Procedure
1. Run system-view
6. Run area area-id
8. Run commit
Step 2 Set a prefix SID.
1. Run system-view

(2020-04-09)

disable ]
6. Run commit
Step 3 (Optional) Configure an adjacency SID.
After OSPF SR is enabled, an adjacency SID can be automatically generated. To
disable the adjacency SID function, run the segment-routing auto-adj-sid
disable command. After a device is restarted, the adjacency SID may change. If an
explicit path uses an adjacency SID, this adjacency SID must be reconfigured. You
can also manually configure an adjacency SID for an explicit path.
1. Run system-view
3. 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.
4. 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
Step 2 Run explicit-path path-name
An explicit path is created, and the explicit path view is displayed.

(2020-04-09)
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.
● To specify a next-hop address for the explicit path, perform the following
operations:
a. Run the next hop ip-address [ include[ [ strict | loose ] | [ incoming |
outgoing ] ] *| exclude ] command to specify a next-hop node for the
explicit path.
The include parameter indicates that a tunnel must pass through a
specified node. The exclude parameter indicates that a tunnel does not
pass through a specified node.
b. (Optional) Run the add hop ip-address1 [ include [ [ strict | loose ] |
[ incoming | outgoing ] ] * | exclude ] { after | before } ip-address2
command to add a node to the explicit path.
c. (Optional) Run the modify hop ip-address1 ip-address2 [ 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 ip-address 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.
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

(2020-04-09)
----End

Procedure
interface:
number command.

egress.
A tunnel ID is set.

(2020-04-09)
path-name command.
value2 ] } &<1-32> }

displayed.
Step 11 Run commit
----End

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

(2020-04-09)

Prerequisites
Procedure
Routing.
information.

----End
1.2.9 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.


(2020-04-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-04-09)
Context
function.
Procedure
Step 3 Run commit
----End

Context
Procedure
1. Run system-view

(2020-04-09)
8. Run commit
1. Run system-view
6. Run commit
----End
1.2.9.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
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


(2020-04-09)
Procedure
interface:
number command.

egress.
A tunnel ID is set.
Step 8 (Optional) Run mpls te cspf path-selection adjacency-sid
A device is enabled to run CSPF to compute an LSP in an SR-MPLS TE strictly
based on adjacency SIDs.
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.

(2020-04-09)
value2 ] } &<1-32> }
displayed.
Step 11 Run commit
----End

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

Prerequisites

(2020-04-09)
Procedure
instance-name ] ]
tunnel information.
----End
1.2.10 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

(2020-04-09)

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
1.2.10.2 Globally Enabling the SR Capability

Context
function.

(2020-04-09)
Procedure
Step 3 Run commit
----End

Context
Procedure
1. Run system-view





6. Run area area-id


8. Run commit

(2020-04-09)
1. Run system-view




disable ]

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


(2020-04-09)
Procedure
interface:
number command.

egress.
A tunnel ID is set.
Step 8 (Optional) Run mpls te cspf path-selection adjacency-sid
A device is enabled to run CSPF to compute an LSP in an SR-MPLS TE strictly
based on adjacency SIDs.
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.

(2020-04-09)
value2 ] } &<1-32> }

displayed.
Step 11 Run commit
----End
1.2.10.6 (Optional) Configuring the UCMP Function of the SR-MPLS TE

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


(2020-04-09)
Prerequisites
Procedure
Routing.
information.
----End
1.2.11 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.
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
A BGP peer is created.

(2020-04-09)
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 }
BGP EPE fault association is enabled for the BGP peer set.
i. Run commit
● 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.
a. Run system-view
b. Run bgp { as-number-plain | as-number-dot }
c. Run peer ipv4-address as-number as-number-plain
d. Run link-state-family unicast

(2020-04-09)
BGP-LS is enabled, and the BGP-LS address family view is displayed.

e. Run peer { group-name | ipv4-address } enable
The device is enabled to exchange BGP-LS routing information with a
specified peer or peer group.
f. 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.12 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-111.
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.

(2020-04-09)
Figure 1-111 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.12.1 Setting a Binding SID

Using binding BIDs 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
configuration on the ingress of the reverse tunnel.

(2020-04-09)
● 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.12.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:
● To configure an IP address for the tunnel interface, run the ip address ip-
number command.

(2020-04-09)
The SR-MPLS TE tunnel is unidirectional and does not need a peer IP address. A separate IP
A tunnel destination address, which is usually the LSR ID of the egress, is

configured.

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

displayed.
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
an SR-MPLS TE tunnel.
Context

(2020-04-09)
be skipped.
Procedure
A PCC is configured and the PCC view is displayed.
A candidate PCE server is configured for a PCC.
Step 5 Run commit
----End
1.2.12.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

(2020-04-09)
1.2.13 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-112.
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-112 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.

(2020-04-09)
● Configure BGP EPE between ASBRs. For details, see Configuring BGP SR.
1.2.13.1 Setting a Binding SID

Using binding BIDs 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
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.

(2020-04-09)
Procedure
Step 2 Run explicit-path
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.
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.13.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
An inter-AS E2E tunnel interface is created, and the tunnel interface view is
displayed.

(2020-04-09)
interface:
● To configure an IP address for the tunnel interface, run the ip address ip-
number command.
The SR-MPLS TE tunnel is unidirectional and does not need a peer IP address. A separate IP
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> }

displayed.
Step 10 Run commit
----End

(2020-04-09)
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.

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 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
an SR-MPLS BE tunnel interface 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
or tunnel binding 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:

(2020-04-09)
● 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.
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
● 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
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 system-view
b. Run route recursive-lookup tunnel [ ip-prefix ip-prefix-name ]
[ tunnel-policy policy-name ]

(2020-04-09)
The function to recurse non-labeled public BGP routes and static routes
to SR-MPLS BE tunnels is enabled.
c. 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 system-view
The BGP view is displayed.
c. 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.
d. 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 system-view
b. Run ip route-static recursive-lookup tunnel [ ip-prefix ip-prefix-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
c. Run commit
● Configure BGP L3VPN services to recurse to SR-MPLS BE tunnels.
For details about how to configure a BGP L3VPN service, see Configuring
Basic BGP/MPLS IP VPN.
a. Run system-view
b. Run ip vpn-instance vpn-instance-name
The VPN instance view is displayed.
c. Run ipv4-family
The VPN instance-specific IPv4 address family view is displayed.

(2020-04-09)
d. Run tnl-policy policy-name

A specified tunnel policy is applied to the VPN instance-specific IPv4
address family.
e. Run commit
● Configure BGP L3VPNv6 services to recurse to SR-MPLS BE tunnels.
For details about how to configure a BGP L3VPNv6 service, see Configuring
Basic BGP/MPLS IPv6 VPN.
a. Run system-view
c. Run ipv6-family
address family.
e. 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.
a. Run system-view
c. Run ipv6-family unicast
The BGP IPv6 unicast address family view is displayed.
d. Run peer ipv4-address enable
A specified 6PE peer is enabled.
e. Run peer ipv4-address tnl-policy tnl-policy-name
A specified tunnel policy is applied to the 6PE peer.
f. Run commit
Method 2: Apply a tunnel selector to all the routes of a specified BGP
IPv6 unicast address family.
a. Run system-view

(2020-04-09)

d. 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.
e. Run commit
● Configure EVPN services to recurse to SR-MPLS BE tunnels.
For details about how to configure an EVPN service, 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:
a. Run system-view
c. Run ipv4-family or ipv6-family
The VPN instance-specific IPv4/IPv6 address family view is displayed.
d. Run tnl-policy policy-name evpn
A specified tunnel policy is applied to the EVPN L3VPN instance.
e. Run commit
To apply a tunnel policy to a BD EVPN instance, perform the following steps:
a. Run system-view
b. Run evpn vpn-instance vpn-instance-name bd-mode
The BD EVPN instance view is displayed.
c. Run tnl-policy policy-name
A specified tunnel policy is applied to the BD EVPN instance.
d. Run commit
To apply a tunnel policy to an EVPN instance that works in EVPN VPWS mode,
perform the following steps:
a. Run system-view
b. Run evpn vpn-instance vpn-instance-name vpws
The view of a specified EVPN instance that works in EVPN VPWS mode is
displayed.

(2020-04-09)

A specified tunnel policy is applied to the EVPN instance that works in
EVPN VPWS mode.
d. Run commit
To apply a tunnel policy to a basic EVPN instance, perform the following
steps:
a. Run system-view
b. Run evpn vpn-instance vpn-instance-name
The EVPN instance view is displayed.
A specified tunnel policy is applied to the basic EVPN instance.
d. Run commit
----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
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-

(2020-04-09)
labeled public routes to recurse to SR-MPLS TE tunnels. The configuration

varies according to the service type.
This section describes how to configure routes and services to recurse to SR-MPLS
TE tunnels through tunnel policies.
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
Select either of the following modes based on the traffic steering mode you select.
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
● Tunnel binding
a. Run system-view
d. Run tunnel binding destination dest-ip-address te { tunnel-name }
&<1-32> [ ignore-destination-check ] [ down-switch ]

(2020-04-09)
A tunnel binding policy is configured to bind the specified destination IP

address and SR-MPLS TE tunnel.
e. Run commit
● 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
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 system-view
The function to recurse non-labeled public BGP routes and static routes
to SR-MPLS TE tunnels is enabled.
c. Run commit
● Configure non-labeled public BGP routes to recurse to SR-MPLS TE tunnels.
a. Run system-view
c. 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.
d. Run commit

(2020-04-09)
● 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 system-view
The function to recurse static routes to SR-MPLS TE tunnels for MPLS
The ip route-static recursive-lookup tunnel command and route
c. 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.
a. Run system-view
c. Run ipv4-family
address family.
e. 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.
a. Run system-view
c. Run ipv6-family
address family.
e. Run commit

(2020-04-09)
● Configure BGP4+ 6PE services to recurse to SR-MPLS TE tunnels.

BGP4+ 6PE.
Method 1: Apply a tunnel policy to a specified BGP4+ peer.
a. Run system-view
A specified 6PE peer is enabled.
A specified tunnel policy is applied to the 6PE peer.
f. Run commit
Method 2: Apply a tunnel selector to all the routes of a specified BGP
IPv6 unicast address family.
a. Run system-view
d. 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.
e. Run commit
● Configure EVPN services to recurse to SR-MPLS TE tunnels.
For details about how to configure an EVPN service, see 3.2 EVPN
Configuration. The configuration varies according to the service type.
steps:
a. Run system-view

(2020-04-09)

The VPN instance-specific IPv4/IPv6 address family view is displayed.
A specified tunnel policy is applied to the EVPN L3VPN instance.
e. Run commit
a. Run system-view
A specified tunnel policy is applied to the BD EVPN instance.
d. Run commit
a. Run system-view
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.
d. Run commit
steps:
a. Run system-view
A specified tunnel policy is applied to the basic EVPN instance.
d. 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.

(2020-04-09)
Usage Scenario
In Figure 1-113, an SR domain is established between PE1 and the P. The P
functions as a mapping server, is assigned a mapping between a prefix and a SID,
and advertises the mapping to the mapping client. PE1 functions as a mapping
client and receives the mapping advertised by the P. An LDP domain resides
between the P and PE2. PE2 supports LDP only. To allow PE1 and PE2 to access
each other, establish an SR LSP and an LDP LSP and configure mapping between
the SR LSP and LDP LSP on the P.
Figure 1-113 Communication between SR and LDP
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
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

(2020-04-09)
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

d. Run commit

● Configure the devices connecting the LDP area and the SR area
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

The configurations of IS-IS SR and LDP interworking are complete.

1.2.17 Configuring OSPF SR to Communicate with LDP

This section describes how to configure OSPF SR to communicate with LDP.

(2020-04-09)
Usage Scenario
In Figure 1-114, an SR domain is established between PE1 and the P. The P
functions as a mapping server, is assigned a mapping between a prefix and a SID,
and advertises the mapping to the mapping client. PE1 functions as a mapping
client and receives the mapping advertised by the P. An LDP domain resides
between the P and PE2. PE2 supports LDP only. To allow PE1 and PE2 to access
each other, establish an SR LSP and an LDP LSP and configure mapping between
the SR LSP and LDP LSP on the P.
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
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

(2020-04-09)
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
● Configure the devices connecting the LDP area and the SR area
a. Run system-view
b. Run mpls
d. Run commit
----End

The configurations of OSPF SR and LDP interworking are complete.
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

(2020-04-09)
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.
Procedure
Step 2 Run isis [ process-id ]
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 } preference preference [ level-1 | level-2 | level-1-2 ]
The solution of selecting a backup path for IS-IS TI-LFA FRR is set.
By default, the preference value is 40 for the node-protection path first solution,
20 for the smallest-cost path first solution, 10 for the non-ECMP first solution, and
5 for the Shared Risk Link Group (SRLG) disjoint first solution. 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.

(2020-04-09)
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 ]
The IS-IS TI-LFA is disabled on an specified 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, which poses the risk of micro loops. To prevent
micro loops, 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.
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

All IS-IS TI-LFA FRR configurations are complete.
● Run the display isis route [ level-1 | level-2 ] [ process-id ] [ verbose ]
command to check information about the primary and backup link
information after IS-IS TI-LFA FRR is enabled.
1.2.19 Configuring OSPF TI-LFA FRR

This section describes how to configure OSPF TI-LFA FRR.

(2020-04-09)
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
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 an specified interface, run either of the
following commands:

(2020-04-09)
– 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.
convergence rates on devices, which poses the risk of micro loops. To prevent
micro loops, perform the following steps:
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.
Step 8 Run commit
----End
Example
All OSPF TI-LFA FRR configurations are complete.
● Run the display ospf [ process-id ] segment-routing routing [ ip-address
[ mask | mask-length ] ] command to check information about the OSPF
segment routing routing table after OSPF TL-LFA FRR is enabled.
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.

(2020-04-09)
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
g. Run segment-routing
The Segment Routing view is displayed.
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

(2020-04-09)
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.
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

(2020-04-09)
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

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.

(2020-04-09)
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
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

(2020-04-09)
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 (SR-MPLS BE) can be configured to detect faults of SR LSPs.
Usage Scenario
If BFD for SR LSP detects a fault on the primary tunnel, VPN FRR rapidly switches
traffic, which minimizes the impact on traffic.
Configure BFD for SR LSP on both the ingress and egress of an SR LSP.
Before configuring BFD for SR LSP, 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

(2020-04-09)
Step 6 Run bfd enable mode tunnel [ filter-policy ip-prefix ip-prefix-name | effect-sr-
lsp ] *
BFD is enabled for SR-MPLS BE tunnels.
If effect-sr-lsp is specified, if BFD Down, SEGR module cancels the SR LSP.
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 tunnels.
Step 8 Run commit
----End

After successfully configuring BFD for SR LSP, 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)
BFD for SR LSP (SR-MPLS BE) can be configured to detect faults of SR LSPs when
SR and LDP communicate.
Usage Scenario
If BFD for SR LSP detects a fault on the primary tunnel when SR communicates
with LDP, VPN FRR rapidly switches traffic, which minimizes the impact on traffic.
Before configuring BFD for SR LSP (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

(2020-04-09)
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
f. Run bfd enable mode tunnel [ filter-policy ip-prefix ip-prefix-name |
effect-sr-lsp | nil-fec ] *
BFD is enabled for SR-MPLS BE tunnels.
If effect-sr-lsp is specified, if BFD Down, SEGR module cancels the SR
LSP.
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

(2020-04-09)
f. Run mpls bfd enable

An MPLS device to dynamically establish a BFD session.
g. Run mpls bfd-trigger host
A policy for dynamically establishing an LDP BFD session is configured.
h. Run commit
● Configure a device that connects the LDP area to the SR area.
a. Run system-view
b. Run mpls
d. Run commit
----End

After successfully configuring BFD for SR LSP, 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

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

(2020-04-09)
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 cfg-name bind mpls-te interface interface-type interface-number
BFD is configured to monitor an SR-MPLS TE tunnel.

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 cannot be run for a one-arm echo session.

5. (Optional) Run min-tx-interval interval
The minimum interval at which the local device sends BFD packets is
changed.
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 the local and remote configurations are as follows:

– Locally configured interval at which BFD packets are sent: 200 ms
– Locally configured interval at which BFD packets are received: 300 ms
– Locally configured detection multiplier: 4
– Remotely configured interval at which BFD packets are sent: 100 ms
– Remotely configured interval at which BFD packets are received: 600 ms
– Remotely configured detection multiplier: 5
– On the local device, the actual interval between sending BFD packets is
600 ms calculated using the formula MAX {200 ms, 600 ms}, the actual
interval between receiving BFD packets is 300 ms calculated using the
formula MAX {100 ms, 300 ms}, and the actual detection period is 1500
ms calculated by multiplying 300 ms by 5.

(2020-04-09)
– On the remote device, the actual interval between sending BFD packets is
6. (Optional) Run min-rx-interval interval
The minimum interval at which the local device receives BFD packets is
changed.
For a one-arm echo session, run the min-echo-rx-interval command to

configure the minimum interval at which the local device receives BFD
packets.
7. (Optional) Run detect-multiplier multiplier
The local BFD detection multiplier is changed.

8. Run commit
Step 3 Set egress BFD parameters.

1. Run system-view

2. Run bfd cfg-name bind mpls-te interface interface-type
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.

The minimum interval at which the local device sends BFD packets is
changed.
If the reverse link is an IP link, you cannot set this parameter.

(2020-04-09)

The minimum interval at which the local device receives BFD packets is
changed.
For a one-arm echo session, run the min-echo-rx-interval command to

configure the minimum interval at which the local device receives BFD
packets.
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 tunnel tunnel-name
[ 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-lsp | for-te ] [ verbose ] command.
– To check static BFD sessions' information, run the display bfd session
static [ for-lsp | for-te ] [ verbose ] command.
● Check BFD statistics.
– To check statistics about all BFD sessions, run the display bfd statistics
session all [ for-lsp | for-te ] [ verbose ] command.
– To check statistics about static BFD sessions, run the display bfd
statistics session static [ discriminator local-discriminator | for-lsp | for-
te ] [ verbose ] command.

(2020-04-09)
– To check statistics about BFD for MPLS-TE sessions, run the display bfd
statistics session mpls-te interface tunnel { tunnel-id | tunnel-number }
te-lsp 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.
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 session-name bind mpls-te interface interface-type interface-
number 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 echo 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 echo session.

(2020-04-09)
A local discriminator of a BFD session is set.

A remote discriminator of a BFD session is set.
This command does not need to be run if a one-arm BFD echo session is
established.
The minimum interval at which BFD packets are sent locally is set.
This parameter cannot be set if a one-arm BFD echo session is established.
The minimum interval at which BFD packets are received locally is set.
If a one-arm BFD echo session is to be established, run the min-echo-rx-
interval command to set the minimum interval at which BFD packets are
received locally.
A local BFD detection multiplier is set.
8. (Optional) Run bit-error-detection
Bit-error-triggered SR-MPLS TE LSP switching is enabled.

(2020-04-09)
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 session-name bind mpls-te interface interface-type interface-
number 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 echo 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 echo session.
A local discriminator of a BFD session is set.

A remote discriminator of a BFD session is set.
This command does not need to be run if a one-arm BFD echo session is
established.
The minimum interval at which BFD packets are sent locally is set.
This parameter cannot be set if a one-arm BFD echo session is established.


(2020-04-09)

The minimum interval at which BFD packets are received locally is set.
If a one-arm BFD echo session is to be established, run the min-echo-rx-

interval command to set the minimum interval at which BFD packets are
received locally.
A 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
----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 tunnel-name 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-ip | for-lsp | for-te ] [ verbose ]
command to check the configurations of all BFD sessions.

(2020-04-09)
– Run the display bfd session static [ for-ip | for-lsp | for-te ] [ 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-ip | for-lsp | for-te ]
[ verbose ] command to check statistics about all BFD sessions.
– Run the display bfd statistics session static [ discriminator local-
discriminator | for-ip | for-lsp | for-te ] [ verbose ] command to check
statistics about static BFD sessions.
– Run the display bfd statistics session mpls-te interface tunnel
{ tunnel-id | tunnel-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.
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:

(2020-04-09)
● 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.
If one-arm-echo is configured, a one-arm BFD echo 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 echo 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:
▪ Run the interface tunnel interface-number

▪ 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.
a. Run system-view
b. Run interface tunnel interface-number
The view of the TE tunnel interface is displayed.
c. 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.

(2020-04-09)
If one-arm-echo is configured, a one-arm BFD echo 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 echo session.
d. 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.
● 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.
● 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.

(2020-04-09)
● Adjust BFD parameters globally.

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

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.

(2020-04-09)
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.
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 interface tunnel interface-number
The view of the E2E SR-MPLS TE tunnel interface is displayed.
e. 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.

(2020-04-09)
Ensure that the mpls te binding-sid label label-value command has

been run on the ingress of the reverse LSP.
f. (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:
g. Run commit
● Enable the capability on a tunnel interface.
– Run system-view
– Run interface tunnel interface-number
– 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.
– 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.
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

(2020-04-09)

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

(2020-04-09)
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.
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.
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.

(2020-04-09)

– Run system-view
– Run mpls
– Run mpls te bfd { min-rx-interval tx-interval | detect-multiplier
multiplier } *
– Run commit
– Run system-view
– Run mpls te bfd { min-rx-interval rx-interval | detect-multiplier
multiplier } *
– Run commit
----End
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.

(2020-04-09)
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) 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.
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:

(2020-04-09)
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.
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.

(2020-04-09)
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.
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 directly 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.

(2020-04-09)
a. Enable MPLS on the interface.

b. IGP enables Segment Routing and IGP is enabled on the interface.
c. Configure the static adjacency label of the corresponding interface in the
Segment Routing view.
4. Run commit
Step 2 Enable SR globally.
1. Run system-view
3. (Optional) Run local-block begin-value end-value [ ignore-conflict ]
The segment routing local block (SRLB) 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 you run the local-block command and specify the ignore-conflict
parameter, if a label conflict occurs, the configuration is forcibly delivered but
does not consume label resources. Specifying this parameter in the command
is mainly used for pre-deployment, and the configuration takes effect after a
device restart.
4. Run commit
Step 3 Configure IGP SR.
For manually configured SR-MPLS TE Policies, configure adjacency SIDs manually.
For controller-delivered SR-MPLS TE Policies, you are advised to configure
adjacency SIDs manually. However, you can also use an IGP to generate adjacency
SIDs dynamically.
● If the IGP is IS-IS, configure IGP SR by referring to 1.2.7.3 Configuring Basic
SR-MPLS TE Functions.
● If the IGP is OSPF, configure IGP SR by referring to 1.2.8.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

(2020-04-09)
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.
You can run the command multiple times to configure multiple SIDs. The
system generates a segment list with a label stack containing SIDs that
are placed by index in ascending order. If a candidate path in the SR-
MPLS 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.
e. Run commit
● Configure an SR-MPLS TE Policy.
a. Run system-view
c. (Optional) Run sr-te-policy bgp-ls enable
The SR-MPLS TE policy is enable 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.
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.

(2020-04-09)
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 specified segment list of a 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.
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.

(2020-04-09)
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
a. Run system-view
as-number-dot }
{ import | export }
f. Run commit
● Apply the route-policy to a BGP VPNv4 peer.
a. Run system-view

(2020-04-09)

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 }
{ 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 }

(2020-04-09)
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
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
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 SR-
MPLS TE Policy for forwarding. This process is called traffic steering. Currently, SR-

(2020-04-09)
MPLS TE Policies can be used for various routes, such as BGP, static, BGP4+ 6PE,
BGP L3VPN, and EVPN routes.
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
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-32> | 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.

(2020-04-09)
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 tunnel-policy policy-name
h. (Optional) Run description description-information
i. 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.

(2020-04-09)
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.
j. 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
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
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
a. Run system-view
c. Run ipv4-family
A tunnel policy is applied to the VPN instance IPv4 address family.
e. Run default-color color-value

(2020-04-09)
The default color used by the L3VPN service when iterating the SR-MPLS
TE Policy tunnel is set.
After the remote cross-route crosses to the VPN instance, if the route
does not carry the color extended community attribute, use The default
color value is SR-MPLS TE Policy tunnel iteration.
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
a. Run system-view
c. Run ipv6-family
The default color used by the L3VPNv6 service when iterating the SR-
MPLS TE Policy tunnel is set.
f. Run commit
● Configure a BGP4+ 6PE service to be recursed to an SR-MPLS TE Policy.
BGP4+ 6PE.
a. Run system-view
A 6PE peer is enabled.
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.

(2020-04-09)
For details about how to configure an EVPN service, see 3.2.5 Configuring
BD-EVPN Functions.
steps:
a. Run system-view
The VPN instance IPv4 or IPv6 address family view is displayed.
A tunnel policy is applied to the EVPN L3VPN instance.
e. Run default-color color-value evpn
The default color used by the EVPN L3VPN service when iterating the SR-
f. Run commit
a. Run system-view
A tunnel policy is applied to the BD EVPN instance.
d. Run default-color color-value
The default color used by the EVPN service when iterating the SR-MPLS
After the remote cross-route crosses to the EVPN instance, if the route
e. Run commit
a. Run system-view
The view of the EVPN instance that works in EVPN VPWS mode is
displayed.

(2020-04-09)

A tunnel policy is applied to the EVPN instance that works in EVPN VPWS
mode.
e. Run commit
steps:
a. Run system-view
A tunnel policy is applied to the basic EVPN instance.
d. Run commit
----End
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

(2020-04-09)
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:
● 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.

(2020-04-09)
● 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.
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

(2020-04-09)
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 directly 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.
a. Enable MPLS on the interface.
b. IGP enables Segment Routing and IGP is enabled on the interface.
c. Configure the static adjacency label of the corresponding interface in the
Segment Routing view.
4. Run commit
Step 2 Enable SR globally.
1. Run system-view
3. (Optional) Run local-block begin-value end-value [ ignore-conflict ]
The segment routing local block (SRLB) 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 you run the local-block command and specify the ignore-conflict
parameter, if a label conflict occurs, the configuration is forcibly delivered but
does not consume label resources. Specifying this parameter in the command
is mainly used for pre-deployment, and the configuration takes effect after a
device restart.
4. Run commit
Step 3 Configure IGP SR.
For manually configured SR-MPLS TE Policies, configure adjacency SIDs manually.
For controller-delivered SR-MPLS TE Policies, you are advised to configure

(2020-04-09)
adjacency SIDs manually. However, you can also use an IGP to generate adjacency
SIDs dynamically.
● If the IGP is IS-IS, configure IGP SR by referring to 1.2.7.3 Configuring Basic
● If the IGP is OSPF, configure IGP SR by referring to 1.2.8.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.
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
BGP is enabled and the BGP view is displayed.
c. Run peer { group-name | ipv4-address } as-number { as-number-plain |
as-number-dot }

(2020-04-09)

BGP-LS is enabled and the BGP-LS address family view is displayed.
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.
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 enable 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

(2020-04-09)
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.
5. Run commit
a. Run system-view
as-number-dot }
{ import | export }
f. Run commit

(2020-04-09)

a. Run system-view
as-number-dot }
{ import | export }
f. Run commit
a. Run system-view
as-number-dot }
{ import | export }
g. Run commit
a. Run system-view
as-number-dot }

(2020-04-09)

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

(2020-04-09)
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 SR-
MPLS TE Policy for forwarding. This process is called traffic steering. Currently, SR-
MPLS TE Policies can be used for various routes, such as BGP, static, BGP4+ 6PE,
BGP L3VPN, and EVPN routes.
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

(2020-04-09)
d. Run tunnel select-seq sr-te-policy load-balance-number load-balance-

number unmix
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-32> | 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

(2020-04-09)
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 tunnel-policy policy-name
h. (Optional) Run description description-information
i. 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.
j. 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
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-04-09)
a. Run system-view
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
c. Run ipv4-family
The default color used by the L3VPN service when iterating the SR-MPLS
f. Run commit
● Configure a BGP L3VPNv6 service to be recursed to an SR-MPLS TE Policy.
a. Run system-view
c. Run ipv6-family
The default color used by the L3VPNv6 service when iterating the SR-

(2020-04-09)
f. Run commit
● Configure a BGP4+ 6PE service to be recursed to an SR-MPLS TE Policy.
BGP4+ 6PE.
a. Run system-view
A 6PE peer is enabled.
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. Run default-color color-value evpn
The default color used by the EVPN L3VPN service when iterating the SR-
f. Run commit

(2020-04-09)
a. Run system-view
e. Run commit
a. Run system-view
displayed.
mode.
e. Run commit
steps:
a. Run system-view
d. Run commit
----End

(2020-04-09)
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.
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:

(2020-04-09)
● 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
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
individual configuration. Select either of the following configuration
modes as needed:
▪ 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.
▪ Individual 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 a single SR-MPLS TE Policy.
If an SR-MPLS TE Policy has both global configuration and individual
configuration, the individual configuration takes effect.
h. (Optional) Run sr-te-policy delete-delay delete-delay-value

(2020-04-09)
A delay in deleting the segment lists of SR-MPLS TE Policies is configured.
The default delay in deleting segment lists is 20000 ms.

i. Run commit

● Configure an SBFD reflector.
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

An SBFD reflector discriminator is configured.

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 HSB 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
switchover to reduce impacts on services.
Before configuring HSB for SR-MPLS TE Policy, configure one or more SR-MPLS TE
Policies.

(2020-04-09)
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
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

(2020-04-09)

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
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
SR-MPLS TE Policy traffic statistics collection enables you to collect statistics about
the traffic forwarded through a specified or all SR-MPLS TE Policies.
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
● Global configuration
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
● Individual configuration
a. Run system-view

(2020-04-09)
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-
name name-value | binding-sid binding-sid ] command to check collected SR-
MPLS TE Policy traffic statistics.
Follow-up Procedure
To clear existing SR-MPLS TE 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.
Prerequisites
Before redirecting a public IPv4 BGP FlowSpec route to an SR-MPLS TE Policy in
manual configuration mode, complete the following tasks:

(2020-04-09)
● Configure a BGP peer relationship.

Context
If no controller is deployed, perform the following operations to manually redirect
a public IPv4 BGP FlowSpec 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.
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.
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


(2020-04-09)
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
----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)
Prerequisites
Before redirecting a public IPv4 BGP FlowSpec route to an SR-MPLS TE Policy in
controller-based dynamic delivery mode, complete the following tasks:
● Use a controller to dynamically deliver an SR-MPLS TE Policy.
Context
If a controller is deployed, the controller can be used to configure a public IPv4
BGP FlowSpec route to be redirected to an SR-MPLS TE Policy. The configuration
process 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.

(2020-04-09)
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 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.
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
automatically imported to the BGP-Flow routing table and then sent to each
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


(2020-04-09)

1.2.39 Configuring Examples for SR-MPLS BE

This section provides several configuration examples of SR-MPLS BE.
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-115:
● 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-115 L3VPN recursive to an IS-IS SR-MPLS BE tunnel
Interfaces 1 through 3 in this example represent GE 1/0/0, GE 2/0/0, and GE 3/0/0, respectively.

(2020-04-09)
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:
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

(2020-04-09)
[*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
[*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] commit
[*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

(2020-04-09)
[*P1-isis-1] quit
[*P1] commit
[*P1-LoopBack1] isis enable 1
[*P1-GigabitEthernet1/0/0] isis enable 1
[*P1] commit
# Configure PE2.
[~PE2] isis 1
[*PE2-isis-1] quit
[*PE2] commit
[*PE2] commit
# Configure P2.
[~P2] isis 1
[*P2-isis-1] quit
[*P2] commit
[*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

(2020-04-09)
[~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] commit
[~PE1] isis 1
[*PE1-isis-1] cost-style wide
[*PE1-isis-1] segment-routing mpls
[*PE1-isis-1] segment-routing global-block 16000 23999
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] commit
[~P1] isis 1
[*P1-isis-1] cost-style wide
[*P1-isis-1] segment-routing mpls
[*P1-isis-1] segment-routing global-block 16000 23999
[*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] interface loopback 1
[*P1-LoopBack1] isis prefix-sid index 20
[*P1] commit
# Configure PE2.
[*PE2] commit
[~PE2] isis 1

(2020-04-09)
[*PE2-isis-1] frr
[*PE2-isis-1] quit
[*PE2] commit
# Configure P2.
[*P2] commit
[~P2] isis 1
[*P2-isis-1] frr
[*P2-isis-1] quit
[*P2] commit
# After completing the configuration, run the display tunnel-info all command
on PEs, and you can view that SR LSPs are set up between PEs. In the following
example, the command output on PE1 is used.
[~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
# Using 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.

(2020-04-09)
[~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 completing the configuration, run the display bgp peer or display bgp
vpnv4 all peer command on PEs, and you can view that a BGP peer relationship is
set up between PEs and the BGP peer relationship is in the Established state. In
the following example, the command output on PE1 is used.
[~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-GigabitEthernet1/0/0] ip binding vpn-instance vpna
[*PE1] commit
# Configure PE2.
[*PE2] commit

(2020-04-09)
# Assign an IP address to each interface on CEs as shown in Figure 1-115. The

detailed configuration procedure is not provided here. For details, see
Configuration Files.
After the configuration, run the display ip vpn-instance verbose command on
PEs to view the configurations of VPN instances. Each PE can successfully ping its
connected CE.
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] 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.
[~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
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

(2020-04-09)
[*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
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.
[~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 Tables: 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

(2020-04-09)
Configuration Files
● PE1 configuration file
#
sysname PE1
#
ip vpn-instance vpna
ipv4-family
route-distinguisher 100:1
tnl-policy policy1
vpn-target 111:1 export-extcommunity
vpn-target 111:1 import-extcommunity
#
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
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 policy1
tunnel select-seq sr-lsp load-balance-number 2
#
return

(2020-04-09)
● 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
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 policy1
#
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
#

(2020-04-09)
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
#
ipv4-family unicast
peer 1.1.1.9 enable
#
ipv4-family vpnv4
policy vpn-target
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
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

(2020-04-09)
#
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
#
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-116:
● 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-116 L3VPN recursive to an OSPF SR-MPLS BE tunnel

(2020-04-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-04-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-04-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] commit
[*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] commit
[*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] commit
[*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] commit

(2020-04-09)

[*P2-LoopBack1] ospf enable 1 area 0
[*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] commit
[~PE1] ospf 1
[*PE1-ospf-1] segment-routing mpls
[*PE1-ospf-1] segment-routing global-block 16000 23999
[*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.

(2020-04-09)
[*P1] commit
[~P1] ospf 1
[*P1-ospf-1] segment-routing mpls
[*P1-ospf-1] segment-routing global-block 16000 23999
[*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] commit
[~PE2] ospf 1
[*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] commit
[~P2] ospf 1
[*P2-ospf-1] segment-routing mpls
[*P2-ospf-1] segment-routing global-block 16000 23999
[*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

(2020-04-09)
on PEs, and you can view that SR LSPs are set up between PEs. 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
# 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
# After completing the configuration, run the display bgp peer or display bgp
vpnv4 all peer command on PEs, and you can view that a BGP peer relationship is
set up between PEs and the BGP peer relationship is in the Established state. In
the following example, the command output on PE1 is used.
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

(2020-04-09)
Step 6 Configure VPN instances in the IPv4 address family on each PE and connect each
PE to a CE.
# Configure PE1.
[*PE1] commit
# Configure PE2.
[*PE2] commit
# Assign an IP address to each interface on CEs as shown in Figure 1-116. The

detailed configuration procedure is not provided here. For details, see
"Configuration Files".
After the configuration, run the display ip vpn-instance verbose command on
PEs to view the configurations of VPN instances. Each PE can successfully ping its
connected CE.
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-04-09)

[*PE2] commit
Step 8 Set up EBGP peer relationships between PEs and CEs.

# Configure CE1.
[*CE1] bgp 65410
[*CE1-bgp] network 10.11.1.1 32
[*CE1-bgp] quit
[*CE1] commit
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
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-04-09)

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 policy1
#
mpls lsr-id 1.1.1.9
#
mpls
#
segment-routing
#
ospf 1
opaque-capability enable
frr
loop-free-alternate
ti-lfa enable
area 0.0.0.0
#
undo shutdown
ip address 172.18.1.1 255.255.255.0
ospf enable 1 area 0
#
undo shutdown
ip address 10.1.1.2 255.255.255.0
#
undo shutdown

(2020-04-09)
ip address 172.16.1.1 255.255.255.0

#
interface LoopBack1
ip address 1.1.1.9 255.255.255.255
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
#
#
#
return
#
sysname P1
#
mpls lsr-id 2.2.2.9
#
mpls
#
segment-routing
#
ospf 1
frr
loop-free-alternate
ti-lfa enable
area 0.0.0.0
#
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
#
return
#
sysname PE2
#
ipv4-family

(2020-04-09)
tnl-policy policy1
#
mpls lsr-id 3.3.3.9
#
mpls
#
segment-routing
#
ospf 1
frr
loop-free-alternate
ti-lfa enable
area 0.0.0.0
#
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
#
#
#
return
#
sysname P2
#
mpls lsr-id 4.4.4.9
#
mpls
#
segment-routing
#

(2020-04-09)
ospf 1
frr
loop-free-alternate
ti-lfa enable
area 0.0.0.0
#
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
#
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-04-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-117, non-labeled public BGP routes are configured to recurse to an
SR-MPLS BE tunnel.
Figure 1-117 Non-labeled public BGP route recursion to an SR-MPLS BE tunnel
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-04-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-04-09)
[~PE1] isis 1
[*PE1-isis-1] quit
[*PE1] commit
[*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] commit
[*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
[*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

(2020-04-09)
Step 4 Configure segment routing on the backbone network.
# Configure PE1.
[*PE1-segment-routing] tunnel-prefer segment-routing
[*PE1] commit
[~PE1] isis 1
[*PE1-isis-1] quit
[*PE1] commit
# Configure the P.
[~P] segment-routing
[*P-segment-routing] tunnel-prefer segment-routing
[*P-segment-routing] quit
[*P] commit
[~P] isis 1
[*P-isis-1] cost-style wide
[*P-isis-1] segment-routing mpls
[*P-isis-1] segment-routing global-block 160000 161000
[*P-isis-1] quit
[*P] interface loopback 1
[*P-LoopBack1] isis prefix-sid index 20
[*P-LoopBack1] quit
[*P] commit
# Configure PE2.
[*PE2] commit
[~PE2] isis 1
[*PE2-isis-1] quit
[*PE2] commit
Step 5 Establish an IBGP peer relationship between PEs.
# Configure PE1.
[~PE1] bgp 100
[*PE1-bgp] commit
[~PE1-bgp] quit
# Configure PE2.
[~PE2] bgp 100
[*PE2-bgp] commit
[~PE2-bgp] quit

(2020-04-09)
After the completing the configuration, run the display bgp peer command on
the PEs. BGP peer relationships between PEs have been established and are in the
Established state. In the following example, the command output on PE1 is used.
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] commit
[~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] commit
[~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
#
mpls lsr-id 1.1.1.9
#
mpls
#
segment-routing
tunnel-prefer segment-routing
#
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
#

(2020-04-09)
interface LoopBack1
ip address 1.1.1.9 255.255.255.255
isis enable 1
#
bgp 100
unicast-route recursive-lookup tunnel tunnel-selector s1
#
ipv4-family unicast
peer 3.3.3.9 enable
#
tunnel-policy p1
#
tunnel-selector s1 permit node 10
apply 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
#
mpls lsr-id 3.3.3.9
#
mpls
#
segment-routing
#
isis 1
is-level level-1

(2020-04-09)
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
unicast-route recursive-lookup tunnel tunnel-selector s1
#
ipv4-family unicast
peer 1.1.1.9 enable
#
tunnel-policy p1
#
tunnel-selector s1 permit node 10
apply 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.
In Figure 1-118, an SR domain is established between PE1 and the P, and an LDP
domain resides between the P and PE2. PE1 and PE2 need to access each other.
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.

(2020-04-09)
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
form 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
[*P-LoopBack1] quit
[*P] commit
# Configure PE2.
[*HUAWEI] commit

(2020-04-09)
[*PE2] commit

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] quit
[*PE1] commit
[*PE1] commit
# Configure the P.
[~P] isis 1
[*P-isis-1] quit
[*P] commit
[*P-LoopBack1] quit
[*P] commit
# Configure PE2.
[~PE2] isis 1
[*PE2-isis-1] quit
[*PE2] commit
[*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] commit

(2020-04-09)
[~P-mpls] quit
[*P-GigabitEthernet2/0/0] mpls
[*P] commit
# Configure PE2.
[*PE2] mpls
[*PE2-mpls] commit
[~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] commit
[~PE1] isis 1
[*PE1-isis-1] quit
[*PE1] commit
# Configure the P.
[*P-segment-routing] tunnel-prefer segment-routing
[*P] commit
[~P] isis 1
[*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] commit
[~P-mpls-ldp] quit
[*P-GigabitEthernet2/0/0] mpls ldp
[*P] commit
# Configure PE2.
[~PE2] mpls ldp
[*PE2-mpls-ldp] commit
[~PE2-mpls-ldp] quit
[*PE2-GigabitEthernet1/0/0] mpls ldp

(2020-04-09)
[*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] commit
[~P] isis 1
[*P-isis-1] segment-routing mapping-server send
[*P-isis-1] quit
[*P] commit
[~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 --- 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.
# 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: IPV4 PREFIX 3.3.3.9/32 : 100 data bytes, press CTRL_C to break
--- FEC: IPV4 PREFIX 3.3.3.9 ping statistics ---
0.00% packet loss
----End
Configuration Files
#
sysname PE1
#
mpls lsr-id 1.1.1.9

(2020-04-09)
#
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
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

(2020-04-09)
#
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-119, traffic can reach CE1 through either PE2 or PE3. IS-IS
anycast FRR can be configured to enable PE2 and PE3 to protect each other,
improving network reliability.
Figure 1-119 IS-IS anycast FRR protection networking
Precautions
None

(2020-04-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.
[*HUAWEI] commit
[*PE2] commit
# Configure PE3.
[*HUAWEI] commit

(2020-04-09)
[*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
[*PE1] commit
# Configure PE2.
[~PE2] isis 1
[*PE2-isis-1] quit
[*PE2] commit
[*PE2] commit
# Configure PE3.
[~PE3] isis 1
[*PE3-isis-1] quit
[*PE3] commit
[*PE3] commit
# Configure PE1.
[*PE1] mpls
[*PE1-mpls] commit
[~PE1-mpls] quit
# Configure PE2.
[*PE2] mpls
[*PE2-mpls] commit
[~PE2-mpls] quit

(2020-04-09)
# 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] commit
[~PE1] isis 1
The SRGP 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] commit
[~PE2] isis 1
[*PE2] commit
# Configure PE3.
[*PE3] commit
[~PE3] isis 1

(2020-04-09)
[*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
160020(B) 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:46:33.920
BFD State: --
Label Stack (Top -> Bottom): { 3 }
Backup UpdateTime : 2018-12-11 06:49:47.550
Backup Label Stack (Top -> Bottom): { }
----End
Configuration Files
#
sysname PE1
#
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
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
#

(2020-04-09)
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
#
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

(2020-04-09)

#
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.
On the network shown in Figure 1-120, SR-MPLS BE tunnels between public
network PEs are deployed. To improve network reliability, SBFD needs to be
deployed. If SBFD detects a fault on an SR-MPLS BE tunnel, a protection
application, for example, VPN FRR, rapidly switches traffic, which minimizes the
impact on traffic.
Figure 1-120 SBFD for SR-MPLS BE tunnel
Precautions
None
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

(2020-04-09)

● VLAN instance name (vpna) and its VPN-target and RD
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
[*PE2] commit
# Configure P2.
[*HUAWEI] commit

(2020-04-09)

[*P2] commit

connectivity between the PEs and Ps. IS-IS is used as an IGP protocol in this
example.
# Configure PE1.
[~PE1] isis 1
[*PE1-isis-1] quit
[*PE1] commit
[*PE1] commit
# Configure P1.
[~P1] isis 1
[*P1-isis-1] quit
[*P1] commit
[*P1] commit
# Configure PE2.
[~PE2] isis 1
[*PE2-isis-1] quit
[*PE2] commit
[*PE2] commit
# Configure P2.
[~P2] isis 1
[*P2-isis-1] quit

(2020-04-09)
[*P2] commit
[*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] commit
[~PE1] isis 1
The SRGB range various according to a live network. Set a range as needed. The SRGB
[*PE1-isis-1] frr
[*PE1-isis-1] quit
[*PE1] commit
# Configure P1.

(2020-04-09)
[*P1] commit
[~P1] isis 1
[*P1-isis-1] frr
[*P1-isis-1] quit
[*P1] commit
# Configure PE2.
[*PE2] commit
[~PE2] isis 1
[*PE2-isis-1] frr
[*PE2-isis-1] quit
[*PE2] commit
# Configure P2.
[*P2] commit
[~P2] isis 1
[*P2-isis-1] frr
[*P2-isis-1] quit

(2020-04-09)
[*P2] commit
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] 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
Seamless BFD Information for SR Tunnel
Total Tunnel Number: 1
-------------------------------------------------------------------
Prefix Discriminator State
-------------------------------------------------------------------
3.3.3.9/32 16385 Up
-------------------------------------------------------------------
----End

(2020-04-09)
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
frr
ti-lfa level-1
#
undo shutdown
ip address 172.16.1.2 255.255.255.0
isis enable 1
#

(2020-04-09)
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
#
mpls
#
segment-routing
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0004.00

(2020-04-09)
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-121, 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-121 TI-LFA FRR for an SR-MPLS BE tunnel

(2020-04-09)
Precautions
In this example, TI-LFA FRR is configured on Device B to protect the link between
Device B and Device E. 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
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] commit
[*DeviceA] interface loopback 1
[*DeviceA-LoopBack1] isis enable 1
[*DeviceA-GigabitEthernet1/0/0] isis enable 1
[*DeviceA] commit

(2020-04-09)
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
[~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] commit
[~DeviceA] isis 1
[*DeviceA-isis-1] segment-routing mpls
[*DeviceA-isis-1] segment-routing global-block 16000 23999
The SRGB range varies according to the device. The configuration in this example is for
reference only.
[*DeviceA-LoopBack1] isis prefix-sid index 10
[*DeviceA] commit

(2020-04-09)
[~DeviceB] segment-routing
[*DeviceB-segment-routing] quit
[*DeviceB] commit
[~DeviceB] isis 1
[*DeviceB-isis-1] segment-routing mpls
[*DeviceB-isis-1] segment-routing global-block 16000 23999
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] commit
[~DeviceC] isis 1
[*DeviceC-isis-1] segment-routing mpls
[*DeviceC-isis-1] segment-routing global-block 16000 23999
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] commit
[~DeviceD] isis 1
[*DeviceD-isis-1] segment-routing mpls
[*DeviceD-isis-1] segment-routing global-block 16000 23999
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] commit
[~DeviceE] isis 1
[*DeviceE-isis-1] segment-routing mpls
[*DeviceE-isis-1] segment-routing global-block 16000 23999
reference only.

(2020-04-09)
[*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] commit
[~DeviceF] isis 1
[*DeviceF-isis-1] segment-routing mpls
[*DeviceF-isis-1] segment-routing global-block 16000 23999
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
--------------------------------------------------------------

-----------------------------------------------------------------------------------------------------------------
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 5000
[*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
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)
-----------------------------

(2020-04-09)
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
Backup Label Stack (Top -> Bottom): {16040, 48141}
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
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:

(2020-04-09)
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

Priority : Low Age : 04:09:15
10.2.1.2 GE2/0/0 0x0000000a
TI-LFA:
Interface : GE3/0/0
NextHop : 10.5.1.2 LsIndex : --
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

(2020-04-09)
Flags: D-Direct, A-Added to URT, L-Advertised in LSPs, S-IGP Shortcut,

U-Up/Down Bit Set, LP-Local Prefix-Sid

# 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 ]
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

(2020-04-09)
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
#
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
#

(2020-04-09)
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
#
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
#

(2020-04-09)
undo shutdown
ip address 10.6.1.1 255.255.255.0
isis enable 1
#
undo shutdown
ip address 10.4.1.1 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
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.

(2020-04-09)
● 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-122 Configuring L3VPN over an SR-MPLS TE tunnel
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.

(2020-04-09)
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
[*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

(2020-04-09)
[*PE1] commit
# Configure P1.
[~P1] isis 1
[*P1-isis-1] quit
[*P1] commit
[*P1] commit
# Configure PE2.
[~PE2] isis 1
[*PE2-isis-1] quit
[*PE2] commit
[*PE2] commit
Step 3 Configure basic MPLS functions and enable MPLS TE on the backbone network.
# Configure PE1.
[*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.

(2020-04-09)
[*PE1] commit
[~PE1] isis 1
[*PE1-isis-1] traffic-eng level-2
[*PE1-isis-1] quit
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] commit
[~P1] isis 1
[*P1-isis-1] traffic-eng level-2
[*P1-isis-1] quit
reference only.
[*P1-LoopBack1] isis prefix-sid absolute 16200
[*P1] commit
# Configure PE2.
[*PE2] commit
[~PE2] isis 1
[*PE2-isis-1] quit
reference only.

(2020-04-09)

[*PE2] commit
[~PE2] explicit-path pe1
[*PE2-explicit-path-pe1] quit
[*PE2-Tunnel1] mpls te path explicit-path pe1
[~PE2-Tunnel1] quit
# After the configuration is complete, run the display tunnel-info all command
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.
----------------------------------------------------------------------------------------
1 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 ---
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
After the configuration is complete, run the display bgp peer or display bgp
vpnv4 all peer command on each PE. The command output shows that the MP-

(2020-04-09)
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.
[*PE2] commit
# Assign an IP address to each CE interface as shown in Figure 1-122. For details,

see "Configuration Files" in this section.
After the configuration is complete, run the display ip vpn-instance verbose
command on each PE. The command output shows the configurations of VPN
instances. Each PE can successfully ping its connected CE.
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

(2020-04-09)
[*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
[*CE1-bgp] quit
[*CE1] commit
Repeat this step on CE2. For configuration details, see "Configuration Files" in this section.
# Configure PE1.
[~PE1] bgp 100
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

(2020-04-09)

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.
------------------------------------------------------------------------------
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
0.00% packet loss
----End
Configuration Files
#
sysname PE1
#
ipv4-family
apply-label per-instance
tnl-policy p1
#
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

(2020-04-09)
#
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
#
bgp 100
#
ipv4-family unicast
peer 3.3.3.9 enable
#
ipv4-family vpnv4
policy vpn-target
peer 3.3.3.9 enable
#
#
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
#
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
#

(2020-04-09)
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
#
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
#

(2020-04-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 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
#
return

#
sysname CE2
#
interface GigabitEthernet 1/0/0
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 LDP VPLS over SR-MPLS TE

The public network tunnel for an LDP VPLS network can be an SR-MPLS TE
tunnel.

(2020-04-09)
Figure 1-123 Configuring LDP VPLS over SR-MPLS TE
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.
On the network shown in Figure 1-123, 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.
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

(2020-04-09)
● 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
# 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 both
globally and per interface. On the ingress node of the tunnel, configure MPLS TE
in the system view.
# Configure PE1.
[*PE1] mpls
[*PE1-mpls] mpls te
[*PE1-mpls] quit
[*PE1] commit
# Configure the P.

(2020-04-09)

[*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.
[~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
[*PE1-ospf-1] quit
# Configure the P.
[*P] ospf 1
[*P-ospf-1] segment-routing mpls

(2020-04-09)
[*P-ospf-1] segment-routing global-block 16000 47999

[*P-ospf-1] quit
# Configure PE2.
[*PE2] ospf 1
[*PE2-ospf-1] quit
Step 5 Configure explicit paths.

# Configure PE1.
[~PE1] explicit-path path2pe2
[*PE1-explicit-path-path2pe2] next sid label 16300 type prefix
[*PE1-explicit-path-path2pe2] quit
# Configure PE2.
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

(2020-04-09)
Step 7 Configure remote LDP sessions.

Set up remote peer sessions between PE1 and PE2.
# Configure PE1.
[~PE1] mpls ldp
[*PE1-mpls-ldp] quit
[*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.
[~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] commit
# Configure PE2.
[~PE2] mpls l2vpn
[*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] 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] commit

(2020-04-09)
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.
[~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
Administrator VSI : no
Isolate Spoken : disable
VSI Index :1
PW Signaling : ldp
Member Discovery Style : --
Bridge-domain Mode : disable
PW MAC Learning Style : unqualify
Encapsulation Type : vlan
MTU : 1500
Diffserv Mode : uniform
Service Class : --
Color : --
DomainId : 255
Domain Name :
Ignore AcState : disable
P2P VSI : 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
primary or secondary : primary
ignore-standby-state : no
VC Label : 18
Peer Type : dynamic
Session : up

(2020-04-09)
Tunnel ID : 0x000000000300000001
Broadcast Tunnel ID : --
Broad BackupTunnel ID : --
Tunnel Policy Name : policy1
CKey : 33
NKey : 1610612843
Stp Enable :0
PwIndex :0
Control Word : disable
Interface Name : GigabitEthernet2/0/0.1

State : up
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
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
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

(2020-04-09)
Configuration Files
#
sysname CE1
#
undo shutdown
#
interface GigabitEthernet1/0/0.1
undo shutdown
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
#
undo shutdown
vlan-type dot1q 10
l2 binding vsi a2
#
undo shutdown
ip address 10.10.1.1 255.255.255.0
ospf cost 1
#
interface LoopBack1
ip address 1.1.1.9 255.255.255.255
ospf enable 1 area 0.0.0.0
ospf prefix-sid absolute 16100
#
interface Tunnel10
destination 3.3.3.9
mpls te tunnel-id 100

(2020-04-09)
mpls te path explicit-path path2pe2

mpls te reserved-for-binding
#
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
mpls-te enable
#
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
ospf cost 1
#
undo shutdown
ip address 10.20.1.1 255.255.255.0
ospf cost 1
#
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
#

(2020-04-09)
#
segment-routing
#
undo shutdown
#
undo shutdown
vlan-type dot1q 10
l2 binding vsi a2
#
undo shutdown
ip address 10.20.1.2 255.255.255.0
ospf cost 1
#
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
#
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.

(2020-04-09)
On the network shown in Figure 1-124, 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.
Figure 1-124 Networking of BD EVPN IRB over SR-MPLS TE
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.

(2020-04-09)
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.
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-124.
# Configure PE1.
[*HUAWEI] commit
[*PE1] commit
# Configure P.
[~HUAWEI] sysname P
[*HUAWEI] commit
[*P-LoopBack1] quit
[*P] commit
# Configure PE2.
[*HUAWEI] commit

(2020-04-09)
[*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] 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.
The following example uses the command output on PE1.
[~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
[~PE1] display ip routing-table
------------------------------------------------------------------------------
Routing Table : _public_

(2020-04-09)
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
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
[*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
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-04-09)

[*P-isis-1] traffic-eng level-2
[*P-isis-1] quit
[*P-LoopBack1] isis prefix-sid absolute 153710
[*P-LoopBack1] quit
# Configure PE2.
[*PE2] mpls
[*PE2-mpls] mpls te
[*PE2-mpls] quit
[*PE2] isis 1
[*PE2-isis-1] quit
[*PE2-Tunnel1] quit
[*PE2] commit
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

(2020-04-09)
Primary Tunnel :- Pri Tunn Sum : -

Backup Tunnel :-
Group Status : Up Oam Status : None
IPTN InLabel :- Tunnel BFD Status : -
BackUp LSP Type : None BestEffort : Disabled
Secondary HopLimit : -
BestEffort HopLimit : -
Secondary Explicit Path Name: -
Secondary Affinity Prop/Mask: 0x0/0x0
BestEffort Affinity Prop/Mask: 0x0/0x0
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 : None
Associated Tunnel Group ID: - Associated Tunnel Group Type: -
Auto BW Remain Time : - Reopt Remain Time :-
Segment-Routing Remote Label : -
Binding Sid :- Reverse Binding Sid : -
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 : Disabled Record Label : Disabled
Route Pinning : Disabled
FRR Flag : Disabled
IdleTime Remain :-
BFD Status :-
Soft Preemption : Disabled
Reroute Flag : Enabled
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

(2020-04-09)
[*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
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] commit
Step 7 Configure a vBDIF interface on each PE and bind the vBDIF interface to a VPN
instance.
# Configure PE1.
[~PE1] interface Vbdif10

(2020-04-09)
[*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-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
[*PE1-vpn-instance-vpn1] tnl-policy srte evpn
[*PE1] commit
# Configure PE2.
[*PE2] commit
Step 9 Establish BGP EVPN peer relationships between PEs.

# Configure PE1.
[~PE1] bgp 100
[*PE1-bgp] peer 3.3.3.3 as-number 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

(2020-04-09)

[*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
[*CE1-GigabitEthernet1/0/0.1] encapsulation dot1q vid 10
[*CE1-GigabitEthernet1/0/0.1] rewrite pop single
# Configure CE2.

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 10.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:

(2020-04-09)
*> 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.2 0.0.0.0
*>i 0:48:00e0-fc12-3456:32:192.168.2.2 3.3.3.3
*>i 0:48:00e0-fc12-3456:32:192.168.2.2 3.3.3.3
*> 0:48:00e0-fc12-7890:32:192.168.1.2 0.0.0.0

Number of Inclusive Multicast Routes: 2
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.2 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.2

(2020-04-09)

Total routes of Route Distinguisher(200:1): 1
BGP routing table entry information of 0:48:00e0-fc12-3456:32:192.168.2.2:
Label information (Received/Applied): 54011 48182/NULL
From: 3.3.3.3 (10.2.1.2)
Route Duration: 0d20h42m36s
Relay IP Nexthop: 10.1.1.2
Relay Tunnel Out-Interface: GigabitEthernet1/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
Remote-Cross route
From: 3.3.3.3 (10.2.1.2)
Relay Tunnel Out-Interface: Tunnel1
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 (10.2.1.2)
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

(2020-04-09)

#
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
#
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
#

(2020-04-09)
ipv4-family unicast
peer 3.3.3.3 enable
#
ipv4-family vpn-instance vpn1
import-route direct
advertise l2vpn evpn
#
l2vpn-family evpn
undo 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
#
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

(2020-04-09)

#
mpls lsr-id 3.3.3.3
#
mpls
mpls te
#
bridge-domain 10
#
#
segment-routing
#
isis 1
is-level level-2
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

(2020-04-09)

#
l2vpn-family evpn
peer 1.1.1.1 enable
#
tunnel-policy srte
#
#
return

#
sysname CE1
#
undo shutdown
#
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-125, EVPN L3VPNv6 is configured on the
backbone network to allow IPv6 interworking at Layer 3 between CEs. In this
Figure 1-125 Networking of configuring EVPN L3VPNv6 over SR-MPLS TE

(2020-04-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.

(2020-04-09)
[*HUAWEI] commit
[*PE1] commit
# Configure P.
[~HUAWEI] sysname P
[*HUAWEI] commit
[*P-LoopBack1] quit
[*P] commit
# Configure PE2.
[*HUAWEI] commit
[*PE2] 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

(2020-04-09)

[*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
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
------------------------------------------------------------------------------


# Configure PE1.
[*PE1] mpls
[*PE1-mpls] mpls te
[*PE1-mpls] quit
[*PE1] isis 1
[*PE1-isis-1] quit

(2020-04-09)

[*PE1-Tunnel1] quit
[*PE1] commit

-----------------------------------------------------------------------------
48140 GE2/0/0 10.1.1.2 ISIS-V4 --- 1500
# Configure the P.
[*P] mpls
[*P-mpls] mpls te
[*P-mpls] quit
[*P] isis 1
[*P-isis-1] quit
[*P-LoopBack1] quit
[*P] commit
# Configure PE2.
[*PE2] mpls
[*PE2-mpls] mpls te
[*PE2-mpls] quit
[*PE2] isis 1
[*PE2-isis-1] quit

(2020-04-09)
[*PE2-Tunnel1] quit
[*PE2] commit
After completing the configurations, run the 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 :-
Ip-Prefix Name : -

(2020-04-09)

IncludeAll : 0x0
IncludeAny : 0x0
ExcludeAny : 0x0
FRR Flag : Disabled
IdleTime Remain :-
BFD Status :-
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
# Configure PE2.
[*PE2] commit
Step 5 Configure and apply a tunnel policy so that EVPN can iterate SR-MPLS TE tunnels.
# Configure PE1.

(2020-04-09)

[*PE1-vpn-instance-vpn1-af-ipv6] tnl-policy srte evpn
[*PE1] commit
# Configure PE2.
[*PE2] commit

# 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
[*PE2-bgp] quit
[*PE2] commit
After completing the configurations, run the display bgp evpn peer command to


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.

(2020-04-09)
[~PE1] bgp 100

[*PE1-bgp6-vpn1] peer 2001:DB8:1::2 as-number 65410
[*PE1-bgp6-vpn1] quit
[*PE1-bgp] quit
[*PE1] commit
# Configure EBGP on CE1.

[~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 Figure 1-125 in this section.


*> 0:[2001:DB8:1::]:64 ::
* ::FFFF:0.0.0.0
*>i 0:[2001:DB8:2::]:64 ::FFFF:3.3.3.3
*> 0:[2001:DB8:4::4]:128 ::FFFF:0.0.0.0
*>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 (10.2.1.2)
Relay IP Out-Interface:
GigabitEthernet2/0/0
Relay Tunnel Out-Interface:
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

(2020-04-09)
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

RelayNextHop : ::FFFF:0.0.0.0 TunnelID :
0x000000000300000001
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

(2020-04-09)
::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
Configuration Files
#
sysname PE1
#
ipv6-family
#
mpls lsr-id 1.1.1.1
#
mpls
mpls te
#
#
segment-routing
#
isis 1
is-level level-2

(2020-04-09)
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
peer 2001:DB8:1::2 as-number 65410
#
l2vpn-family evpn
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

(2020-04-09)

#
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
#
#
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

(2020-04-09)
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
peer 1.1.1.1 enable
#
tunnel-policy srte
#
return
#
sysname CE1
#
undo shutdown
ipv6 enable
#
interface LoopBack1
ipv6 enable
#
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

(2020-04-09)

#
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.
In Figure 1-126, PE1 is to establish a tunnel to PE2 and an LSP to PE2. Segment
routing (SR) is used to generate path information and forward data. PE1 is the
ingress, and PE2 is the egress. IS-IS neighbor relationships are 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.
● 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-126 Example for configuring the controller to run NETCONF to deliver
configurations to create an SR-MPLS TE tunnel
Interfaces 1 through 3 in this example represent GE 1/0/0, GE 2/0/0, and GE 3/0/0,

respectively.

(2020-04-09)
1. Assign an IP address and its mask to every interface and configure a loopback
interface address as an 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-126
● 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-126.
Procedure
Step 1 Assign an IP address and a mask to each interface.
# Configure PE1.
[*HUAWEI] commit

(2020-04-09)
[*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.
[~P1] isis 1
[*P1-isis-1] quit

(2020-04-09)

[*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
[*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

(2020-04-09)
[*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
-------------------------------------------------------------------------------
- - - 101/101 T lsp
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
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

(2020-04-09)
#
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
network-entity 10.0000.0000.0002.00
traffic-eng level-2
bgp-ls enable 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
#
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

(2020-04-09)
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
#
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

(2020-04-09)
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-127, establish a tunnel and LSP from PE1 to
PE2, and use segment routing (SR) 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 a
label path 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.
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-127 Configuring static BFD for SR-MPLS TE

respectively.

(2020-04-09)
1. Assign an IP address and a mask to each interface, and configure a loopback
address as an LSR ID on each node.
LSR.
3. Enable segment routing globally on each node.
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-127
● IS-IS process ID: 1; system ID: loopback0 address; IS-IS level: level-2
● IS-IS neighbor relationship between P1 and the controller, as shown in Figure
1-127
● Name of a BFD session
● Local and remote discriminators of a BFD session
Procedure
# Configure PE1.

(2020-04-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-04-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.
# Configure PE1.
[~PE1] mpls lsr-id 10.21.2.9
[~PE1] mpls
[*PE1-mpls] mpls te
[*PE1-mpls] quit
[~PE1] interface gigabitethernet 1/0/0
The configurations except the LSR ID configuration on P1 and PE2 are the same as
those on PE1.
Step 5 Enable segment routing globally on each node.
# 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
[~PE1-isis-1] quit
The configuration on P1 and PE2 is the same as that on PE1.

(2020-04-09)
Step 7 Configure a tunnel interface on PE1.
# Configure PE1.
[~PE1-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.
# On PE1, configure a BFD session to monitor an SR-MPLS TE tunnel, and specify

the minimum interval between sending BFD packets and the minimum interval
between receiving BFD packets.
[~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
# On PE2, configure a BFD session to monitor a reverse SR-MPLS TE tunnel, and

specify the minimum interval between sending BFD packets and the minimum
interval between receiving BFD packets.
[~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
# 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

(2020-04-09)
Configuration Files
#
sysname PE1
#
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
import-route static
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
#
bfd pe2tope1 bind mpls-te interface Tunnel10
discriminator local 12
discriminator remote 21
min-tx-interval 100
min-rx-interval 100
#
return
#
sysname P1
#
#
mpls
mpls te
#
segment-routing
#
isis 1
is-level level-2
cost-style wide
network-entity 11.2222.2222.2222.00
import-route static
traffic-eng level-2
#

(2020-04-09)
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
#
#
mpls
mpls te
#
segment-routing
#
isis 1
is-level level-2
cost-style wide
network-entity 11.3333.3333.3333.00
import-route static
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
#
interface Tunnel10
destination 10.21.2.9
mpls te tunnel-id 2
#
bfd
#
bfd pe2tope1 bind mpls-te interface Tunnel10
min-tx-interval 100
min-rx-interval 100
#
return

(2020-04-09)
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.
In Figure 1-128, PE1 is to establish a tunnel to PE2 and the primary and backup
LSPs to PE2. Segment routing (SR) is used to generate path information and
forward data. 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.
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-128 Networking diagram for configuring dynamic BFD for SR-MPLS TE
LSP
Interfaces 1 to 3 in this example represent GE 1/0/0, GE 2/0/0, and GE 3/0/0, respectively.

(2020-04-09)
1. Assign an IP address and its mask to every interface and configure a loopback
interface address as an LSR ID on every node.
LSR.
3. Enable SR globally on each node.
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-04-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-128
● 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-04-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 P1 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.
# Configure PE1.

(2020-04-09)
[*PE1] mpls
[*PE1-mpls] mpls te
[*PE1-mpls] quit
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 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
Tunnel Attributes :
Traffic Switch :-
Session ID :1

(2020-04-09)
Signaling Protocol : RSVP

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 :-
Offload Explicit Path Name:
Tunnel Group :-
Backup Tunnel :-
Group Status : Up Oam Status : -
BackUp LSP Type : Hot-Standby BestEffort : Enabled
Ip-Prefix Name : -
PCE Delegate : Only status report LSP Control Status : Local control
Entropy Label :None
Auto BW Remain Time : 200 s Reopt Remain Time : 100 s
Metric Inherit IGP : None
FRR Attr Source : - Is FRR degrade down : No

IncludeAll : 0x0
IncludeAny : 0x0
ExcludeAny : 0x0
Explicit Path Name : main Hop Limit: -
FRR Flag : Disabled
IdleTime Remain :-
BFD Status :-
Soft Preemption : Enabled
Reroute Flag : Disabled

(2020-04-09)
Pce Flag : Normal

Backup LSP ID : 1.1.1.9:46945

IsBestEffortPath : No
LSP State : UP LSP Type : Hot-Standby
IncludeAll : 0x0
IncludeAny : 0x0
ExcludeAny : 0x0
Explicit Path Name : - Hop Limit: -
Record Route : Enabled Record Label : Disabled
FRR Flag : Disabled
IdleTime Remain :-
BFD Status :-
Soft Preemption : Enabled
Pce Flag : Normal
Path Setup Type : CSPF
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
Lsp ID : 1.1.1.1 :1 :26
Hop 0 Label 330000 NAI 10.1.1.2

Hop Information
Hop 0 Label 330002 NAI 10.1.2.2
Hop 1 Label 330002 NAI 10.1.3.1
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

(2020-04-09)
[*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 and PE2. 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
mpls
mpls te
#
interface LoopBack0
ip address 1.1.1.1 255.255.255.255
isis enable 1
#
interface Tunnel1

(2020-04-09)

destination 3.3.3.3
mpls te tunnel-id 1
mpls te pce delegate
mpls te backup hot-standby
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
#
segment-routing
#
isis 1
is-level level-2
cost-style wide
network-entity 10.0000.0000.0004.00
traffic-eng level-2

(2020-04-09)
#
undo shutdown
ip address 10.1.1.2 255.255.255.0
isis enable 1
mpls
mpls te
#
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-129, 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
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-129 TI-LFA FRR for a loose SR-MPLS TE tunnel

(2020-04-09)
Precautions
In this example, TI-LFA FRR is configured on Device B to protect the link between
Device B and Device E. 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
[~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

(2020-04-09)
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] commit
[*DeviceA-LoopBack1] isis enable 1
[*DeviceA-GigabitEthernet1/0/0] isis enable 1
[*DeviceA] 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
[~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

(2020-04-09)
[*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] commit
[~DeviceA] isis 1
[*DeviceA-isis-1] segment-routing mpls
[*DeviceA-isis-1] segment-routing global-block 16000 23999
reference only.
[*DeviceA-LoopBack1] isis prefix-sid index 10
[*DeviceA] commit
[~DeviceB] segment-routing
[*DeviceB-segment-routing] quit
[*DeviceB] commit
[~DeviceB] isis 1
[*DeviceB-isis-1] segment-routing mpls
[*DeviceB-isis-1] segment-routing global-block 16000 23999
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] commit
[~DeviceC] isis 1
[*DeviceC-isis-1] segment-routing mpls
[*DeviceC-isis-1] segment-routing global-block 16000 23999
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

(2020-04-09)
[*DeviceD] commit
[~DeviceD] isis 1
[*DeviceD-isis-1] segment-routing mpls
[*DeviceD-isis-1] segment-routing global-block 16000 23999
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] commit
[~DeviceE] isis 1
[*DeviceE-isis-1] segment-routing mpls
[*DeviceE-isis-1] segment-routing global-block 16000 23999
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] commit
[~DeviceF] isis 1
[*DeviceF-isis-1] segment-routing mpls
[*DeviceF-isis-1] segment-routing global-block 16000 23999
reference only.
[*DeviceF-isis-1] quit
[*DeviceF] interface loopback 1
[*DeviceF-LoopBack1] isis prefix-sid index 60
[*DeviceF-LoopBack1] quit
[*DeviceF] commit
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

(2020-04-09)
[*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 :-
Session ID : 100
FTid : 8193
Bfd Cap : None
Min BW :- Max BW :-
Readjust Value :-
Backup Tunnel :-
Ip-Prefix Name : -

(2020-04-09)


IncludeAll : 0x0
IncludeAny : 0x0
ExcludeAny : 0x0
Explicit Path Name : p1 Hop Limit: -
FRR Flag : Disabled
IdleTime Remain :-
BFD Status :-
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 5000
[*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
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

(2020-04-09)

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

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

(2020-04-09)

10.5.1.2 GE3/0/0 16060
TI-LFA:
Interface : GE2/0/0

Direct GE1/0/0 0x00000000

Direct GE2/0/0 0x00000000

10.2.1.2 GE2/0/0 0x0000000a
TI-LFA:
Interface : GE3/0/0
NextHop : 10.5.1.2 LsIndex : --
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

(2020-04-09)
# 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 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 ]
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

(2020-04-09)

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
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
#
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
#

(2020-04-09)
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
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

(2020-04-09)

#
undo shutdown
ip address 10.6.1.1 255.255.255.0
isis enable 1
#
undo shutdown
ip address 10.4.1.1 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
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 in Figure 1-130, PE1 and ASBR1 are in AS 100, PE2 and
ASBR2 are in AS 200, and ASBR1 and ASBR2 are directly connected using two
physical links. PE1 needs to establish a bidirectional E2E tunnel to PE2. The

(2020-04-09)
Segment Routing (SR) protocol is used to generate and forward data. In the
direction from PE1 to PE2, PE1 is the ingress, and PE2 is the egress. In the direction
from PE2 to PE1, PE2 is the ingress, and PE1 is the egress.
Figure 1-130 E2E SR-MPLS TE tunnel networking
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 (tunnel 1) and AS 200 (tunnel
2); tunnel interface name of the PE1-to-PE2 E2E SR-MPLS TE tunnel (tunnel
3) and that of the PE2-to-PE1 E2E SR-MPLS TE tunnel (tunnel 3)
Procedure
# Configure PE1.

(2020-04-09)
[*HUAWEI] commit
[*PE1] commit
# Configure ASBR1.
[~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 ASBR1
[*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

(2020-04-09)
[*PE1] isis 1
[*PE1-isis-1] quit
[*PE1] commit
[*PE1] commit
[~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
In the preceding step, a PE1-to-ASBR1 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:

-----------------------------------------------------------------------------
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] commit
[*ASBR1] interface loopback 1
[*ASBR1-LoopBack1] isis enable 1
[*ASBR1-LoopBack1] isis prefix-sid absolute 16200
[*ASBR1-GigabitEthernet3/0/0] isis enable 1

(2020-04-09)
[*ASBR1-GigabitEthernet3/0/0] mpls
[*ASBR1-GigabitEthernet3/0/0] mpls te
[*ASBR1] commit
[~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
In the preceding step, an ASBR1-to-PE1 adjacency label is used in the next sid label command
[~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] commit
[*ASBR2] interface loopback 1
[*ASBR2-LoopBack1] isis enable 1
[*ASBR2-LoopBack1] isis prefix-sid absolute 16300
[*ASBR2-GigabitEthernet3/0/0] isis enable 1
[*ASBR2-GigabitEthernet3/0/0] mpls te
[*ASBR2] commit
[~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

(2020-04-09)
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.1 ISIS-V4 --- 1500
# Configure PE2.
[~PE2] mpls
[*PE2-mpls] mpls te
[*PE2-mpls] quit
[*PE2] isis 1
[*PE2-isis-1] quit
[*PE2] commit
[*PE2] commit
[~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
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

(2020-04-09)
Step 4 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] bgp 200
[~ASBR2-bgp] peer 2.2.2.2 as-number 100
[*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 completing the configuration, run the display bgp egress-engineering

command to view 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
Remote Interface Address : 3.3.3.3
SID Label : 32768
Peer Set SID Label : --
Nexthop : 10.2.1.2
Out interface : GigabitEthernet2/0/0
Nexthop : 10.1.1.2

(2020-04-09)
Peer Adj : 10.2.1.2

Local ASN : 100
Remote ASN : 200
Interface Identifier :7
SID Label : 32769
Nexthop : 10.2.1.2
Peer Adj : 10.1.1.2

Local ASN : 100
Remote ASN : 200
SID Label : 32770
Nexthop : 10.1.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.2.1.1
Nexthop : 10.1.1.1
Peer Adj : 10.2.1.1

Local ASN : 200
Remote ASN : 100
SID Label : 31769
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
Step 5 Set binding SIDs for the SR-MPLS TE tunnels within AS domains.
In the direction from PE1 to PE2:

(2020-04-09)
# 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 6 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-04-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 Name : tunnel3
Tunnel Attributes :
Traffic Switch :-
Session ID : 100
FTid :2
Bfd Cap : Enabled
Min BW :- Max BW :-
Readjust Value :-
Backup Tunnel :-
IPTN InLabel :- Tunnel BFD Status : Down
Ip-Prefix Name : -
Binding Sid : 2001 Reverse Binding Sid : 2002

IncludeAll : 0x0
IncludeAny : 0x0

(2020-04-09)
ExcludeAny : 0x0
CT0 Bandwidth(Kbit/sec): 0 CT1Bandwidth(Kbit/sec): 0
Explicit Path Name : path2pe2 Hop Limit: -
FRR Flag : Disabled
IdleTime Remain :-
BFD Status : DOWN
Pce Flag : Normal
# Check the status on PE2.
Tunnel Name : tunnel3
Tunnel Attributes :
Traffic Switch :-
Session ID : 400
FTid : 65
Bfd Cap : None
Min BW :- Max BW :-
Readjust Value :-
Backup Tunnel :-
Ip-Prefix Name : -

(2020-04-09)

Binding Sid : 2002 Reverse Binding Sid : 2001

IncludeAll : 0x0
IncludeAny : 0x0
ExcludeAny : 0x0
Explicit Path Name : path2pe1 Hop Limit: -
FRR Flag : Disabled
IdleTime Remain :-
BFD Status :-
Pce Flag : Normal
----End
Configuration Files
#
sysname PE1
#
mpls lsr-id 1.1.1.1
#
mpls
mpls te
#
segment-routing
#
isis 1
is-level level-2
network-entity 10.0000.0000.0001.00
cost-style wide
traffic-eng level-2
#
interface loopback 1
ip address 1.1.1.1 255.255.255.255
isis enable 1
#
undo shutdown
ip address 10.0.1.1 255.255.255.0

(2020-04-09)
isis enable 1
mpls
mpls te
#
explicit-path path2asbr1
#
next sid label 1000 type binding-sid
#
interface tunnel1
ip address unnumbered interface loopback 1
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
network-entity 10.0000.0000.0002.00
cost-style wide
traffic-eng level-2
#
ip address 2.2.2.2 255.255.255.255
isis enable 1
#
undo shutdown
ip address 10.1.1.1 255.255.255.0
mpls
mpls te
#
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

(2020-04-09)
isis enable 1
mpls
mpls te
#
ip route-static 3.3.3.3 32 gigabitethernet1/0/0 10.1.1.2 description asbr1toasbr2
#
bgp 100
peer 3.3.3.3 connect-interface loopback 1
peer 3.3.3.3 ebgp-max-hop 2
peer 3.3.3.3 egress-engineering
ipv4-family unicast
network 2.2.2.2 32
network 10.1.1.0 24
network 10.2.1.0 24
import-route isis 1
#
#
interface tunnel1
destination 1.1.1.1
mpls te tunnel-id 1
#
return
#
#
sysname ASBR2
#
mpls lsr-id 3.3.3.3
#
mpls
mpls te
#
segment-routing
#
isis 1
is-level level-2
network-entity 10.0000.0000.0003.00
cost-style wide
traffic-eng level-2
#
ip address 3.3.3.3 255.255.255.255
isis enable 1
#
undo shutdown
ip address 10.1.1.2 255.255.255.0
mpls
mpls te
#
undo shutdown
ip address 10.2.1.2 255.255.255.0
mpls
mpls te
#

(2020-04-09)
undo shutdown
ip address 10.9.1.1 255.255.255.0
isis enable 1
mpls
mpls te
#
#
bgp 200
peer 2.2.2.2 connect-interface loopback 1
ipv4-family unicast
network 3.3.3.3 32
network 10.1.1.0 24
network 10.2.1.0 24
import-route isis 1
#
#
interface tunnel2
destination 4.4.4.4
mpls te tunnel-id 1
#
return
#
#
sysname PE2
#
mpls lsr-id 4.4.4.4
#
mpls
mpls te
#
segment-routing
#
isis 1
is-level level-2
network-entity 10.0000.0000.0004.00
cost-style wide
traffic-eng level-2
#
ip address 4.4.4.4 255.255.255.255
isis enable 1
#
undo shutdown
ip address 10.9.1.2 255.255.255.0
isis enable 1
mpls
mpls te
#
explicit-path path2asbr2
#

(2020-04-09)

#
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-131, 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, tunnel 1 and tunnel 2 on PE1 transmit important services, and
tunnel 3 transmits other services.
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-131 CBTS networking in an L3VPN over SR-MPLS TE scenario

(2020-04-09)
Precautions
None
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
● 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

(2020-04-09)

[*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.

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

(2020-04-09)
[~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] 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. The following example uses the command output on PE1.
Route Flags: R - relay, D - download to fib
------------------------------------------------------------------------------

2.2.2.9/32 ISIS 15 10 D 10.1.1.2 GigabitEthernet1/0/0

(2020-04-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
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.
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.
[*PE1] mpls
[*PE1-mpls] mpls te
[*PE1-mpls] quit
# Configure P1.
[*P1] mpls
[*P1-mpls] mpls te

(2020-04-09)
[*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
interface of each tunnel.
# Configure PE1.
[~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 2/0/0
[~P1-GigabitEthernet2/0/0] mpls te bandwidth max-reservable-bandwidth 100000
[*P1-GigabitEthernet2/0/0] mpls te bandwidth bc0 100000
# Configure P2.
Step 6 Configure QoS on each PE.

(2020-04-09)
# 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-behavior-behavior2] quit
[~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.
# 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

(2020-04-09)
# 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
# Display the node SID of each node. The following example uses the command
output on PE1.
[~PE1] display segment-routing prefix mpls forwarding

--------------------------------------------------------------

-----------------------------------------------------------------------------------------------------------------
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
# 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] next sid label 16030 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] next sid label 16030 type prefix
[*PE2-explicit-path-pe2_pe1] commit
[~PE2-explicit-path-pe2_pe1] quit
Step 8 Configure MPLS TE tunnel interfaces.

(2020-04-09)
# 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.
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
[*PE1-Tunnel2] mpls te service-class af2
[~PE1-Tunnel2] quit
[*PE1-Tunnel3] mpls te service-class default
[~PE1-Tunnel3] commit
[~PE1-Tunnel3] quit
[*PE1] tunnel-policy policy1
[*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.

(2020-04-09)

[*PE1-vpn-instance-vpn1-af-ipv4] tnl-policy policy1
[*PE1-vpn-instance-vpn1-af-ipv4] vpn-target 111:1 both
[*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
[*PE1-GigabitEthernet2/0/0] ip-address 10.10.1.1 24
[~PE1-GigabitEthernet2/0/0] commit
# Configure PE2.
[*PE2-vpn-instance-vpn2-af-ipv4] vpn-target 111:1 both
[*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
Step 10 Establish an EBGP peer relationship between each PE and its connected CE.
# Configure CE1.
[*CE1] bgp 65410
[*CE1-bgp] import-route direct
[*CE1-bgp] quit
[*CE1] commit
The configuration of CE2 is similar to the configuration of CE1. For configuration details,
# Configure PE1.
[~PE1] bgp 100
[*PE1-bgp-vpn1] peer 10.10.1.2 as-number 65410
[*PE1-bgp-vpn1] commit
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

(2020-04-09)

CTRL_C to break
0.00% packet loss
CTRL_C to break
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

(2020-04-09)
rule 10 permit source 10.40.0.0 0.0.255.255

#
acl number 2002
#
traffic classifier service1
if-match acl 2001
#
if-match acl 2002
#
traffic behavior behavior1
service-class af1 color green
#
#
traffic policy policy1
classifier service1 behavior behavior1
#
segment-routing
#
isis 1
is-level level-2
cost-style wide
traffic-eng level-2
network-entity 00.0005.0000.0000.0001.00
#
undo shutdown
ip address 10.1.1.1 255.255.255.0
mpls
mpls te
mpls te bandwidth max-reservable-bandwidth 100000
mpls te bandwidth bc0 100000
isis enable 1
#
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

(2020-04-09)
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
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
traffic-eng level-2
network-entity 00.0005.0000.0000.0002.00
#
undo shutdown
ip address 10.1.1.2 255.255.255.0
mpls
mpls te
isis enable 1
#
undo shutdown
ip address 10.2.1.1 255.255.255.0
mpls
mpls te
isis enable 1
#
interface LoopBack1

(2020-04-09)
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
traffic-eng level-2
network-entity 00.0005.0000.0000.0003.00
#
undo shutdown
ip address 10.3.1.1 255.255.255.0
mpls
mpls te
isis enable 1
#
undo shutdown
ip address 10.2.1.2 255.255.255.0
mpls
mpls te
isis enable 1
#
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

(2020-04-09)
#
segment-routing
#
isis 1
is-level level-2
cost-style wide
traffic-eng level-2
network-entity 00.0005.0000.0000.0004.00
#
undo shutdown
ip address 10.3.1.2 255.255.255.0
mpls
mpls te
isis enable 1
#
undo shutdown
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
#

(2020-04-09)
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.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-132, 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 tunnel 1 to transmit important services and tunnel 2 to
transmit other services.
Figure 1-132 CBTS networking in an L3VPN over LDP over SR-MPLS TE scenario

(2020-04-09)
Precautions
The destination IP address of a tunnel must be equal to the LSR ID of the egress
of the tunnel.
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

(2020-04-09)
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 P3.
[*HUAWEI] commit
[*P3] commit
# Configure PE2.

(2020-04-09)
[*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
# Configure P2.
[~P2] isis 1
[*P2-isis-1] quit
# Configure P3.
[~P3] isis 1
[*P3-isis-1] quit

(2020-04-09)

# 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
[~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

(2020-04-09)
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
# 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

(2020-04-09)
# 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)
A '*' 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
--------------------------------------------------------------------------
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
A '*' 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
----------------------------------------------------------------------
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

(2020-04-09)
# 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: P2
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 : ----
Hello Packet sent/received : 425/382
------------------------------------------------------------------------------
TOTAL: 1 Remote-Peer(s) Found.
Step 6 Configure bandwidth attributes for the outbound interface of each TE tunnel.
# Configure P1.
# Configure P3.
[*P3-GigabitEthernet2/0/0] mpls te bandwidth max-reservable-bandwidth 20000
# 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

(2020-04-09)

[*PE1-GigabitEthernet2/0/0] ip binding vpn-instance VPNA
[*PE1] acl 2001
[*PE1] acl 2002
[~PE1] traffic classifier service2
[~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-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.
# Configure P1.

(2020-04-09)
[*P1] isis 1
[*P1-isis-1] commit
[~P1-isis-1] quit
# Configure P2.
[*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 GE2/0/0 10.1.1.1 ISIS-V4 --- 1500
48092 GE1/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] next sid label 48091 type adjacency

(2020-04-09)
[*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] next sid label 48091 type adjacency
[*P2-explicit-path-p2_p1] next sid label 48090 type adjacency
[*P2-explicit-path-p2_p1] commit
[~P2-explicit-path-p2_p1] quit
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.
Run the mpls te service-class { service-class & <1-8> | default } command to set a service
class for packets carried by each tunnel.
# 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 tunnel12
[*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

(2020-04-09)
[*P2-Tunnel1] quit
[*P2] commit
# Configure CE1.
[*CE1] bgp 65410
[*CE1-bgp] quit
[*CE1] commit
# 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
# 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

(2020-04-09)
0.00% packet loss
# Check information about LDP LSP establishment on each PE. 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
-------------------------------------------------------------------------------
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
#

(2020-04-09)
if-match acl 2001

#
if-match acl 2002
#
#
#
traffic policy test
share-mode
#
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.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

(2020-04-09)
#
explicit-path p1_p2
#
mpls ldp
#
ipv4-family
#
mpls ldp remote-peer lsrd
remote-ip 4.4.4.4
#
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
mpls te igp shortcut
mpls te igp metric absolute 1
isis enable 1
destination 4.4.4.4
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

(2020-04-09)
#
return
#
sysname P3
#
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.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

(2020-04-09)
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
#
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
traffic-eng level-2
#

(2020-04-09)
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
#
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

(2020-04-09)
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
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 tunnel 1 to transmit services with DSCP values ranging from
0 to 10 and tunnel 2 to transmit other services by default.
Figure 1-133 Networking for DSCP-based IP service recursion to SR-MPLS TE

tunnels

(2020-04-09)
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.
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 policy on each PE.
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

(2020-04-09)
[*P1] commit
# Configure PE2.
[*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
[*PE1] commit
# Configure P1.
[~P1] isis 1
[*P1-isis-1] quit
[*P1] commit

(2020-04-09)

[*P1] commit
# Configure PE2.
[~PE2] isis 1
[*PE2-isis-1] quit
[*PE2] commit
[*PE2] commit
# Configure P2.
[~P2] isis 1
[*P2-isis-1] quit
[*P2] commit
[*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

(2020-04-09)
[*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
[*PE1] commit
[~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] commit
[~P1] isis 1
[*P1-isis-1] quit
[*P1] commit
# Configure PE2.
[*PE2] commit
[~PE2] isis 1
[*PE2-isis-1] quit
[*PE2] commit
# Configure P2.
[*P2] commit
[~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

(2020-04-09)

[*PE1-explicit-path-path1] quit
[*PE1] interface Tunnel1
[*PE1-Tunnel1] mpls te path explicit-path path1
[*PE1-Tunnel1] quit
[*PE1-Tunnel2] quit
[*PE1] commit
# Configure PE2.
[*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

(2020-04-09)

[~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
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
# Assign an IP address to each interface on CEs, as shown in Figure 1-133. 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.

(2020-04-09)
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 1 unmix
[*PE1] commit
[*PE1] commit
# Configure PE2.
[*PE2-tunnel-policy-p1] tunnel select-seq sr-te load-balance-number 1 unmix
[*PE2] commit
[*PE2] commit
# Configure CE1.
[*CE1] bgp 65410
[*CE1-bgp] network 10.11.1.1 32
[*CE1-bgp] quit
[*CE1] commit
Repeat this step on CE2. For configuration details, see Configuration Files in this section.
# Configure PE1.
[~PE1] bgp 100
Repeat this step on PE2. For configuration details, see Configuration Files in this section.
command on the PEs and check whether BGP peer relationships have been

(2020-04-09)
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.
------------------------------------------------------------------------------
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

(2020-04-09)

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 default
[*PE1-Tunnel2] quit
[*PE1] commit
# Configure PE2.
[*PE2-Tunnel1] match dscp ipv4 0 to 10
[*PE2-Tunnel1] quit
[*PE2-Tunnel2] match dscp 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, tunnel 1 transmits services with DSCP values ranging
from 0 to 10, and tunnel 2 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

(2020-04-09)

#
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
#
#
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
#
tunnel-policy p1
tunnel select-seq sr-te load-balance-number 1 unmix
#
return
#
sysname P1
#
mpls lsr-id 2.2.2.9

(2020-04-09)
#
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
#
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

(2020-04-09)

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
#
#
interface Tunnel1
destination 1.1.1.9
mpls te tunnel-id 1
match dscp ipv4 0 to 10
#
interface Tunnel2
destination 1.1.1.9
mpls te tunnel-id 2
match dscp ipv4 default
#
tunnel-policy p1
tunnel select-seq sr-te load-balance-number 1 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

(2020-04-09)
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
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
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.

(2020-04-09)
● 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-134 L3VPN route recursion to manually configured SR-MPLS TE Policies
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.

(2020-04-09)
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. Establish an MP-IBGP peer relationship between PEs for them to exchange
6. 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.
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.
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.

(2020-04-09)

[*HUAWEI] commit
[*PE2] commit
# Configure P2.
[*HUAWEI] commit
[*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
[*PE1] commit
# Configure P1.
[~P1] isis 1
[*P1-isis-1] quit
[*P1] commit
[*P1] commit
# Configure PE2.

(2020-04-09)
[~PE2] isis 1
[*PE2-isis-1] quit
[*PE2] commit
[*PE2] commit
# Configure P2.
[~P2] isis 1
[*P2-isis-1] quit
[*P2] commit
[*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.

(2020-04-09)

[*PE1] commit
[~PE1] isis 1
[*PE1-isis-1] quit
[*PE1] commit
# Configure P1.
[*P1] commit
[~P1] isis 1
[*P1-isis-1] quit
[*P1] commit
# Configure PE2.
[*PE2] commit
[~PE2] isis 1
[*PE2-isis-1] quit
[*PE2] commit
# Configure P2.
[*P2] commit
[~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] index 10 sid label 330000
[*PE1-segment-routing-segment-list] quit
[*PE1-segment-routing] segment-list pe1backup
[*PE1-segment-routing] sr-te policy policy100 endpoint 3.3.3.9 color 100
[*PE1-segment-routing-te-policy] binding-sid 115
[*PE1-segment-routing-te-policy] mtu 1000
[*PE1-segment-routing-te-policy] candidate-path preference 100
[*PE1-segment-routing-te-policy-path] segment-list pe1backup
[*PE1-segment-routing-te-policy-path] quit
[*PE1-segment-routing-te-policy-path] segment-list pe1

(2020-04-09)
[*PE1-segment-routing-te-policy] quit
[*PE1] commit
# Configure PE2.
[*PE2] commit
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 BFD : Disable
Admin State : UP DiffServ-Mode :-
Traffic Statistics : Disable Backup Hot-Standby : Disable
Candidate-path Count : 2
Candidate-path Preference: 200

Path State : Valid Path Type : Primary
Protocol-Origin : Configuration(30) Originator : 0, 0.0.0.0
Discriminator : 200 Binding SID :-
GroupId :2 Policy Name : policy100
Segment-List Count : 1
Segment-List : pe1
Segment-List ID : 129 XcIndex : 68
List State : UP BFD State :-
EXP :0 TTL : 255
DeleteTimerRemain : -
Label : 330000, 330002

Path State : Invalid Path Type :-
Segment-List : pe1backup
Segment-List ID : 194 XcIndex :-
List State : DOWN BFD State :-
EXP :0 TTL : 255
Label : 330001, 330003
Step 6 Configure SBFD and HSB on each PE.

(2020-04-09)
# 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
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

(2020-04-09)
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.
[*PE1] commit
# Configure PE2.
[*PE2] commit
# Configure interface IP addresses on each CE according to Figure 1-134. For

configuration details, see "Configuration Files" in this section.
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.
IP address 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 operation fails.
Step 10 Configure a tunnel selection policy on each PE for the specified SR-MPLS TE Policy
to be preferentially selected.

(2020-04-09)
# Configure PE1.
[*PE1-tunnel-policy-p1] tunnel select-seq sr-te-policy load-balance-number 1 unmix
[*PE1] commit
[*PE1] commit
# Configure PE2.
[*PE2] commit
[*PE2] commit
Step 11 Establish an EBGP peer relationship between each CE-PE pair.

# Configure CE1.
[*CE1] bgp 65410
[*CE1-bgp] network 10.11.1.1 32
[*CE1-bgp] quit
[*CE1] commit
# Configure PE1.
[~PE1] bgp 100
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.

(2020-04-09)


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.

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

(2020-04-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
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 100
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

(2020-04-09)
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
#
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

(2020-04-09)

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

(2020-04-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
#
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
network 10.11.1.1 255.255.255.255
#
ipv4-family unicast
#
return
#
sysname CE2
#
undo shutdown

(2020-04-09)
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.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.
Figure 1-135 L3VPN route recursion to manually configured SR-MPLS TE Policies

(2020-04-09)
Precautions
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.

(2020-04-09)
Data Preparation
Procedure
# Configure PE1.
[*HUAWEI] commit
[*PE1] commit
# Configure P1.
[*HUAWEI] commit
[*P1] commit
# Configure PE2.
[*HUAWEI] commit
[*PE2] commit
# Configure P2.
[*HUAWEI] commit

(2020-04-09)

[*P2] commit
# Configure PE1.
[~PE1] isis 1
[*PE1-isis-1] quit
[*PE1] commit
[*PE1] commit
# Configure P1.
[~P1] isis 1
[*P1-isis-1] quit
[*P1] commit
[*P1] commit
# Configure PE2.
[~PE2] isis 1
[*PE2-isis-1] quit
[*PE2] commit
[*PE2] commit
# Configure P2.
[~P2] isis 1

(2020-04-09)
[*P2-isis-1] quit
[*P2] commit
[*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] commit
[~PE1] isis 1
[*PE1-isis-1] quit
[*PE1] commit
# Configure P1.
[*P1] commit
[~P1] isis 1
[*P1-isis-1] quit
[*P1] commit

(2020-04-09)
# Configure PE2.
[*PE2] commit
[~PE2] isis 1
[*PE2-isis-1] quit
[*PE2] commit
# Configure P2.
[*P2] commit
[~P2] isis 1
[*P2-isis-1] quit
[*P2] commit

# Configure PE1.
[*PE1-segment-routing-te-policy] diffserv-mode pipe af1 green
[*PE1] commit
# Configure PE2.
[*PE2-segment-routing-te-policy] diffserv-mode pipe af1 green

(2020-04-09)
[*PE2] commit
output on PE1.
Admin State : UP DiffServ-Mode : Pipe, AF1, Green

Segment-List : pe1
EXP :0 TTL : 255
Label : 330000, 330002

EXP :0 TTL : 255
Label : 330001, 330003

# Configure PE1.
[~PE1] bfd
[*PE1-bfd] quit
[*PE1] sbfd
[*PE1-sbfd] quit
# Configure PE2.
[~PE2] bfd
[*PE2-bfd] quit
[*PE2] sbfd

(2020-04-09)
[*PE2-sbfd] quit

# 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
# Configure PE1.
[*PE1] commit
# Configure PE2.

(2020-04-09)
[*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
[*PE1] ip vpn-instance vpna
[*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
[*PE2] commit
After completing the configuration, run the display sr-te policy group 1
command on each PE to check SR-MPLS TE Policy group status.

(2020-04-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.
[*CE1] bgp 65410
[*CE1-bgp] network 10.11.1.1 32
[*CE1-bgp] quit
[*CE1] commit
# Configure PE1.
[~PE1] bgp 100


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.

(2020-04-09)

------------------------------------------------------------------------------
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
0.00% packet loss
----End
Configuration Files
#
sysname PE1
#
ipv4-family

(2020-04-09)
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
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

(2020-04-09)
#
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
#
sysname PE2
#
ipv4-family
tnl-policy p1
#
bfd
#
sbfd
#
mpls lsr-id 3.3.3.9
#
mpls
#
segment-routing

(2020-04-09)

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
#
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

(2020-04-09)
#
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
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-04-09)
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-136 L3VPN route recursion to dynamically delivered SR-MPLS TE Policies
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-04-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-04-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-04-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
[*PE1] commit
# Configure P1.
[~P1] isis 1
[*P1-isis-1] quit
[*P1] commit

(2020-04-09)

[*P1] commit
# Configure PE2.
[~PE2] isis 1
[*PE2-isis-1] quit
[*PE2] commit
[*PE2] commit
# Configure P2.
[~P2] isis 1
[*P2-isis-1] quit
[*P2] commit
[*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.

(2020-04-09)
[*P2] mpls
[*P2-mpls] commit
[~P2-mpls] quit

# Configure PE1.
[*PE1] commit
[~PE1] isis 1
The SRGB range in this example is for reference only. It varies according to the device and
needs to be set as needed.
[*PE1-isis-1] quit
[*PE1] commit
# Configure P1.
[*P1] commit
[~P1] isis 1
[*P1-isis-1] quit
[*P1] commit
# Configure PE2.
[*PE2] commit
[~PE2] isis 1
[PE2-isis-1] traffic-eng level-1
[*PE2-isis-1] quit
[*PE2] commit

(2020-04-09)
# Configure P2.
[*P2] commit
[~P2] isis 1
[*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] quit
# Enable IS-IS SR-MPLS TE on PE2.

[~PE2] isis 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-srpolicy] peer 10.3.1.2 enable
[*PE1-bgp-af-srpolicy] commit
[~PE1-bgp-af-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-srpolicy] peer 10.4.1.2 enable

(2020-04-09)
[*PE2-bgp-af-srpolicy] commit
[~PE2-bgp-af-srpolicy] quit
[~PE2-bgp] quit

address family-specific peer relationships on the controller.
[~Controller] bgp 100
[*Controller-bgp] link-state-family unicast
[*Controller-bgp-af-ls] quit
[*Controller-bgp] ipv4-family sr-policy
[*Controller-bgp-af-srpolicy] peer 10.3.1.1 enable
[*Controller-bgp-af-srpolicy] peer 10.4.1.1 enable
[*Controller-bgp-af-srpolicy] commit
[~Controller-bgp-af-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. Run the
display sr-te policy command to check SR-MPLS TE Policy information. The

Protocol-Origin : BGP(20) Originator : 0, 0.0.0.0
Segment-List : pe1
EXP :0 TTL : 255
Label : 330000, 330002

Protocol-Origin : BGP(20) Originator : 0, 0.0.0.0
EXP :0 TTL : 255
Label : 330001, 330003

# Configure PE1.
[~PE1] bfd
[*PE1-bfd] quit
[*PE1] sbfd

(2020-04-09)

[*PE1-sbfd] quit
# 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-04-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

(2020-04-09)

[*PE1] commit
# Configure PE2.
[*PE2] commit
[*PE2] commit

# Configure CE1.
[*CE1] bgp 65410
[*CE1-bgp] network 10.11.1.1 32
[*CE1-bgp] quit
[*CE1] commit
# Configure PE1.
[~PE1] bgp 100


10.1.1.1 4 65410 91 90 0 01:15:39 Established 1

(2020-04-09)

route toward a CE.

------------------------------------------------------------------------------
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-04-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
#
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 sr-policy

(2020-04-09)
#
ipv4-family vpnv4
policy vpn-target
peer 3.3.3.9 enable
#
#
#
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
#
sbfd
#
mpls lsr-id 3.3.3.9
#

(2020-04-09)
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
#
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
#

(2020-04-09)
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
#
#
#
return
#
sysname CE1
#
undo shutdown

(2020-04-09)
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
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-MPLS TE Policies to ensure secure communication
between users of the same VPN.
Configure L3VPNv6 routes to be recursed to SR-MPLS TE Policies to ensure secure

Figure 1-137 L3VPNv6 route recursion to manually configured SR-MPLS TE

Policies

(2020-04-09)
Precautions
configurations, such as the IPv6 address and routing protocol configuration, on the

instance.

(2020-04-09)
Data Preparation
Procedure
# Configure PE1.
[*HUAWEI] commit
[*PE1] commit
# Configure P1.
[*HUAWEI] commit
[*P1] commit
# Configure PE2.
[*HUAWEI] commit
[*PE2] commit
# Configure P2.
[*HUAWEI] commit

(2020-04-09)

[*P2] commit
# Configure PE1.
[~PE1] isis 1
[*PE1-isis-1] quit
[*PE1] commit
[*PE1] commit
# Configure P1.
[~P1] isis 1
[*P1-isis-1] quit
[*P1] commit
[*P1] commit
# Configure PE2.
[~PE2] isis 1
[*PE2-isis-1] quit
[*PE2] commit
[*PE2] commit
# Configure P2.
[~P2] isis 1

(2020-04-09)
[*P2-isis-1] quit
[*P2] commit
[*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] commit
[~PE1] isis 1
[*PE1-isis-1] quit
[*PE1] commit
# Configure P1.
[*P1] commit
[~P1] isis 1
[*P1-isis-1] quit
[*P1] commit

(2020-04-09)
# Configure PE2.
[*PE2] commit
[~PE2] isis 1
[*PE2-isis-1] quit
[*PE2] commit
# Configure P2.
[*P2] commit
[~P2] isis 1
[*P2-isis-1] quit
[*P2] commit

# Configure PE1.
[*PE1] commit
# Configure PE2.

(2020-04-09)

[*PE2] commit
output on PE1.

Segment-List : pe1
EXP :0 TTL : 255
Label : 330000, 330002

EXP :0 TTL : 255
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-04-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-04-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

IPv6 address by specifying -a source-ipv6-address in the ping ipv6 -vpn-instance vpn-
instance-name -a source-ipv6-address dest-ipv6-address command to ping the CE
connected to the remote PE. Otherwise, the ping operation fails.
# Configure PE1.
[*PE1] commit
[*PE1] commit
# Configure PE2.
[*PE2] commit

(2020-04-09)
[*PE2] commit

# Configure CE1.
[*CE1-LoopBack1] ipv6 enable
[*CE1-LoopBack1] ipv6 address 2001:db8::11:1 128
[*CE1-GigabitEthernet1/0/0] ipv6 enable
[*CE1-GigabitEthernet1/0/0] ip 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] quit
[*CE1] commit
# 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

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-04-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 :
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:db8::22:2
bytes=56 Sequence=1 hop limit=62 time = 170 ms

(2020-04-09)

--- 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
ip address 10.13.1.1 255.255.255.0
isis enable 1

(2020-04-09)
#
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
#
interface LoopBack1
ip address 2.2.2.9 255.255.255.255

(2020-04-09)
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
#
bgp 100

(2020-04-09)

#
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
ipv6 address 2001:db8::11:1 128
#

(2020-04-09)
bgp 65410
router-id 10.10.10.10
#
ipv6-family unicast
peer 2001:db8::1:2 enable
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
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-138 shows an example for configuring non-labeled public BGP routes to
be recursed to manually configured SR-MPLS TE Policies.
Figure 1-138 Recursion of non-labeled public BGP routes to manually configured

SR-MPLS TE Policies

(2020-04-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-04-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-04-09)
# Configure PE1.
[~PE1] isis 1
[*PE1-isis-1] quit
[*PE1] commit
[*PE1] commit
# Configure P1.
[~P1] isis 1
[*P1-isis-1] quit
[*P1] commit
[*P1] commit
# Configure PE2.
[~PE2] isis 1
[*PE2-isis-1] quit
[*PE2] commit
[*PE2] commit
# Configure P2.
[~P2] isis 1
[*P2-isis-1] quit
[*P2] commit

(2020-04-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

# Configure PE1.
[*PE1] commit
[~PE1] isis 1
[*PE1-isis-1] quit
[*PE1] commit
# Configure P1.
[*P1] commit
[~P1] isis 1
[*P1-isis-1] quit
[*P1] commit
# Configure PE2.
[*PE2] commit
[~PE2] isis 1

(2020-04-09)
[*PE2-isis-1] quit
[*PE2] commit
# Configure P2.
[*P2] commit
[~P2] isis 1
[*P2-isis-1] quit
[*P2] commit

# Configure PE1.
[*PE1] commit
# Configure PE2.
[*PE2] commit
output on PE1.

(2020-04-09)


Segment-List : pe1
EXP :0 TTL : 255
Label : 330000, 330002

EXP :0 TTL : 255
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.

(2020-04-09)
[*PE1] commit
# Configure PE2.
[*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
After completing the configuration, run the display bgp 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
# Configure PE1.
[*PE1] commit
[~PE1] route recursive-lookup tunnel tunnel-policy p1
[*PE1] commit
# Configure PE2.
[*PE2] commit
[~PE2] route recursive-lookup tunnel tunnel-policy p1
[*PE2] commit
Step 10 Configure each PE to import a local route.

# Configure PE1.

(2020-04-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-04-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
network-entity 10.0000.0000.0002.00

(2020-04-09)
#
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-04-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-04-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.
As shown in Figure 1-139, there is no direct link between the IPv6 network where
CE1 resides and the IPv6 network where CE2 resides. To allow CE1 and CE2 to
communicate with each other through the SR network, establish a 6PE peer
relationship between PE1 and PE2. 6PE peers use MP-BGP to send IPv6 routes
learned from their respective CEs and use SR-MPLS TE Policies to forward IPv6
traffic.
Figure 1-139 BGP4+ 6PE route recursion to manually configured SR-MPLS TE

Policies
Precautions
In the BGP4+ 6PE scenario, no VPN instance needs to be configured.


(2020-04-09)
5. 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-04-09)

[*PE2] commit
# Configure P2.
[*HUAWEI] commit
[*P2] commit
# Configure PE1.
[~PE1] isis 1
[*PE1-isis-1] quit
[*PE1] commit
[*PE1] commit
# Configure P1.
[~P1] isis 1
[*P1-isis-1] quit
[*P1] commit
[*P1] commit
# Configure PE2.
[~PE2] isis 1
[*PE2-isis-1] quit
[*PE2] commit

(2020-04-09)

[*PE2] commit
# Configure P2.
[~P2] isis 1
[*P2-isis-1] quit
[*P2] commit
[*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] commit
[~PE1] isis 1

(2020-04-09)
[*PE1-isis-1] quit
[*PE1] commit
# Configure P1.
[*P1] commit
[~P1] isis 1
[*P1-isis-1] quit
[*P1] commit
# Configure PE2.
[*PE2] commit
[~PE2] isis 1
[*PE2-isis-1] quit
[*PE2] commit
# Configure P2.
[*P2] commit
[~P2] isis 1
[*P2-isis-1] quit
[*P2] commit
# Configure PE1.
[*PE1] commit
# Configure PE2.

(2020-04-09)
[*PE2] commit
output on PE1.

Segment-List : pe1
EXP :0 TTL : 255
Label : 330000, 330002

EXP :0 TTL : 255
Label : 330001, 330003
# Configure PE1.
[~PE1] bfd
[*PE1-bfd] quit
[*PE1] sbfd

(2020-04-09)

[*PE1-sbfd] quit
# 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 enable
[*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-af-ipv6] quit
[~PE2-bgp] quit
After completing the configuration, run the display bgp ipv6 peer command on
each PE. The following example uses the command output on PE1. The command

(2020-04-09)
output shows that a BGP peer relationship has been established between the PEs
and is in the Established state.
[~PE1] display bgp ipv6 peer

3.3.3.9 4 100 6 7 0 00:01:16 Established 0
# Configure PE1.
[*PE1] commit
[~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] commit
[~PE2] bgp 100
[*PE2-bgp-af-ipv6] peer 1.1.1.9 tnl-policy p1
[*PE2-bgp] quit
[*PE2] commit
# Configure CE1.
[*CE1-LoopBack1] ipv6 address 2001:db8::11:1 128
[*CE1-GigabitEthernet1/0/0] ipv6 enable
[*CE1-GigabitEthernet1/0/0] ip 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
# Configure PE1.

(2020-04-09)
[~PE1] bgp 100

[*PE1-bgp] peer 2001:db8::1:1 as-number 65410
[*PE1-bgp-af-ipv6] peer 2001:db8::1:1 enable
[*PE1-bgp] quit
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.
[~PE1] display bgp ipv6 peer

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



(2020-04-09)
Destination : 2001:2001::1 PrefixLength : 128

RelayNextHop : 2001:DB8::1:1 TunnelID : 0x0

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 2002:2002::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
--- 2001:db8::22:2 ping statistics ---

0.00% packet loss
----End

(2020-04-09)
Configuration Files
#
sysname PE1
#
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

(2020-04-09)
peer 3.3.3.9 label-route-capability
peer 3.3.3.9 tnl-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
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

(2020-04-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
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

(2020-04-09)
#
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
ipv6 address 2001:2001::1 128
#
bgp 65410
router-id 10.10.10.10
#
ipv6-family unicast
network 2001:2001::1 128
#
return
#
sysname CE2
#
undo shutdown
ipv6 enable
#
interface LoopBack1
ipv6 enable
ipv6 address 2002:2002::2 128
#
bgp 65420
router-id 10.20.20.20
#
ipv6-family unicast
network 2002:2002::2 128
#
return

(2020-04-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-140, PE1, P1, P2, and PE2 are in the same AS
and run IS-IS to implement networking. An SR-MPLS TE Policy is configured on
PE1 and PE2 to carry EVPN services over an SR path.
Figure 1-140 Networking of EVPN route recursion based on an SR-MPLS TE Policy
Configuration Notes
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-04-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 Assign IP addresses to each device interface.
# Configure PE1.
[*HUAWEI] commit
[*PE1] commit
# Configure P1.
[*HUAWEI] commit
[*P1] commit
# Configure PE2.

(2020-04-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-04-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] commit

(2020-04-09)
[~PE1] isis 1
[*PE1-isis-1] quit
[*PE1] commit
# Configure P1.
[*P1] commit
[~P1] isis 1
[*P1-isis-1] quit
[*P1] commit
# Configure PE2.
[*PE2] commit
[~PE2] isis 1
[*PE2-isis-1] quit
[*PE2] commit
# Configure P2.
[*P2] commit
[~P2] isis 1
[*P2-isis-1] quit
[*P2] commit

# Configure PE1.
[~PE1-segment-routing] segment-list path1
[*PE1-segment-routing] segment-list path2
[*PE1-segment-routing-te-policy-path] segment-list path1

(2020-04-09)
[*PE1] commit
# 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-04-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 completing the configurations, run the display bgp evpn peer command on
PEs to check that the BGP EVPN peer relationship has been established between
the PEs and is in the Established state. The following example uses the command
output on PE1.

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-04-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-bd10] quit
[*PE2-Vbdif10] quit
[*PE2] bgp 100

(2020-04-09)
[*PE2-bgp] quit
[*PE2] commit
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.
From: 3.3.3.9 (10.12.1.2)

(2020-04-09)
Relay IP Out-Interface:GigabitEthernet1/0/0
Ext-Community: RT <1 : 1>, Color <0 : 200>
cost 20
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
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:

(2020-04-09)
From: 3.3.3.9 (10.12.1.2)

Ext-Community: 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 (10.12.1.2)
Relay Tunnel Out-Interface: policy100(srtepolicy)
Ext-Community: 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
----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
#

(2020-04-09)
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
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

(2020-04-09)

peer 3.3.3.9 enable
#
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

(2020-04-09)
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 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

(2020-04-09)
segment-list path2
#
isis 1
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
#

(2020-04-09)
#
return
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-141, 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-141 Networking for redirecting public IPv4 BGP FlowSpec routes to SR-
MPLS TE Policies
Precautions
None
1. Configure IS-IS on the backbone network for the PEs to communicate.

(2020-04-09)
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.
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

(2020-04-09)
[*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
[*PE1] commit
# Configure P1.
[~P1] isis 1
[*P1-isis-1] quit
[*P1] commit
[*P1] commit
# Configure PE2.
[~PE2] isis 1
[*PE2-isis-1] quit
[*PE2] commit

(2020-04-09)
[*PE2] commit
# Configure P2.
[~P2] isis 1
[*P2-isis-1] quit
[*P2] commit
[*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] commit
[~PE1] isis 1
[*PE1-isis-1] quit
[*PE1] commit
# Configure P1.

(2020-04-09)
[*P1] commit
[~P1] isis 1
[*P1-isis-1] quit
[*P1] commit
# Configure PE2.
[*PE2] commit
[~PE2] isis 1
[*PE2-isis-1] quit
[*PE2] commit
# Configure P2.
[*P2] commit
[~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.

(2020-04-09)

TunnelId : 8193 TunnelType : SR-TE Policy

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

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.

(2020-04-09)
[~PE2] bgp 100

[*PE2-bgp] commit
[~PE2-bgp] quit
After the configuration is complete, run the display bgp peer command on the
PEs and check whether a BGP peer relationship 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


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.

(2020-04-09)
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
[*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

(2020-04-09)
Match action :
AS-path Nil, origin igp, MED 0, pref-val 0, valid, local, best, pre 255
3.3.3.9
----End
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

(2020-04-09)
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
#
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
#

(2020-04-09)
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
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-04-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) is a protocol designed to forward IPv6 data packets
on a network using the source routing model. IPv6 forwarding plane-based SRv6
enables the ingress to add a segment routing header (SRH) to an IPv6 packet and
push an explicit IPv6 address stack into the SRH. After receiving the packet, each
transit node updates the IPv6 destination IP address in the packet and offsets the
address stack to implement hop-by-hop forwarding.
Purpose
Future networks will be 5G oriented. Transport networks also need to be adapted
to this and face the trends in simplifying networks, providing low latency, and
implementing software-defined networking (SDN) and network functions
virtualization (NFV).
To develop 5G networks, customers hope to use IPv6 addresses to more easily
implement VPNs. The SRv6 technology uses existing IPv6 forwarding techniques
and extends the IPv6 header to implement label forwarding-like processing. Some
IPv6 addresses are defined as instantiated segment IDs (SIDs). Each SID has its
own explicit functions. SIDs are operated to implement simplified VPNs and
flexibly plan paths.
Benefits
SRv6 offers the following benefits to users:
● Streamlines network configurations to more easily implement VPNs.
SRv6 does not use MPLS techniques and is fully compatible with existing IPv6
networks. Nodes only need to support IPv6 forwarding instead of MPLS

(2020-04-09)
forwarding. Transit nodes can be incapable of SRv6 and forward IPv6 packets
carrying the SRH over routes.
● Provides topology independent-loop-free alternate (TI-LFA), which improves
FRR protection.
SRv6, in combination with the remote loop-free alternate (RLFA) FRR
algorithm, supports any topology in theory and overcomes drawbacks in
conventional tunnel protection.
● Facilitates traffic optimization on IPv6 forwarding paths.
SIDs with various service types are used to flexibly plan explicit paths on the
ingress to adjust service traffic.
2.1.2 Understanding Segment Routing IPv6
2.1.2.1 SRv6 Fundamentals
SRH
An IPv6 packet consists of a standard IPv6 header, extension header (0...n), and
payload. A segment routing header (SRH) is added as an extension header to
implement segment routing IPv6 (SRv6) based on the IPv6 forwarding plane. The
SRH 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, so that transit nodes can forward
the packets based on path information contained in the SRH. Figure 2-1 shows
the SRH format.

(2020-04-09)
Figure 2-1 SRH format
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: IPv6-Route
● 58: ICMPv6
● 59: No Next Header for IPv6
Hdr Ext Len 8 bits Length of the SRH spanning from Segment List [0] to
Segment List [n].
Routing 8 bits Route header type. SRHs have a routing type value of
Type 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.

(2020-04-09)
Tag 16 bits Tag indicating a packet as part of a class or group of

packets.
Segment 128 bits Segment list that is numbered from the last segment
List [n] ×n of a path. A segment list is in the format of an IPv6
where n address.
is an
integer
Figure 2-2 shows the abstract SRH format.
Figure 2-2 Abstract SRH format
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 [2], ..., Segment List [n]>:
segment list information in an SRv6 packet. Similar to an MPLS label stack in
SR MPLS, it is generated on the ingress. Segment List [0] is the first segment
list to be processed on an SRv6 path, followed by Segment List [1] and
Segment List [2]. Segment List [n] is the n+1 segment list to be processed.
According to SRv6 standards, segment list information can also be expressed in inverse
order, for example, (Segment List [2], Segment List [1], Segment List [0]). This format is
equivalent to <Segment List [0], Segment List [1], Segment List [2]>. Note the difference
between the <> and () symbols:
● <Segment List [0], Segment List [1], Segment List [2]> represents a SID list where
Segment List [0] is the first SID and Segment List [2] is the last SID to be processed.
● (Segment List [2], Segment List [1], Segment List [0]) represents the same SID list but
encoded in an inverse mode where the rightmost SID is the first SID and the leftmost
SID is the last SID to be processed.
For SRH expression of IPv6 packets, the (Segment List [2], Segment List [1], Segment List
[0]) format is more convenient.
In SRv6, every time a packet passes through an SRv6-capable node, the value of
the Segments Left (SL) field decreases by 1 and the IPv6 DA changes, as shown in
Figure 2-3. The SL and Segments List fields are both used to determine an IPv6
DA.
● If the value of the SL field is n (n – 0 = n), the IPv6 DA value is equal to the
Segments List [0] value.

(2020-04-09)
● If the value of the SL field is n minus 1, the IPv6 DA value is equal to the
● If the value of the SL field is n minus 2, the IPv6 DA value is equal to the
● ...
● If the Segments Left field value is 0 (n – n = 0), the IPv6 DA value is equal to
the Segments List [n] value.
Figure 2-3 IPv6 DA conversion
2.1.2.2 SRv6 Segments
An SRv6 segment ID (SID) is an IPv6 address. It 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. Therefore, in general, each locator
value must be unique in an SR domain. However, in special scenarios, such as
anycast protection, multiple devices can 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 segments 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. A function may require additional arguments that can be
placed after the Function part. In this 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 is used to define packet flow and service
information. The Function and Arguments parts can both be defined, resulting in
an SRv6 SID structure that improves network programmability.

(2020-04-09)
My Local SID Table

Each SRv6-capable node keeps a "My Local SID Table" containing all SRv6
segments generated on the node. An SRv6 forwarding information table (FIB) can
be generated based on this table. The "My Local SID Table" provides the following
functions:
● Defines locally generated SIDs, such as End.X SIDs.
● Specifies instructions bound to the SIDs.
● 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
Endpoint SID that identifies the prefix of a destination address. It is similar to a
prefix 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
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 SID can be
obtained by all nodes in the SRv6 domain, 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
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, which is similar to an IPv4 VPN label, is used in VPN scenarios.

(2020-04-09)
Figure 2-7 End.DT4 SID
End.DT6 SID
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,
which is similar to an IPv6 VPN label, is used in VPNv6 scenarios.
Figure 2-8 End.DT6 SID
End.DX4 SID
End.DX4 SID is a provider edge (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 packet to the Layer 3
interface bound to the SID. The End.DX4 SID, which is similar to an IPv4 CE label,
is used in VPN scenarios.
Figure 2-9 End.DX4 SID
End.DX6 SID
End.DX6 SID is a provider edge (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 packet to the Layer 3
interface bound to the SID. The End.DX6 SID, which is similar to an IPv6 CE label,
is used in VPNv6 scenarios.

(2020-04-09)
Figure 2-10 End.DX6 SID
End.DX2 SID and End.DX2L SID

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 its
extension headers and then forward the remaining packet content to the
outbound interface bound to the SID. The End.DX2 SID is used in L2VPN/EVPN
VPWS scenarios.
If a bypass tunnel exists on the network, an End.DX2L SID is generated
automatically.
Figure 2-11 End.DX2 SID and End.DX2L SID
End.DT2U SID
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 its extension headers, search the MAC
address table based on the exposed destination MAC address, and forward the
remaining packet content to the outbound interface bound to the SID. The
End.DT2U SID is used in EVPN VPLS unicast scenarios.
If a bypass tunnel exists on the network, an End.DT2UL SID is generated
automatically and used to send unicast traffic over the bypass tunnel when a CE is
dual-homed to two PEs.

(2020-04-09)
Figure 2-12 End.DT2U SID
End.DT2M SID
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 its extension headers and then
broadcast the remaining packet content in the bridge domain (BD). The End.DT2M
SID is used in EVPN VPLS broadcast, unknown-unicast, multicast (BUM) scenarios.
Figure 2-13 End.DT2M SID
End.OP SID
End.OP SID is an OAM SID that specifies the punt behavior to be implemented for
an OAM packet in ping and tracert scenarios. On the network shown in Figure
2-14, if ingress node A attempts to ping End.X SID A4:4::45 between nodes D and
E through End.X SID A2:2::1, 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 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

(2020-04-09)
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
2.1.2.3 SRv6 Nodes
SRv6 Nodes
SRv6 nodes perform multiple roles, which are described as follows:
● Source SRv6 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's role is determined by the task it performs in SRv6 packet forwarding. A
node can play different roles. For example, a node can be the source node on one
SRv6 path while also being 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.

(2020-04-09)
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.
Transit Node Behaviors

Transit nodes do not need to parse SRv6 SRHs. Table 2-2 lists the common
behaviors of transit nodes. T indicates transit.
Table 2-2 Transit node behaviors
Transit Node Function Description

Behavior
T Forwards a received packet based on the IPv6 routing table,

without inspecting the SRH.
T.Insert Inserts an SRv6 TE Policy to a received IP packet and forwards

the packet by searching the IPv6 routing table.
T.Encaps Encapsulates an outer IPv6 packet header and an SRv6 TE

Policy for a received IP packet and forwards the packet by
searching the IPv6 routing table.
T.Encaps.L2 Encapsulates an outer IPv6 packet header and an SRv6 TE

Policy for a received Layer 2 packet and forwards the packet by
searching the IPv6 routing table.
Transit series instructions are triggered by IPv6 addresses that are neither local
interface addresses nor local SRv6 SIDs advertised by nodes. For example, assume

(2020-04-09)
that a T.Encaps behavior policy is configured on a node, with the triggering

condition being IPv6 addresses in the network segment 2001:DB8:100::/64. When
the node receives the data packets carrying IPv6 addresses in that network
segment, the policy is triggered. The node then performs the T.Encaps behavior by
inserting the corresponding outer IPv6 packet header and SRv6 TE Policy and
searches the IPv6 routing table for a route matching the first SRv6 SID to forward
the packets.
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 richer service requirements.
Table 2-3 lists the common flavors and their functions.
Table 2-3 Flavors
Flavor Function Description
PSP Penultimate segment pop of the SRH (PSP). This function pops
the SRH from a packet on the penultimate endpoint node and
is similar to penultimate hop popping (PHP) in MPLS. Because
the SRH has lost its usage value on the last-hop endpoint
node, PSP can be performed to reduce the node's burden. If
PSP is disabled, the SRH is removed only on the egress.
USP Ultimate segment POP of the SRH (USP). This function pops
the SRH from a packet on the last endpoint node.
2.1.2.4 SRv6 BE
2.1.2.4.1 L3VPNv4 over SRv6 BE
L3VPNv4 over SRv6 BE Overview

L3VPNv4 over SRv6 BE transmits L3VPNv4 data over SRv6 BE paths. Table 2-4
describes the characteristics of L3VPNv4 over SRv6 BE.
Table 2-4 Characteristics of L3VPNv4 over SRv6 BE
Item L3VPNv4 over SRv6 BE
VPN service type IPv4 VPN over SRv6 BE.
VPNv4 route distinguisher and RD: distinguishes routes of different VPN

leaking instances.
RT: used for route leaking.
Route transfer IPv6 peering is enabled in the BGP VPNv4

address family to transfer IPv4 routes.

(2020-04-09)
Item L3VPNv4 over SRv6 BE
Public network routing BGP4+ and IS-ISv6.

protocols
VPN label Not involved. VPN labels are replaced with

SRv6 VPN SIDs.
MPLS label Not involved.
VPN routing table lookup An egress identifies a VPN instance based on

an SRv6 VPN SID and searches the IP routing
table of the VPN instance.
Figure 2-16 shows the typical L3VPNv4 over SRv6 BE networking.
Figure 2-16 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-17 shows how L3VPNv4 over SRv6 BE is implemented from CE1 to CE2.

(2020-04-09)
Figure 2-17 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 nodes.
2. PE2 advertises an SRv6 locator route to PE1.
3. Route advertisement from CE1 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. 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 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 installs the route, this route is then
associated with an SRv6 VPN SID.
7. PE1 advertises the route to CE1.
CE1 learns the route from PE1 using RIP, OSPF, IS-IS, or BGP. This process is
similar to that from CE2 to PE2.
Figure 2-18 describes route advertisement and data forwarding from CE2 to CE1
in an L3VPNv4 over SRv6 BE scenario.

(2020-04-09)
Figure 2-18 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 table, named My Local SID
Table.
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 against the
destination IPv4 address prefix of the packet and finds associated SRv6 VPN
SID and next hop information. PE1 then encapsulates the packet into an IPv6
packet using the SRv6 VPN SID A2:1::B100 as a destination address.
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-04-09)
5. PE2 searches My Local SID Table based on A2:1::B100 and finds an End.DT4
SID. 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.4.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-19 shows how EVPN L3VPNv4 over SRv6 BE is implemented.
Figure 2-19 EVPN L3VPNv4 over SRv6 BE implementation

1. SRv6 and SRv6 VPN are configured on each PE. Transit nodes support IPv6.
3. CE2 advertises its local IPv4 route to PE2.
CE2 can communicate with PE2 using a static route or using RIP, OSPF, IS-IS,
or BGP.
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. 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.
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

(2020-04-09)
preferential route selection. If PE1 determines to install the route, this route is
CE1 learns the route from PE1 using a static route or using RIP, OSPF, IS-IS, or
BGP. This process is similar to that from CE2 to PE2.
Figure 2-20 shows route advertisement and data forwarding in an EVPN L3VPNv4
over SRv6 BE scenario.
Figure 2-20 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 table, named My Local SID Table.
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 against the

(2020-04-09)
destination IPv4 address prefix 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.
5. PE2 searches My Local SID Table based on A2:1::C100 and hits an End.DT4
by the End.DT4 SID for packet forwarding.
2.1.2.4.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-21 shows how EVPN L3VPNv6 over SRv6 BE is implemented.
Figure 2-21 EVPN L3VPNv6 over SRv6 BE implementation

1. SRv6 and SRv6 VPN are configured on each PE. Transit nodes support IPv6.
3. CE2 advertises its local IPv6 route to PE2.
CE2 can communicate with PE2 using a static route or using RIPng, OSPFv3,
IS-IS, or BGP4+.
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).

(2020-04-09)
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.
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
preferential route selection. If PE1 determines to install the route, this route is
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-22 shows route advertisement and data forwarding in an EVPN L3VPNv6
over SRv6 BE scenario.
Figure 2-22 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 table, named My Local SID Table.
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.

(2020-04-09)
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.
bound, PE1 searches the IPv6 routing table of the VPN instance against the
destination IPv6 address prefix 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::D100 as the destination address.
5. PE2 searches My Local SID Table based on A2:1::D100 and hits an End.DT6
by the End.DT6 SID for packet forwarding.
2.1.2.4.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-23 shows how routes are advertised in an EVPN VPWS over SRv6 BE
single-homing scenario.

(2020-04-09)
Figure 2-23 Route advertisement in an EVPN VPWS over SRv6 BE single-homing

scenario
The route advertisement process is as follows:

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-24 shows how data is forwarded in an EVPN VPWS over SRv6 BE single-
homing scenario.

(2020-04-09)
Figure 2-24 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 based on the destination address A2:1::150
and hits an End.DX2 SID. According to the instruction specified by the SID, PE2
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.DX2 SID.
EVPN VPWS over SRv6 BE Dual-Homing Active-Active Scenario

dual-homing active-active scenario.

(2020-04-09)
Figure 2-25 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 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-04-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-26 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-26, 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.

(2020-04-09)
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.
AC-Side Fault Protection in Dual-homing Scenarios

On the network shown in Figure 2-27, 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 PE3 receives the traffic, PE3 searches My Local SID
Table and hits an End.DX2L SID. According to the instruction specified by the SID,
PE2 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-27 AC-side fault protection in dual-homing scenarios
2.1.2.4.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.

(2020-04-09)
MAC Address Learning in an EVPN VPLS over SRv6 BE Scenario

Figure 2-28 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.
Figure 2-28 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-29 shows how unicast data is forwarded in an EVPN VPLS over SRv6 BE
scenario.

(2020-04-09)
Figure 2-29 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 based on the destination address A3:1::B300
and finds an End.DT2U SID. 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-30 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-04-09)
Figure 2-30 MDT for BUM traffic in an EVPN VPLS over SRv6 BE scenario
Figure 2-31 shows how BUM traffic is forwarded in an EVPN VPLS over SRv6 BE
scenario.

(2020-04-09)
Figure 2-31 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-04-09)
corresponding to the End.DT2M SIDs. PE2 and PE3 then flood the original
Layer 2 packet through their AC interfaces to receivers.
2.1.2.5 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-5 shows IS-IS extensions for SRv6.
Table 2-5 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-32 shows the format of the SRv6 Locator TLV.
Figure 2-32 SRv6 Locator TLV

(2020-04-09)
Table 2-6 Fields in the SRv6 Locator TLV

Type 8 bits Type.
Length 8 bits Length.
MTID 12 bits Multi-topology identifier.
Metric 32 bits Metric.
Flags 8 bits Flag bit. 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-33 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

(2020-04-09)
capabilities supported by the local node. Figure 2-34 shows the format of the
SRv6 Capabilities sub-TLV.
Figure 2-34 SRv6 Capabilities sub-TLV
Table 2-7 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-35 shows the format of the SRv6 End SID sub-TLV.
Figure 2-35 SRv6 End SID sub-TLV

(2020-04-09)
Table 2-8 Fields in the SRv6 End SID sub-TLV

Type 8 bits Type.
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-36 shows the format of the SRv6 End.X SID sub-TLV.
Figure 2-36 SRv6 End.X SID sub-TLV

(2020-04-09)
Table 2-9 Fields in the SRv6 End.X SID sub-TLV

Type 8 bits Type.
Flags 8 bits Flag bit. Figure 2-37 shows the format of this field.
Figure 2-37 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-38 shows the format of the SRv6 LAN End.X SID
sub-TLV.

(2020-04-09)
Figure 2-38 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-10 describes the fields in this
sub-TLV.
Table 2-10 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-39 shows the format of the Node MSD sub-TLV.
Figure 2-39 Node MSD sub-TLV
Table 2-11 describes the fields in the Node MSD sub-TLV.

(2020-04-09)
Table 2-11 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 T.Insert MSD Type: specifies the
maximum number of SIDs that can be inserted as
part of the "T.Insert" operation. Value 0 indicates
that the local node cannot perform a T.Insert
operation.
● Maximum T.Encaps MSD Type: specifies the
maximum number of SIDs that can be included as
part of the "T.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-12 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-04-09)
Table 2-12 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.6 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-04-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-40, 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-40 BGP EPE networking
On the network shown in Figure 2-40, 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 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

(2020-04-09)
network shown in Figure 2-40, BGP EPE allocates only Peer-Node SIDs
2001:db8::4, 2001:db8::5, and 2001:db8::6 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. For multi-hop EBGP peers, they must be directly
connected through physical links. This is because transit nodes do not have BGP
peer SID information, resulting in forwarding failures.
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.
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-41 and Figure 2-42 show Link NLRI formats.
Figure 2-41 Format of link information (Peer-Adj SIDs) advertised by BGP-LS

(2020-04-09)
Table 2-13 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: Peer-Adj-SID TLV
Figure 2-42 Format of SRv6 SID information (Peer-Node SIDs) advertised by BGP-
LS

(2020-04-09)
Table 2-14 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-43 shows the format of an SRv6 BGP Peer-Node SID.
Figure 2-43 SRv6 BGP Peer-Node SID format
Table 2-15 Fields in an SRv6 BGP Peer-Node SID TLV


(2020-04-09)
Flags 8 bits Flags field used in an SRv6 BGP Peer-Node SID TLV.
Figure 2-44 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 Weight of the SID, 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.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 is generated.
● 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.

(2020-04-09)
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-45. 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.
Figure 2-45 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.14.1 SR-MPLS TE Policy Creation.

(2020-04-09)
An SRv6 TE Policy can be created using End SIDs, End.X SIDs, anycast SIDs, binding
SIDs, or a combination of them.
Figure 2-46 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. Moreover, the preference values must be
unique. The first-hop SID of a segment list can be an End SID or End.X SID, but
cannot be any binding SID.
Figure 2-46 Manual SRv6 TE Policy configuration
Figure 2-47 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
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-04-09)
Figure 2-47 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
Route coloring is to add the Color 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.
policy.
SRv6 TE Policies support color-based traffic steering that steers traffic into an SRv6
TE Policy by recursing the traffic route to the SRv6 TE Policy based on the color
value and destination address in the route. Figure 2-48 shows the traffic steering
process.

(2020-04-09)
Figure 2-48 Color-based traffic steering
2.1.2.7.3 SRv6 TE Policy-based Data Forwarding
IPv4 L3VPN is used as an example to describe how data is forwarded through an

SRv6 TE Policy. Figure 2-49 shows the data forwarding process.
1. The controller delivers an SRv6 TE Policy to headend device PE1.
2. Endpoint device PE2 advertises BGP VPNv4 route 10.2.2.2/32 to PE1. The next-
hop address in the BGP route is the address of PE2, that is, 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 address in the route. The SID list of 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.

(2020-04-09)
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.
Figure 2-49 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 monitor SRv6
tunnels. With a simplified BFD state machine, SBFD shortens the negotiation time
and improves network-wide flexibility.
SBFD Implementation
Figure 2-50 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

(2020-04-09)
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.
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-50 SBFD Implementation
SBFD State Machine of the Initiator

The initiator's SBFD state machine has only two alternating states: up and down.
Figure 2-51 shows how the SBFD state machine works.
Figure 2-51 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.

(2020-04-09)
● 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.
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.
The SRv6 TE Policy remains up only unless the SID stack is revoked. 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-52 shows the SBFD for SRv6 TE Policy detection process.
Figure 2-52 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

(2020-04-09)
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
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 is still 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-53, an SRv6 TE Policy is deployed between PE1
and PE3 and between PE2 and PE4. Figure 2-53 lists possible failure points and
corresponding protection schemes.

(2020-04-09)
Figure 2-53 SRv6 TE Policy-related fault scenarios
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 SRv6 TE Policy on PE1 is deleted. As a result,
the corresponding VPNv4 route cannot recurse to the SRv6 TE Policy.
Because route recursion is still required, the VPNv4 route recurses to an
SRv6 BE path (if any exists on the network). 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 a mirror 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.

(2020-04-09)
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-54 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.
Figure 2-54 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 IPv4 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.

(2020-04-09)
4. A mirror SID is configured on PE2 to protect PE1, generating a <Mirror SID,

Locator> mapping entry (for example, <A2::100, A1::>).
5. PE2 propagates the mirror SID through an IGP and generates a local SID
table. After receiving the mirror SID, P1 generates an FRR entry with the next-
hop address being PE2 and the action being Push mirror SID. In addition, P1
generates a low-priority route that cannot be recursed.
6. BGP subscribes to mirror 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 <Mirror 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 mirror SID into the packet header and forwards the packet to
PE2. After parsing the received packet, PE2 obtains the mirror SID, queries the
local SID table, and finds that the instruction specified by the mirror 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, the VPN route received by PE2 from PE1 is deleted, causing the <Remote
SRv6 VPN SID, VPN> entry to be deleted and ultimately resulting in problems. To
prevent this, enable GR on PE2 and PE1 to maintain routes or enable delayed
deletion for the <Remote SRv6 VPN SID, VPN> entry on PE2.
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-
Independent Loop-free Alternate FRR (TI-LFA) uses an explicit path to represent a
backup path, which poses no topology constraints and provides more reliable fast
reroute (FRR).

(2020-04-09)
IPv6 TI-LFA
In Figure 2-55, 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-55 RLFA
TI-LFA FRR protects links and nodes on SRv6 tunnels. Figure 2-56 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-04-09)
Figure 2-56 TI-LFA
2.1.2.9 SRv6 Microloop Avoidance
Microloops are transient loops that could occur on a network following non-
simultaneous convergence of IGP-running network nodes because IGPs use
distributed link state databases (LSDBs). This type of loop disappears after all the
nodes on the forwarding path complete convergence. Microloops result in a series
of issues, including packet loss, jitter, and out-of-order packets, and therefore must
be avoided.
Microloop Avoidance in Traffic Switchover Scenarios

On the network shown in Figure 2-57, if DeviceB fails and DeviceA converges
earlier than DeviceF, DeviceA forwards traffic to DeviceF. Because DeviceF does not
complete convergence, it still forwards the traffic along the original path, causing
a loop between DeviceA and DeviceF.

(2020-04-09)
Figure 2-57 Microloop avoidance in a traffic switchover scenario
To prevent the microloop, after DeviceB fails, DeviceA delays its convergence until
DeviceF finishes convergence and switches traffic to a TI-LFA backup path. After
DeviceA completes convergence, it switches traffic from the TI-LFA backup path to
the converged path.
Microloop Avoidance in a Traffic Switchback Scenario

On the network shown in Figure 2-58, data traffic travels along the backup path
before the link between DeviceB and DeviceC recovers. If the link between DeviceB
and DeviceC recovers and DeviceA completes convergence earlier than DeviceB,
DeviceA forwards traffic to DeviceB. Because DeviceB does not complete
convergence, it still forwards the traffic along the backup path, causing a loop
between DeviceA and DeviceB.

(2020-04-09)
Figure 2-58 Microloop avoidance in a traffic switchback scenario
To prevent the microloop, after DeviceA performs a traffic switchback, it adds E2E
explicit path information (for example, End.X SID of DeviceB) to packets and
forwards the packets to DeviceB. After receiving the packets, DeviceB forwards
them to DeviceC based on SRH information in the packets.
After DeviceB converges, DeviceA stops adding an SRH to packets and forwards
the packets to DeviceC in IPv6 forwarding mode.
2.1.2.10 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.10.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 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 requires the use of SRv6
OAM extensions to check the reachability to the address. If this requirement is not
met, ICMPv6 ping does not work in this case. Currently, SRv6 OAM extensions are
implemented by setting the O-bit (OAM bit) in the SRH or by inserting End.OP
SIDs at an appropriate place in the SRH.

(2020-04-09)
SRH O-bit
O-bit is located in the Flags field of the SRH shown in Figure 2-1. Figure 2-59
shows the format of the Flags field.
Figure 2-59 Format of the Flags field in the SRH
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.
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.10.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

Working process of SRv6 SID ping
On the network shown in Figure 2-60, Device A, Device B, and Device C have SRv6
capabilities, and an SRv6 path is established between Device A and Device C.

(2020-04-09)
Figure 2-60 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.
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.
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

(2020-04-09)
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

Working process of SRv6 SID tracert
Assume that an SRv6 SID tracert operation is initiated on Device A as shown in
Figure 2-60. 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.
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.
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.

(2020-04-09)
▪ 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.10.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
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-61, 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-61 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.

(2020-04-09)
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-61. 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
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.
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.

(2020-04-09)
– 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.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

Acronym and Full Name
Abbreviation
CSPF constraint shortest path first
FRR fast re-route
MSD maximum SID depth
NETCONF Network Configuration Protocol
PHP penultimate hop popping
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

(2020-04-09)
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) is designed to forward IPv6 data packets on a
network through source routing.
SRv6 is based on the IPv6 forwarding plane. With SRv6, the ingress adds a
segment routing header (SRH) into IPv6 packets and pushes an explicit IPv6
address stack into the SRH. After receiving such a packet, each transit node
updates the IPv6 destination address in the packet and offsets the address stack to
implement per-hop forwarding.
SRv6 offers the following benefits to users:
● Simplified network configuration and easier VPN implementation
SRv6 does not use MPLS techniques and is fully compatible with existing IPv6
networks. Nodes only need to support IPv6 forwarding instead of MPLS
forwarding. Transit nodes can be incapable of SRv6 and forward IPv6 packets
carrying the SRH over routes.
● Enhanced fast reroute (FRR) protection capability
SRv6 works with the remote loop-free alternate (RLFA) FRR algorithm to
provide topology-independent loop-free alternate (TI-LFA) protection. This
protection technique supports all topologies in theory and overcomes
drawbacks in conventional tunnel protection.
● Flexible traffic optimization on IPv6 forwarding paths
Segment IDs (SIDs) with various service types are used, enabling the ingress
to flexibly plan explicit paths and adjust service traffic.
2.2.2 Segment Routing IPv6 Licensing Requirements and


(2020-04-09)
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-04-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-04-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-04-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-04-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-04-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-04-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-04-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-04-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-04-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-04-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-04-09)
2.2.3 Activating SRv6 Port Licenses for a Board

You can configure SRv6 services on a board only after SRv6 port licenses are
activated for the board.
Before you configure SRv6 services on a CM board, 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
SRv6 port licenses are activated for a specified board.
This command takes effect only for CM boards.
Step 4 Run commit
----End

Run the display license resource usage port-srv6 { all | slot slot-id } [ active |
deactive ] command to check whether SRv6 port licenses have been activated for
the board.
2.2.4 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-62, 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-04-09)
Figure 2-62 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 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 its view is displayed.
3. Run ipv4-family
The VPN instance IPv4 address family is enabled, and its view 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
Exit the VPN instance view.

(2020-04-09)
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.
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 IPv6 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 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-04-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 ] * ]
A SID node route locator is configured.
4. Run opcode func-opcode end-dt4 vpn-instance vpn-instance-name
A static SID's operation code (opcode) is configured.
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 in routes.
13. Run segment-routing ipv6 locator locator-name [ auto-sid-disable ]
VPN routes are enabled to carry the SID attribute.
If auto-sid-disable is not specified, dynamic SID allocation is supported. If
static SIDs are configured for the SID node route locator named using locator-
name, use the static SIDs. Otherwise, use dynamically allocated SIDs.
14. Run commit
Step 6 Enable IS-IS SRv6 on PEs.

(2020-04-09)

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 ping command to check the connectivity between CEs.
2.2.5 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.
Figure 2-63 EVPN L3VPN over SRv6 BE networking
Before configuring EVPN L3VPN over SRv6 BE, complete the following tasks:

(2020-04-09)

Procedure
Functions.
Step 2 Configure an L3VPN instance.
For IPv4 services, configure an IPv4 L3VPN instance.

A VPN instance is created, and the VPN instance view is displayed.
2. Run ipv4-family
The VPN instance IPv4 address family is enabled, and the view of this address
family is displayed.
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.
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


(2020-04-09)
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.
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.

(2020-04-09)
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 [ ipv4-source-address ]
A source interface and a source address are specified to set up a TCP
connection with the BGP peer.
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 only one end, 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 ]
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.

(2020-04-09)
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.
By default, the Next Header field value is 143 in an SRv6 extension header. To
be compatible with earlier versions, you can perform this step to change the
value to 59.


5. Run opcode func-opcode { end-dt4 | end-dt6 } vpn-instance vpn-instance-
name evpn
A static SID's operation code (opcode) is configured. The end-dt4 parameter
is specified for IPv4 services, and the end-dt6 parameter is specified for IPv6
services.
Alternatively, run opcode func-opcode { end-dx4 | end-dx6 } vpn-instance

vpn-instance-name evpn interface interface-type interface-number nexthop
nexthop-address
A static SID's opcode is configured. The end-dx4 parameter is specified for
IPv4 services, and the end-dx6 parameter is specified for IPv6 services.

(2020-04-09)
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.
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 the SID attribute 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 SID attribute
carried in 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 all BGP VPN routes:
– 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.

(2020-04-09)
– 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
Step 6 Enable IS-IS SRv6 on PEs.
3. Run commit
----End

After configuring EVPN L3VPN over SRv6 BE, verify the configuration.
● Run the display bgp evpn { all | route-distinguisher route-distinguisher |
vpn-instance vpn-instance-name } 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.6 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.

(2020-04-09)
Figure 2-64 EVPN VPWS over SRv6 BE networking
Before configuring EVPN VPWS over SRv6 BE, complete the following tasks:
Procedure
Functions.
Step 2 Configure EVPN and EVPL instances on each PE.
1. Run system-view
2. Run evpn source-address ip-address
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.
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-04-09)
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.
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.
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.

(2020-04-09)
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.


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

(2020-04-09)

1. (Optional) Run evpn srv6 next-header-field { 59 | 143 }A value is set for the
Next Header field in an SRv6 extension header.
value to 59.
5. Run opcode func-opcode end-dx2 evpl-instance evpl-instance-id
A static SID's operation code (opcode) is configured.
6. (Optional) Run opcode func-opcode end-dx2l evpl-instance evpl-instance-id
An End.DX2L SID's 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.
locator-name must be set to the route locator configured in step c.
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

(2020-04-09)
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 the SID attribute to EVPN routes to be sent.
If static SIDs are configured for the SID node route locator named 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.
The device is enabled to perform route recursion based on the SID attributes
carried by 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
The locator view is displayed.
c. Run opcode func-opcode end-op
An End.OP SID opcode is configured.
d. Run commitThe configuration is committed.
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-opendOp [ -a source-
ip | -c count | -exp exp-value | -m interval | -s packet-size | -t time-out | -r
reply-mode | -tc tc ] *

(2020-04-09)
A ping operation is performed to check the EVPN-VPWS status.

– Run tracert evpn vpws local-ce-id remote-ce-id end-opendOp [ -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.
vpn-instance vpn-instance-name } routing-table [ { ad-route | es-route |
inclusive-route | mac-route | prefix-route } prefix ] command to check BGP
EVPN routing 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.7 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
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-65 EVPN VPLS over SRv6 BE networking

(2020-04-09)
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
9. Run quit
10. Run quit
Exit the BGP view.
11. Run commit
value to 59.

(2020-04-09)

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 node route 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.
Perform this step if a static node route locator is configured using the static
static-length 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.
locator-name must be set to the route locator configured in step c.
Configuring both End.DT2U and End.DT2UL SIDs is required.
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 ]
The SID attribute is added to the EVPN routes to be sent.
For the preceding command:
– If locator-name is specified, you need to configure an End.DT2M SID, with
the args parameter being set. If unicast-locator-name is specified, you

(2020-04-09)
need to configure both End.DT2U and End.DT2UL SIDs. If both locator-

name and unicast-locator-name are specified, you need to create
corresponding route locators in step c.
– In EVPN VPLS dual-homing scenario, the args parameter is used to splice
ESI labels for End.DT2M SIDs only. This causes a waste of End.DT2U SIDs.
In this case, you can configure a SID node route locator of the End.DT2U
type and a SID node route locator of the End.DT2M type. The args
parameter does not need to be specified for the SID node route locator of
the End.DT2U type. The two SID node route locators can be bound to the
same EVPN instance to conserve SIDs.
– If static SIDs are configured for the SID node route locator named using
locator-name or unicast-locator-name, use the static SIDs. Otherwise, use
dynamically allocated SIDs.
The device is enabled to perform route recursion based on the SID attributes
carried by 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.
EVPN routing information.
2.2.8 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
SRv6 TI-LFA FRR protects links and nodes on SR tunnels. If a link or node fails,
traffic is rapidly switched to a backup path, minimizing traffic loss.
In some LFA or remote LFA (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 to resolve the issue.
Before configuring IS-IS SRv6 TI-LFA FRR, enable IS-IS SRv6.

(2020-04-09)
Procedure
An IS-IS process is created, and the IS-IS view is displayed.
Step 3 Run ipv6 frr
The IPv6 IS-IS FRR view is displayed.
Step 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.
Step 5 Run ti-lfa [ level-1 | level-2 | level-1-2 ]
IS-IS SRv6 TI-LFA is enabled.
Step 6 (Optional) Run tiebreaker { node-protecting | lowest-cost | non-ecmp | srlg-
disjoint } preference preference [ level-1 | level-2 | level-1-2 ]
The solution of selecting a backup path for IS-IS SRv6 TI-LFA FRR is set.
By default, the preference value is 40 for the node-protection path first solution,
20 for the smallest-cost path first solution, 10 for the non-ECMP path first
solution, and 5 for the shared risk link group (SRLG) disjoint path first solution. A
larger value indicates a higher priority.
Before configuring the srlg-disjoint parameter, you need to run the isis srlgsrlg-
value command in the IS-IS interface view to configure the IS-IS SRLG function.
Step 7 (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.
convergence rates on devices, posing the risk of microloops. To prevent
microloops, perform the following steps:
1. Run quit

(2020-04-09)

The IS-IS process is enabled, and the IS-IS view is displayed.
Local IS-IS anti-microloop is enabled.
4. (Optional) Run avoid-microloop frr-protected rib-update-delay rib-update-
delay
A delay in IS-IS route delivery is configured.
5. Run ipv6 avoid-microloop segment-routing
Remote IS-IS anti-microloop is enabled.
6. (Optional) Run ipv6 avoid-microloop segment-routing rib-update-delay
rib-update-delay
A delay in SRv6 IS-IS route delivery is configured.
Step 9 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.9 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.

(2020-04-09)
● 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.9.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 SID and End.X SID, 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

value to 59.
SRv6 is enabled.
4. Run commit

(2020-04-09)
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.

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's operation code (opcode) is configured.
c. Run opcode func-opcode end-x interface interface-name nexthop
nexthop-address [ no-psp ]
A static End.X SID's opcode is configured.
d. Run quit
Exit the segment routing IPv6 locator view.
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 segment routing IPv6 view.
g. Run isis [ process-id ]
h. Run ipv6 enable
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
The device is enabled to send routes that carry SIDs to the IS-IS module.
k. Run commit
● Configure IS-IS to dynamically generate SIDs.
b. Run quit
c. Run quit

(2020-04-09)
d. Run isis [ process-id ]

e. Run ipv6 enable
IS-IS IPv6 capabilities are enabled.
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.9.2 Configuring an SRv6 TE Policy

SRv6 TE Policy is a tunneling technology developed based on SRv6. 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 stack of SIDs and places the SIDs by index index in
ascending order. If a candidate path in an 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

(2020-04-09)

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

(2020-04-09)
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.
5. Run commit
a. Run system-view
c. Run peer { ipv4-address | group-name } as-number as-number
{ import | export }
f. Run commit

(2020-04-09)
a. Run system-view
{ import | export }
f. Run commit
a. Run system-view
{ import | export }
g. Run commit
a. Run system-view
d. Run l2vpn-family evpn

(2020-04-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-04-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
1. Run system-view
2. Run tunnel-policy policy-name
3. (Optional) Run description description-information
A description is configured for the tunnel policy.
4. 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.
5. 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
● Configure a BGP L3VPNv6 service to recurse to an SRv6 TE Policy.
a. Run system-view

(2020-04-09)
c. Run ipv6-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.
d. Run commit

(2020-04-09)

steps:
a. Run system-view
The basic EVPN instance view is displayed.
d. Run commit
----End
2.2.9.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 to initiate a ping
operation on the specified SRv6 TE Policy for connectivity check.
----End

(2020-04-09)
2.2.10 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.10.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 SID and End.X SID, 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-04-09)
Procedure
Step 1 Enable SRv6.
1. Run system-view

value to 59.
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's operation code (opcode) is configured.
c. Run opcode func-opcode end-x interface interface-name nexthop
nexthop-address [ no-psp ]
A static End.X SID's 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
g. Run isis [ process-id ]

(2020-04-09)
h. Run ipv6 enable

IPv6 is enabled for the IS-IS process.
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
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.10.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.

(2020-04-09)
● Link-specific TE metric
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

(2020-04-09)
The BC bandwidth is configured for the link.
● 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

(2020-04-09)
Mappings between affinity bits and names are configured.

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 interface interface-type interface-number
e. 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.
f. 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.
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.10.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-04-09)
Step 3 Run ipv6 enable

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

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.
1. Run system-view

(2020-04-09)

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


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.10.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.
Procedure

(2020-04-09)
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.
5. Run commit
a. Run system-view

(2020-04-09)

{ import | export }
f. Run commit
a. Run system-view
{ import | export }
f. Run commit
a. Run system-view
{ import | export }
g. Run commit

(2020-04-09)

a. Run system-view
d. Run l2vpn-family evpn
{ 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.

(2020-04-09)

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
1. Run system-view
A description is configured for the tunnel policy.
balance-number
configured.
5. 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

(2020-04-09)

e. Run commit
● Configure a BGP L3VPNv6 service to recurse to an SRv6 TE Policy.
a. Run system-view
c. Run ipv6-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

(2020-04-09)
d. Run commit
a. Run system-view
displayed.
mode.
d. Run commit
steps:
a. Run system-view
The basic EVPN instance view is displayed.
d. Run commit
----End
2.2.10.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.

(2020-04-09)
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 to initiate a ping
operation on the specified SRv6 TE Policy for connectivity check.
----End
2.2.11 Configuring L3VPNv4 over SRv6 TE Policy

This section describes how to configure L3VPNv4 over SRv6 TE Policy.
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-66 L3VPNv4 over SRv6 TE Policy networking
Before configuring L3VPNv4 over SRv6 TE Policy, complete the following tasks:

Procedure
Functions.

(2020-04-09)
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 ]
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 L3VPN 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.
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.

(2020-04-09)
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.
A router ID is configured.
The device is enabled to exchange VPN-IPv4 routes with a specified peer.
7. Run peer ipv6-address prefix-sid
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 VPN routes to carry the SID attribute.

(2020-04-09)
4. (Optional) Run opcode func-opcode end-dt4 vpn-instance vpn-instance-

name
A static SID operation code (opcode) is configured.
5. Run quit
6. Run quit
Exit the SRv6 view.
The BGP-VPN instance IPv4 address family view is displayed.
VPN routes are enabled to carry the SID attribute.
If auto-sid-disable is not specified, dynamic SID allocation is supported. If
static SIDs are configured for the SID node route locator named using locator-
name, use the static SIDs. Otherwise, use dynamically allocated 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
Step 6 Configure an SRv6 TE Policy. For details, see 2.2.9 Configuring an SRv6 TE Policy
(Manual Configuration) or 2.2.10 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.
The BGP Color Extended Community is configured.
4. Run quit
Exit the route-policy view.

(2020-04-09)

7. Run peer ipv6-address route-policy route-policy-name { import | export }
8. Run quit
9. Run quit
Exit the BGP view.
A tunnel policy is created, and the tunnel policy view is displayed.
balance-number
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 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 ip vpn-instance vpn-instance-name tunnel-info nexthop
nexthopIpv6Addr command to check information about the tunnel to which

(2020-04-09)
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 <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.12 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-67, 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-67 EVPN L3VPNv4 over SRv6 TE Policy networking
Before configuring EVPN L3VPNv4 over SRv6 TE Policy, configure an SRv6 TE
Policy manually or use a controller to dynamically deliver an SRv6 TE Policy.
SRv6 TE Policy configuration requires you to apply a tunnel policy to a specified

EVPN L3VPNv4 instance when you configure traffic steering.
Procedure
2. Run ipv4-family

(2020-04-09)
extcommunity ] evpn
5. (Optional) Run default-color color-value evpn
The default color value is specified for the L3VPN service to recurse to an
SRv6 TE Policy.
If a remote EVPN route without carrying the Color Extended Community is
recursion.
8. Run quit
9. Run quit



An IPv4 address is configured for the interface.

4. Run quit
Step 3 Configure BGP EVPN peer relationships.

(2020-04-09)

number-dot }
A remote PE is configured as a peer.
interface-type interface-number

policy-name ] *
Other protocol routes 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
host resides.

7. Run quit
Exit the BGP-VPN instance IPv4 address family view.


The device is enabled to exchange EVPN routes with a specified peer or peer
group.

(2020-04-09)

11. Run quit
12. Run commit
Step 4 On each PE, configure EVPN L3VPNv4 services to recurse to an SRv6 TE Policy.
The device is enabled to add the SID attribute to VPN routes before sending
the routes to EVPN.
3. Run segment-routing ipv6 traffic-engineer [ best-effort ] evpn
The function to recurse EVPN L3VPN services to SRv6 TE Policies is enabled.
4. (Optional) Run segment-routing ipv6 apply-sid all-nexthop evpn
The device is configured to allocate SIDs to all BGP VPN IPv4 routes, 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.
5. Run commit
----End

After configuring EVPN L3VPNv4 over SRv6 TE Policy, verify the configuration.
● Run thedisplay bgp vpnv4 { all | route-distinguisher route-distinguisher |
vpn-instance vpn-instance-name } routing-table [ network [ prefix-
length ] ] command to check BGP VPNv4 route information. The command
output shows that the value of Relay Tunnel Out-Interface is an 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.

(2020-04-09)
2.2.13 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-68, PE1 and PE2 communicate through an
IPv6 public network. An SRv6 TE Policy is configured on the network to carry
EVPN L3VPNv6 services.
Before configuring EVPN L3VPNv6 over SRv6 TE Policy, configure an SRv6 TE
Policy manually or use a controller to dynamically deliver an SRv6 TE Policy.

EVPN L3VPN 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

(2020-04-09)
5. (Optional) Run default-color color-value evpn

The default color value is specified for the L3VPNv6 service to recurse to an
SRv6 TE Policy.
recursion.
8. Run quit
9. Run quit



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
Step 3 Configure BGP EVPN peers.

number-dot }

(2020-04-09)

policy-name ] *
Other protocol routes 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
host resides.
7. Run quit
Exit the BGP-VPN instance IPv6 address family view.
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 commit
Step 4 On each PE, configure EVPN L3VPNv6 services to recurse to an SRv6 TE Policy.

(2020-04-09)

The device is enabled to add the SID attribute to VPN routes when
propagating the routes to the EVPN peer.
3. Run segment-routing ipv6 traffic-engineer [ best-effort ] evpn
The device is enabled to recurse EVPN L3VPNv6 services to SRv6 TE Policies.
4. (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 all BGP VPN IPv6 routes, run
the segment-routing ipv6 apply-sid all-nexthop evpn command.
– 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.
5. Run commit
----End

After configuring EVPN L3VPNv6 over SRv6 TE Policy, verify the configuration.
● Run the display bgp vpnv6{ all | route-distinguisher route-distinguisher |
vpn-instance vpn-instance-name } routing-table [ network [ prefix-
length ] ] command to check BGP VPNv6 route information. The command
output shows that the value of Relay Tunnel Out-Interface is an 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.14 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-69, PE1 and PE2 communicate through an IPv6

(2020-04-09)
public network. An SRv6 TE Policy is configured on the network to carry EVPN

VPWSs.
Figure 2-69 EVPN VPWS over SRv6 TE Policy
Before configuring EVPN VPWS over SRv6 TE Policy, configure an SRv6 TE Policy
manually or use a controller to dynamically deliver an SRv6 TE Policy.
EVPN instance that works in VPWS mode when you configure 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.
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-04-09)
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.
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

(2020-04-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.
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.
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
attributes to the specified peer.

(2020-04-09)
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.
The view of an EVPL instance that works in SRv6 mode is displayed.
If static SIDs are configured for the SID node route locator named using
locator-name, use the static SIDs. Otherwise, use dynamically allocated SIDs.
3. 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.
6. Run quit
7. Run commit
Step 5 (Optional) Verify EVPN VPWS connectivity.
1. Configure an End.OP SID on the remote PE.
b. Run locator locator-name
The locator view is displayed.
c. Run opcode func-opcode end-op
An End.OP SID opcode is configured.
d. Run commitThe configuration is committed.

(2020-04-09)
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-opendOp [ -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-opendOp [ -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 an 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.15 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-70, PE1 and PE2 communicate through an IPv6 public network. An SRv6
TE Policy is configured on the network to carry EVPN VPLSs.

(2020-04-09)
Figure 2-70 EVPN VPLS over SRv6 TE Policy networking
Before configuring EVPN VPLS 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.
SRv6 TE Policy configuration requires you to apply a tunnel policy to a
specified EVPN instance that works in BD mode when you configure traffic
steering.
● Deploy BD-EVPN functions between PE1 and PE2.
Procedure
1. Run system-view







(2020-04-09)

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.

The view of the EVPN instance that works in BD mode is displayed.

The SID attribute to be added needs to be configured during SRv6 TE Policy

configuration.
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.
5. Run quit

6. 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 an SRv6 TE Policy.

(2020-04-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.16 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.16.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 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:
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.

(2020-04-09)
Procedure
● Configure a public End.DT4 SID.
a. Run system-view
b. Run segment-routing ipv6
c. Run encapsulation source-address ipv6-address [ ip-ttl ttl-value ]
A source address is specified for SRv6 VPN encapsulation.
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 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 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.
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 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 system-view

(2020-04-09)

c. Run ipv4-family flow


automatically imported to the BGP-Flow routing table and then sent to
each peer.
e. 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.
f. 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.
g. Run commit
----End


2.2.16.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.
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 an SRv6 TE Policy (in controller-based dynamic delivery mode).

(2020-04-09)
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
process 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 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
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.
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

(2020-04-09)
----End

2.2.17 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 specified segment lists, with the egress of the SRv6 TE Policy
being 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-71 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,

(2020-04-09)
Figure 2-71 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 the route to PE3. The route carries the VPN SID,
RT, RD, and color information.
4. A mirror SID is configured on PE2 to protect PE1, generating a <Mirror SID,
Locator> mapping entry, for example, <A2::100, A1::>.
5. PE2 propagates the mirror SID through an IGP and generates a local SID
table. After receiving the mirror SID, P1 generates an FRR entry with the next-
hop address being PE2 and the action being Push mirror SID. In addition, P1
generates a low-priority route that does not support recursion.
6. BGP subscribes to mirror SID configuration. After receiving the VPN 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 with the local <Mirror 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 general, PE3 forwards traffic to the private network through the PE3-P1-
PE1-CE2 path. If PE1 fails, P1 detects that the next hop of PE1 is unreachable
and switches traffic to the FRR path.

(2020-04-09)
2. P1 pushes the mirror SID into the packet header and forwards the packet to
PE2. After parsing the received packet, PE2 obtains the mirror SID, queries the
local SID table, and finds that the instruction bound to the mirror 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. Then, PE2 searches the VPN routing table and
forwards the packet to CE2.
If PE1 fails, the peer relationship between PE2 and PE1 is interrupted. As a result,
the VPN route received by PE2 from PE1 is deleted, causing the <Remote SRv6
VPN SID, VPN> entry to be deleted. Therefore, you need to enable GR between
PE2 and PE1 to maintain routes or enable delayed deletion 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.9 Configuring an SRv6 TE Policy
(Manual Configuration) and 2.2.10 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.13 Configuring EVPN L3VPNv6
over SRv6 TE Policy and 2.2.14 Configuring EVPN VPWS over SRv6 TE Policy.
Step 3 Configure protection on PE2.

1. Run system-view


4. Run opcode func-opcode end-m mirror-locator ipv6-address prefix-length
An End.M SID is configured.
opcode func-opcode must be configured within the local locator range. The
locator to be protected is specified using mirror-locator ipv6-address prefix-
length.
5. Run commit
Step 4 Configure IPv6 IS-IS FRR on each P.

1. Run system-view


(2020-04-09)
The IS-IS process is enabled, and the IS-IS view is displayed.

3. Run ipv6 frr
The IPv6 IS-IS FRR view is displayed.
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
----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.18 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

(2020-04-09)
2.2.19 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 or segment lists reaches
the specified threshold. This facilitates O&M.
Context
If the number of SRv6 TE Policies or segment lists exceeds the upper limit, adding
new SRv6 TE Policies or segment lists may affect existing services. To prevent this,
you can configure alarm thresholds for the number of SRv6 TE Policies and the
number of 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
lower-limit lowerLimitValue
An alarm threshold is configured for the number of SRv6 TE Policies.
Step 5 Run commit
----End
2.2.20 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.

(2020-04-09)
This increases the packet size and must be taken into account when an SRv6 path
MTU is configured.
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.
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. Run commit
● Configure a path MTU for an SRv6 TE Policy.
a. Run system-view
c. Run path-mtu mtu-value
A global path MTU is configured for an SRv6 TE Policy.
d. Run commit
----End
2.2.21 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
configuration takes effect.
Procedure
Step 1 Global configuration

(2020-04-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
The SRv6 TE Policy view is displayed.
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 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.

(2020-04-09)
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

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.
If all of the preceding three commands are run, only the last command takes
effect.
Table 2-17 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-04-09)
Table 2-17 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
End.X SID
(PSP) and
End.X SID (no
PSP, no USP)
is specified,
the other type
of SID is
dynamically
allocated.

(2020-04-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-04-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-04-09)

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.23 Using Ping/Tracert to Test an SRv6 Network

Ping and tracert can be used to test and monitor a Segment Routing IPv6 (SRv6)
network.
2.2.23.1 Using Ping to Test the Connectivity of an SRv6 Network

Ping can be used to test the connectivity of a Segment Routing IPv6 (SRv6)
network that carries IPv6 packets.
Context
After configuring SRv6, you can perform the following configurations in any view
of a 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

(2020-04-09)
--- ipv6-sid ping statistics---

0.00% packet loss
● Test the connectivity of an 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.23.2 Using Tracert to Test the Path Information of an SRv6 Network

Tracert can be used to test the path information of a Segment Routing IPv6
(SRv6) network that carries IPv6 packets.
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

(2020-04-09)
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.
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-otp 2001:db8:2::1 -a 2001:db8:1::1 -q 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.24 Configuration Examples for SRv6 BE

This section provides SRv6 BE configuration examples.
2.2.24.1 Example for Configuring L3VPNv4 over SRv6 BE

This section provides an example for configuring SRv6 BE to carry L3VPNv4
services.
● 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 in area 1.
It is required that a bidirectional SRv6 BE path be deployed between PE1 and PE2
to carry L3VPNv4 services.
Figure 2-72 L3VPNv4 over SRv6 BE networking

(2020-04-09)
1. Enable IPv6 forwarding on each device 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 IS-IS SRv6 on each device.
4. Configure VPN instances on PE1 and PE2.
5. Establish an EBGP peer relationship between each PE and its connected CE.
6. Establish an MP-IBGP peer relationship between PEs.
7. Configure SRv6 on PE1 and PE2.
Data Preparation
● IPv6 address of each interface on PE1, the P, and PE2

● Area ID of PE1, the P, and PE2
● Level on PE1, the P, and PE2
● VPN instance name, RD, and RT on PE1 and PE2
Procedure
Step 1 Enable IPv6 forwarding on each device and configure an IPv6 address for each
interface. The following example uses the configuration of PE1. The configuration
of other devices is similar to the configuration of PE1. For configuration details,
[*HUAWEI] commit
[~PE1-GigabitEthernet1/0/0] ipv6 enable
[*PE1-GigabitEthernet1/0/0] ipv6 address 2001::1 96

(2020-04-09)
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-GigabitEthernet1/0/0] commit
[~P-GigabitEthernet1/0/0] quit
[*P] interface loopback1
[*P-LoopBack1] isis ipv6 enable 1
[*P-LoopBack1] commit
[~P-LoopBack1] quit
# Configure PE2.
[~PE2] isis 1
[*PE2-isis-1] quit
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.

--------------------------------------------------------------------------------

(2020-04-09)
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:FE41:13 10 A/-/-/-
2001::/96 GE1/0/0 Direct 10 D/-/L/-
2002::/96 GE1/0/0 FE80::3A92:6CFF:FE21:10 20 A/-/-/-
GE1/0/0 FE80::3A92:6CFF:FE41:13
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.
[*PE2] commit



(2020-04-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] 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
10.1.1.2 4 65410 11 9 0 00:06:37 Established 1

(2020-04-09)

# 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

# Configure PE1.
[~PE1] segment-routing ipv6
[~PE1-segment-routing-ipv6] encapsulation source-address 1::1
[*PE1-segment-routing-ipv6] locator as1 ipv6-prefix 10::1 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-vpna] segment-routing ipv6 best-effort
[*PE1-bgp-vpna] segment-routing ipv6 locator as1
[~PE1-bgp-vpna] quit
[~PE1-bgp] quit
[~PE1] isis 1
[*PE1-isis-1] segment-routing ipv6 locator as1

(2020-04-09)
[~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::1 PrefixLength: 64
StaticLength : 32 Reference : 2
ArgsLength : 0
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.

Status codes: * - valid, > - best, d - damped, x - best external, a - add
path,

(2020-04-09)

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.
[~PE1] display ip routing-table vpn-instance
vpna
route
------------------------------------------------------------------------------
Destination/Mask Proto Pre Cost Flags NextHop

Interface
10.1.1.0/24 Direct 0 0 D 10.1.1.1

10.1.1.1/32 Direct 0 0 D 127.0.0.1
10.1.1.255/32 Direct 0 0 D 127.0.0.1
10.2.1.0/24 IBGP 255 0 RD 30::1:0:3C SRv6 BE
11.11.11.11/32 EBGP 255 0 RD 10.1.1.2
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

(2020-04-09)
[~PE1] display ip routing-table vpn-instance vpna 22.22.22.22

verbose
route
------------------------------------------------------------------------------
Summary Count : 1
NextHop: 30::1:0:3C Neighbour: 3::3
IndirectID: 0x1000133 Instance:
RelayNextHop: 30::1:0:3C Interface: SRv6 BE
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
Configuration Files
#
sysname PE1
#
ipv4-family
#
segment-routing ipv6
encapsulation source-address 1::1
locator as1 ipv6-prefix 10::1 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

(2020-04-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 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
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-04-09)
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
#
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
#

(2020-04-09)
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.24.2 Example for Configuring L3VPNv4 over SRv6 BE ECMP

This section provides an example for configuring L3VPNv4 over SRv6 BE ECMP.
● PE1, PE2, P1, and P2 are in the same AS and run IS-IS to implement IPv6
● PE1, PE2, P1, and P2 are Level-2 devices in area 1.
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-73 L3VPNv4 over SRv6 BE ECMP networking

(2020-04-09)
Precautions
When configuring IPv4 VPN 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.
interface.
device. In addition, configure dynamic BFD for IPv6 IS-IS.
3. Configure IS-IS SRv6 on PE1 and PE2.
Data Preparation
● IPv6 address of each interface on PE1, PE2, P1, and P2
● Area ID of PE1, PE2, P1, and P2
● Level on PE1, PE2, P1, and P2
Procedure
Step 1 Enable IPv6 forwarding and configure an IPv6 address for each interface. The
following example uses the configuration of PE1. The configuration of other

(2020-04-09)
devices is similar to the configuration of PE1. For configuration details, see

[*HUAWEI] commit
[*PE1-GigabitEthernet1/0/0] ipv6 address 2001:db8:1::1 96
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
[*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.

(2020-04-09)
[~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.

--------------------------------------------------------------------------------
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-04-09)

--------------------------------

--------------------------------------------------------------------------------
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-04-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
10.1.1.2 4 65410 11 9 0 00:06:37 Established 1

# Configure PE1.
[~PE1] bgp 100

(2020-04-09)
[~PE1-bgp] quit
# Configure PE2.
[~PE2] bgp 100
[~PE2-bgp] quit
BGP peer relationships have been established successfully.
# 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

(2020-04-09)

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
RelayNextHop: 30::1:0:21 Interface: SRv6 BE
The preceding command output shows that the VPN route 22.22.22.22/32 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

(2020-04-09)
#
ipv6 bfd all-interfaces enable
#
#
undo shutdown
ipv6 enable
isis ipv6 enable 1
#
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

(2020-04-09)
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
#
ipv4-family
#
bfd
#
#
isis 1
is-level level-2
cost-style wide
network-entity 10.0000.0000.0003.00
#

(2020-04-09)

#
#
undo shutdown
ipv6 enable
isis ipv6 enable 1
#
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

(2020-04-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.24.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.
● PE1, PE2, and PE3 are in the same AS and run IS-IS to implement IPv6
● The PEs are Level-2 devices in area 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-74 Networking of VPN FRR configuration for L3VPNv4 over SRv6 BE

(2020-04-09)
Precautions
When configuring VPN FRR for IPv4 VPN 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.
interface.
device.
8. 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
● Area ID of each PE
● Level of each PE
● VPN instance name, RD, and RT on each PE
Procedure
following example uses the configuration of PE1. The configuration of other
devices is similar to the configuration of PE1. For configuration details, see
[*HUAWEI] commit

(2020-04-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.

(2020-04-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
-----------------------------

--------------------------------

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

(2020-04-09)

[*PE3] 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-04-09)
# Configure PE3.
[~PE3] bgp 100
[~PE3-bgp] quit


10.1.1.2 4 65410 1695 1704 0 24:37:20 Established 1

# Configure PE1.
[~PE1] bgp 100
[~PE1-bgp] quit
# Configure PE2.
[~PE2] bgp 100
[~PE2-bgp] quit
# Configure PE3.
[~PE3] bgp 100
[~PE3-bgp] quit

(2020-04-09)
# 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
[~PE3-bgp] quit
[~PE3] isis 1

(2020-04-09)
[~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] ipv4-family vpn-instance vpna
[~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
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.

(2020-04-09)
[~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
ip address 10.1.1.1 255.255.255.0
#
interface LoopBack1
ipv6 enable
isis ipv6 enable 1

(2020-04-09)
#
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
isis ipv6 enable 1
#
undo shutdown
ip address 10.2.1.1 255.255.255.0
#

(2020-04-09)
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
#
undo shutdown
ip address 10.3.1.1 255.255.255.0
#
interface LoopBack1
ipv6 enable

(2020-04-09)
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
#
ipv4-family unicast
network 22.22.22.22 255.255.255.255

(2020-04-09)

#
return
2.2.24.4 Example for Configuring EVPN L3VPNv4 over SRv6 BE

This section provides an example for configuring SRv6 BE to carry EVPN L3VPNv4
services.
On the network shown in Figure 2-75, 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-75 EVPN L3VPNv4 over SRv6 BE networking
interface.
device.
3. Configure an IPv4 L3VPN instance on each PE and bind the IPv4 L3VPN
instance to an access-side interface.
4. Establish a BGP EVPN peer relationship between PEs.
6. Configure SRv6 BE on PEs.

(2020-04-09)
Data Preparation
● L3VPN instance name: vpn1
● RD and RT values of the L3VPN instance: 100:1 and 1:1
Procedure
[*HUAWEI] commit
[*PE1] interface LoopBack 1
[*PE1-LoopBack1] ipv6 enable
[*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
[*P-LoopBack1] quit
[*P] commit
# Configure PE2.

(2020-04-09)
[~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.
[*PE2] bgp 100

(2020-04-09)
[*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
[~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

(2020-04-09)

# 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
After the configuration is complete, run the display bgp evpn peer command on
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::10 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.
[*PE2-segment-routing-ipv6-locator] opcode ::200 end-dt4 vpn-instance vpn1 evpn
[*PE2] isis 1
[*PE2-isis-1] quit
[*PE2] bgp 100

(2020-04-09)
[*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

path,

*> 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
------------------------------------------------------------------------------

Interface
10.1.1.0/24 Direct 0 0 D 10.1.1.1

10.1.1.1/32 Direct 0 0 D 127.0.0.1
10.1.1.255/32 Direct 0 0 D 127.0.0.1
10.2.1.0/24 IBGP 255 0 RD 2001:DB8:130::200 SRv6 BE
11.11.11.11/32 EBGP 255 0 RD 10.1.1.2
22.22.22.22/32 IBGP 255 0 RD 2001:DB8:130::200 SRv6 BE


(2020-04-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
Reply from 22.22.22.22: bytes=56 Sequence=1 ttl=253 time=127
ms
ms
ms
ms
ms

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::10 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
#
undo shutdown
ip address 10.1.1.1 255.255.255.0

(2020-04-09)
#
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
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-04-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
#
return

(2020-04-09)

#
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.24.5 Example for Configuring EVPN L3VPNv6 over SRv6 BE

This section provides an example for configuring SRv6 BE to carry EVPN L3VPNv6
services.
SRv6 BE path be deployed between PE1 and PE2 to carry EVPN L3VPNv6 services.
Figure 2-76 EVPN L3VPNv6 over SRv6 BE networking

(2020-04-09)
interface.
device.
Data Preparation
● L3VPN instance name: vpn1
● RD and RT values of the L3VPN instance: 100:1 and 1:1
Procedure
[*HUAWEI] commit
[*PE1] commit

# Configure PE1.
[~PE1] isis 1
[*PE1-isis-1] quit
[*PE1] commit
# Configure the P.
[~P] isis 1

(2020-04-09)

[*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.
[*PE1] bgp 100

(2020-04-09)
[*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] quit
[*PE1] commit
# Configure PE2.
[~PE2] bgp 100
[*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

(2020-04-09)

[*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


*> 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



(2020-04-09)


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
#
#
#
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

(2020-04-09)
#
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
#
sysname PE2
#
ipv6-family
#
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0003.00
#
#
#
undo shutdown

(2020-04-09)
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.24.6 Example for Configuring EVPN L3VPNv6 over SRv6 BE ECMP

This section provides an example for configuring EVPN L3VPNv6 over SRv6 BE
ECMP.
● PE1, PE2, P1, and P2 are in the same AS and run IS-IS to implement IPv6
● PE1, PE2, P1, and P2 are Level-2 devices in area 1.
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-77 EVPN L3VPNv6 over SRv6 BE ECMP networking

(2020-04-09)
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.
interface.
2. Enable IS-IS, configure a level, and specify a network entity on each device. In
addition, configure dynamic BFD for IPv6 IS-IS.
Data Preparation
● IPv6 address of each interface on PE1, PE2, P1, and P2

● Area ID of PE1, PE2, P1, and P2
● Level on PE1, PE2, P1, and P2

(2020-04-09)
Procedure
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

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
# Configure P1.
[~P1] bfd
[*P1-bfd] quit
[*P1] isis 1
[*P1-isis-1] quit

(2020-04-09)

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

--------------------------------------------------------------------------------
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-04-09)
-----------------------------

--------------------------------

--------------------------------------------------------------------------------
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] quit
[*PE1] commit
# Configure PE2.
[*PE2] bgp 100
[*PE2-bgp] quit
[*PE2] commit

(2020-04-09)
# 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
[~PE2-bgp] quit

(2020-04-09)

2001:DB8:11::2 4 65410 98 103 0 01:22:02 Established 2

# Configure PE1.
[~PE1] bgp 100
[*PE1-bgp] peer 3::3 as-number 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.
[*PE1-segment-routing-ipv6] encapsulation source-address 1::1
[*PE1] isis 1
[*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.

(2020-04-09)

[*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 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---


(2020-04-09)
0.00% packet loss

----End
Configuration Files
#
sysname PE1
#
ipv6-family
#
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
#
ipv4-family unicast
#
ipv6-family unicast
#

(2020-04-09)
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
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

(2020-04-09)

isis ipv6 enable 1
#
interface LoopBack1
ipv6 enable
isis ipv6 enable 1
#
return
#
sysname PE2
#
ipv6-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
#
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
#

(2020-04-09)

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
#
interface LoopBack1
ipv6 enable
#
bgp 65420
router-id 10.12.1.1
#
ipv4-family unicast
#
ipv6-family unicast
import-route direct
#
return

(2020-04-09)
2.2.24.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.
● PE1, PE2, and PE3 are in the same AS and run IS-IS to implement IPv6
● The PEs are Level-2 devices in area 1.
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-78 Networking of VPN FRR configuration for EVPN L3VPNv6 over SRv6
BE
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.

(2020-04-09)
interface.
2. Enable IS-IS, configure a level, and specify a network entity on each device.
4. Configure IPv6 VPN instances on PE1 and PE2, and connect PE1 and PE2 to
CEs.
8. Enable VPN FRR on PE1 and configure BFD to detect peer locator route
reachability to speed up VPN FRR switching.
Data Preparation
● IPv6 address of each PE interface
● Area ID of each PE
● Level of each PE
● VPN instance name, RD, and RT on each PE
Procedure
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

# Configure PE1.
[~PE1] isis 1
[*PE1-isis-1] quit

(2020-04-09)

# 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-04-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/-
# 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-04-09)
[*PE3-bgp] quit
[*PE3] commit
# Configure CE1.
[*CE1] bgp 65410
[~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

(2020-04-09)
[~PE3-bgp] quit

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

(2020-04-09)


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
[*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

(2020-04-09)
[*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-vpn-instance-vpna-af-ipv6] route-select delay 300
[~PE1] bgp 100
[~PE1-bgp] ipv6-family vpn-instance vpna
[~PE1-bgp-6-vpna] route-select delay 300
[~PE1-bgp-6-vpna] quit
[~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 :
BkNextHop : 30::1:0:21 BkInterface : SRv6 BE
BkLabel : NULL BkTunnelID : 0x0
BkPETunnelID : 0x0 BkIndirectID : 0x100016A

(2020-04-09)
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
--- 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

(2020-04-09)
#
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
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

(2020-04-09)
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 PE3
#
ipv6-family
#
#
isis 1
is-level level-2
cost-style wide
network-entity 10.0000.0000.0004.00
#
#
#
undo shutdown
ipv6 enable

(2020-04-09)

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
#
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
#

(2020-04-09)
undo shutdown
ipv6 enable
#
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.24.8 Example for Configuring EVPN VPWS over SRv6 BE

This section provides an example for configuring SRv6 BE to carry EVPN VPWSs.
SRv6 BE path be deployed between PE1 and PE2 to carry EVPN VPWSs.
Figure 2-79 EVPN VPWS over SRv6 BE networking

(2020-04-09)
1. Enable IPv6 forwarding on each router and configure an IPv6 address for each
interface.
router.
3. Configure EVPN VPWS and EVPL instances on each PE and bind the EVPL
instance to an access-side sub-interface.
Data Preparation
● EVPN instance name: evrf1
● RD and RT values of the EVPN instance: 100:1 and 1:1
Procedure
Step 1 Enable IPv6 forwarding on each router and configure an IPv6 address for each
of other routers is similar to the configuration of PE1. For configuration details,
[*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 configuration of other devices is similar to the
configuration of PE1. For configuration details, see Configuration Files in this
section.
# Configure PE1.
[~PE1] isis 1
[*PE1-isis-1] quit

(2020-04-09)
# Configure the P.
[~P] isis 1
[*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
-----------------------------

(2020-04-09)
--------------------------------

--------------------------------------------------------------------------------
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 FE80::3A5D:67FF:FE31:307 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
[*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-GigabitEthernet2/0/0.1] evpl instance 1
[*PE2] commit
# Configure PE1.
[~PE1] bgp 100
[*PE1-bgp] route-id 1.1.1.1
[*PE1-bgp] quit
[*PE1] commit
# Configure PE2.
[~PE2] bgp 100

(2020-04-09)

[*PE2-bgp] quit
[*PE2] commit
# Configure PE1.
[*PE1] bgp 100
[*PE1-bgp] quit
[*PE1-evpl-srv6-1] segment-routing ipv6 locator PE1
[*PE1] evpn vpn-instance evrf1 vpws
[*PE1-vpws-evpn-instance-evrf1] segment-routing ipv6 best-effort
[*PE1] commit
# Configure PE2.
[*PE2] bgp 100
[*PE2-bgp] quit
[*PE2-vpws-evpn-instance-evrf1] segment-routing ipv6 best-effort
[*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

(2020-04-09)
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 : 10.1.13.184
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 ID :
Out Interface :
Last Interface UP Timestamp : 2018-12-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
Relay IP Out-
Interface:GigabitEthernet1/0/0
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

(2020-04-09)
Route Type: 1 (Ethernet Auto-Discovery (A-D) route)

ESI: 0000.0000.0000.0000.0000, Ethernet Tag ID: 200
0000.0000.0000.0000.0000:200:
Remote-Cross route
From: 2001:DB8:3::3 (3.3.3.3)
Relay IP Out-
Ext-Community: RT <1 : 1>, EVPN L2 Attributes <MTU:1500 C:0 P:1 B:
0>
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
#

(2020-04-09)

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
#
#
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
#
#

(2020-04-09)
#
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0003.00
#
#
undo shutdown
ipv6 enable
isis ipv6 enable 1
#
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.24.9 Example for Configuring EVPN VPLS over SRv6 BE

This section provides an example for configuring SRv6 BE to carry EVPN E-LAN
services.
SRv6 BE path be deployed between PE1 and PE2 to carry EVPN E-LAN services.
Figure 2-80 EVPN VPLS over SRv6 BE networking

(2020-04-09)
interface.
device.
3. Configure an EVPN instance in BD mode on each PE and bind the EVPN
Data Preparation
● BD ID: 100
● Names of SID node route locators on PE1: PE1_ARG, PE1; names of SID node
route locators on PE2: PE2_ARG, PE2; dynamically generated opcodes
● Length of the SID node route locators PE1_ARG and PE2_ARG: 10 (as specified
in the args parameter)
Procedure
interface.
[*HUAWEI] commit

(2020-04-09)

[*PE1] commit
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-04-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

(2020-04-09)

[*PE2] commit

# 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] isis 1

(2020-04-09)

[*PE2-isis-1] quit
[*PE2-evpn-instance-evrf1] segment-routing ipv6 best-effort
[*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/128 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
#

(2020-04-09)

segment-routing ipv6 locator PE1_ARG unicast-locator PE1
#
bridge-domain 100
#
encapsulation source-address 2001:db8:1::1
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-04-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

(2020-04-09)

isis ipv6 enable 1
#
bgp 100
router-id 3.3.3.3
#
ipv4-family unicast
#
l2vpn-family evpn
policy vpn-target
#
#
return
2.2.24.10 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.
● 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-81 Inter-AS L3VPNv4 over SRv6 BE networking

(2020-04-09)
interface.
device.
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
● 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.

(2020-04-09)
[~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-GigabitEthernet1/0/0] commit
[~ASBR1-GigabitEthernet1/0/0] quit
[*ASBR1] interface loopback1
[*ASBR1-LoopBack1] isis ipv6 enable 1
[*ASBR1-LoopBack1] commit
[~ASBR1-LoopBack1] quit
# Configure ASBR2.
[~ASBR2] isis 10
# 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.

(2020-04-09)
# Configure PE1.
[*PE1] commit
# Configure PE2.
[*PE2] commit
# Assign an IP address to each interface on the CEs, as shown in Figure 2-81. For
# 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.

(2020-04-09)

[*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
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

(2020-04-09)
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] network 10:: 64
[*ASBR1-bgp-af-ipv6] quit
[*ASBR1-bgp] quit
[*ASBR1] ip ipv6-prefix p1 permit 10:: 64
[*ASBR1] route-policy rp1 permit node 10
[*ASBR1-route-policy] if-match ipv6 address prefix-list p1
[*ASBR1-route-policy] quit
[*ASBR1] isis 1
[*ASBR1-isis-1] import-route bgp route-policy rp1
[*ASBR1] commit
# Configure ASBR2.
[~ASBR2] bgp 200
[*ASBR2-bgp-af-ipv6] network 40:: 64
[*ASBR2-bgp] quit
[*ASBR2] ip ipv6-prefix p1 permit 40:: 64
[*ASBR2] route-policy rp1 permit node 10
[*ASBR2-route-policy] if-match ipv6 address prefix-list p1
[*ASBR2] isis 10
[*ASBR2-isis-10] 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-af-vpnv4] quit
[~PE1-bgp] quit
# Configure PE2.
[~PE2] bgp 200

(2020-04-09)

[~PE2-bgp] quit
on the PEs to check whether BGP peer relationships have been established
BGP peer relationships have been established successfully. The following example


PrefRcv
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
Run the display segment-routing ipv6 locator [ locator-name ] verbose

command to check SRv6 locator information. The following example uses the

---------------------------

ArgsLength : 0
AutoSIDPoolID: 8193
Total Locator(s): 1

-------------------------------------
SID : 10::1:0:20/128 FuncType : End.DT4

VPN Name : vpna VPN ID : 3
Total SID(s): 1

(2020-04-09)
[~CE1] ping -a 11.11.11.11 22.22.22.22
ms
ms
ms
ms
ms

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

(2020-04-09)
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
#
return
#
sysname ASBR1
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0002.00
import-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
peer 2020::2 enable
#
route-policy rp1 permit node 10
if-match ipv6 address prefix-list p1
#
ip ipv6-prefix p1 index 10 permit 10:: 64
#
return

(2020-04-09)

#
sysname ASBR2
#
isis 10
is-level level-1
cost-style wide
network-entity 10.0000.0000.0003.00
import-route bgp route-policy rp1
#
#
#
undo shutdown
ipv6 enable
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
peer 2020::1 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 PE2
#
ipv4-family
#
#
isis 10
is-level level-1
cost-style wide
network-entity 10.0000.0000.0004.00
#

(2020-04-09)
#
#
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
#
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

(2020-04-09)
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.25 Configuration Examples for SRv6 TE Policy

This section provides SRv6 TE Policy configuration examples.
2.2.25.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.
It is required that a bidirectional SRv6 TE Policy be deployed between PE1 and PE2
to carry L3VPNv4 services.
Figure 2-82 L3VPNv4 over SRv6 TE Policy networking

(2020-04-09)
interface.
device.
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
● Process ID of PE1, the P, and PE2
Procedure
Step 1 Enable the IPv6 forwarding capability and configure IPv6 addresses for interfaces.
# Configure PE1. The configuration of other devices is similar to the configuration
of PE1. For configuration details, see Configuration Files in this section.
[*HUAWEI] commit

# Configure PE1.
[~PE1] isis 1
[*PE1-isis-1] quit
# Configure the P.
[~P] isis 1

(2020-04-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
-----------------------------

--------------------------------

--------------------------------------------------------------------------------
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:FE41:13 10 A/-/-/-
2001::/96 GE1/0/0 Direct 10 D/-/L/-
2002::/96 GE1/0/0 FE80::3A92:6CFF:FE21:10 20 A/-/-/-
GE1/0/0 FE80::3A92:6CFF:FE41:13

(2020-04-09)

that PE.
# Configure PE1.
[*PE1] commit
# Configure PE2.
[*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

(2020-04-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-04-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. On PEs, configure VPN routes to carry the SID attribute.
# Configure PE1.
[*PE1] bgp 100
[*PE1-bgp-vpna] segment-routing ipv6 traffic-engineer best-effort
[~PE1-bgp] quit
[~PE1] isis 1
[~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::1 64 static 32
[*P-segment-routing-ipv6-locator] quit
[*P-segment-routing-ipv6] quit
[~P] isis 1
[*P-isis-1] segment-routing ipv6 locator as1
[*P-isis-1] commit
[~P-isis-1] quit
# Configure PE2.
[*PE2] bgp 100

(2020-04-09)

[~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
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::1:0:0/128 FuncType : End

Flavor : --

Flavor : PSP
Total SID(s): 2
---------------------------------

Flavor : --

Flavor : PSP
Total SID(s): 2
[~P] display segment-routing ipv6 local-sid end forwarding
---------------------------------

Flavor : --

Flavor : PSP

(2020-04-09)
Total SID(s): 2
# Configure PE1.
[~PE1-segment-routing-ipv6] segment-list list1
[*PE1-segment-routing-ipv6-segment-list-list1] index 5 sid ipv6 20::1:0:0
[*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 : Active State Change Time : 2019-02-17 11:45:30
Admin State : UP Traffic Statistics : Disable
Candidate-path Preference : 100

Path State : Active Path Type : Primary
Discriminator : 100 Binding SID : 10::100
Template ID :0
DelayTimerRemain : - Segment-List Count : 1
Segment-List : list1
Segment-List ID : 1 XcIndex :1
List State : UP DelayTimerRemain :-
Weight :1
SID :
20::1:0:0
30::1:0:0

(2020-04-09)
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
22.22.22.22/32 IBGP 255 0 RD 3::3 policy1
------------------------------------------------------------------------------

(2020-04-09)
Summary Count : 1
NextHop: 3::3 Neighbour: 3::3
IndirectID: 0x10000E0 Instance:

[~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
#
srv6-te-policy locator as1
segment-list list1
index 5 sid ipv6 20::1:0:0
srv6-te policy policy1 endpoint 3::3 color 101
binding-sid 10::100
segment-list list1
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0001.00
#
#
#

(2020-04-09)
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
#
#
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-04-09)
undo shutdown
ipv6 enable
isis ipv6 enable 1
#
interface LoopBack1
ipv6 enable
isis ipv6 enable 1
#
return
#
sysname PE2
#
ipv4-family
tnl-policy p1
#
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
isis ipv6 enable 1
#
bgp 100
router-id 2.2.2.2
#
ipv4-family unicast
#
ipv6-family unicast

(2020-04-09)
#
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
network 22.22.22.22 255.255.255.255
#
return

(2020-04-09)
2.2.25.2 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.
SRv6 TE Policy be deployed between PE1 and PE2 to carry EVPN L3VPNv4 services.
interface.
device.

(2020-04-09)
Data Preparation
● Area number of PE1, the P, and PE2
● IS-IS level of PE1, the P, and PE2
Procedure
interface.
[*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

(2020-04-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
# Configure PE1.
[*PE1] bgp 100
[*PE1-bgp-vpna] advertise l2vpn evpn
[*PE1-bgp] quit
[*PE1] commit
# Configure PE2.

(2020-04-09)

[*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
[~PE1-bgp] quit
# Configure CE2.
[*CE2] bgp 65420
[*CE2-bgp] quit
[*CE2] commit
# Configure PE2.
[~PE2] bgp 100
[~PE2-bgp] quit

(2020-04-09)


PrefRcv
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
[*PE2-bgp] quit
[*PE2] commit


2001:DB8:3::3 4 100 49 49 0 00:30:41 Established 2
# Configure PE1.
[~PE1-segment-routing-ipv6] encapsulation source-address 2001:DB8:1::1
[*PE1] bgp 100
[~PE1-bgp-af-evpn] quit
[*PE1-bgp-vpna] segment-routing ipv6 traffic-engineer best-effort evpn
[*PE1-bgp-vpna] segment-routing ipv6 locator PE1 evpn

(2020-04-09)
[~PE1-bgp] quit
[~PE1] isis 1
[~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::10 64 static 32
[~P] isis 1
[*P-isis-1] segment-routing ipv6 locator P
[*P-isis-1] commit
[~P-isis-1] quit
# Configure PE2.
[*PE2] bgp 100
[*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::10 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::1:0:1E/128 FuncType : End

Flavor : --

(2020-04-09)
SID : 2001:DB8:100::1:0:1F/128 FuncType : End

Flavor : PSP
Total SID(s): 2
---------------------------------
SID : 2001:DB8:130::1:0:0/128 FuncType : End

Flavor : --

Flavor : PSP
Total SID(s): 2
---------------------------------

Flavor : --
LocatorName: P LocatorID: 1

Flavor : PSP
Total SID(s): 2

# Configure PE1.
[*PE1-segment-routing-ipv6-segment-list-list1] index 5 sid ipv6 2001:DB8:120::1:0:0
[~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.
[*PE2-segment-routing-ipv6-segment-list-list1] index 10 sid ipv6 2001:DB8:100::1:0:1E

(2020-04-09)
Color : 101 Endpoint : 2001:DB8:3::3
TunnelId :1 Binding SID : 2001:DB8:100::450

Discriminator : 100 Binding SID : 2001:DB8:100::450
Template ID :0
Weight :1
SID :
2001:DB8:120::1:0:0
2001:DB8:130::1:0:0

# Configure PE1.
[*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

(2020-04-09)
After the configuration is complete, run the display ipv6 routing-table vpn-
TE Policy.
route
------------------------------------------------------------------------------

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
route
------------------------------------------------------------------------------
Summary Count : 1
NextHop: 2001:DB8:3::3 Neighbour: 2001:DB8:3::3
Label: NULL QoSInfo: 0x0
IndirectID: 0x10000DF Instance:
RelayNextHop: :: Interface: policy1

[~CE1] ping -a 11.1.1.1 22.2.2.2

0.00% packet loss
----End

(2020-04-09)
Configuration Files
#
sysname PE1
#
ipv4-family
tnl-policy p1 evpn
#
srv6-te-policy locator PE1
segment-list list1
index 5 sid ipv6 2001:DB8:120::1:0:0
index 10 sid ipv6 2001:DB8:130::1:0:0
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
#
#
#
undo shutdown
ip address 10.11.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
#
import-route direct
segment-routing ipv6 traffic-engineer best-effort evpn
#
l2vpn-family evpn
peer 2001:DB8:3::3 route-policy p1 import

(2020-04-09)

#
#
tunnel-policy p1
#
return
#
sysname P
#
locator P ipv6-prefix 2001:DB8:120::10 64 static 32
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0002.00
#
segment-routing ipv6 locator P
#
#
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 evpn
#
segment-list list1
index 5 sid ipv6 2001:DB8:120::1:0:0
index 10 sid ipv6 2001:DB8:100::1:0:1E
segment-list list1
#
isis 1

(2020-04-09)
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
#
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

(2020-04-09)
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.25.3 Example for Configuring EVPN L3VPNv6 over SRv6 TE Policy

L3VPNv6 services.
SRv6 TE Policy be deployed between PE1 and PE2 to carry EVPN L3VPNv6 services.

(2020-04-09)
interface.
device.
Data Preparation

Procedure
interface.

(2020-04-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

(2020-04-09)

output on PE1.

--------------------------------------------------------------------------------
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 CE1.
[*CE1-LoopBack1] ipv6 address 2001:DB8:111::111 128
[*CE1] bgp 65410

(2020-04-09)

[*CE1-bgp] quit
[*CE1] commit
# Configure PE1.
[~PE1] bgp 100
[~PE1-bgp] quit
# Configure CE2.
[*CE2-LoopBack1] ipv6 address 2001:DB8:222::222 128
[*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

(2020-04-09)

[*PE1-bgp] quit
[*PE1] commit
# Configure PE2.
[~PE2] bgp 100
[*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-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

(2020-04-09)

[*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
[~PE2-isis-1] quit

---------------------------

ArgsLength : 0
AutoSIDPoolID: -
Total Locator(s): 1

---------------------------------

Flavor : --

Flavor : PSP
Total SID(s): 2
---------------------------------

Flavor : --

(2020-04-09)

Flavor : PSP
Total SID(s): 2
---------------------------------

Flavor : --

Flavor : PSP
Total SID(s): 2
# Configure PE1.
# Configure PE2.


(2020-04-09)

Template ID :0
Weight :1
SID :
2001:DB8:120::1:0:0
2001:DB8:130::1:0:0

# Configure PE1.
[*PE1] bgp 100
[*PE1-bgp] quit
# Configure PE2.
[*PE2] bgp 100
[*PE2-bgp] quit
After the configuration is complete, run the display ipv6 routing-table vpn-
TE Policy.

(2020-04-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

(2020-04-09)
--- 2001:DB8:222::222 ping statistics---

0.00% packet loss
----End
Configuration Files
#
sysname PE1
#
ipv6-family
tnl-policy p1 evpn
#
segment-list list1
index 5 sid ipv6 2001:DB8:120::1:0:0
index 10 sid ipv6 2001:DB8:130::1:0:0
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
#

(2020-04-09)

import-route direct
#
l2vpn-family evpn
#
#
tunnel-policy p1
#
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
#
ipv6-family
tnl-policy p1 evpn
#

(2020-04-09)

segment-list list1
index 5 sid ipv6 2001:DB8:120::1:0:0
index 10 sid ipv6 2001:DB8:100::1:0:0
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
#
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

(2020-04-09)

#
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
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.25.4 Example for Configuring EVPN VPWS over SRv6 TE Policy (Manual
Configuration)
VPWSs.
SRv6 TE Policy be deployed between PE1 and PE2 to carry EVPN VPWSs.
Figure 2-85 EVPN VPWS over SRv6 TE Policy networking

(2020-04-09)
interface.
device.
4. Configure EVPN VPWS and EVPL instances on each PE and bind the EVPL
Data Preparation

Procedure
interface.

(2020-04-09)

of PE1. For configuration details, see "Configuration Files" in this section.
[*HUAWEI] commit
[*PE1] commit
configuration of PE1. For configuration details, see "Configuration Files" in this
section.
# 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

(2020-04-09)
[*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.
[*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
[*CE1] interface gigabitethernet 1/0/0
[*CE1-GigabitEthernet1/0/0] portswitch
[*CE1-GigabitEthernet1/0/0] undo shutdown

(2020-04-09)
[*CE1-GigabitEthernet1/0/0] port link-type access

[*CE1-GigabitEthernet1/0/0] port default vlan 1
[*CE1-GigabitEthernet1/0/0] commit
[~CE1-GigabitEthernet1/0/0] quit
# Configure CE2.
<CE2> system-view
[~CE2] vlan 1
[*CE2-vlan1] quit
[*CE2] interface gigabitethernet 1/0/0
[*CE2-GigabitEthernet1/0/0] portswitch
[*CE2-GigabitEthernet1/0/0] undo shutdown
[*CE2-GigabitEthernet1/0/0] port link-type access
[*CE2-GigabitEthernet1/0/0] port default vlan 1

# Configure PE1.
[~PE1] bgp 100
[*PE1-bgp] quit
[*PE1] commit
# Configure PE2.
[~PE2] bgp 100
[*PE2-bgp] quit
[*PE2] commit


2001:DB8:3::3 4 100 40 40 0 00:30:41 Established 2
# Configure PE1.

(2020-04-09)
[*PE1] bgp 100

[~PE1-bgp] quit
[~PE1] evpl instance 1 srv6-mode
[*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] commit
[~P-isis-1] quit
# Configure PE2.
[*PE2] bgp 100
[~PE1-bgp] quit
[~PE2] evpl instance 1 srv6-mode
[*PE2-vpws-evpn-instance-evrf1] segment-routing ipv6 traffic-engineer best-effort
[*PE2] commit
[~PE2] isis 1
[~PE2-isis-1] quit


---------------------------

ArgsLength : 0
AutoSIDPoolID: -

(2020-04-09)
Total Locator(s): 1

---------------------------------

Flavor : --

Flavor : PSP
Total SID(s): 2
---------------------------------

Flavor : --

Flavor : PSP
Total SID(s): 2
---------------------------------

Flavor : --

Flavor : PSP
Total SID(s): 2

# Configure PE1.
# Configure PE2.

(2020-04-09)

[*PE2-segment-routing-ipv6-segment-list-list1] index 10 sid ipv62001:DB8:100::1:0:0

Policy State : Active State Change Time : 2020-03-03
02:32:11

Template ID :0
Weight :1
SID :
2001:DB8:120::1:0:0
2001:DB8:130::1:0:0
# 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.

(2020-04-09)
[*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
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.



(2020-04-09)
*> 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.

0000.0000.0000.0000.0000:200:
From: 2001:DB8:3::3 (3.3.3.3)
Relay IP Out-
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
0000.0000.0000.0000.0000:200:
Remote-Cross route
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
#

(2020-04-09)

tnl-policy p1
#
#
segment-list list1
index 5 sid ipv6 2001:DB8:120::1:0:0
index 10 sid ipv6 2001:DB8:130::1:0:0
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
#
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-04-09)
tunnel-policy p1
#
#
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
#
tnl-policy p1
#
#
segment-list list1
index 5 sid ipv6 2001:DB8:120::1:0:0
index 10 sid ipv6 2001:DB8:100::1:0:0
segment-list list1
#
isis 1

(2020-04-09)
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
#
#
tunnel-policy p1
#
#
return
sysname CE1
#
vlan batch 1
#
portswitch
undo shutdown
port link-type access
port default vlan 1
#
return
sysname CE2
#
vlan batch 1
#

(2020-04-09)
portswitch
undo shutdown
port default vlan 1
#
return
2.2.25.5 Example for Configuring EVPN VPLS over SRv6 TE Policy (Manual
Configuration)
E-LAN services.
SRv6 TE Policy be deployed between PE1 and PE2 to carry EVPN E-LAN services.
Figure 2-86 EVPN VPLS over SRv6 TE Policy networking
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.
interface.
device.
3. Configure an EVPN instance in BD mode on each PE and bind the EVPN

(2020-04-09)
Data Preparation
● BD ID: 100
● Names of SID node route locators on PE1: PE1_ARG, PE1; names of SID node
route locators on PE2: PE2_ARG, PE2; dynamically generated opcodes
● Length of the SID node route locators PE1_ARG and PE2_ARG: 10 (as specified
in the args parameter)
Procedure
interface.
[*HUAWEI] commit
[*PE1] commit
section.
# Configure PE1.
[~PE1] isis 1
[*PE1-isis-1] quit
# Configure the P.
[~P] isis 1

(2020-04-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
-----------------------------

--------------------------------

--------------------------------------------------------------------------------
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/-/-/-

(2020-04-09)
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
# Configure PE1.
[~PE1] bgp 100
[*PE1-bgp] quit
[*PE1] commit
# Configure PE2.
[~PE2] bgp 100
[*PE2-bgp] quit
[*PE2] commit

(2020-04-09)


PrefRcv
2001:DB8:3::3 4 100 31 34 0 00:18:39 Established 1
# Configure PE1.
[*PE1] isis 1
[*PE1-isis-1] quit
[*PE1-evpn-instance-evrf1] segment-routing ipv6 traffic-engineer best-effort
[*PE1] commit
# Configure the P.
[~P] isis 1
[*P-isis-1] commit
[~P-isis-1] quit
# Configure PE2.
[*PE2] isis 1
[*PE2-isis-1] quit
[*PE2-evpn-instance-evrf1] segment-routing ipv6 traffic-engineer best-effort
[*PE2] commit


(2020-04-09)

---------------------------

IPv6Prefix : 2001:DB8:11:: PrefixLength: 64
ArgsLength : 0
AutoSIDPoolID: 8195
LocatorName : PE1_ARG LocatorID : 6

IPv6Prefix : 2001:DB8:12:: PrefixLength: 64
ArgsLength : 10
AutoSIDPoolID: 8196
AutoSIDEnd : 2001:DB8:12:0:FFFF:FFFF:FFFF:FC00
Total Locator(s): 2

---------------------------------

Flavor : --

Flavor : PSP
Total SID(s): 2
---------------------------------

Flavor : --

Flavor : PSP
Total SID(s): 2
---------------------------------

Flavor : --

Flavor : PSP
Total SID(s): 2
# Configure PE1.

(2020-04-09)

# Configure PE2.

TunnelId : 8193 Binding SID : 2001:DB8:11::450
11:50:30

Template ID :0
Weight :1
SID :
2001:DB8:120::1:0:0
2001:DB8:21::1:0:1E
# Configure PE1.

(2020-04-09)

[*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.
[~CE1] interface gigabitethernet1/0/0
[~CE1-GigabitEthernet1/0/0] undo shutdown
[*CE1] interface gigabitethernet1/0/0.1
[*CE1] commit
# Configure CE2.
[~CE2] interface gigabitethernet1/0/0
[~CE2-GigabitEthernet1/0/0] undo shutdown
[*CE2] interface gigabitethernet1/0/0.1
[*CE2] 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
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:0:0/118 FuncType : End.DT2M

(2020-04-09)

LocatorName : PE1_ARG LocatorID: 6
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::1:0:5C/128 FuncType : End.DT2U

LocatorName : PE1 LocatorID: 5
Total SID(s): 1
output shows the EVPN routes sent from the peer end. The following example

path,

Network(EthTagId/MacAddrLen/MacAddr/IpAddrLen/IpAddr)
NextHop
*>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
Network(EthTagId/MacAddrLen/MacAddr/IpAddrLen/IpAddr)
NextHop
*> 0:48:38c2-6721-0300:0:0.0.0.0 0.0.0.0
*i 2001:DB8:3::3
*> 0:48:38c2-6761-0300:0:0.0.0.0 0.0.0.0

Network(EthTagId/IpAddrLen/OriginalIp)
NextHop
*> 0:32:1.1.1.1 127.0.0.1
*>i 0:32:3.3.3.3 2001:DB8:3::3
Network(EthTagId/IpAddrLen/OriginalIp)
NextHop
*> 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)

(2020-04-09)

Relay IP Out-
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 IP Out-
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 can ping each other. For example:
[~CE1] ping 10.1.1.2
ms
ms
ms
ms
ms

0.00% packet loss
----End
Configuration Files

(2020-04-09)
#
sysname CE1
#
undo shutdown
#
undo shutdown
vlan-type dot1q 10
ip address 10.1.1.1 255.255.255.0
#
return
#
sysname PE1
#
tnl-policy p1
#
bridge-domain 100
#
locator PE1 ipv6-prefix 2001:DB8:11:: 64 static 32
locator PE1_ARG ipv6-prefix 2001:DB8:12:: 64 static 32 args 10
segment-list list1
index 5 sid ipv6 2001:DB8:120::1:0:0
index 10 sid ipv6 2001:DB8:21::1:0:1E
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
#
rewrite pop single
bridge-domain 100
#
interface LoopBack1
ipv6 enable
ip address 1.1.1.1 255.255.255.255
isis ipv6 enable 1

(2020-04-09)
#
bgp 100
router-id 1.1.1.1
#
ipv4-family unicast
#
l2vpn-family evpn
policy vpn-target
#
#
tunnel-policy p1
#
#
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
ip address 2.2.2.2 255.255.255.255
isis ipv6 enable 1
#
return

#
sysname PE2
#

(2020-04-09)
tnl-policy p1
#
bridge-domain 100
#
locator PE2 ipv6-prefix 2001:DB8:21:: 64 static 32
locator PE2_ARG ipv6-prefix 2001:DB8:22:: 64 static 32 args 10
segment-list list1
index 5 sid ipv6 2001:DB8:120::1:0:0
index 10 sid ipv6 2001:DB8:11::1:0:1E
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
router-id 3.3.3.3
#
ipv4-family unicast
#
l2vpn-family evpn
policy vpn-target
#
#
tunnel-policy p1

(2020-04-09)
#
#
return
#
sysname CE2
#
undo shutdown
#
undo shutdown
vlan-type dot1q 10
ip address 10.1.1.2 255.255.255.0
#
return
2.2.25.6 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.
It is required that a bidirectional SRv6 TE Policy be deployed between PE1 and PE2
to carry L3VPNv4 services. In this example, PE2 is the egress of the SRv6 TE Policy,
Figure 2-87 Networking for L3VPNv4 over SRv6 TE Policy egress protection

(2020-04-09)
interface.
device.
9. Configure egress protection on PE3.
Data Preparation
● IPv6 address of each interface on PE1, the P, PE2, and PE3
● Process ID of PE1, the P, PE2, and PE3
● Level on PE1, the P, PE2, and PE3
● VPN instance name, RD, and RT on PE1, PE2, and PE3
Procedure
Step 1 Enable IPv6 forwarding and configure IPv6 addresses for interfaces.
[*HUAWEI] commit

# Configure PE1.
[~PE1] isis 1
[*PE1-isis-1] quit

(2020-04-09)
# Configure the P.
[~P] isis 1
[*P-isis-1] quit
[~P-LoopBack1] quit
# Configure PE2.
[~PE2] isis 1
[*PE2-isis-1] quit
# Configure PE3.
[~PE3] isis 1
[*PE3-isis-1] quit

output on PE1.

(2020-04-09)

--------------------------------------------------------------------------------
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/-/-/-
10::/64 - - 0 A/-/L/-
20::/64 GE1/0/0 FE80::3AC2:67FF:FE31:300 10 A/-/-/-
30::/64 GE1/0/0 FE80::3AC2:67FF:FE41:307 10 A/-/-/-
40::/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/-/-/-
GE1/0/0 FE80::3AC2:67FF:FE41:307
2003::/96 GE1/0/0 FE80::3AC2:67FF:FE31:300 20 A/-/-/-
GE1/0/0 FE80::3AC2:67FF:FE61:302
2004::/96 GE1/0/0 FE80::3AC2:67FF:FE41:307 20 A/-/-/-
GE1/0/0 FE80::3AC2:67FF:FE61:302
that PE.
# Configure PE1.
[*PE1] commit
# Configure PE2.

(2020-04-09)
[*PE2] commit
# Configure PE3.
[*PE3] 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

(2020-04-09)
# 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
[~PE1-bgp] quit
# Configure PE2.
[~PE2] bgp 100

(2020-04-09)
[~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.
[*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

(2020-04-09)
[*P-segment-routing-ipv6] locator as1 ipv6-prefix 20::1 64 static 32

[~P] isis 1
[*P-isis-1] segment-routing ipv6 locator as1
[*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
[~PE3-bgp] quit
[~PE3] isis 1
[~PE3-isis-1] quit


---------------------------

ArgsLength : 0

(2020-04-09)
Total Locator(s): 1

---------------------------------

Flavor : --

Flavor : PSP
Total SID(s): 2
---------------------------------

Flavor : --

Flavor : PSP
Total SID(s): 2
---------------------------------

Flavor : --

Flavor : PSP
Total SID(s): 2

# Configure PE1.
# Configure PE2.

(2020-04-09)


Template ID :0
Weight :1
SID :
20::1:0:0
30::1:0:0

# Configure PE1.
[*PE1] bgp 100
[*PE1-bgp] quit
# Configure PE2.

(2020-04-09)
[*PE2] bgp 100
[*PE2-bgp] quit

TE Policy.

------------------------------------------------------------------------------

10.2.1.0/24 IBGP 255 0 RD 3::3 policy1
22.22.22.22/32 IBGP 255 0 RD 3::3 policy1
------------------------------------------------------------------------------
Summary Count : 1
Step 9 Configure egress protection on PE3.
# Configure PE3.
[*PE3-segment-routing-ipv6-locator] opcode ::999 end-m mirror-locator 30::1 64
[*PE3] commit
# Configure the P.

(2020-04-09)
[~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
After the configuration is complete, run the display segment-routing ipv6 local-
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}
Flags: D-Direct, A-Added to URT, L-Advertised in LSPs, S-IGP
Shortcut,

[~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

(2020-04-09)
Run the ping command again. The command output shows that CEs belonging to
the same VPN can still ping each other. For example:
[~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
#
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
#
#
#
undo shutdown
ip address 10.1.1.1 255.255.255.0
#
undo shutdown
ipv6 enable
isis ipv6 enable 1
#

(2020-04-09)
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
#
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0002.00
#
ipv6 frr
#
#
undo shutdown
ipv6 enable
isis ipv6 enable 1
#
undo shutdown
ipv6 enable

(2020-04-09)
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
#
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
#
undo shutdown
ipv6 enable
isis ipv6 enable 1
#
interface LoopBack1
ipv6 enable
isis ipv6 enable 1
#
bgp 100
router-id 2.2.2.2

(2020-04-09)

#
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 ::999 end-m mirror-locator 30::1 64
#
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
ip address 10.3.1.1 255.255.255.0
#
undo shutdown

(2020-04-09)
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
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

(2020-04-09)
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.25.7 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.
● 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-88 Inter-AS L3VPNv4 over SRv6 TE Policy networking

(2020-04-09)
interface.
device.
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. Configure 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
● 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.

(2020-04-09)
[~PE1] isis 1
[*PE1-isis-1] quit
# Configure ASBR1.
[~ASBR1] isis 1
# Configure ASBR2.
[~ASBR2] isis 10
# Configure PE2.
[~PE2] isis 10
[*PE2-isis-10] quit


(2020-04-09)
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.
[*PE2] commit
# Assign an IP address to each interface on the CEs, as shown in Figure 2-88. For
# Configure CE1.

(2020-04-09)
[*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

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

(2020-04-09)

[*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
[*PE2] isis 10
[*PE2-isis-10] segment-routing ipv6 locator as1 auto-sid-disable
[~PE2-isis-10] quit

---------------------------

ArgsLength : 0
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
[~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::1 64 static 32

(2020-04-09)
[*ASBR1-segment-routing-ipv6-locator] opcode ::200 end-x interface GigabitEthernet1/0/0 nexthop

2001::1
[*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] 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] peer 2020::2 enable
[*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::1 64 static 32
[*ASBR2-segment-routing-ipv6-locator] opcode ::100 end-x interface GigabitEthernet1/0/0 nexthop
2002::2
[*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] commit
[~ASBR2-isis-10] quit
[~ASBR2] bgp 200
[*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] peer 2020::1 enable
[*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 the inter-AS static End.X SID allocated to the ASBR. 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

(2020-04-09)
Nexthop : 2020::2
Out Interface : GigabitEthernet2/0/0
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
[~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.

(2020-04-09)
[*PE1-segment-routing-ipv6-segment-list-list1] index 5 sid ipv6 10::100

# Configure PE2.
[*PE2-segment-routing-ipv6-segment-list-list1] index 5 sid ipv6
40::200
[*PE2-segment-routing-ipv6-segment-list-list1] index 10 sid ipv6
30::200

11:16:30

Template ID :0
Weight :1
SID :
10::100
20::100
30::100

(2020-04-09)
# Configure PE1.
[*PE1] bgp 100
[*PE1-bgp] quit
# Configure PE2.
[*PE2] bgp 200
[*PE2-bgp] quit

TE Policy.
route
------------------------------------------------------------------------------

Interface
10.1.1.0/24 Direct 0 0 D 10.1.1.1

10.1.1.1/32 Direct 0 0 D 127.0.0.1
10.1.1.255/32 Direct 0 0 D 127.0.0.1
10.2.1.0/24 EBGP 255 0 RD 4::4 policy1
11.11.11.11/32 EBGP 255 0 RD 10.1.1.2
22.22.22.22/32 EBGP 255 0 RD 4::4 policy1

(2020-04-09)

route
------------------------------------------------------------------------------
Summary Count : 1
Protocol: EBGP Process ID: 0
RelayNextHop: :: Interface: policy1

[~CE1] ping -a 11.11.11.11 22.22.22.22
ms
ms
ms
ms
ms

0.00% packet loss
----End
Configuration Files
#
sysname PE1
#
ipv4-family
tnl-policy p1
#
opcode ::100 end-x interface GigabitEthernet1/0/0 nexthop 2001::2 no-
psp
segment-list list1
index 5 sid ipv6 10::100
srv6-te policy policy1 endpoint 4::4 color

(2020-04-09)
101
binding-sid 10::1000
segment-list list1
#
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
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
#
import-route direct
segment-routing ipv6 traffic-engineer
#
#
tunnel-policy p1
#
return
#
sysname ASBR1
#
opcode ::200 end-x interface GigabitEthernet1/0/0 nexthop 2001::1 no-psp
#

(2020-04-09)
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
#
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 10:: 64
import-route direct
peer 2020::2 enable
#
return
#
sysname ASBR2
#
opcode ::100 end-x interface GigabitEthernet1/0/0 nexthop 2002::2
#
isis 10
is-level level-1
cost-style wide
network-entity 10.0000.0000.0003.00
import-route bgp
#
#
#
undo shutdown
ipv6 enable

(2020-04-09)
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 2020:: 96
import-route direct
peer 2020::1 enable
#
return
#
sysname PE2
#
ipv4-family
tnl-policy p1
#
opcode ::200 end-x interface GigabitEthernet1/0/0 nexthop
2002::1
segment-list list1
srv6-te policy policy1 endpoint 1::1 color
101
binding-sid 40::1000
segment-list list1
#
isis 10
is-level level-1
cost-style wide
network-entity 10.0000.0000.0004.00
#
#

(2020-04-09)
#
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
peer 1::1 connect-interface
LoopBack1
#
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
#
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

(2020-04-09)

#
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-04-09)
New IP Technologies 3 EVPN
3 EVPN
3.1 EVPN
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-04-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. In addition, EVPN enables PEs to use locally stored
MAC addresses to respond to ARP Request messages from connected sites,
minimizing the number of broadcast ARP Request messages.
3.1.2 Understanding EVPN
EVPN Networking
An EVPN has a similar network structure to a BGP/MPLS IP VPN. In EVPN
networking, CEs at each site connect to PEs on the ISP backbone network. These
PEs have EVPN instances configured and establish BGP EVPN peer relationships
and MPLS/SR tunnels with each other. Unlike a BGP/MPLS IP VPN, an EVPN has its
sites on Layer 2 networks. Therefore, the PEs learn MAC addresses but not IP
routes from the CEs, and then advertise the learned MAC addresses to other sites
using EVPN routes.
In EVPN networking, a CE can be single-homed to one PE or multi-homed to
several PEs. On the network shown in Figure 3-1, CE1, CE2, and CE4 use the
single-homing mode, whereas CE3 uses the multi-homing mode. Load balancing
can be implemented in CE multi-homing networking.
EVPN defines Ethernet segment identifiers (ESIs) to identify links between PEs and
CEs. Links connecting multiple PEs to the same CE have the same ESI, and links
connecting multiple PEs to different CEs have different ESIs. PEs exchange routes
that carry ESIs, so that a PE can discover other PEs connecting to the same CE as
itself.

(2020-04-09)
Figure 3-1 EVPN networking
A PE can use both IPv4 and IPv6 addresses to establish EVPN peer relationships with other
PEs. An MPLS, VXLAN or SR tunnel can be established between IPv4 EVPN peers to carry
services, while an SRv6 tunnel needs to be established between IPv6 EVPN peers to carry
services. The EVPN routes that carry the SID can be sent only to IPv6 EVPN peers. The EVPN
routes that do not carry the SID can be sent 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), called the EVPN NLRI. EVPN
NLRI includes the following types of EVPN routes:
● Ethernet A-D route: carries the reachability of the local PE to the MAC
addresses of its connected sites. PEs advertise Ethernet A-D routes after
establishing a BGP EVPN peer relationship. Ethernet A-D routes can be
classified as Ethernet A-D Per ES routes or Ethernet A-D Per EVI routes.
Ethernet A-D Per ES routes are used in fast convergence, redundancy mode,
and split horizon scenarios. Ethernet A-D Per EVI routes are used in alias
scenarios. Figure 3-2 shows the NLRI packet format of Ethernet A-D routes.
Figure 3-2 EVPN NLRI specific to the Ethernet A-D route

(2020-04-09)
The meanings of fields are as follows:

– Route Distinguisher: In Ethernet A-D Per ES routes, the value of this field
is the source IP address configured for a PE, such as X.X.X.X:0. In Ethernet
A-D Per EVI routes, the value of this field is the RD value configured for
an EVPN instance.
– Ethernet Segment Identifier: Uniquely identifies the connection between
a PE and a CE.
– Ethernet Tag ID: In Ethernet A-D Per ES routes, the value of this field is
all Fs. In Ethernet A-D Per EVI routes, this field identifies a sub-broadcast
domain in an ES. If the value of this field is all 0s, the EVI has only one
broadcast domain.
– MPLS Label: In Ethernet A-D Per ES routes, the value of this field is all 0s.
In Ethernet A-D Per EVI routes, this field indicates the MPLS label used
for EVPN unicast traffic load balancing.
According to the standard, the MPLS Label field in a per-ES route is all 0s. By
default, the value of the MPLS Label field in a per-ES route on the current device
is equal to an ESI label value. After the peer esad-route-compatible enable
command is run, the MPLS Label field is changed to all 0s.
● MAC/IP advertisement route: carries EVPN instance RD, ESI, and label
information on the local PE. A PE uses MAC advertisement routes to advertise
unicast MAC address reachability information to other PEs. For details, see
Unicast MAC Address Transmission. Figure 3-3 shows the format of an
EVPN NLRI specific to the MAC/IP advertisement route. In addition to NLRI,
MAC/IP Advertisement route contains the RT of EVPN instance and next-hop
address.
Figure 3-3 EVPN NLRI specific to the MAC/IP advertisement route
The description of each field is as follows:

– Route Distinguisher: an 8-byte field representing the RD value of an
EVPN instance.

(2020-04-09)
– Ethernet Segment Identifier: a 10-byte field that identifies links between

PEs and CEs.
– Ethernet Tag ID: The value of this field is all zeros except that it is the
same as the local service ID in an EVPN VPWS scenario or the same as
the BD tag value in BD EVPN access in VLAN-aware mode.
– MAC Address Length: a 1-byte field representing the length of the MAC
address advertised by the route.
– MAC Address: a 6-byte field representing the MAC address advertised by
the route.
– IP Address Length: a field representing the mask length of the host IP
address advertised by the route.
– IP Address: a field representing the host IP address advertised by the
route.
– MPLS Label1: a field representing the label used for Layer 2 service traffic
forwarding.
– MPLS Label2: a field representing the label used for Layer 3 service traffic
forwarding.
This type of route plays the following roles on the control plane:
– MAC address advertisement
To implement Layer 2 service interworking between hosts connected to
different PEs, the two PEs need to learn host MAC addresses from each
other. The PEs function as BGP EVPN peers to exchange MAC/IP routes so
that they can obtain the host MAC addresses. The MAC Address Length
and MAC Address fields identify the MAC address of a host.
– ARP advertisement
A MAC/IP advertisement route can carry both the MAC and IP addresses
of a host, and therefore can be used to advertise ARP entries between
PEs. The MAC Address and MAC Address Length fields identify the MAC
address of the host, whereas the IP Address and IP Address Length fields
identify the IP address of the host. This type of MAC/IP route is called the
ARP route.
– IP route advertisement
To implement Layer 3 service interworking between IPv4 hosts connected
to different 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 exchange MAC/IP advertisement routes to advertise host IPv4
addresses to each other. The IP Address Length and IP Address fields
carried in the MAC/IP advertisement routes indicate the destination
addresses of host IP routes, and the MPLS Label2 field must carry a label
used for Layer 3 service traffic forwarding. In this case, MAC/IP
advertisement routes are also called Integrate Routing and Bridge (IRB)
routes.
An ARP route carries host MAC and IP addresses and a Layer 2 VNI. An IRB route
carries host MAC and IP addresses, a Layer 2 VNI, and a Layer 3 VNI. Therefore,
IRB routes carry ARP routes and can be used to advertise IP routes as well as ARP
entries.

(2020-04-09)
– Host ND information advertisement

A MAC/IP advertisement route can carry both the MAC and IPv6
addresses of a host, and therefore can be used to advertise ND entries
between PEs. The MAC Address and MAC Address Length fields identify
the MAC address of the host, whereas the IPv6 Address and IPv6 Address
Length fields identify the IPv6 address of the host. This type of MAC/IP
route is called the ND route.
– IPv6 route advertisement
To implement Layer 3 service interworking between IPv6 hosts connected
to different 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 exchange MAC/IP advertisement routes to advertise host IPv4
addresses to each other. The IP Address Length and IP Address fields
carried in the MAC/IP advertisement routes indicate the destination
addresses of host IPv6 routes, and the MPLS Label2 field must carry a
label used for Layer 3 service traffic forwarding. In this case, MAC/IP
advertisement routes are also called IRBv6 routes.
An ND route carries the following valid information: host MAC address, host IPv6
address, and Layer 2 VNI. An IRBv6 route carries the following valid information:
host MAC address, host IPv6 address, Layer 2 VNI, and Layer 3 VNI. An IRBv6
route includes information about an ND route and therefore can be used to
advertise both a host IPv6 route and host ND entry.
● Inclusive multicast route: After a BGP peer relationship is established between
PEs, the PEs transmit inclusive multicast routes to each other. An inclusive
multicast route carries the RD and RTs of the EVPN instance on the local PE,
source IP address (usually the loopback address of the local PE), and Provider
Multicast Service Interface (PMSI). The PMSI is used to carry the tunnel type
(ingress replication or mLDP) and tunnel label information in multicast
packets. The PMSI and RTs are carried in the route attribute information, and
the RD and source IP address are carried in the NLRI. Figure 3-4 shows the
format of the EVPN NLRI specific to an inclusive multicast route. In this
situation, EVPN involves broadcast, unknown unicast, and multicast (BUM)
traffic. A PE forwards the BUM traffic that it receives to other PEs in P2MP
mode. A tunnel is established to transmit BUM traffic between PEs through
inclusive multicast routes. For details, see BUM Packet Transmission.
Figure 3-4 EVPN NLRI specific to the inclusive multicast route

EVPN instance.

(2020-04-09)
– Ethernet Tag ID: The value of this field is all zeros except that it is the
same as the local service ID in an EVPN VPWS scenario or the same as
the BD tag value in BD EVPN access in VLAN-aware mode.
– IP Address Length: a 1-byte field representing the length of the source IP
address configured on the local PE.
– Originating Router's IP Address: a 4-byte or 16-byte field representing the
source IP address configured on the local PE.
● Ethernet segment route: carries ESI information, source IP address and RD
(source IP:0) on 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 election. Figure 3-5 shows the format of an EVPN
NLRI specific to the Ethernet segment route.
Figure 3-5 EVPN NLRI specific to the Ethernet segment route

– Route Distinguisher: an 8-byte field representing a combination of the
source IP address on the local PE and :0, such as X.X.X.X:0.
PEs and CEs.
– IP Address Length: a 1-byte field representing the length of the source IP
address configured on the local PE.
– Originating Router's IP Address: a 4-byte or 16-byte field representing the
source IP address configured on the local PE.
● IP prefix route: used to advertise a host IP address or the network segment to
which the host IP address belongs, which has been received from the access
network. Figure 3-6 shows the format of an EVPN NLRI specific to an IP
prefix route.
Figure 3-6 Format of EVPN NLRI specific to an IP prefix route

(2020-04-09)

EVPN instance.
PEs and CEs.
– Ethernet Tag ID: Currently, each bit of the field value must be 0.
– IP Prefix Length: IP prefix mask length carried in the route.
– IP Prefix: IP prefix address carried in the route.
– GW IP Address: default gateway address.
– MPLS Label: a field representing the label used for Layer 3 service traffic
forwarding.
Unicast MAC Address Advertisement

On the network shown in Figure 3-7, unicast MAC addresses are advertised as
follows:
1. CE1 sends an ARP Request message or a gratuitous ARP message to advertise
its MAC address (MAC A) and IP address to CE2. After the ARP Request
message or gratuitous ARP message arrives at PE1, PE1 generates a MAC/IP
advertisement route based on MAC A.
2. CE2 receives the ARP Request message or gratuitous ARP message from CE1
and responds with an ARP Reply message or a gratuitous ARP message
carrying CE2's MAC address (MAC B) and IP address. After the ARP Reply
message or gratuitous ARP message arrives at PE2, PE2 generates a MAC/IP
advertisement route based on MAC B.
3. PE1 and PE2 exchange MAC/IP advertisement route that carry MAC
addresses, next hops, and EVPN instance extended community attributes
(such as RTs).
4. PE1 and PE2 locate the corresponding EVPN instance on the local device
based on the RT matching result and then construct EVPN instance
forwarding entries based on the NLRIs carried in received MAC/IP
advertisement route.
Figure 3-7 Unicast MAC address advertisement networking

(2020-04-09)
Unicast Packet Transmission

After a PE connecting to a site has learned the MAC addresses of other sites and
established public network tunnels, the PE can send unicast packets to other sites.
On the network shown in Figure 3-8, unicast packets are transmitted 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
sequence into the unicast packets. PE2 then forwards the encapsulated
unicast packets to PE1.
3. PE1 decapsulates the received unicast packets and sends the unicast packets
to the sites of the EVPN identified by the EVPN label carried in the packets.
Figure 3-8 Unicast packet transmission networking
BUM Packet Transmission

After two PEs establish a BGP EVPN peer relationship, they exchange inclusive
multicast routes. A PE can discover PEs that belong to the same EVPN instance as
itself based on RTs carried in the inclusive multicast routes it receives. The RTs
identify the reachability information of these PEs. This PE then automatically
establishes MPLS tunnels with these PEs. BUM packets can then traverse these
LDP tunnels. 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. Specifically, PE1 replicates the received BUM
packets and encapsulates the EVPN BUM label, public network Tunnel label,
PE1's MAC address, and P's MAC address in sequence into these packets
before sending them to PE2 and PE3.
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.

(2020-04-09)
In the case where a CE is dual-homed to two PEs, an EVPN ESI label will be encapsulated
into the BUM packets exchanged between the two PEs to prevent loops.
Figure 3-9 BUM packet transmission networking
3.1.3 EVPN-MPLS
3.1.3.1 EVPN Multi-Homing Technology
Related Concepts
● Designated forwarder (DF) election
On the network shown in Figure 3-10, 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 allows one PE to be elected to forward BUM traffic.
The elected PE is referred to as the DF. 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 is Down, the PE functions as a backup DF.
If a PE interface connecting to a CE is Up, the PE and other PEs with Up
interfaces elect a primary DF using the following procedure:
a. The PEs establish BGP EVPN 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

(2020-04-09)
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. 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.
An Ethernet segment may have multiple VLANs configured. In this case, the
smallest VLAN ID is used as the V value.
Figure 3-10 DF election networking
● Split horizon
On the network shown in Figure 3-11, CE1 is dual-homed to PE1 and PE2
and has load balancing enabled. If PE1 and PE2 have established a BGP EVPN
peer relationship with each other, after PE1 receives BUM traffic from CE1,
PE1 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 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.

(2020-04-09)
Figure 3-11 Split horizon networking
● Redundancy mode and aliasing

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-12, the transmission mode of unicast traffic sent by PE3 to CE1 varies
according to the redundancy modes configured on PE1 and PE2. If PE1 and
PE2 are both configured to work in All-Active mode, after PE1 and PE2 send
Ethernet auto-discovery route carrying the redundancy mode to PE3, PE3
sends unicast traffic destined for CE1 to both PE1 and PE2 in load balancing
mode.
EVPN also supports aliasing, which is the ability of a PE to signal that it has
reachability to an EVPN instance on a given Ethernet segment even when it
has learned no MAC addresses from that Ethernet segment. In the case where
a CE is multi-homed to several PEs, it is possible that only a single PE learns a
set of the MAC addresses associated with traffic transmitted by the CE.
Aliasing enables remote PEs to learn the reachability of CE-side MAC
addresses based on the ESIs carried in Ethernet auto-discovery route
received from multi-homing PEs. On the network shown in Figure 3-12, only
PE1 sends MAC/IP advertisement routes that carry CE-side MAC addresses
to PE3, but PE3 can learn from Ethernet auto-discovery route that PE2 is
also reachable to CE1. As a result, PE3 load-balances traffic destined for CE1
between PE1 and PE2.

(2020-04-09)
Figure 3-12 Redundancy mode and aliasing networking
● Fast route convergence

On the network shown in Figure 3-13, if the link between CE1 and PE1 fails,
PE1 advertises an Ethernet auto-discovery route to PE3, informing PE3 that
PE1 has become unreachable to Site 1. Upon receipt of the route, PE3
withdraws the corresponding routes and sends traffic to Site 1 only through
PE2, implementing fast route convergence.
Figure 3-13 Fast route convergence networking
3.1.3.2 EVPN Seamless MPLS Fundamentals

Seamless MPLS achieves end-to-end service transmission along an LSP traversing
the access, aggregation, and core layers. Therefore, service traffic can be
transmitted between any two points on an LSP. The seamless MPLS network
architecture maximizes service scalability using the following functions:
● Allows access nodes to signal all services to an LSP.
● Uses the same transport layer convergence technology to switch all services
to backup paths in case of network-side faults, ensuring proper service
transmission.

(2020-04-09)
Background
The use of MPLS networks increases requirements for service scalability of
network architecture. Different MANs of a service provider or collaborative
backbone networks of different service providers often span multiple ASs.
Implementation
Through seamless MPLS networking, all services (support inter-AS Option C) are
signaled to an LSP only by access nodes, and all network-side faults are rectified
using the same transport layer convergence technology, which does not affect
service transmission.
Usage Scenario
Seamless MPLS supports the following networking solutions:
● Intra-AS seamless MPLS: The access, aggregation, and core layers are
deployed within a single AS. This solution mainly applies to mobile bearer
networks.
● Inter-AS seamless MPLS: The access and aggregation layers are deployed
within a single AS, whereas the core layer in another AS. This solution mainly
applies to enterprise services.

(2020-04-09)
EVPN Intra-AS Seamless MPLS
Table 3-1 EVPN intra-AS seamless MPLS networking

Network Description
Deployment
Deploy In Figure 3-14, routing protocols are deployed on

routing devices as follows:
protocols. ● An IGP (IS-IS or OSPF) is enabled on devices at the
access, aggregation, and core layers to establish
connectivity within the AS.
● 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
An AGG and core ABR are configured as route
reflectors (RRs) so that a CSG and MASG can obtain
routes destined for each other's loopback address.
● The next hop addresses in BGP routes are set on the
Control AGG and core ABR to the devices' own addresses to
plane prevent advertising unnecessary IGP area-specific
public routes.
Figure 3-14 Routing protocol deployment for intra-AS

seamless MPLS networking

(2020-04-09)
Network Description
Deployment
Deploy In Figure 3-15, tunnels are deployed as follows:

tunnels. ● 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 routing policy. After the devices exchange
labeled BGP routes, an end-to-end BGP LSP is
established between the CSG and MASG.
Figure 3-15 Tunnel deployment for intra-AS seamless

MPLS networking

(2020-04-09)
Network Description
Deployment
Figure 3-16 illustrates the forwarding plane of intra-AS

seamless MPLS networking. Seamless MPLS is mainly
used to transmit EVPN packets. The following example
demonstrates how EVPN packets, including labels and
data, 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)
function is enabled on the AGG, the CSG has
Forwarding plane
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
AGG pushes a core-layer MPLS tunnel label to each
packet and forwards the packets to the MASG.
4. Upon receipt, 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-04-09)
Network Description
Deployment
Figure 3-16 Forwarding plane for intra-AS seamless

MPLS networking

(2020-04-09)
EVPN Inter-AS Seamless MPLS
Table 3-2 EVPN inter-AS seamless MPLS networking

Network Description
Deployment
Deploy In Figure 3-17, routing protocols are deployed on

routing devices as follows:
protocols ● An IGP (IS-IS or OSPF) is enabled on devices at the
. access, aggregation, and core layers to establish
connectivity within the AS.
● 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 between an AGG ASBR
and a core ASBR is established, and IBGP peer
relationships between other devices are established.
● The AGG is configured as an RR so that IBGP peers
can exchange BGP routes, and the CSG and MASG
can obtain BGP routes destined for each other's
Control
loopback addresses.
plane
● If the AGG ASBR and core ASBR are indirectly
connected, an IGP neighbor relationship between
them must be established to implement connectivity
between ASs.
Figure 3-17 Routing protocol deployment for inter-AS

seamless MPLS networking

(2020-04-09)
Network Description
Deployment
Deploy In Figure 3-18, tunnels are deployed as follows:

tunnels. ● A public network tunnel is established using LDP, TE,
or LDP over TE in each IGP area. An LDP LSP or a TE
LSP is established if more than one hop exists
between the AGG ASBR and core ASBR.
● The CSG, AGG, AGG ASBR, and core ASBR are
enabled to advertise labeled routes and assign labels
to BGP routes that match a specified routing policy.
After the devices exchange labeled BGP routes, a BGP
LSP is established between the CSG and core ASBR.
● Tunnel deployment in the core area is as follows:
– A BGP LSP between the core ASBR and MASG is
established. This BGP LSP and the BGP LSP
between the CSG and core ASBR are combined
into an end-to-end BGP LSP. The route to the
MASG's loopback address is imported 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 imports the route to the routing table.
The core ASBR assigns a BGP label to the route
and associates the route with an intra-AS LSP. The
BGP LSP between the CSG and core ASBR and the
MPLS LSP in the core area are combined into an
end-to-end tunnel.
Figure 3-18 Tunnel deployment for inter-AS seamless

MPLS networking

(2020-04-09)
Network Description
Deployment
Figure 3-19 illustrates the forwarding plane of the inter-

AS seamless MPLS networking with a core-layer BGP
LSP established. Seamless MPLS is mainly used to
transmit EVPN packets. The following example
demonstrates how EVPN packets, including labels and
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
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 core ASBR, the
core ASBR has removed the MPLS tunnel labels from
the packets, and therefore, the MASG receives
The EVPN packet transmission along the inter-AS
seamless MPLS LSP is complete.

(2020-04-09)
Network Description
Deployment
Figure 3-19 Forwarding plane for the inter-AS seamless

MPLS networking with a BGP LSP established in the core
area
Figure 3-20 illustrates the forwarding plane for the

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. The difference is
that without a BGP LSP in the core area, the core ASBR
removes BGP labels from packets and pushes MPLS
tunnel labels into these packets.
Figure 3-20 Forwarding plane for the inter-AS seamless

MPLS networking without a BGP LSP established in the
core area

(2020-04-09)
Reliability
Seamless MPLS network reliability can be improved using various functions. If a
network fault occurs, a device immediately detects the fault and switch traffic to a
standby link.
The following examples demonstrate reliability functions on an inter-AS seamless

MPLS network.
● A fault occurs on a link between a CSG and an AGG.

On the inter-AS seamless MPLS network shown in Figure 3-21, 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-21 Traffic protection triggered by a fault on the link between the
CSG and AGG on the inter-AS seamless MPLS network
● A fault occurs on an AGG.

On the inter-AS seamless MPLS network shown in Figure 3-22, 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 AGG1
failure, the BFD module instructs CSG1 to switch traffic from the primary path
to the backup path.
Figure 3-22 Traffic protection triggered by a fault on an AGG on the inter-AS

seamless MPLS network

(2020-04-09)
● A fault occurs on the link between an AGG and an AGG ASBR.

On the inter-AS seamless MPLS network shown in Figure 3-23, 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 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 on the link between an

AGG and an AGG ASBR on the inter-AS seamless MPLS network
● A fault occurs on an AGG ASBR.

On the inter-AS seamless MPLS network shown in Figure 3-24, 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 BGP auto FRR. BGP auto FRR switches both
upstream and downstream traffic from the primary path to backup paths.
Figure 3-24 Traffic protection triggered by a fault on an AGG ASBR on the

inter-AS seamless MPLS network
● A fault occurs on the link between an AGG ASBR and a core ASBR.
On the inter-AS seamless MPLS network shown in Figure 3-25, BFD for
interface is configured on AGG ASBR1 and core ASBR1. If the BFD module
detects a fault on the link between AGG ASBR1 and core ASBR1, the BFD
module triggers BGP Auto FRR. BGP auto FRR switches both upstream and
downstream traffic from the primary path to backup paths.

(2020-04-09)
Figure 3-25 Traffic protection triggered by a fault on the link between an

AGG ASBR and a core ASBR on the inter-AS seamless MPLS network
● A fault occurs on a core ASBR.

On the inter-AS seamless MPLS network shown in Figure 3-26, 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 instructs AGG ASBR1 to switch both upstream and downstream
traffic from the primary path to backup paths.
Figure 3-26 Traffic protection triggered by a fault on a core ASBR on the

inter-AS seamless MPLS network
● A link fault occurs in the core area.

On the inter-AS seamless MPLS network shown in Figure 3-27, 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 triggers the LDP FRR, TE hot-
standby, or BGP FRR function. The reliability function switches both upstream
and downstream traffic from the primary path to the backup path.

(2020-04-09)
Figure 3-27 Traffic protection from a link fault in a core area on the inter-AS
seamless MPLS network
● A fault occurs on an MASG.

On the inter-AS seamless MPLS network shown in Figure 3-28, BFD for BGP
tunnel is configured on CSG1. BFD for BGP tunnel is implemented in
compliance with relevant standards "Bidirectional Forwarding Detection (BFD)
for MPLS Label Switched Paths (LSPs)." BFD for BGP tunnel monitors end-to-
end BGP LSPs, including a BGP LSP connected to an LDP LSP. If MASG1
functioning as a PE fails, BFD for BGP LSP can rapidly detect the fault and
trigger VPN FRR switching so that both upstream and downstream traffic are
switched from the primary path to the backup path.
Figure 3-28 Traffic protection triggered by a fault on an MASG on the inter-

AS seamless MPLS network
● An access-side link fails.

On the inter-AS seamless MPLS network shown in Figure 3-29, if an E-Trunk
in Single-Active redundancy mode detects the link failure, and the E-Trunk
switches traffic from the primary path to the backup path and disables
interface blocking on the link between CE1 and PE2. Then upstream traffic on
CE1 is forwarded to PE2. For BUM traffic on the network side, PE1 sends a Per
ES-AD-withdraw message to PE2, and PE2 is elected as the primary DF to
forward BUM traffic. For unicast traffic, PE3 receives a MAC route advertised
by PE2 and forwards the traffic to PE2.

(2020-04-09)
If an E-Trunk in Active-Active redundancy mode detects the link failure, PE1

sends a Per ES-AD route-withdraw message to PE3, and PE3 forwards unicast
traffic to PE2.
Figure 3-29 Traffic protection triggered by an access-side link fault in a core

area on the inter-AS seamless MPLS network
● A PE on the access side fails.

If PE1 fails, the reliability implementation is similar to that in the access-side
link failure scenario. The other PEs detect PE1 failure and switch traffic from
the primary path to backup paths without withdrawing routes.
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.

(2020-04-09)
Service Mode Usage Scenario
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.
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-30, 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-30 VLAN-based mode
VLAN Bundle
On the network shown in Figure 3-31, 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.

(2020-04-09)
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.
Figure 3-31 VLAN-bundle mode
VLAN-Aware Bundle
On the network shown in Figure 3-32, 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-32 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.

(2020-04-09)
– 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
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

(2020-04-09)
Figure 3-33 shows the format of a MAC/IP route.
Figure 3-33 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 Mask 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:

(2020-04-09)
● MAC address advertisement

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 Length and MAC Address
fields identify 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 and MAC Address Length fields identify the MAC address of the
host, whereas the IP Address and IP Address Length fields identify 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 Length and IP Address fields
identify 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.
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 Length and IP Address fields
carried in the MAC/IP routes indicate 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.
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. It can be seen that an IRBv6 route
includes information about an ND route and therefore can be used to advertise both a
host IPv6 route and host ND entry.
Type 3 Route: Inclusive Multicast Route

An inclusive multicast route comprises a prefix and a PMSI attribute. Figure 3-34
shows the format of an inclusive multicast route.

(2020-04-09)
Figure 3-34 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
Tag ID The value is all 0s in this type of route.
IP Mask 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.

Label

(2020-04-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. At the same time, an ingress replication list based on VNI is created
for subsequent BUM packet forwarding, and the remote VTEP's IP address will be
added to this list.
Type 5 Route: IP Prefix Route
Figure 3-35 shows the format of an IP prefix route.
Figure 3-35 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-04-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
Overview
Ethernet virtual private network (EVPN) virtual private wire service (VPWS)
provides a P2P L2VPN service solution based on the EVPN service architecture.
This solution simplifies the EVPN technology by using MPLS tunnels over a
backbone network to provide Layer 2 packet forwarding between access circuits
(ACs) with no need of searching for MAC address entries.
As shown in Figure 3-36, the basic architecture of EVPN VPWS consists of the
following parts:
● AC: is an independent link or circuit that connects a CE to a PE. An AC
interface can be a physical or logical interface. AC attributes include the
encapsulation type, maximum transmission unit (MTU), and interface
parameters of a specified link type.
● EVPL instance: An EVPLS instance maps to an AC. Each EVPL instance has a
service ID. The EVPL instance of the local PE maps to that of the peer 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
point-to-point 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: indicates a network-side MPLS tunnel or SR tunnel.
Compared with the traditional L2VPN VPWS solution, the EVPN VPWS solution
simplifies the control and data models and uses BGP as the control plane where

(2020-04-09)
the BGP route selection and the BGP next hop recursion are used to choose traffic
paths over backbone networks. This eliminates the need of specifying PWs.
Figure 3-36 EVPN VPWS networking
Routes Used by EVPN VPWS

On the basis of BGP, EVPN defines a new type of network layer reachability
information (NLRI), which is called EVPN NLRI. EVPN VPWS supports the following
types of EVPN NLRIs:
● Ethernet Auto-Discovery (Ethernet AD) routes: include Ethernet Auto-
Discovery Per EVI routes and Ethernet Auto-Discovery Per ES 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-37 shows the NLRI format of EVI Ethernet AD routes.
Figure 3-37 NLRI format of EVI Ethernet AD routes
▪ RD: 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 a connection

between a PE and a CE.
▪ Ethernet Tag ID: indicates the local service ID of the EVPL instance
on the local PE.

(2020-04-09)
▪ MPLS Label: For a non-SRv6 tunnel, this field is the EVPL label
assigned based on each EVI Ethernet Auto-Discovery route. For an
SRv6 tunnel, this field is the SRv6 SID of this tunnel.
In addition to NLRI, an EVI Ethernet Auto-Discovery route carries the
Layer 2 extended community attribute that includes the following control
fields:
▪ C: identifies a control word. If this control field is set to 1, packets

sent by the local PE must carry control information.
▪ P: is used to identify whether the local PE is the master PE. In all-

active scenarios, this control field must be set to 1.
▪ B: is used to identify whether the local PE is the backup PE in dual-

homing single-active scenarios.
● Ethernet Segment (ES) route: An ES route carries the RD, Ethernet segment
identifier (ESI) value, and source IP address of the local PE to allow automatic
discovery and DF election between PEs connecting to the same CE. Figure
3-38 shows the NLRI format of ES routes.
Figure 3-38 NLRI format of ES routes

– Route Distinguisher: is a combination of the source IP address on the
local PE and :0, such as X.X.X.X:0.
– Ethernet Segment Identifier: uniquely identifies a connection between a
PE and a CE.
– IP Address Length: indicates the length of the source IP address
configured on the local PE.
– Originating Router's IP Address: indicates the source IP address
Packet Exchange Process in Single-Homing Scenarios

Figure 3-36 shows the packet exchange process in EVPN VPWS single-homing
scenarios.
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 configured with a local
service ID and a remote service ID. After the configuration, the local PE
generates the forwarding entries indicating the association between the AC
interface and EVPL instance.

(2020-04-09)
2. PE1 and PE2 each send EVI Ethernet AD routes to the peer device. The EVI
Ethernet AD routes carry the RD, RT, next-hop information, local service ID,
and EVPL label or SRv6 SID.
3. PE1 and PE2 each receive EVI Ethernet AD routes from the peer device 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, the forwarding
entries indicating the association between the MPLS or SRv4/v6 tunnel and
local EVPL instance are generated.
Packet Exchange Process in Dual-Homing Single-Active Scenarios (with an

E-Trunk Deployed)
On the CE dual-homing network shown in Figure 3-39, PE1 and PE2 work in
single-active mode and an E-Trunk is deployed between them. 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 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 configured with a local service ID and a
remote service ID. After the configuration, the local PE generates the
forwarding entries 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 send ES routes that carry the RD, RT, ESI, and source IP address.
DF election is not triggered between PE1 and PE2 upon receipt of ES routes.
The master/backup relationship between PE1 and PE2 are determined based
on the E-Trunk deployed between them. In this example, PE1 is the master PE,
and PE2 is the backup PE.
3. PE1 and PE2 send PE3 the ES Ethernet AD routes that carry the RD, RT, next-
hop information, and single-active mode information.
4. The PEs send each other the EVI Ethernet AD routes that carry the RD, RT,
next-hop information, local service ID, EVPL label or SRv6 SID, and master/
backup role.
5. Upon receipt of EVI Ethernet AD 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, the forwarding entries indicating the association between the
MPLS or SRv4/v6 tunnel and local EVPL instance are 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, the FRR entries indicating the association between the
MPLS or SRv4/v6 tunnel and local EVPL instance are generated. The entries

(2020-04-09)
destined for PE1 are the master entries, and the entries destined for PE2 are
the backup entries.
remote service ID configured for the local EVPL instance, the bypass entries
indicating the association between the MPLS or SRv4/v6 tunnel and local
EVPL instance are generated.
Figure 3-39 EVPN VPWS dual-homing single-active networking (with an E-Trunk

deployed)
Packet Exchange Process in Dual-Homing Single-Active Scenarios (with No

E-Trunk Deployed)
On the CE dual-homing network shown in Figure 3-40, PE1 and PE2 work in
single-active mode and an E-Trunk is not deployed between them. The packet
exchange process in this scenario is similar to that in the scenario with an E-Trunk
deployed. The only difference is that the master/backup relationship between PE1
and PE2 in this scenario is determined by the DF election mechanism of EVPN
VPWS.
Figure 3-40 EVPN VPWS dual-homing single-active networking (with no E-Trunk

deployed)
By default, the PE with a smaller source IP address is elected as the master DF.
This, however, causes all service traffic to travel through the same PE, which may

(2020-04-09)
lead to unbalanced network load. To address this problem, enable the service ID-
based DF election. Taking Figure 3-41 as an example, the service ID-based DF
election process is as follows:
1. PE1 and PE2 send each other the ES routes that carry the RD, RT, ESI, and
source IP address.
2. Upon receipt of ES routes, PE1 and PE2 construct PE lists based on different
ESIs. The PEs in a PE list are ordered by the source IP address in ascending
order, and the system assigns an index starting at 0 to each PE in ascending
order.
3. Each ES corresponds to a local service ID. The system calculates the DF
election result of each ES based on the formula "service ID mod N", where N
indicates the number of PEs. As shown in Figure 3-41, the service ID
corresponding to ESx is 100, the number of PEs (N) is 2, and the ESx is
calculated out to be 0. The system searches the PE list of ESx for the index
and finds that the DF election result of ESx is PE1. Similarly, the DF election
result of ESy is PE2. This allows traffic from different Es to be transmitted over
different PEs.
The DF election result determines the P control field in EVI Ethernet AD routes.
Figure 3-41 DF election in EVPN VPWS
Packet Exchange Process in Dual-Homing All-Active Scenarios

On the CE dual-homing network shown in Figure 3-42, PE1 and PE2 work in all-
active mode. The 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 configured with a local service ID and a

(2020-04-09)
remote service ID. After the configuration, the local PE generates the
forwarding entries 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 configured with the same ESI.
2. 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 ES Ethernet AD routes that carry the RD, RT, next-
hop information, and all-active mode information.
4. The PEs send each other the EVI Ethernet AD routes that carry the RD, RT,
next-hop information, local service ID, EVPL label or SRv6 SID, and master/
backup role.
5. Upon receipt of EVI Ethernet AD 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, the forwarding entries indicating the association between the
MPLS or SRv4/v6 tunnel and local EVPL instance are 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, load balancing entries of the MPLS or SRv4/v6 tunnel and
local EVPL instance are generated.
remote service ID configured for the local EVPL instance, the bypass entries
indicating the association between the MPLS or SRv4/v6 tunnel and local
EVPL instance are generated.
Figure 3-42 EVPN VPWS networking in dual-homing all-active scenarios
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

(2020-04-09)
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.
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.

(2020-04-09)
Figure 3-43 PBB-EVPN networking
Table 3-7 describes the key points in PBB-EVPN implementation.
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.

(2020-04-09)
Plane Key Points in Related Concepts

Implementation
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.
Figure 3-44 Prefix format of a MAC advertisement route packet

(2020-04-09)
– 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

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

(2020-04-09)
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.
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

(2020-04-09)
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.
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.

(2020-04-09)
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
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.

(2020-04-09)
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
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.
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.

(2020-04-09)
Figure 3-52 BUM packet transmission networking
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.

(2020-04-09)
Figure 3-53 Unicast packet transmission networking
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

(2020-04-09)
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

As the number of services carried on an EVPN increases, the number of user MAC
addresses managed by the EVPN is also going Up. 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.
● 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.
To implement the preceding functions, an E-Tree extended community attribute is
defined in a standard protocol. Figure 3-55 shows the packet format of this
attribute. The packet format includes the Leaf Label field and the Flags field. The
Flags field contains eight bits, in which the first seven are all zeros and the last
identifies whether an EVPN MAC route is from a leaf AC interface. If the MAC
route comes from this interface, the value is set to 1. The extended community
attribute can be advertised through Ethernet auto-discovery (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.

(2020-04-09)
Figure 3-55 Packet format of the extended community attribute used by EVPN E-
Tree
Take the network shown in Figure 3-56 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 routing 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:
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. 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 and CE5. Instead, PE2 only
sends the traffic to CE3, implementing BUM traffic isolation between leaf AC
interfaces.

(2020-04-09)
Figure 3-56 Network with EVPN E-Tree deployed
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.
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-04-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-04-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-04-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-04-09)
and are also clients of the RR. An EVPN instance with a specific RT is configured
on each PE.
Figure 3-59 Basic usage scenario of EVPN ORF
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.
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-04-09)
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 no Internet Group Management Protocol (IGMP)
snooping is 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
transmitted on the network through EVPN routes, and multicast forwarding

(2020-04-09)
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), 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: route distinguisher (RD) set 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 eight bits. The first four most significant bits are
reserved, and the last three least significant bits are used to identify the
IGMP version. For example, if bit 5 is set to 1, the IGMP version of the
multicast entry carried in the route is IGMPv3. Only one of the last three
least significant 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, respectively.

(2020-04-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) set 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 eight bits. The first four most significant bits are
reserved, and the last three least significant bits are used to identify the
IGMP version. For example, if bit 5 is set to 1, the IGMP version of the
multicast entry carried in the route is IGMPv3. Only one of the last three

(2020-04-09)
least significant 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, 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
and IGMP on CE1's interface connected to PE1.
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.

(2020-04-09)
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 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.
Figure 3-63 Single-homing access for IGMP snooping over EVPN MPLS
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,
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

(2020-04-09)
work in dual-active mode, and ensure that the Eth-Trunk interfaces on PE1 and
PE2 are both Up.
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 adds the
mLDP tunnel interfaces of the corresponding EVPN instances as outbound
interfaces.
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.

(2020-04-09)
Figure 3-64 Dual-homing access for IGMP snooping over EVPN MPLS on the
multicast source side
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.
IGMPv3 is not supported in access-side dual-homing access scenarios.
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
route carries the access-side ESI of PE2 and contains the IGMP version and V2
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-

(2020-04-09)
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.
7. After receiving an IGMP Report message, CE1 creates IGMP and PIM entries
and forwards multicast traffic to PE1.
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) entries based on the IGMP Report messages received
from CE2, and sends IGMP Join Synch routes withdraw message to PE3. PE3
then deletes the receivers' entries to ensure that the local (*, G) entries are
the same as those 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.
Figure 3-65 Dual-homing access for IGMP snooping over EVPN MPLS on the
access side
3.1.11 Application Scenarios for EVPN
3.1.11.1 Using EVPN to Interconnect Other Networks

On the network shown in Figure 3-66, 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.

(2020-04-09)
● 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-66 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
networks will evolve to EVPN. Specifically, L3VPN HVPN, which carries Layer 3
services, needs to evolve to EVPN L3VPN HVPN.
Figure 3-67 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.

(2020-04-09)
Figure 3-67 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
Route Advertisement from CE1 to Device 1 on an EVPN L3VPN HoVPN or

EVPN L3VPN H-VPN
Figure 3-68 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:

(2020-04-09)
– 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-68 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-69 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.
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.

(2020-04-09)
Figure 3-69 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-70 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.
Figure 3-70 Route advertisement from Device 1 to CE1 on an EVPN L3VPN H-VPN

(2020-04-09)
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
(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:

(2020-04-09)
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-71, the components involved in the 6VPE function are the edge router
(PE), customer edge router (CE), and core router (P) of the backbone network.
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.

(2020-04-09)
Figure 3-71 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-72, 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.
– GW IP Address: Specifies the default gateway address.
– MPLS Label: Specifies the VPN label of EVPN.

(2020-04-09)
Figure 3-72 EVPN 6VPE model
In Figure 3-73, 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-73 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-74, 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
DCs. An MPLS or SR tunnel can be deployed between DCI-PEs to carry IPv6
services.

(2020-04-09)
Figure 3-74 Application of EVPN 6VPE in DCI scenarios
3.1.11.4 EVPN Splicing
Background
The current MAN is evolving into EVPN. However, because there are a large
number of devices at the aggregation layer, it is difficult for the MAN to evolve
into EVPN at a time. To allow traditional L3VPN, VPWS or VPLS to be still used at
the aggregation layer and the core layer to evolve into EVPN first, splicing
between EVPN and the traditional network must be supported.
L3VPN Accessing EVPN

The network between the UPE and NPE1 resides at the aggregation layer. The
network between NPE1 and NPE2 resides at the core layer. An L3VPN is deployed
at the aggregation layer, and EVPN-MPLS is deployed at the core layer. After
receiving user routes from the access side, the UPE sends these routes to NPE1
through a BGP VPNv4 peer relationship. Both an EVPN instance and an L3VPN
instance are configured on NPE1. After receiving BGP VPNv4 routes, NPE1 imports
these routes into the L3VPN instance, encapsulates the routes into EVPN routes,
and sends the EVPN routes to NPE2 through a BGP EVPN peer relationship. This
implementation is L3VPN accessing EVPN as such.

(2020-04-09)
Figure 3-75 L3VPN accessing EVPN
VLL Accessing EVPN

On a network with VLL accessing EVPN, CE1 and CE2 stand for two users. Each
user has three sites: CE1-1, CE1-2, and CE1-3 for CE1, and CE2-1, CE2-2, and CE2-3
for CE2. NIDs, which function as aggregation devices on the user side, are
attached to the user sites and access the aggregation network. When accessing
the aggregation network, the CEs use the S-VLAN and C-VLAN tags. S-VLAN
indicates an NID, and C-VLAN indicates the user site connected to the NID. The
users access the VLL network, a Layer 2 network, through the NIDs. The UPE and
NPE1 belong to the aggregation layer, at which an MPLS network is deployed.
Services between the devices are carried using a VLL. NPE1 and NPE2 belong to
the core layer, at which an MPLS network is deployed. Services between them are
carried through an EVPN.
To allow communication between different sites of the same user, VLL accessing
EVPN supports the following scenarios:
● Single-homing scenario
An NID on the access side can be single-homed to a UPE through a main
interface. The UPE establishes a PW with NPE1 for each NID. On NPE1 and
NPE2, an EVPN instance is created for each user. On NPE1, a VLL is connected
to the EVPN through a PW VE interface. The VLL is bound to the PW VE
interface, and the EVPN instances are bound to the PW VE sub-interfaces that
are configured as QinQ VLAN tag termination sub-interfaces. In this manner,
traffic of user packets is imported to different EVPN instances based on the S-
VLAN and C-VLAN tags.

(2020-04-09)
Figure 3-76 Single-homing scenario 1 for VLL accessing EVPN (per NID per
PW)
Additionally, VLL accessing EVPN allows multiple NIDs to share a PW. In this
scenario, multiple NIDs are aggregated to a switch, which then accesses a PW
on a UPE.
Figure 3-77 Single-homing scenario 2 for VLL accessing EVPN (multiple NIDs
per PW)
● Dual-homing scenario
A UPE is dual-homed to the master and slave NPEs through primary and
secondary PWs respectively to improve access reliability. On the EVPN, the
NPE1-NPE3 link and the NPE2-NPE3 link can be configured to work in single-
active mode or in all-active mode, which allows for load balancing.

(2020-04-09)
Figure 3-78 Dual-homing scenario for VLL accessing EVPN
Splicing VXLAN and VPLS

When a DC with an EVPN VXLAN deployed interconnects to an enterprise campus
through an MPLS L2VPN, splicing VXLAN and VPLS must be deployed.
On the network shown in Figure 3-79, the EOR, 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-79 Splicing VXLAN and VPLS
Splicing Primary and Secondary PWs with an Anycast VXLAN Tunnel in an

EVPN Active-Active Scenario
On the network shown in Figure 3-80, 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 EOR. In this manner, PE1, PE2, and the EOR can
communicate with each other. PE1 and PE2 communicate with the external
network (an access network or the Internet) through the VPLS network. 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 directly sent to the PE-AGG through the primary PW.

(2020-04-09)
Traffic received by PE2 is forwarded to PE1 through the bypass VXLAN tunnel and
then sent to the PE-AGG through the primary PW. Traffic from the PE-AGG to the
server is transmitted along the reverse paths.
Figure 3-80 Splicing primary and secondary PWs with an anycast VXLAN tunnel in
an EVPN active-active scenario
Splicing VPLS and MPLS EVPN

VPLS has inherent defects, such as a lack of support in load balancing and heavy
consumption of network resources (MAC learning and ARP learning require packet
broadcast on the entire network). As EVPN becomes widely used, VPLS networks
are gradually evolving to EVPNs. However, such evolution cannot be implemented
at a time due to complex network environments. Specifically, some devices may
be deployed with VPLS and some other devices are deployed with EVPN. In this
case, the function of VPLS splicing with MPLS EVPN can be deployed to ensure
interworking on the entire network.
As shown in Figure 3-81, VPLS is deployed between CSGs and ASGs, and CSGs are
connected to ASGs through the primary and secondary PWs. EVPN is deployed
between ASGs and RSGs. On ASG1 and ASG2, a BD is configured and bound to a
VSI and an EVPN instance. In this manner, all PWs in the VSI can be connected to
the EVPN through BDs. On the CSG dual-homed to ASG1 and ASG2, the same ESI
is configured for the primary and secondary PW interfaces. The procedure for
traffic forwarding is as follows:
1. Because an ESI is configured on ASG1's PW interface and the PW is in the Up
state, ASG1 sends Ethernet A-D routes to the RSG.
2. After the Layer 2 packets sent by Site 1 reach ASG1 through the CSG, ASG1
generates MAC routes for the EVPN based on the MAC address of Site 1 in
the Layer 2 packets. Such MAC routes are sent to the RSG based on the BGP
EVPN peer relationship, and the RSG generates MAC forwarding entries based
on the received Ethernet A-D routes. Similarly, the RSG sends MAC routes that
carry the MAC address of Site 2 to ASGs and generate the corresponding MAC
forwarding entries.
3. After the forwarding entries are successfully set up, these entries can guid
through the forwarding of unicast traffic and BUM traffic. Taking the unicast

(2020-04-09)
traffic sent from Site 1 to Site 2 as an example, upon receipt of the traffic
from the primary PW, ASG1 forwards the traffic to the RSG based on the MAC
routes sent by the RSG. The RSG then forwards the traffic to Site 2.
Although ASG1 and ASG2 transmit Ethernet Segment routes to each other, DF election
between ASG1 and ASG2 is implemented based on the PW status. The device (ASG1)
connected to the primary PW is the primary DF, and the device (ASG2) connected to the
secondary PW is the backup DF.
In BUM traffic forwarding scenarios, because the network is deployed with split horizon and
the backup DF blocks traffic, loops or extra packets do not occur on the network.
Figure 3-81 Networking of VPLS splicing with 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:

(2020-04-09)
● 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.
● ASBRs do not store EVPN routes or advertise EVPN routes to each other.
Figure 3-82 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.

(2020-04-09)
Figure 3-83 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
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.

(2020-04-09)
Table 3-8 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.
On the network shown in Figure 3-84, 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-9.

(2020-04-09)
Figure 3-84 Basic DCI scenario

(2020-04-09)
Table 3-9 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-04-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-04-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-10 describes Layer 3 route advertisement and Layer 2 route
advertisement.

(2020-04-09)
Table 3-10 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-04-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-04-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-04-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-04-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-11 describes Layer 2 traffic forwarding and Layer 3 traffic forwarding.

(2020-04-09)
Table 3-11 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-04-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-04-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-04-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-04-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-04-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.
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-85 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-04-09)
Figure 3-85 NFVI distributed gateway networking
Function Deployment
In NFVI distributed gateway networking (SR tunnels) shown in Figure 3-85, 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-04-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-86 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-85)
connecting to non-direct-link L2GW/L3GWs, MAC entries include the

(2020-04-09)
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.
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-87 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.
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.
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.

(2020-04-09)
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-88 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-04-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-04-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-04-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-04-09)
Figure 3-92 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-85 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-85 as
an example, because the Add-Path function is deployed on L2GW/

(2020-04-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-93, 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-04-09)
Figure 3-93 North-south traffic forwarding from mobile phones to the Internet
As shown in Figure 3-94, 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-04-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-04-09)
Figure 3-94 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-95, 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-04-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-95 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-04-09)
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-96 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-04-09)
Function Deployment
On the network shown in Figure 3-96, 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-04-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-04-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-98 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
interface is used as the outbound interface in MAC entries. For the IPU

(2020-04-09)
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.
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-99 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-04-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-04-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-96 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-04-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-04-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-04-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-04-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-04-09)
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-105 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-04-09)
Function Deployment
On the network shown in Figure 3-105, 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-04-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-04-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.
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-04-09)
Figure 3-108 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-04-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-04-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-105 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-04-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-04-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-04-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-04-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.
Networking Description
On the network shown in Figure 3-114, the first layer is the user-side access
network where Layer 2 services are carried between CPEs and UPEs to implement

(2020-04-09)
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-114 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-04-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-04-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. In addition, EVPN enables PEs to use locally stored
MAC addresses to respond to ARP Request messages from connected sites,
minimizing the number of broadcast ARP Request messages.
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-04-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-04-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-04-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-04-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-04-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-04-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-04-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-04-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-04-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-04-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-04-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-04-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-04-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-04-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-04-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-04-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-04-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-04-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-04-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-04-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-04-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-04-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-04-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 EVPN service can be configured on a board only after EVPN interface licenses
are activated on the board in CM mode.

(2020-04-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.
This command applies only to CM boards on which the EVPN function is license-
specific.
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-115, to allow Layer 2 networks at different
sites to communicate, configure EVPN. Specifically:

(2020-04-09)
● 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.
● 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.
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

Configure EVPN instances on PEs to manage EVPN routes.

(2020-04-09)
Context
EVPN instances isolate EVPN routes from public network routes, and the routes of
EVPN instances from each other. EVPN instances are required in all EVPN
networking solutions.
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 EVPN instance takes effect only after the RD is configured. The RDs of different
EVPN instances on a PE must be different.
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.
Step 5 Run vpn-target vpn-target &<1-8> [ both | export-extcommunity | import-

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 for
an EVPN instance address family, run the vpn-target command several times.
The RT used by an Ethernet segment route is generated based on the middle six bytes of
the ESI. For example, if the ESI is 0011.1001.1001.1001.1002, then 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 EVPN instance is configured to filter MAC advertisement routes to be sent.
An export routing policy must be configured for precise EVPN route control. An
export routing 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 MAC advertisement routes received.

(2020-04-09)
An import routing policy must also be configured for precise EVPN route control.
An import routing policy filters routes that are received from other PEs.
Step 8 (Optional) Run mac limit number [ simply-alert | mac-unchanged ]
The maximum number of MAC addresses allowed by an EVPN instance is

configured.
After a device learns a large number of MAC addresses, system performance may
deteriorate when the device is busy processing services. This is because MAC
addresses consume system resources. To improve system security and reliability,
run the mac limit command to configure the maximum number of MAC
addresses allowed by an EVPN instance. If the number of MAC addresses learned
by an EVPN instance exceeds the maximum number, the system displays an alarm
message, instructing you to check the validity of MAC addresses in the EVPN
instance.
After you configure the maximum number of MAC addresses allowed by an EVPN
instance, you can run the mac threshold-alarm upper-limit upper-limit-value
lower-limit lower-limit-value command to configure the upper and lower
thresholds for triggering MAC address alarms. This command enables you to learn
MAC address usage based on MAC address alarm reporting and clearing.
Step 9 (Optional) Run tnl-policy policy-name
The EVPN instance is associated with a tunnel policy.
This configuration enables PEs to use TE tunnels to transmit data packets.
Step 10 (Optional) Run isolate spoken
Forwarding isolation is enabled in the EVPN instance.
When users who use the same service are bound to the same EVPN instance,
configuring forwarding isolation in the EVPN instance prevents the users from
accessing each other.
Step 11 (Optional) Run control-word enable
The EVPN 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 EVPN control word function so that MPLS packets can be reassembled
using the control word.
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.

(2020-04-09)
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 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

Configure the same ESI for PE interfaces connecting to the same CE.

(2020-04-09)
Context
PEs connecting to the same CE must have the same ESI configured. PEs exchange
routes that carry ESIs, so that a PE can discover other PEs connecting to the same
CE as itself. This helps implement load balancing.
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.
● An ESI-configured interface must be Up. If the interface is Down, Ethernet
segment routes cannot be generated. When a CE is dual-homed to PEs, Eth-
Trunk interfaces have to be configured on the CE and PEs so that they can
access each other. To ensure fast convergence, configuring an E-Trunk
between the two PEs is recommended.
An ESI can be either statically configured or dynamically generated on an
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.
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 the ESI is optional on a single-homing PE.
A dynamically generated ESI is in the format of xxxx.xxxx.xxxx.xxxx.xxxx where x is a
hexadecimal number. Such an ESI starts with 01 and then the system MAC address of the LACP
and the port key. The rest is padded with 0.
Procedure
● (Optional) Configure E-Trunk.
a. Run system-view
b. Run e-trunk e-trunk-id
E-Trunk is configured, and the E-Trunk view is displayed.
c. Run priority priority
A priority is configured for the E-Trunk.
d. 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.
e. Run quit
f. Run interface eth-trunk trunk-id
The Eth-Trunk interface view is displayed.
g. Run e-trunk e-trunk-id
The Eth-Trunk interface is added to the E-Trunk.

(2020-04-09)
One Eth-Trunk interface can be added only to one E-Trunk mechanism.

h. (Optional) Run e-trunk mode force-master
The working mode of E-Trunk member interfaces is configured as master.
In dual-active scenarios, this command needs to be run to achieve dual-

master-PE for traffic load balancing. In single-active scenarios, this
command does not need to be configured on PEs, and the evpn
redundancy-mode single-active command must be run.
i. Run quit

j. Run lacp e-trunk system-id mac-address
An E-Trunk LACP system ID is configured.
The LACP system IDs in one E-Trunk mechanism must be the same.
k. (Optional) Run lacp e-trunk priority priority
An E-Trunk LACP system priority is configured.
The LACP system priorities in one E-Trunk mechanism must be the same.
l. Run commit

● Statically configure an ESI on an interface.
a. Run system-view


c. Run esi esi
An ESI is configured.
d. Run commit

● 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 configured as static LACP.

d. Run commit
----End

(2020-04-09)
3.2.4.5 Configuring a BGP EVPN Peer Relationship

After two PEs establish a BGP EVPN peer relationship, they can exchange EVPN
routes.
Context
In EVPN networking, PEs need to have BGP EVPN peer relationships established
before they can exchange EVPN route information and implement communication
between EVPN instances.
Perform the following steps on each PE.
Procedure
Step 2 Run bgp as-number
Step 3 Run peer ipv4-address as-number as-number
A BGP EVPN peer IP address is specified.
Step 4 Run peer ipv4-address connect-interface loopback interface-number
The interface on which a TCP connection to the specified peer is to be established
is specified.
A PE must use a loopback interface address with a 32-bit mask to set up an MP-IBGP peer
relationship with the peer PE, so that VPN routes can be relayed to tunnels. The routes to
the local loopback interface are 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
The capability to exchange EVPN routes with the specified peer is enabled.
Step 7 (Optional) Run peer ipv4-address group group-name
The BGP EVPN peer is added to a 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 DF election delay is configured.
If the network is unstable, the PE interfaces connecting to a CE will frequently
alternate between Up and Down, resulting in frequent DF elections. As a result,
the network performance deteriorates. To prevent frequent DF elections, run the

(2020-04-09)
timer df-delay command to set a greater DF election delay. This ensures that the
network remains stable.
In an EVPN dual-homing scenario where interface-based DF election is enabled,
you need to run this command to set the delay interval for DF election to 0s
prevent the long-time existence of dual backup devices during 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 advertisement routes that can be received from
each peer is configured.
If an EVPN instance may import many invalid MAC advertisement routes from
peers and these routes occupy a large proportion of the total MAC advertisement
routes. If the received MAC advertisement routes exceed 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 10 (Optional) Perform the following operations to enable the function to advertise
the routes carrying the large-community attribute to BGP EVPN peers:
The large-community attribute includes a 2-byte or 4-byte AS number and two 4-
byte LocalData fields, allowing the administrator to flexibly use 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 peer { ipv4-address | group-name } route-policy route-policy-name
export
The outbound route-policy of the BGP EVPN peer is configured.
2. Run peer { ipv4-address | group-name } advertise-large-community
The device is enabled to advertise the routes carrying the large-community
attribute to BGP EVPN peers or peer groups.
If the routes carrying the large-community attribute does not need to be
advertised to one BGP EVPN peer in the peer group, run the peer ipv4-
address advertise-large-community disable command.
Step 11 Run commit
----End
3.2.4.6 (Optional) Configuring a PE's 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 an EVPN PE to

(2020-04-09)
work with other EVPN PEs in load-balancing mode, change its global redundancy
mode to Single-Active. In Single-Active mode, the master PE used to transmit
traffic is determined based on DF election or the active/standby status of access-
side Eth-Trunk interfaces.
Procedure
Step 2 Run evpn redundancy-mode single-active
The Single-Active redundancy mode is configured.
Step 3 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 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.
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

(2020-04-09)
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) Configuring the Redundancy Mode and DF Precedence by

ESI
In a scenario where multiple CEs are dual-homed to PEs, if users want BUM traffic
to be transmitted to different CEs in different modes (load balancing or non-load
balancing) or want the master DF to be specified by configuring a precedence, you
can configure the redundancy mode and DF precedence by ESI.
Context
On the network shown in Figure 3-116, CE1 and CE2 are each dual-homed to PE1
and PE2. The PE interfaces that connect to CE1 have ESI1 (shown in green), and
the PE interfaces that connect to CE2 have ESI2 (shown in blue). 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.
If users want the BUM traffic to be sent from CE3 to CE2 to be forwarded over
PE1, configure the DF precedence by ESI on PE1 and PE2 and specify PE1 as the
master DF.
Figure 3-116 Setting a redundancy mode per ESI instance

(2020-04-09)
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 with a specific name is created. The value of the esi
variable must be the same as the statically configured ESI.
d. Run evpn redundancy-mode { single-active | all-active }
A redundancy mode is set for the static ESI instance.

e. (Optional) Run df-election type preference-based
The preference-based DF election function is enabled.

f. (Optional) Run preference preference
A preference is configured. A larger value indicates a higher priority.

g. (Optional) Run non-revertive
The non-revertive function is enabled. As shown in Figure 3-116, CE2 is

dual-homed to PE1 and PE2. In this example, PE1 is elected as the master
DF for traffic forwarding because of a higher precedence. If PE4 that has
a higher DF precedence than PE1 is deployed on the network, PE4
becomes the master DF and traffic is switched to PE4 for forwarding. If
users do not want traffic switching, run the non-revertive command on
PE1 to enable the non-revertive 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 with a specific name is created.

A redundancy mode is set for the dynamic ESI instance.


(2020-04-09)

h. Run quit
The ESI-DYNAMIC view is displayed.
i. Run quit
j. Run quit
k. Run interface eth-trunk trunk-id
The view of an Eth-Trunk interface is displayed.
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.
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

(2020-04-09)
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
interface-type interface-number
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
3.2.4.10 (Optional) Board Selection for Internal Loopback on a Main Control

Board
When packets enter a public network from an EVPN or BD EVPN for broadcast,
unknown unicast, and multicast (BUM) forwarding, you can enable board
selection for internal loopback on a main control board to improve the link
switching performance.
Context
Currently, EVPN, VPLS, L2MC, and L3MC services use the internal GRE reserved
interfaces to implement public-network-and-private-network decoupling in the
BUM forwarding process. When a loopback board is removed, the BUM traffic is
interrupted for a short time. In addition, when any board is inserted or removed,
transient packet loss or extra packet generation may occur on the leaf nodes of
the other boards.

(2020-04-09)
Procedure
Step 2 Run evpn reserve-interface enhancement
Board selection for internal loopback on a main control board is enabled when
packets enter a public network from an EVPN or BD EVPN for BUM forwarding.
When packets enter a public network from an EVPN or BD EVPN for BUM
forwarding, board selection for internal loopback is performed based on interface
boards by default. To enable board selection for internal loopback on a main
control board, run the evpn reserve-interface enhancement command. 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.
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.
● 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.

(2020-04-09)
● 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.
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 EVPN instances from each other. EVPN instances are required in all EVPN
networking solutions.

(2020-04-09)
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.
Step 3 (Optional) Run description description-information
A description is configured for the EVPN instance.
Similar to the description of a host name or an interface, the EVPN instance
description helps users memorize the EVPN instance.
different EVPN instances on the same PE must be different.
An RD cannot be modified after being configured but can be deleted. If the RD of an EVPN
instance is deleted, VPN targets configured in the EVPN instance are also deleted.

extcommunity ]
A VPN target is a BGP extended community attribute 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.
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.
Step 6 (Optional) Run filter-policy { acl-number | acl-name acl-name } export

The EVPN instance is configured to filter MAC advertisement 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 advertised to other PEs.
Step 7 (Optional) Run filter-policy { acl-number | acl-name acl-name } import
The EVPN instance is configured to filter MAC advertisement routes received.
To precisely control EVPN routes, an import route-policy must also 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-04-09)
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 running may be affected when the system processes
many services. 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 reported to prompt you to check the validity of existing
MAC addresses.
After the maximum number of MAC addresses allowed by an EVPN instance is set,
you can run the mac threshold-alarm upper-limit upper-limit-value lower-limit
lower-limit-value command to set the upper and lower thresholds for triggering
MAC address alarms. The alarm generation and clearance help you detect
threshold-crossing events of MAC addresses.
Step 9 (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

or SR tunnel.
Step 10 (Optional) Run bypass-vxlan disable
The inter-chassis VXLAN function is disabled from the instance.
By default, after the bypass-vxlan enable command is globally run, the device
can be deployed only with EVPN VXLAN-related functions. This step needs to be
performed if users want to configure EVPN MPLS-related functions for some BD-
EVPN instances.
The EVPN control-word function is enabled.
enable the EVPN control word function so that MPLS packets can be reassembled
Step 12 Run commit
----End
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.

(2020-04-09)
Procedure
Step 2 Run evpn source-address ip-address
Step 3 Run commit
----End
3.2.5.3 Configuring an ESI

Ethernet segment identifiers (ESIs) must be configured for interfaces connecting
PEs to CEs. Different PE interfaces connecting to the same CE must have the same
ESI configured.
Context
PEs connecting to the same CE must have the same ESI configured. In this way,
the PEs exchange routes that carry ESIs, so that a PE can discover other PEs
connecting to the same CE as itself. This helps implement load balancing or FRR.
ESI-configured interfaces must be Up. If the interface is Down, Ethernet segment
routes cannot be generated. When a CE is dual-homed to PEs, Eth-Trunk interfaces
have to be configured on the CE and PEs so that they can access each other. In
this case, however, one of the Eth-Trunk interfaces that connect the CE to the PEs
is Down. To ensure that both Eth-Trunk interfaces are Up, configure an E-Trunk
between the two PEs.
An ESI can be obtained for an interface in the following ways:
● Statically configured
● Dynamically generated
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.
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. Therefore, configuring an ESI on
a single-homed PE is optional.
Procedure
● (Optional) Configure an E-Trunk.
a. Run system-view
b. Run e-trunk e-trunk-id

(2020-04-09)
An E-Trunk is configured, and the E-Trunk view is displayed.

c. Run priority priority
The E-Trunk priority is configured.
d. 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.
e. Run quit
f. Run interface eth-trunk trunk-id
g. Run e-trunk e-trunk-id
The Eth-Trunk interface is added to the E-Trunk.
One Eth-Trunk interface can be added only to one E-Trunk.
h. (Optional) Run e-trunk mode force-master
The working mode of E-Trunk member interfaces is configured as master.
In dual-active scenarios, this command needs to be run to achieve dual-
master-PE for traffic load balancing. In single-active scenarios, this
command does not need to be configured on PEs, and the evpn
redundancy-mode single-active command must be run.
i. Run quit
j. Run lacp e-trunk system-id mac-address
An LACP system ID is configured for the E-Trunk.
The LACP system IDs for the same E-Trunk must be the same.
k. (Optional) Run lacp e-trunk priority priority
An LACP system priority is configured for the E-Trunk.
The LACP system priorities for the same E-Trunk must be the same.
l. Run commit
● 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

(2020-04-09)
● Manually configure an ESI for an interface.
Perform this configuration if a VLAN is used to access an EVPN.
a. Run system-view

The view of an interface is displayed.

c. Run esi esi
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 view of a BD is displayed.

c. Run esi esi
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.
Context
An EVPN instance can be bound to a BD using a VXLAN Network Identifier (VNI)
or using MPLS.
● In VNI mode, an EVPN instance is bound to a BD after a VNI is configured. If

an EVPN instance needs to access a VPLS network, the EVPN instance must
be bound to a BD in VNI mode.
● In MPLS mode, an EVPN instance is bound to a BD directly in the BD view.
Procedure

(2020-04-09)
Step 2 Run bridge-domain bd-id
The view of the BD to which an EVPN instance will be bound is displayed.
Step 3 (Optional) 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.
Step 4 Run evpn binding vpn-instance evpn-name [ bd-tag bd-tag ]
An 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.
Step 5 Run quit
Step 6 Run interface interface-type interface-number.subnum mode l2
Before running this command, ensure that the Layer 2 interface on which the 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.
Step 7 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 8 Run rewrite pop { single | double }
The traffic behavior is set to pop so that the Ethernet sub-interface removes VLAN
tags from received packets.
For single-tagged packets that a Layer 2 sub-interface receives, specify single to

remove the tags from these packets.
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 so that the sub-interface can

transmit data packets through this BD.
Step 10 Run commit
----End

(2020-04-09)
3.2.5.5 Creating an L3VPN Instance and Binding It to a VBDIF Interface

If you want to use an EVPN to transmit Layer 3 services, you must 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 Configuring an L3VPN Instance.

2. Run ipv4-family
The IPv4 address family is enabled for the VPN instance, and the VPN
instance IPv4 address family view is displayed.
extcommunity ] evpn
VPN targets are configured for the VPN instance IPv4 address family to
mutually import routes with the local EVPN instance.
5. Run evpn mpls routing-enable
EVPN is enabled to generate and advertise IP prefix routes and IRB routes.
EVPN routes that can be imported into the VPN instance IPv4 address family
are associated with a tunnel policy.
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

(2020-04-09)
9. Run quit
Exit from the VPN instance IPv4 address family view.
10. Run quit
Exit from the VPN instance view.

2. Run ipv6-family
extcommunity ] evpn
9. Run quit
10. Run quit
Step 3 Run interface vbdif bd-id
A VBDIF interface is created, and the VBDIF interface view is displayed.
Step 4 Run ip binding vpn-instance vpn-instance-name
The L3VPN instance is bound to the VBDIF interface.

(2020-04-09)
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-mask }
An IPv4/IPv6 address is configured for the VBDIF interface to implement Layer 3
interworking.
Step 7 (Optional) Run mac-address mac-address
A MAC address is configured for the VBDIF interface.
Step 8 Run vxlan anycast-gateway enable
Distributed gateway is enabled.
After distributed gateway is enabled, the discards the ARP/ND messages received
from the network side and learns only ARP/ND messages from the user side and
generates host routes.
Step 9 Run arp collect host enable or ipv6 nd collect host enable
The function to advertise hots ARP/ND routes and IRB/IRBv6 routes is enabled.
Step 10 Run commit
----End
3.2.5.6 Configuring a BGP EVPN Peer Relationship

After two PEs establish a BGP EVPN peer relationship, they can exchange EVPN
routes.
Context
In EVPN networking, PEs need to have BGP EVPN peer relationships established
before they can exchange EVPN route information and implement communication
between EVPN instances.
Perform the following steps on each PE.
Procedure
A BGP EVPN peer IP address is specified.

(2020-04-09)
The interface on which a TCP connection to the specified peer is to be established

is specified.
A PE must use a loopback interface address with a 32-bit mask to set up an MP-IBGP peer
relationship with the peer PE, so that VPN routes can be relayed to tunnels. The routes to
the local loopback interface are advertised to the peer PE using an IGP on the MPLS
backbone network.

The capability to exchange EVPN routes with the specified peer is enabled.
Step 7 (Optional) Run peer ipv4-address group group-name
The BGP EVPN peer is added to a peer group.
Adding BGP EVPN peers to peer groups simplifies BGP network configuration and
management.
Step 8 Run peer { ipv4-address | group-name } advertise { irb | arp | irbv6 | nd }
IRB/IRBv6 or ARP/ND route advertisement is configured.
Step 9 (Optional) Run timer df-delay delay-value
A DF election delay is configured.
If the network is unstable, the PE interfaces connecting to a CE will frequently
alternate between Up and Down, resulting in frequent DF elections. As a result,
the network performance deteriorates. To prevent frequent DF elections, run the
timer df-delay command to set a greater DF election delay. This ensures that the
network remains stable.
In an EVPN dual-homing scenario where interface-based DF election is enabled,
you need to run this command to set the delay interval for DF election to 0s
prevent the long-time existence of dual backup devices during switchback from
causing a traffic interruption.
Step 10 (Optional) Run peer { group-name | ipv4-address } mac-limit number
The maximum number of MAC advertisement routes that can be received from
each peer is configured.
If an EVPN instance may import many invalid MAC advertisement routes from
peers and these routes occupy a large proportion of the total MAC advertisement
routes. If the received MAC advertisement routes exceed 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 11 (Optional) Run route-select delay delay-value [ exclusive-eviad ]
The route selection delay function is configured. After the primary path is restored,
this function allows route selection to be performed after the forwarding entries
are updated on the devices on the primary path. This prevents traffic loss caused

(2020-04-09)
by switchback. The exclusive-eviad parameter can be specified to enable the

route selection delay function for non-EVI AD routes. If users want EVPN VPWS
not be affected after the route selection delay function is enabled, set this
parameter.
Step 12 (Optional) Perform the following operations to enable the function to advertise
the routes carrying the large-community attribute to BGP EVPN peers:
The large-community attribute includes a 2-byte or 4-byte AS number and two 4-

byte LocalData fields, allowing the administrator to flexibly use 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 peer { ipv4-address | group-name } route-policy route-policy-name

export
The outbound route-policy of the BGP EVPN peer is configured.

2. Run peer { ipv4-address | group-name } advertise-large-community
The device is enabled to advertise the routes carrying the large-community

attribute to BGP EVPN peers or peer groups.
If the routes carrying the large-community attribute does not need to be

advertised to one BGP EVPN peer in the peer group, run the peer ipv4-
address advertise-large-community disable command.
Step 13 (Optional) Run peer ipv4-address graceful-restart static-timer restart-time
The maximum duration from the time the local device finds that the peer device is
restarted to the time a BGP EVPN session is re-established is set.
BGP GR prevents traffic interruptions caused by re-establishment of a BGP peer

relationship. You can run either the graceful-restart timer restart time or peer
graceful-restart static-timer command to set this maximum wait time.
● To set the maximum wait time for re-establishing all BGP peer relationships,
run the graceful-restart timer restart command in the BGP view. The
maximum wait time can be set to 3600s at most.
● To set the maximum wait time for re-establishing a specified BGP-EVPN peer
relationship, run the peer graceful-restart static-timer command in the BGP
EVPN view. The maximum wait time can be set to a value greater than 3600s.
If both the graceful-restart timer restart time and peer graceful-restart static-
timer commands are run, the latter configuration takes effect.
This step can be performed only after GR has been enabled using the graceful-restart
command in the BGP view.
Step 14 Run commit
----End

(2020-04-09)
3.2.5.7 (Optional)Configuring a PE's 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 an EVPN PE to
work with other EVPN PEs in load-balancing mode, change its global redundancy
mode to Single-Active. In Single-Active mode, the master PE used to transmit
traffic is determined based on DF election or the active/standby status of access-
side Eth-Trunk interfaces.
Procedure
The Single-Active redundancy mode is configured.
Step 3 Run commit
----End
3.2.5.8 (Optional) Configuring the Redundancy Mode by ESI

In a scenario where multiple CEs are dual-homed to PEs, if users want BUM traffic
to be transmitted to different CEs in different modes (load balancing or non-load
balancing) or want the master DF to be specified by configuring a precedence, you
can configure the redundancy mode and DF precedence by ESI.
Context
On the network shown in Figure 3-117, CE1 and CE2 are each dual-homed to PE1
and PE2. The PE interfaces that connect to CE1 have ESI1 (shown in green), and
the PE interfaces that connect to CE2 have ESI2 (shown in blue). 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.
If users want the BUM traffic to be sent from CE3 to CE2 to be forwarded over
PE1, configure the DF precedence by ESI on PE1 and PE2 and specify PE1 as the
master DF.

(2020-04-09)
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 with a specific name is created. The value of the esi
variable must be the same as the statically configured ESI.
A redundancy mode is set for the static ESI instance.
h. Run commit
● Set a redundancy mode based on a dynamically generated ESI.

(2020-04-09)
a. Run system-view

b. Run evpn

c. Run esi dynamic-name esi-name
A dynamic ESI instance with a specific name is created.

A redundancy mode is set for the dynamic ESI instance.




h. Run quit
The ESI-DYNAMIC view is displayed.

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.

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.

(2020-04-09)
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
----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.

(2020-04-09)
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.
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.

(2020-04-09)
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

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

(2020-04-09)
● 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.
● 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.

(2020-04-09)
Figure 3-118 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 provides a P2P L2VPN service solution based on the EVPN service
architecture. Before configuring EVPN VPWS over MPLS, you must configure EVPN
functions.
Configuration Procedures
To configure EVPN functions, see 3.2.4 Configuring Common EVPN Functions.
3.2.6.2 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.

(2020-04-09)
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
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.

(2020-04-09)
The EVPL control-word function is enabled.
enable the EVPL control word function so that MPLS packets can be reassembled
Step 12 Run commit
----End
3.2.6.3 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.
Procedure
Step 2 Run interface interface-type interface-number.subnum mode l2
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

(2020-04-09)
3.2.6.4 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.
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.
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

(2020-04-09)
----End
3.2.6.5 (Optional) Configuring DF Election

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, you can enable designated forwarder
(DF) election on the multi-homing PEs to determine the primary and backup DFs.
Context
The following figure shows the EVPN VPWS multi-homing scenario. CE1 is dual-
homed to PE1 and PE2, and MPLS LDP tunnels are established between PE1 and
PE3 and between PE2 and PE3 so that CE1 and CE2 can communicate with each
other. When PEs work in single-active mode and no E-Trunk is configured, to
prevent CE1 from receiving duplicate traffic from both PE1 and PE2, DF election
must be enabled on PE1 and PE2 so that a primary DF is selected to forward BUM
traffic. This helps save network resources.
Figure 3-119 Configuring DF election
Procedure
Step 2 Run evpn
The global EVPN configuration view is created and displayed.
Step 3 Run vpws-df-election type service-id
Service ID-based DF election is configured.
In addition to configuring service ID-based DF election, you can configure VLAN-based DF

election using the df-election type vlan command.
Step 4 Run commit

(2020-04-09)
----End
3.2.6.6 (Optional) Configuring FRR

In an EVPN VPWS over MPLS scenario where multi-homing in single-active mode
is enabled, you can configure fast reroute (FRR) to prevent traffic loss on the
primary PE in case of a fault.
Usage Scenario
The following figure shows the EVPN VPWS over MPLS scenario where CE1 is
dual-homed to PE1 and PE2 in single-active mode. PE3 forwards traffic only to the
primary PE according to the primary/backup DF status of PE1 and PE2. If PE1 is
the primary DF, the path marked red between CE1 and CE2 is the primary path,
and path marked blue is the backup path. To prevent a fault on the primary path
from causing a traffic loss, FRR must be configured.
In normal conditions, downstream traffic on PE3 is sent to PE1. After local and
remote FRR functions are configured on PE1 and PE2, if PE1 detects a link fault
between itself and CE1, PE1 forwards traffic to PE2, and then PE2 forwards traffic
to CE1. After remote FRR is enabled on PE3, if PE3 detects a link fault between
itself and PE1, PE3 quickly switches traffic to PE2, and then PE2 forwards traffic to
CE1.
Figure 3-120 Configuring FRR
Procedure
● Configure local and remote FRR functions on PE1 and PE2.
a. Run system-view

(2020-04-09)

The view of an EVPN instance for a VPWS is displayed.
c. Run local-remote frr enable
Local and remote FRR functions are enabled in the EVPN instance.
In addition to enabling local and remote FRR functions in an EVPN instance, you
can enable local and remote FRR functions globally using the local-remote
vpws-frr enable command in the global EVPN view.
d. Run commit
● Configure remote FRR on PE3.
a. Run system-view
The view of an EVPN instance for the VPWS is displayed.
c. Run remote frr { enable | disable }
Remote FRR is enabled in the EVPN instance.
In addition to enabling remote FRR in the EVPN instance view, you can also
enable remote FRR globally using the remote vpws-frr enable command in the
global EVPN view. By default, if the remote frr enable command is not run in
the VPWS-EVPN instance view, the remote vpws-frr enable command
configuration in the global view takes effect. If both the remote frr enable
command and the remote vpws-frr enable command are run, the remote frr
enable command configuration takes effect.
d. Run commit
----End
3.2.6.7 Verifying the Configuration of EVPN VPWS over MPLS Functions

After configuring EVPN VPWS over MPLS functions, verify the configuration.
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

(2020-04-09)
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-121, 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.
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-121 Intra-AS mutual VPN communication
● Inter-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 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.

(2020-04-09)
Figure 3-122 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-123, 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.
each PE and DC-GW to mutually transmit VM IP routes.
Figure 3-123 DCI network

(2020-04-09)
● 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 Configuring an L3VPN Instance.

2. Run ipv4-family
extcommunity ] evpn

(2020-04-09)

9. Run quit
10. Run quit

2. Run ipv6-family
extcommunity ] evpn
9. Run quit
10. Run quit

(2020-04-09)
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-mask }
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.
If a BGP RR needs to be configured on the network, establish BGP EVPN peer

relationships between all the PEs and the RR.

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.

(2020-04-09)
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.
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
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

(2020-04-09)
● (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.
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,

(2020-04-09)
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
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
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-124, an L3VPN is already deployed. If a user
wants to deploy an EVPN L3VPN over the network, co-existence of the EVPN

(2020-04-09)
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-124 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 Configuring a BGP EVPN Peer Relationship.
● 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.
a. Run ip vpn-instance vpn-instance-name

b. Run ipv4-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.

(2020-04-09)
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
g. Run quit
h. Run commit
For IPv6 services, perform the following configurations.
a. Run ip vpn-instance vpn-instance-name
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).
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

(2020-04-09)
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
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 }

(2020-04-09)
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.
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-125, 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
network through the VPLS network, on which PW redundancy is configured.

(2020-04-09)
Specifically, the PE-AGG connects to PE1 and PE2 through primary and secondary
PWs, respectively.
Figure 3-125 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
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

(2020-04-09)
----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-126, 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.
Figure 3-126 Carrying multicast services over an EVPN

(2020-04-09)
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.
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

(2020-04-09)
● 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
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

(2020-04-09)
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).
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.

(2020-04-09)
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.
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.

(2020-04-09)
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.
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.

(2020-04-09)
● Configure an apply clause.

(Optional) Configuring an apply Clause helps you add or modify the
attributes of EVPN routes.
● Apply a route-policy.
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-04-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-04-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
Step 3 Run df-election type vlan
VLAN-based DF election is configured.
Step 4 Run commit
----End

After configuring VLAN-based DF election, check the configurations.

(2020-04-09)
Run the display evpn vpn-instance name vpn-instance-name df result command

to view the DF election result in the EVPN instance. The following example uses
the command output for the EVPN instance named evpna.
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-04-09)
Application Scenarios
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-127, 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-127 CE dual-homing networking

(2020-04-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-128, 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-128 CE dual-homing networking

(2020-04-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 scenario, a CE is dual-homed to

MAC routes on dual- two PEs. After FRR is enabled for MAC routes on dual-
homing PEs. 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-04-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-04-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-129, 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-04-09)
Figure 3-129 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-04-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.
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-04-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-04-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-04-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 2 Run bgp { as-number-plain | as-number-dot }
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
address family view.
Step 6 Run quit
Exit from the BGP-VT address family view.

(2020-04-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-130, 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-04-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-130 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-04-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-131, 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-131 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-04-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
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-04-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-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 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-04-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
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-04-09)
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-04-09)
▪ 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-133, 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.
Figure 3-133 Networking of VPLS splicing with MPLS EVPN E-LAN

(2020-04-09)
Before splicing VPLS with MPLS EVPN E-LAN, complete the following tasks:
● Configure LDP VPLS between CSGs and ASGs.
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.
The redundancy mode of the static ESI instance is set to single-active.
Step 5 Run quit
Return to the global EVPN configuration view.
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.
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.

(2020-04-09)
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
The BD view is displayed.
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.
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.

(2020-04-09)
Usage Scenario
On the network shown in , 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-134 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:
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.

(2020-04-09)
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.
● 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
3.2.22.2 Creating an L3VE Interface

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

(2020-04-09)
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
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

(2020-04-09)
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
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

(2020-04-09)
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.
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-135, 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.

(2020-04-09)
Figure 3-135 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.
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.

(2020-04-09)
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.
Context
In a MetroFabric scenario with CU separation deployed, as shown in Figure 3-136,
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.

(2020-04-09)
Figure 3-136 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.
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.

(2020-04-09)
Procedure
Step 1 Configure a BGP EVPN peer relationship between MEF1 and MEF2.
3. Run peer ipv4-address as-number as-number
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.
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.
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 }
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.

(2020-04-09)
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.
Step 4 Run commit
----End

(2020-04-09)

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-137, 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-137 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.
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.

(2020-04-09)
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.
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

(2020-04-09)
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
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).

(2020-04-09)
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
The device is configured to advertise EVPN routes carrying the VXLAN
encapsulation attribute to the TOR.
Step 10 Run quit

(2020-04-09)
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.
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
● 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.
a. Run system-view

(2020-04-09)
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-138, 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-138 Splicing VXLAN and VPLS

(2020-04-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.
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.
● 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-04-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
EVPN route information.
– 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-139 MPLS EVPN E-LAN Option B networking

(2020-04-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
The BGP-IPv4 unicast address family view is displayed.
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-04-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 BGP-IPv4 unicast address family view is displayed.
The function to exchange IPv4 routes with the peer ASBR is enabled.
Step 10 Run quit

(2020-04-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-04-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-04-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-04-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.
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-04-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-140 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-04-09)
Figure 3-140 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-04-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.
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 Configuring a BGP EVPN Peer
Relationship.
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-04-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
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-04-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 Configuring a BGP EVPN Peer
Relationship.
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-04-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-04-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.
● 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 Configuring a BGP EVPN Peer Relationship.
● 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-04-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.
● 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 Configuring a BGP EVPN Peer Relationship.
● 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-04-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
The BGP-VPNv4 address family view is displayed.
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-04-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-141 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-04-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-04-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 based on BGP EVPN IGMP Join Synch
routes is enabled in the BD.
d. (Optional) Run evi vpn-target
The EVI-RT extended community attributes of IGMP Join Synch routes are
associated with 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
d. Run igmp-snooping signal-ignore-df enable
The DF status ignoring function is enabled in the BD of the non-DF node.
e. Run evi vpn-target vrfRt [ vrfRtType ]
f. Run commit

(2020-04-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-SM 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

k. Run igmp-snooping signal-ignore-df enable
The DF status ignoring function is enabled in the BD of 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-04-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-142, 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-142 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,
complete the following tasks:
● On the network in area A, 2.2.5 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-04-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-04-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-143, 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-04-09)
Figure 3-143 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.13 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-04-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-04-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 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
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

(2020-04-09)
Figure 3-144 Configuring DCI functions
Before configuring DCI functions, configure MPLS tunnels over the DCI backbone
network.
3.2.31.1 Configuring a DCI Scenario with an E2E VXLAN EVPN Deployed on a

Gateway
An end-to-end VXLAN EVPN uses one service platform, which helps implement
unified VXLAN VNI resource management.
Context
GWs and DCI-PEs are separately deployed. DCI-PEs function as edge devices on
the underlay network and ensure VTEPs in data centers are reachable through
routes, without saving data center tenant and host information.
In Figure 3-145, data center gateways GW1 and GW2 are connected to the
backbone network. BGP/MPLS IP VPN functions are deployed on the DCI
backbone network to transmit VTEP IP information between GW1 and GW2. A
VXLAN tunnel is established between GW1 and GW2 for inter-data center E2E
VXLAN packet encapsulation and VM communication.

(2020-04-09)
Figure 3-145 Configuring a DCI Scenario with an E2E VXLAN EVPN Deployed on a
Gateway
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 Establish a VXLAN tunnel to GW1 on GW2. For configuration details, see
Configuring Device-specific VXLAN.
----End
3.2.31.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.
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-146, VXLAN tunnels are established within

(2020-04-09)
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-146 Configuring a DCI Scenario with a VLAN Layer 3 Sub-interface

Accessing a Common L3VPN
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.
The sub-interface is bound to a VPN instance.

An IP address is configured for the sub-interface.
Step 3 Run commit

(2020-04-09)
----End
3.2.31.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-147, 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.
Figure 3-147 Configuring a DCI scenario with a VXLAN EVPN L3VPN accessing a
common L3VPN

(2020-04-09)
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
{ 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

(2020-04-09)

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
3.2.31.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-148, 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.

(2020-04-09)
Figure 3-148 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-149, 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.
Figure 3-149 Configuring a DCI scenario with a VLAN base accessing an

MPLS EVPN IRB (PE and gateway are separately deployed)

(2020-04-09)
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.
The remote PE is specified as the BGP peer.
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.
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

(2020-04-09)

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.
2. Run ipv4-family
extcommunity ] evpn
9. Run quit

(2020-04-09)
10. Run quit


2. Run ipv6-family
extcommunity ] evpn
9. Run quit
10. Run quit
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.

(2020-04-09)
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-mask }
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.
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.

(2020-04-09)
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
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
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.

(2020-04-09)
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.
The reflector cluster-id command applies only to RRs.

6. Run quit

7. Run quit
Step 6 Run commit
----End

(2020-04-09)
3.2.31.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-150, 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.
Figure 3-150 Configuring a DCI Scenario with a VXLAN EVPN Accessing an MPLS
EVPN IRB

(2020-04-09)
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 ]
mutually import routes with the remote PE's L3VPN instance.
extcommunity ] evpn
10. Run quit

(2020-04-09)

11. Run quit

2. Run ipv6-family
extcommunity ]
mutually import routes with the remote PE's L3VPN instance.
extcommunity ] evpn
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.

(2020-04-09)
1. Run system-view
The remote DCI-PE is specified as the BGP peer.
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.
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.

(2020-04-09)
– 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.31.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.
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.
● Run the display bgp vpnv4 { all | route-distinguisher route-distinguisher |
vpn-instance vpn-instance-name } routing-table command to check BGP
VPNv4 route information.

(2020-04-09)
● Run the display bgp vpnv6 { all | route-distinguisher route-distinguisher |

vpn-instance vpn-instance-name } routing-table command to check BGP
VPNv6 route information.
----End
3.2.32 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.
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

(2020-04-09)
routes sent by external devices based on the BGP VPNv4/v6 peer

relationships.
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.
Figure 3-151 Networking of an NFVI distributed gateway (SR tunnels)

(2020-04-09)
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.
3.2.32.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


c. Run tunnel-prefer segment-routing
SR-MPLS BE tunnels are enabled to take precedence over LDP tunnels.

d. Run commit
----End

(2020-04-09)
3.2.32.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.
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.

(2020-04-09)
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.
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

(2020-04-09)
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 }
A BGP VPN peer relationship is established.
6. Run peer { ipv4-address | ipv6-address | group-name } connect-interface
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

(2020-04-09)
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.

3. Run irb asymmetric
The asymmetric mode is enabled for IRB routes.

4. Run quit
Step 5 Run commit
----End
3.2.32.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

(2020-04-09)
– 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.
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

(2020-04-09)

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

(2020-04-09)
3.2.32.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.
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


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.


(2020-04-09)

c. Run maximum load-balancing [ ebgp | ibgp ] number [ ecmp-
nexthop-changed ]
d. Run quit
enabled.
g. Run quit
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

(2020-04-09)

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
3.2.32.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
Example
If the configuration succeeds, the display bgp vpnv4 vpn-instance vpn-instance-
name peer or display bgp vpnv6 vpn-instance vpn-instance-name peer

(2020-04-09)
command output shows that VPN peer relationships have been established
between DC-GWs and VNFs.
# In IPv4 NFVI distributed gateway scenarios:
<DCGW> display bgp vpnv4 vpn-instance vpn1 peer



5.5.5.5 4 100 8136 8135 0 0118h05m Established 4
6.6.6.6 4 100 8140 8167 0 0118h07m Established 0



2001:DB8:5::5 4 100 7136 7135 0 0118h05m Established 4
2001:DB8:6::6 4 100 7140 7167 0 01:59:11 Established 0
The display bgp vpnv4 vpn-instance vpn-instance-name routing-table or

display bgp vpnv6 vpn-instance vpn-instance-name routing-table command
output shows that DC-GWs have received mobile phone routes from VNFs and the
next-hop addresses of the mobile phone routes are VNF addresses.
# In IPv4 NFVI distributed gateway scenarios (in this example, the destination IPv4
address of mobile phone routes is 10.10.10.10):
<DCGW> display bgp vpnv4 vpn-instance vpn1 routing-table


*>i 5.5.5.5/32 1.1.1.1 0 100 0 ?

*i 1.1.1.1 0 100 0 ?
i 5.5.5.5 0 100 0 ?
*>i 6.6.6.6/32 1.1.1.1 0 100 0 ?
*i 2.2.2.2 0 100 0 ?
*i 2.2.2.2 0 100 0 ?
*> 10.1.1.0/24 0.0.0.0 0 0 ?
*i 5.5.5.5 0 100 0 ?
*> 10.1.1.1/32 0.0.0.0 0 0 ?
*> 10.2.1.0/24 0.0.0.0 0 0 ?
*i 5.5.5.5 0 100 0 ?
*> 10.2.1.1/32 0.0.0.0 0 0 ?
*> 10.3.1.0/24 0.0.0.0 0 0 ?
*> 10.3.1.1/32 0.0.0.0 0 0 ?
*> 10.4.1.0/24 0.0.0.0 0 0 ?
*> 10.4.1.1/32 0.0.0.0 0 0 ?
*>i 10.10.10.10/32 5.5.5.5 0 100 0 ?

(2020-04-09)
*> 33.33.33.33/32 0.0.0.0 0 0 ?

*>i 44.44.44.44/32 9.9.9.9 0 100 0 ?
*> 127.0.0.0/8 0.0.0.0 0 0 ?
address of mobile phone routes is 2001:DB8:10::10):


*> Network : :: PrefixLen : 0
NextHop : :: LocPrf :
MED :0 PrefVal : 32768
Label :
Path/Ogn : i
*i
NextHop : ::FFFF:9.9.9.9 LocPrf : 100
MED :0 PrefVal : 0
Label : 200/NULL
Path/Ogn : i
*> Network : 2001:DB8:1:: PrefixLen : 64
MED :0 PrefVal : 0
Label :
Path/Ogn : ?
*> Network : 2001:DB8:1::1 PrefixLen : 128
MED :0 PrefVal : 0
Label :
Path/Ogn : ?
MED :0 PrefVal : 0
Label :
Path/Ogn : ?
MED :0 PrefVal : 0
Label :
Path/Ogn : ?
MED :0 PrefVal : 0
Label :
Path/Ogn : ?
MED :0 PrefVal : 0
Label :
Path/Ogn : ?
MED :0 PrefVal : 0
Label :
Path/Ogn : ?
MED :0 PrefVal : 0
Label :
Path/Ogn : ?
*>i Network : 2001:DB8:5::5 PrefixLen : 128

(2020-04-09)

MED :0 PrefVal : 0
Label :
Path/Ogn : ?
*i
MED :0 PrefVal : 0
Label :
Path/Ogn : ?
MED :0 PrefVal : 0
Label :
Path/Ogn : ?
*i
MED :0 PrefVal : 0
Label :
Path/Ogn : ?
*i
MED :0 PrefVal : 0
Label :
Path/Ogn : ?
NextHop : 2001:DB8:5::5 LocPrf :
MED :0 PrefVal : 0
Label :
Path/Ogn : ?
MED :0 PrefVal : 0
Label :
Path/Ogn : ?
MED :0 PrefVal : 0
Label : 200/NULL
Path/Ogn : ?
*> Network : FE80:: PrefixLen : 10
MED :0 PrefVal : 0
Label :
Path/Ogn : ?
The display ip routing-table vpn-instance vpn-instance-name or display ipv6

routing-table vpn-instance vpn-instance-name command output shows that the
VPN routing tables of DC-GWs include mobile phone routes and the outbound
interfaces of the mobile phone routes are VBDIF interfaces.
<DCGW> display ip routing-table vpn-instance vpn1
------------------------------------------------------------------------------
0.0.0.0/0 Static 60 0 DB 0.0.0.0 NULL0

5.5.5.5/32 IBGP 255 0 RD 10.2.1.2 Vbdif20
IBGP 255 0 RD 10.1.1.2 Vbdif10
6.6.6.6/32 IBGP 255 0 RD 10.1.1.3 Vbdif10
IBGP 255 0 RD 10.3.1.2 Vbdif30
IBGP 255 0 RD 10.4.1.2 Vbdif40
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

(2020-04-09)
10.2.1.0/24 Direct 0 0 D 10.2.1.1 Vbdif20

10.2.1.1/32 Direct 0 0 D 127.0.0.1 Vbdif20
10.2.1.255/32 Direct 0 0 D 127.0.0.1 Vbdif20
10.3.1.0/24 Direct 0 0 D 10.3.1.1 Vbdif30
10.3.1.1/32 Direct 0 0 D 127.0.0.1 Vbdif30
10.3.1.255/32 Direct 0 0 D 127.0.0.1 Vbdif30
10.4.1.0/24 Direct 0 0 D 10.4.1.1 Vbdif40
10.4.1.1/32 Direct 0 0 D 127.0.0.1 Vbdif40
10.4.1.255/32 Direct 0 0 D 127.0.0.1 Vbdif40
10.10.10.10/32 IBGP 255 0 RD 5.5.5.5 Vbdif20
IBGP 255 0 RD 5.5.5.5 Vbdif10
44.44.44.44/32 IBGP 255 0 RD 4.4.4.4 VXLAN

<DCGW> display ipv6 routing-table vpn-instance vpn1
Destination : :: PrefixLength : 0
Cost :0 Protocol : Static

Interface : Vbdif10 Flags :D







(2020-04-09)


Interface : Vbdif20 Flags : RD







Interface : LoopBack2 Flags :D

RelayNextHop : :: TunnelID : 0x0000000027f0000001
Interface : VXLAN Flags : RD


(2020-04-09)

(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-152 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,
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

(2020-04-09)
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.

(2020-04-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-04-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.33.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-04-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-04-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-04-09)

export
18. Run quit
BGP-VPN instance.
22. Run quit
23. Run quit
2. Run quit

(2020-04-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-04-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-04-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-04-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.33.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. Enter the BGP-VPNv4 or BGP-VPNv6 address family view.


(2020-04-09)


enabled.
g. Run quit

h. Run quit

i. Run commit




nexthop-changed ]

d. Run quit


enabled.
g. Run quit

h. Run quit

i. Run commit


(2020-04-09)



nexthop-changed ]

d. Run quit


enabled.
number path-number

is configured.
i. Run quit

j. Run quit

k. Run commit
----End

Function

(2020-04-09)
Prerequisites
Procedure
addresses.
interfaces.
----End
Example



5.5.5.5 4 100 8136 8135 0 0118h05m Established 4
6.6.6.6 4 100 8140 8167 0 0118h07m Established 0



2001:DB8:6::6 4 100 7140 7167 0 01:59:11 Established 0


(2020-04-09)


*>i 5.5.5.5/32 1.1.1.1 0 100 0 ?

*i 1.1.1.1 0 100 0 ?
i 5.5.5.5 0 100 0 ?
*>i 6.6.6.6/32 1.1.1.1 0 100 0 ?
*i 2.2.2.2 0 100 0 ?
*i 2.2.2.2 0 100 0 ?
*> 10.1.1.0/24 0.0.0.0 0 0 ?
*i 5.5.5.5 0 100 0 ?
*> 10.1.1.1/32 0.0.0.0 0 0 ?
*> 10.2.1.0/24 0.0.0.0 0 0 ?
*i 5.5.5.5 0 100 0 ?
*> 10.2.1.1/32 0.0.0.0 0 0 ?
*> 10.3.1.0/24 0.0.0.0 0 0 ?
*> 10.3.1.1/32 0.0.0.0 0 0 ?
*> 10.4.1.0/24 0.0.0.0 0 0 ?
*> 10.4.1.1/32 0.0.0.0 0 0 ?
*>i 10.10.10.10/32 5.5.5.5 0 100 0 ?
*> 33.33.33.33/32 0.0.0.0 0 0 ?
*>i 44.44.44.44/32 9.9.9.9 0 100 0 ?
*> 127.0.0.0/8 0.0.0.0 0 0 ?


Label :
Path/Ogn : i
*i
MED :0 PrefVal : 0
Label : 200/NULL
Path/Ogn : i
MED :0 PrefVal : 0
Label :
Path/Ogn : ?

(2020-04-09)
MED :0 PrefVal : 0
Label :
Path/Ogn : ?
MED :0 PrefVal : 0
Label :
Path/Ogn : ?
MED :0 PrefVal : 0
Label :
Path/Ogn : ?
MED :0 PrefVal : 0
Label :
Path/Ogn : ?
MED :0 PrefVal : 0
Label :
Path/Ogn : ?
MED :0 PrefVal : 0
Label :
Path/Ogn : ?
MED :0 PrefVal : 0
Label :
Path/Ogn : ?
MED :0 PrefVal : 0
Label :
Path/Ogn : ?
*i
MED :0 PrefVal : 0
Label :
Path/Ogn : ?
MED :0 PrefVal : 0
Label :
Path/Ogn : ?
*i
MED :0 PrefVal : 0
Label :
Path/Ogn : ?
*i
MED :0 PrefVal : 0
Label :
Path/Ogn : ?
MED :0 PrefVal : 0
Label :
Path/Ogn : ?
MED :0 PrefVal : 0
Label :
Path/Ogn : ?

(2020-04-09)

MED :0 PrefVal : 0
Label : 200/NULL
Path/Ogn : ?
MED :0 PrefVal : 0
Label :
Path/Ogn : ?

------------------------------------------------------------------------------
0.0.0.0/0 Static 60 0 DB 0.0.0.0 NULL0

5.5.5.5/32 IBGP 255 0 RD 10.2.1.2 Vbdif20
IBGP 255 0 RD 10.1.1.2 Vbdif10
6.6.6.6/32 IBGP 255 0 RD 10.1.1.3 Vbdif10
IBGP 255 0 RD 10.3.1.2 Vbdif30
IBGP 255 0 RD 10.4.1.2 Vbdif40
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 Direct 0 0 D 10.2.1.1 Vbdif20
10.2.1.1/32 Direct 0 0 D 127.0.0.1 Vbdif20
10.2.1.255/32 Direct 0 0 D 127.0.0.1 Vbdif20
10.3.1.0/24 Direct 0 0 D 10.3.1.1 Vbdif30
10.3.1.1/32 Direct 0 0 D 127.0.0.1 Vbdif30
10.3.1.255/32 Direct 0 0 D 127.0.0.1 Vbdif30
10.4.1.0/24 Direct 0 0 D 10.4.1.1 Vbdif40
10.4.1.1/32 Direct 0 0 D 127.0.0.1 Vbdif40
10.4.1.255/32 Direct 0 0 D 127.0.0.1 Vbdif40
10.10.10.10/32 IBGP 255 0 RD 5.5.5.5 Vbdif20
IBGP 255 0 RD 5.5.5.5 Vbdif10
44.44.44.44/32 IBGP 255 0 RD 4.4.4.4 VXLAN




(2020-04-09)













(2020-04-09)






(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
gateway function.
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

(2020-04-09)
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
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.

(2020-04-09)
tasks:
L2GW/L3GWs.
On DC-GWs, the configuration involves only creating L3VPN instances and
establishing BGP EVPN peer relationships.

(2020-04-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 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-04-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-04-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-04-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-04-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-04-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-04-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-04-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.34.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-04-09)



nexthop-changed ]

d. Run quit


enabled.
g. Run quit

h. Run quit

i. Run commit




nexthop-changed ]

d. Run quit

(2020-04-09)

enabled.
number path-number
is configured.
i. Run quit
j. Run quit
k. Run commit
----End

Function
Prerequisites
Procedure
addresses.

(2020-04-09)
interfaces.
----End
Example



5.5.5.5 4 100 8136 8135 0 0118h05m Established 4
6.6.6.6 4 100 8140 8167 0 0118h07m Established 0



2001:DB8:6::6 4 100 7140 7167 0 01:59:11 Established 0



*>i 5.5.5.5/32 1.1.1.1 0 100 0 ?

*i 1.1.1.1 0 100 0 ?
i 5.5.5.5 0 100 0 ?
*>i 6.6.6.6/32 1.1.1.1 0 100 0 ?
*i 2.2.2.2 0 100 0 ?

(2020-04-09)
*i 2.2.2.2 0 100 0 ?
*> 10.1.1.0/24 0.0.0.0 0 0 ?
*i 5.5.5.5 0 100 0 ?
*> 10.1.1.1/32 0.0.0.0 0 0 ?
*> 10.2.1.0/24 0.0.0.0 0 0 ?
*i 5.5.5.5 0 100 0 ?
*> 10.2.1.1/32 0.0.0.0 0 0 ?
*> 10.3.1.0/24 0.0.0.0 0 0 ?
*> 10.3.1.1/32 0.0.0.0 0 0 ?
*> 10.4.1.0/24 0.0.0.0 0 0 ?
*> 10.4.1.1/32 0.0.0.0 0 0 ?
*>i 10.10.10.10/32 5.5.5.5 0 100 0 ?
*> 33.33.33.33/32 0.0.0.0 0 0 ?
*>i 44.44.44.44/32 9.9.9.9 0 100 0 ?
*> 127.0.0.0/8 0.0.0.0 0 0 ?


Label :
Path/Ogn : i
*i
MED :0 PrefVal : 0
Label : 200/NULL
Path/Ogn : i
MED :0 PrefVal : 0
Label :
Path/Ogn : ?
MED :0 PrefVal : 0
Label :
Path/Ogn : ?
MED :0 PrefVal : 0
Label :
Path/Ogn : ?
MED :0 PrefVal : 0
Label :
Path/Ogn : ?
MED :0 PrefVal : 0
Label :
Path/Ogn : ?
MED :0 PrefVal : 0
Label :

(2020-04-09)
Path/Ogn : ?
MED :0 PrefVal : 0
Label :
Path/Ogn : ?
MED :0 PrefVal : 0
Label :
Path/Ogn : ?
MED :0 PrefVal : 0
Label :
Path/Ogn : ?
*i
MED :0 PrefVal : 0
Label :
Path/Ogn : ?
MED :0 PrefVal : 0
Label :
Path/Ogn : ?
*i
MED :0 PrefVal : 0
Label :
Path/Ogn : ?
*i
MED :0 PrefVal : 0
Label :
Path/Ogn : ?
MED :0 PrefVal : 0
Label :
Path/Ogn : ?
MED :0 PrefVal : 0
Label :
Path/Ogn : ?
MED :0 PrefVal : 0
Label : 200/NULL
Path/Ogn : ?
MED :0 PrefVal : 0
Label :
Path/Ogn : ?

------------------------------------------------------------------------------

(2020-04-09)
0.0.0.0/0 Static 60 0 DB 0.0.0.0 NULL0

5.5.5.5/32 IBGP 255 0 RD 10.2.1.2 Vbdif20
IBGP 255 0 RD 10.1.1.2 Vbdif10
6.6.6.6/32 IBGP 255 0 RD 10.1.1.3 Vbdif10
IBGP 255 0 RD 10.3.1.2 Vbdif30
IBGP 255 0 RD 10.4.1.2 Vbdif40
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 Direct 0 0 D 10.2.1.1 Vbdif20
10.2.1.1/32 Direct 0 0 D 127.0.0.1 Vbdif20
10.2.1.255/32 Direct 0 0 D 127.0.0.1 Vbdif20
10.3.1.0/24 Direct 0 0 D 10.3.1.1 Vbdif30
10.3.1.1/32 Direct 0 0 D 127.0.0.1 Vbdif30
10.3.1.255/32 Direct 0 0 D 127.0.0.1 Vbdif30
10.4.1.0/24 Direct 0 0 D 10.4.1.1 Vbdif40
10.4.1.1/32 Direct 0 0 D 127.0.0.1 Vbdif40
10.4.1.255/32 Direct 0 0 D 127.0.0.1 Vbdif40
10.10.10.10/32 IBGP 255 0 RD 5.5.5.5 Vbdif20
IBGP 255 0 RD 5.5.5.5 Vbdif10
44.44.44.44/32 IBGP 255 0 RD 4.4.4.4 VXLAN







(2020-04-09)













(2020-04-09)

3.2.35 Configuration Examples for EVPN

This section provides EVPN configuration examples.
3.2.35.1 Example for Configuring a VPN to Access a Common EVPN E-LAN

This section provides an example for configuring a VPN to Access a common EVPN
E-LAN.
On the network shown in Figure 3-154, Site 1 and Site 2 reside on Layer 2
networks. To allow Site 1 and Site 2 to communicate over the backbone network,
configure EVPN. Specifically, create EVPN instances on the PEs to store EVPN
routes sent from CEs or remote PEs and configure an RR to reflect EVPN routes. To
ensure high transmission efficiency, configure the All-Active redundancy mode on
PE1 and PE2 to implement load balancing.
Interfaces 1 through 3 in this example represent GE 1/0/0, GE 2/0/0, and GE 3/0/0 respectively.
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 the ESI is optional on a dual-homing PE.

(2020-04-09)
Precautions
When configuring a VPN to access a common EVPN E-LAN, note the following:
● On the same EVPN, the export VPN target list of a site shares VPN targets
with the import VPN target lists of the other sites; the import VPN target list
of a site shares VPN targets with the export VPN target lists of the other sites.
● It is recommended that you configure a PE's local loopback interface address
as the EVPN source address.
1. Configure an IGP on the backbone network to allow PEs and the RR to
communicate.
2. Configure basic MPLS functions and MPLS LDP, and establish MPLS LSPs on
the backbone network.
3. Configure an EVPN instance on each PE.
5. Bind each PE interface that connects to a CE to the EVPN instance.
6. Configure an ESI for each PE interface that connects to a CE.
7. Configure BGP EVPN peer relationships between PEs and the RR, and
configure the PEs as RR clients.
8. Configure a redundancy mode on PE1 and PE2.
9. Configure CEs and PEs to communicate.
10. Associate BFD sessions with the AC interfaces on PE1 and PE2 to accelerate
DF switching during an AC link fault.
Data Preparation
● EVPN instance name (evpna)
● EVPN instance RDs (100:1, 200:1, and 300:1) and RTs (1:1) on PEs
Procedure
Step 1 Assign an IP address to each interface on the RR and PEs according to Figure
3-154. 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 as the IGP 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

(2020-04-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-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 configuration is 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
[~PE1] display ospf peer
OSPF Process 1 with Router ID 10.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
State: Full Mode:Nbr is Slave Priority: 1
DR: 10.1.1.1 BDR: 10.1.1.2 MTU: 0
Dead timer due in 35 sec
Retrans timer interval: 5
Neighbor is up for 00h00m30s
Authentication Sequence: [ 0 ]
------------------------------------------------------------------------------

2.2.2.2/32 OSPF 10 2 D 10.1.1.2 GigabitEthernet2/0/0

(2020-04-09)

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 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
[*RR-GigabitEthernet3/0/0] commit
[~RR-GigabitEthernet3/0/0] quit
# Configure PE3.
[*PE3] mpls
[*PE3-mpls] quit
[*PE3] mpls ldp
After the configuration is complete, LDP sessions are established between PEs and
the RR. Run the display mpls ldp session command. The command output shows

(2020-04-09)
that Status is Operational. Run the display mpls ldp lsp command. The
command output shows LDP LSP configurations.

A '*' before a session means the session is being deleted.
--------------------------------------------------------------------------
--------------------------------------------------------------------------
--------------------------------------------------------------------------
[~PE1] display mpls ldp lsp
LDP LSP Information
-------------------------------------------------------------------------------
DestAddress/Mask In/OutLabel UpstreamPeer NextHop OutInterface
-------------------------------------------------------------------------------
1.1.1.1/32 3/NULL 3.3.3.3 127.0.0.1 Loop0
*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
-------------------------------------------------------------------------------
TOTAL: 7 Normal LSP(s) Found.
TOTAL: 1 Liberal LSP(s) Found.
TOTAL: 0 FRR LSP(s) Found.
A '*' before an LSP means the LSP is not established
A '*' before a Label means the USCB or DSCB is stale
A '*' before a UpstreamPeer means the session is stale
A '*' before a DS means the session is stale
A '*' before a NextHop means the LSP is FRR LSP
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 Configure an EVPN instance on each PE.
# Configure PE1.
[~PE1] evpn vpn-instance evpna
[*PE1-evpn-instance-evpna] route-distinguisher 100:1
[*PE1-evpn-instance-evpna] vpn-target 1:1
[*PE1-evpn-instance-evpna] quit
[*PE1] commit
# Configure PE2.
[*PE2] commit
# Configure PE3.
[*PE3] commit

(2020-04-09)

# Configure PE1.
[*PE1] commit
# Configure PE2.
[*PE2] commit
# Configure PE3.
[*PE3] commit
Step 6 Configure an ESI for PE1 and PE2 interface that connects to a CE. (In this example,
an ESI is dynamically generated. For details on how to configure a static ESI, see
Configuring an ESI.)
# Configure PE1.
[~PE1] lacp e-trunk priority 1
[*PE1] lacp e-trunk system-id 00E0-FC00-0000
[*PE1] e-trunk 1
[*PE1-e-trunk-1] priority 10
[*PE1-e-trunk-1] peer-address 2.2.2.2 source-address 1.1.1.1
[*PE1-e-trunk-1] quit
[*PE1] interface eth-trunk 10
[*PE1-Eth-Trunk10] mode lacp-static
[*PE1-Eth-Trunk10] e-trunk 1
[*PE1-Eth-Trunk10] quit
[*PE1] commit
# Configure PE2.
[~PE2] lacp e-trunk priority 1
[*PE2] lacp e-trunk system-id 00E0-FC00-0000
[*PE2] e-trunk 1
[*PE2-Eth-Trunk10] mode lacp-static
[*PE2] commit
Step 7 Bind each PE interface that connects to a CE to the EVPN instance.

# Configure PE1.
[~PE1] interface eth-trunk 10
[*PE1-Eth-Trunk10] e-trunk mode force-master
[*PE1-Eth-Trunk10] evpn binding vpn-instance evpna
[*PE1-Eth-Trunk10] commit
[~PE1-Eth-Trunk10] quit
[*PE1-GigabitEthernet1/0/0] eth-trunk 10
# Configure PE2.
[*PE2-Eth-Trunk10] commit

(2020-04-09)
[~PE2-Eth-Trunk10] quit
# Configure PE3.
[*PE3-GigabitEthernet2/0/0] evpn binding vpn-instance evpna
Step 8 Configure 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] 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] 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

(2020-04-09)
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 5 4 0 00:00:26 Established 1
2.2.2.2 4 100 5 4 0 00:00:27 Established 1
4.4.4.4 4 100 8 4 0 00:00:28 Established 4
Step 9 Configure CEs and PEs to communicate.

# Configure CE1.
[~CE1] interface Eth-Trunk1
[*CE1-Eth-Trunk1] mode lacp-static
[*CE1-Eth-Trunk1] quit
[*CE1-GigabitEthernet1/0/0] eth-trunk 1
If PE1 and PE2 work in Single-Active redundancy mode, GE 1/0/0 and GE 2/0/0 on CE1
must join different Eth-Trunk interfaces.
# Configure CE2.
Step 10 Associate BFD sessions with the AC interfaces on PE1 and PE2 to accelerate DF
switching during an AC link fault.
# Configure PE1.
[~PE1] bfd
[*PE1-bfd] quit
[*PE1] bfd bfd1 bind peer-ip 2.2.2.2 track-interface interface Eth-Trunk10
[*PE1-bfd-session-bfd1] discriminator local 10
[*PE1-bfd-session-bfd1] discriminator remote 20
[*PE1-bfd-session-bfd1] quit
[*PE1-Eth-Trunk10] es track bfd bfd1
[*PE1] commit
# Configure PE2.
[~PE2] bfd
[*PE2-bfd] quit

(2020-04-09)

[*PE2] commit

Run the display bgp evpn all routing-table mac-route command on PE3. The
command output shows MAC/IP advertisement routes destined for CE1.
[~PE3] display bgp evpn all routing-table mac-route



*>i 1:48:00e0-fc12-3456:0:0.0.0.0 1.1.1.1

*>i 1:48:00e0-fc12-3456:0:0.0.0.0 2.2.2.2
EVPN-Instance evpna:
*>i 1:48:00e0-fc12-3456:0:0.0.0.0 1.1.1.1
*i 2.2.2.2
Run the display bgp evpn all routing-table mac-route mac-route command on
PE3. The command output shows that MAC/IP advertisement routes destined for
CE1 work in load balancing mode.

From: 3.3.3.3 (3.3.3.3)
Relay Tunnel Out-Interface: LDP LSP
Ext-Community:RT <1 : 1>
Originator: 10.1.1.1
Cluster list: 3.3.3.3
0138.ba56.b790.0201.2100

From: 3.3.3.3 (3.3.3.3)

(2020-04-09)

0138.ba56.b790.0201.2100
Remote-Cross route
From: 3.3.3.3 (3.3.3.3)
0138.ba56.b790.0201.2100

Remote-Cross route
From: 3.3.3.3 (3.3.3.3)
AS-path Nil, origin incomplete, localpref 100, pref-val 0, valid, internal, select, pre 255, not preferred for
router ID
0138.ba56.b790.0201.2100
----End
Configuration Files
#
sysname PE1
#
lacp e-trunk system-id 00e0-fc00-0000
lacp e-trunk priority 1
#
evpn vpn-instance evpna
#
bfd
#

(2020-04-09)
mpls lsr-id 1.1.1.1

#
mpls
#
mpls ldp
#
ipv4-family
#
e-trunk 1
priority 10
peer-address 2.2.2.2 source-address 1.1.1.1
#
interface Eth-Trunk10
mode lacp-static
e-trunk 1
e-trunk mode force-master
evpn binding vpn-instance evpna
es track bfd bfd1
#
undo shutdown
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 bfd1 bind peer-ip 2.2.2.2 track-interface interface Eth-Trunk10
#
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
#
#
#
bfd
#

(2020-04-09)
mpls lsr-id 2.2.2.2

#
mpls
#
mpls ldp
#
ipv4-family
#
e-trunk 1
priority 10
#
mode lacp-static
e-trunk 1
es track bfd bfd1
#
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
#
#
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
#
mpls ldp

(2020-04-09)
#
ipv4-family
#
undo shutdown
ip address 10.3.1.2 255.255.255.0
mpls
mpls ldp
#
undo shutdown
#
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
● RR configuration file
#
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

(2020-04-09)

#
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
#
mode lacp-static
#
undo shutdown
eth-trunk 1
#
undo shutdown
eth-trunk 1
#
return

#
sysname CE2
#
#
undo shutdown
eth-trunk 1
#
return
3.2.35.2 Example for Configuring Eth-Trunk Sub-interfaces to Access a

Common EVPN E-LAN in Active-Active Mode
This section provides an example for configuring EVPN with a CEdual-homed to
PEs through Eth-Trunk sub-interfaces.

(2020-04-09)
On the network shown in Figure 3-155, Site1 and Site2 reside on Layer 2
networks. To allow Site1 and Site2 to communicate over the backbone network,
configure EVPN functions. Specifically, create EVPN instances on the PEs to store
EVPN routes sent from CEs or remote PEs and configure a route reflector (RR) to
reflect EVPN routes. To have the BUM traffic balanced along the links between
CE1 and PE1 and between CE1 and PE2, configure Eth-Trunk sub-interfaces on PE1
and PE2 to connect to CE1 and then configure VLAN-based DF election.
To improve reliability for the EVPN, configure also the following functions in this
example:
● Function that the AC status influences DF election
● Delay after which ES routes are advertised
● Per-ES AD route division based on RTs
Interfaces 1 through 3 in this example represent Ethernet 1/0/0, Ethernet 2/0/0, and Ethernet
3/0/0, respectively.
In a single-homing scenario, fast convergence, split horizon, and DF election required in a dual-
homing scenario do not take effect. Therefore, configuring an ESI in a single-homing scenario is
optional.
Precautions
When configuring Eth-Trunk sub-interfaces to access a common EVPN E-LAN in
active-active mode, note the following:
● On the same EVPN, the export VPN target list of a site shares VPN targets
with the import VPN target lists of the other sites; the import VPN target list
of a site shares VPN targets with the export VPN target lists of the other sites.

(2020-04-09)
● Using the local loopback interface address of a PE as the source address is

recommended.
communicate.
3. Configure EVPN instances on the PEs.
4. Configure a source address on each PE.
5. Configure each PE's sub-interface connecting to a CE.
6. Bind each PE's sub-interface connecting to a CE to an EVPN instance on each
PE.
7. Configure an ESI for each PE interface connecting to a CE.
8. Configure EVPN BGP peer relationships between PEs and the RR, and
10. Configure VLAN-based DF election and the function that the AC status
influences DF election.
11. Associate BFD sessions with the AC interfaces on PE1 and PE2 to accelerate
DF switching during an AC link fault.
Data Preparation
● EVPN instance name (evpna and evpnb)
● EVPN instance evpna's RDs (100:1, 200:1, and 300:1) and RTs (1:1) on PEs
EVPN instance evpnb's RDs (100:2, 200:2, 300:2) and RTs (2:2) on PEs
Procedure
communicate. OSPF is used as the IGP in this example.
# Configure PE1.
[~PE1] ospf 1
[~PE1-ospf-1] quit
# Configure PE2.
[~PE2] ospf 1

(2020-04-09)
[~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
After completing the configurations, PE1, PE2, and PE3 can establish OSPF
(M) Indicates MADJ neighbor

Neighbors
Area 0.0.0.0 interface 10.1.1.1 (Eth2/0/0)'s neighbors

State: Full Mode:Nbr is Master Priority: 1
DR: 10.1.1.1 BDR: 10.1.1.2 MTU: 0
------------------------------------------------------------------------------


(2020-04-09)

# Configure PE1.
[*PE1] mpls
[*PE1-mpls] quit
[*PE1] mpls ldp
[*PE1] interface ethernet 2/0/0
[*PE1-Ethernet2/0/0] mpls
[*PE1-Ethernet2/0/0] mpls ldp
[*PE1-Ethernet2/0/0] commit
[~PE1-Ethernet2/0/0] quit
# 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
[*RR] interface ethernet 1/0/0
[*RR-Ethernet1/0/0] mpls
[*RR-Ethernet1/0/0] mpls ldp
[*RR-Ethernet1/0/0] quit
[*RR-Ethernet2/0/0] quit
[*RR-Ethernet3/0/0] commit
[~RR-Ethernet3/0/0] quit
# Configure PE3.
[*PE3] mpls
[*PE3-mpls] quit
[*PE3] mpls ldp
After the configurations are complete, LDP sessions are established between PEs
and the RR. Run the display mpls ldp session command. The command output

(2020-04-09)
shows that Status is Operational. Run the display mpls ldp lsp command. The
An asterisk (*) before a session means the session is being deleted.
--------------------------------------------------------------------------
--------------------------------------------------------------------------
--------------------------------------------------------------------------
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 Eth2/0/0
2.2.2.2/32 32829/32829 3.3.3.3 10.1.1.2 Eth2/0/0
3.3.3.3/32 NULL/3 - 10.1.1.2 Eth2/0/0
3.3.3.3/32 32828/3 3.3.3.3 10.1.1.2 Eth2/0/0
4.4.4.4/32 NULL/32830 - 10.1.1.2 Eth2/0/0
4.4.4.4/32 32830/32830 3.3.3.3 10.1.1.2 Eth2/0/0
-------------------------------------------------------------------------------
Step 4 Configure EVPN instances on the PEs.

# Configure PE1.
[*PE1] evpn vpn-instance evpnb
[*PE1-evpn-instance-evpnb] route-distinguisher 100:2
[*PE1-evpn-instance-evpnb] vpn-target 2:2
[*PE1-evpn-instance-evpnb] quit
[*PE1] commit
# Configure PE2.
[*PE2] commit
# Configure PE3.

(2020-04-09)

[*PE3-evpn-instance-evpnb] vpn-target 2:2
[*PE3-evpn-instance-evpnb] quit
[*PE3] evpn redundancy-mode single-active
[*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 Eth-Trunk sub-interface on each PE connecting to a CE.

# Configure PE1.
[~PE1] e-trunk 1
[*PE1] interface eth-trunk 10.1
[*PE1-Eth-Trunk10.1] vlan-type dot1q 1
[*PE1-Eth-Trunk10.1] quit
[*PE1-Ethernet1/0/0] eth-trunk 10
[*PE1-Ethernet1/0/0] quit
[*PE1] commit
# Configure PE2.
[~PE2] e-trunk 1
[*PE2] commit
# Configure PE3.

(2020-04-09)

[*PE3] commit
Step 7 Bind each sub-interface to the EVPN instances on each PE.

# Configure PE1.
[~PE1] interface eth-trunk 10.1
[*PE1-Eth-Trunk10.1] evpn binding vpn-instance evpna
[*PE1-Eth-Trunk10.2] evpn binding vpn-instance evpnb
[*PE1] commit
# Configure PE2.
[*PE2-Eth-Trunk10.1] evpn binding vpn-instance evpna
[*PE2-Eth-Trunk10.2] evpn binding vpn-instance evpnb
[*PE2] commit
# Configure PE3.
[*PE3-Eth-Trunk10] evpn binding vpn-instance evpnb
[*PE3] commit
Step 8 Configure ESIs on PE1's and PE2's interfaces connecting to a CE.

# Configure PE1.
[*PE1-Eth-Trunk10] esi 0000.1111.2222.1111.1111
[*PE1] commit
# Configure PE2.
[*PE2-Eth-Trunk10] esi 0000.1111.2222.1111.1111
[*PE2] commit
Step 9 Configure EVPN BGP peer relationships between PEs and the RR, and configure
# Configure PE1.
[~PE1] bgp 100

(2020-04-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
# 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

# Configure CE1.
[~CE1] vlan batch 1 2
[*CE1] interface Eth-Trunk20

(2020-04-09)
[*CE1-Eth-Trunk20] portswitch
[*CE1-Eth-Trunk20] port link-type trunk
[*CE1-Eth-Trunk20] port trunk allow-pass vlan 1 to 2
[*CE1] interface ethernet1/0/0
[*CE1-Ethernet1/0/0] eth-trunk 20
[*CE1-Ethernet1/0/0] quit
[*CE1] commit
# Configure CE2.
[~CE2] vlan batch 1 2
[*CE2] interface Eth-Trunk 10
[*CE2-Eth-Trunk10] portswitch
[*CE2-Eth-Trunk10] port link-type trunk
[*CE2-Eth-Trunk10] port trunk allow-pass vlan 1 to 2
[*CE2] commit
Step 11 Configure VLAN-based DF election and the function that the AC status influences
DF election on PE1 and PE2.
Run the display evpn vpn-instance name evpna df result and display evpn vpn-
instance name evpnb df result commands on PE1 to check the DF election
result.
[~PE1] display evpn vpn-instance name evpna df result
ESI Count: 1
ESI: 0000.1111.2222.1111.1111
Eth-Trunk10.1:
Current State: IFSTATE_UP
DF Result : Primary
[~PE1] display evpn vpn-instance name evpnb df result
ESI Count: 1
ESI: 0000.1111.2222.1111.1111
Eth-Trunk10.2:
DF Result : Primary
The preceding command output shows that PE1 is elected to be the primary DF in
both evpna and evpnb. Therefore, PE1 will forward the BUM traffic.
# Configure PE1.
[~PE1] evpn
[*PE1-evpn] df-election type vlan
[*PE1-evpn] df-election ac-influence enable
[*PE1-evpn] quit
[*PE1] commit
# Configure PE2.
[~PE2] evpn
[*PE2-evpn] df-election type vlan
[*PE2-evpn] df-election ac-influence enable
[*PE2-evpn] quit
[*PE2] commit

(2020-04-09)
Run the display evpn vpn-instance name evpna df result and display evpn vpn-
instance name evpnb df result commands on PE1 to check the DF election
result.
[~PE1] display evpn vpn-instance name evpna df result
ESI Count: 1
ESI: 0000.1111.2222.1111.1111
Eth-Trunk10.1:
DF Result : Backup
[~PE1] display evpn vpn-instance name evpnb df result
ESI Count: 1
ESI: 0000.1111.2222.1111.1111
Eth-Trunk10.2:
DF Result : Primary
After VLAN-based DF election is configured, PE2 is elected to be the primary DF in

evpna while PE1 is elected to be the primary DF in evpnb. In this case, PE1 and
PE2 will forward the BUM traffic in load balancing mode.
Step 12 Set a delay after which ES routes are advertised on PE1 and PE2.
# Configure PE1.
[*PE1-Eth-Trunk10] timer es-recovery 30
[*PE1] commit
# Configure PE2.
[*PE2-Eth-Trunk10] timer es-recovery 30
[*PE2] commit
Step 13 Associate BFD sessions with the AC interfaces on PE1 and PE2 to accelerate DF
switching during an AC link fault.
# Configure PE1.
[~PE1] bfd
[*PE1-bfd] quit
[*PE1] bfd bfd2 bind peer-ip 2.2.2.2
[*PE1] commit
# Configure PE2.
[~PE2] bfd
[*PE2-bfd] quit
[*PE2] bfd bfd1 bind peer-ip 1.1.1.1

(2020-04-09)

[*PE2] commit

Run the display bgp evpn all routing-table command on PE3. The command
output shows that EVPN routes are sent from the remote PEs (PE1 and PE2).


*>i 0000.1111.2222.1111.1111:0 1.1.1.1
*>i 0000.1111.2222.1111.1111:0 1.1.1.1
*>i 0000.1111.2222.1111.1111:4294967295 1.1.1.1
*>i 0000.1111.2222.1111.1111:4294967295 2.2.2.2
*>i 0000.1111.2222.1111.1111:0 1.1.1.1
*>i 0000.1111.2222.1111.1111:4294967295 1.1.1.1
*i 2.2.2.2
EVPN-Instance evpnb:
*>i 0000.1111.2222.1111.1111:0 1.1.1.1
*>i 0000.1111.2222.1111.1111:4294967295 1.1.1.1
*i 2.2.2.2

*>i 0:32:1.1.1.1 1.1.1.1
*>i 0:32:2.2.2.2 2.2.2.2
*> 0:32:4.4.4.4 127.0.0.1
*>i 0:32:1.1.1.1 1.1.1.1
*>i 0:32:2.2.2.2 2.2.2.2
*> 0:32:4.4.4.4 127.0.0.1

(2020-04-09)
*>i 0:32:1.1.1.1 1.1.1.1
*>i 0:32:2.2.2.2 2.2.2.2
*> 0:32:4.4.4.4 127.0.0.1
EVPN-Instance evpnb:
*>i 0:32:1.1.1.1 1.1.1.1
*>i 0:32:2.2.2.2 2.2.2.2
*> 0: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
----End
Configuration Files
#
sysname PE1
#
evpn
df-election type vlan
#
#
evpn vpn-instance evpnb
#
bfd
#
mpls lsr-id 1.1.1.1
#
mpls
#
mpls ldp
#
e-trunk 1
#
e-trunk 1
esi 0000.1111.2222.1111.1111
es track bfd bfd2
timer es-recovery 30
#
interface Eth-Trunk10.1
vlan-type dot1q 1
#
vlan-type dot1q 2

(2020-04-09)
evpn binding vpn-instance evpnb

#
interface Ethernet1/0/0
undo shutdown
port-tx-enabling-delay 30000
carrier up-hold-time 30000
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 bfd2 bind peer-ip 2.2.2.2
#
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
#
evpn
df-election type vlan
#
#
#
bfd
#
mpls lsr-id 2.2.2.2
#
mpls
#

(2020-04-09)
mpls ldp
#
e-trunk 1
#
e-trunk 1
esi 0000.1111.2222.1111.1111
es track bfd bfd1
timer es-recovery 30
#
vlan-type dot1q 1
#
vlan-type dot1q 2
#
undo shutdown
port-tx-enabling-delay 30000
carrier up-hold-time 30000
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 bfd1 bind peer-ip 1.1.1.1
#
#
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
#
evpn redundancy-mode single-active
#

(2020-04-09)

#
#
mpls lsr-id 4.4.4.4
#
mpls
#
mpls ldp
#
#
vlan-type dot1q 1
#
vlan-type dot1q 2
#
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
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
#

(2020-04-09)
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
mpls ldp
#
undo shutdown
ip address 10.1.1.2 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
#
sysname CE1
#
vlan batch 1 to 2
#
portswitch
port link-type trunk
port trunk allow-pass vlan 1 to 2
#
undo shutdown
eth-trunk 20
#
undo shutdown

(2020-04-09)
eth-trunk 20
#
return

#
sysname CE2
#
vlan batch 1 to 2
#
portswitch
port trunk allow-pass vlan 1 to 2
#
undo shutdown
eth-trunk 10
#
return
3.2.35.3 Example for Configuring Eth-Trunk Sub-interfaces to Access a BD

EVPN IRB in Active-Active Mode
This section provides an example for enabling transmission of both Layer 2 and
Layer 3 traffic in a CE dual-homing scenario.
On the network shown in Figure 3-156, to allow Site 1 and Site 2 to communicate
over the backbone network, configure the EVPN and VPN functions to transmit
both Layer 2 and Layer 3 traffic. 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. A route reflector (RR) is configured
to reflect both EVPN and VPN routes. To balance BUM 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.
Figure 3-156 Configuring eth-trunk sub-interfaces to access a BD EVPN IRB in

active-active mode (carrying both layer 2 and layer 3 services)
Interfaces 1 through 3 in this example represent GigabitEthernet 1/0/0, GigabitEthernet 2/0/0,

and GigabitEthernet 3/0/0, respectively.

(2020-04-09)
Precautions
When you configure Eth-Trunk sub-interfaces to access a BD EVPN IRB in active-
active mode (carrying both layer 2 and layer 3 services), 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.
● Using the local loopback interface address of a PE as the source address is
recommended.

communicate.
6. Bind each PE's sub-interface to the EVPN and VPN instances.
8. Configure EVPN BGP peer relationships between the PEs and RR, and

(2020-04-09)
10. Enable PE1 and PE2 to send ARP packets at a constant speed to limit the rate
at which ARP broadcasts request packets. This ensures a rapid traffic
switchover after a CE fault occurs.
Data Preparation
● EVPN instance named evpna and VPN instance named vpnb
● EVPN instance evpna's RDs (100:1, 200:1, 300:1) and RTs (1:1) on PEs VPN
instance vpnb's RDs (100:2, 200:2, 300:2) and RTs (2:2) on PEs
Procedure
3-156. For configuration details, see "Configuration Files" in this section.
communicate. OSPF is used in this example.
# 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
After the configurations are complete, PE1, PE2, and PE3 can establish OSPF

(2020-04-09)
routes to Loopback 1 of each other.

Neighbors
Area 0.0.0.0 interface 10.1.1.1 (Eth2/0/0)'s 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.
[*PE2] mpls
[*PE2-mpls] quit
[*PE2] mpls ldp

(2020-04-09)
# 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 are established between the
PEs and RR. Run the display mpls ldp session command. The command output
--------------------------------------------------------------------------
--------------------------------------------------------------------------
--------------------------------------------------------------------------
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-04-09)
-------------------------------------------------------------------------------

# Configure PE1.
[~PE1] evpn vpn-instance evpna bd-mode
[*PE1] ip vpn-instance vpnb
[*PE1-vpn-instance-vpnb] ipv4-family
[*PE1-vpn-instance-vpnb-af-ipv4] route-distinguisher 100:2
[*PE1-vpn-instance-vpnb-af-ipv4] vpn-target 2:2 evpn
[*PE1-vpn-instance-vpnb-af-ipv4] evpn mpls routing-enable
[*PE1-vpn-instance-vpnb-af-ipv4] quit
[*PE1-vpn-instance-vpnb] quit
[*PE1-bd10] evpn binding vpn-instance evpna
[*PE1-bd10] quit
[*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-bd10] quit
[*PE2] evpn
[*PE2-evpn] quit
[*PE2] commit
# Configure PE3.

(2020-04-09)
[*PE3-bd10] quit
[*PE3] commit

# Configure PE1.
[*PE1] commit
# Configure PE2.
[*PE2] commit
# Configure PE3.
[*PE3] commit

# Configure PE1.
[~PE1] e-trunk 1
[*PE1] interface eth-trunk 10.1 mode l2
[*PE1-Eth-Trunk10.1] encapsulation dot1q vid 2
[*PE1-Eth-Trunk10.1] rewrite pop single
[*PE1-Eth-Trunk10.1] bridge-domain 10
[*PE1] commit
# Configure PE2.
[~PE2] e-trunk 1
[*PE2] commit
# Configure PE3.

(2020-04-09)
[*PE3] commit
Step 7 Bind each sub-interface to the EVPN and VPN instances on each PE.
# Configure PE1.
[*PE1-Vbdif10] ip binding vpn-instance vpnb
[*PE1-Vbdif10] arp distribute-gateway enable
[*PE1-Vbdif10] quit
[*PE1] commit
# Configure PE2.
[*PE2-Vbdif10] quit
[*PE2] commit
# Configure PE3.
[*PE3-Vbdif10] quit
[*PE3] commit
Step 8 Configure an ESI for each PE interface that connects to a CE.

# Configure PE1.
[*PE1-Eth-Trunk10] esi 0000.1111.2222.1111.1111
[*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 9 Configure EVPN BGP peer relationships between the PEs and RR, and configure
# Configure PE1.
[~PE1] bgp 100

(2020-04-09)

[*PE1-bgp] ipv4-family vpn-instance vpnb
[*PE1-bgp-vpnb] import-route direct
[*PE1-bgp-vpnb] advertise l2vpn evpn
[*PE1-bgp-vpnb] quit
[*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-af-evpn] peer 1.1.1.1 advertise irb
[*RR-bgp] quit
[*RR] commit
After the configurations are complete, run the display bgp evpn peer command
on the RR. The command output shows that BGP peer relationships have been

(2020-04-09)


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

# Configure CE1.
[*CE1] bridge-domain 10
[*CE1-bd10] quit
[*CE1] interface Eth-Trunk20.1 mode l2
[*CE1-Eth-Trunk20.1] encapsulation dot1q vid 2
[*CE1-Eth-Trunk20.1] bridge-domain 10
[*CE1-Eth-Trunk20.1] quit
[*CE1] commit
# Configure CE2.
[~CE2] interface Eth-Trunk 10
[*CE2-bd10] quit
[*CE2] interface Eth-Trunk 10.1 mode l2
[*CE2] commit
Step 11 Enable PE1 and PE2 to send ARP packets at a constant speed to limit the rate at
which ARP broadcasts request packets. This ensures a rapid traffic switchover after
a CE fault occurs.
# Configure PE1.
[~PE1] arp constant-send enable
[*PE1] arp constant-send maximum 1
[*PE1] commit
# Configure PE2.
[~PE2] arp constant-send enable
[*PE2] arp constant-send maximum 1
[*PE2] commit

output shows that EVPN routes are sent from the remote PEs (PE1 and PE2).

(2020-04-09)


*>i 0000.1111.2222.1111.1111:0 1.1.1.1
*> 0000.1111.3333.4444.5555:0 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:0 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:0 127.0.0.1
*>i 0:48:00e0-fc12-3456:0:0.0.0.0 1.1.1.1
*> 0:48:00e0-fc12-3450:0:0.0.0.0 0.0.0.0
*>i 0:48:00e0-fc12-7890:0:0.0.0.0 2.2.2.2
*>i 0:48:00e0-fc12-3456:0:0.0.0.0 1.1.1.1
*> 0:48:00e0-fc12-3450:0:0.0.0.0 0.0.0.0
*>i 0:48:00e0-fc12-7890:0:0.0.0.0 2.2.2.2
*>i 0:32:1.1.1.1 1.1.1.1
*>i 0:32:2.2.2.2 2.2.2.2
*> 0:32:4.4.4.4 127.0.0.1
*>i 0:32:1.1.1.1 1.1.1.1
*>i 0:32:2.2.2.2 2.2.2.2
*> 0: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
*> 0000.1111.3333.4444.5555 127.0.0.1
*> 0000.1111.3333.4444.5555 127.0.0.1

(2020-04-09)

*> 0:192.168.3.0:24 0.0.0.0
*>i 0:192.168.2.0:24 2.2.2.2
*>i 0:192.168.1.0:24 1.1.1.1
----End
Configuration Files
#
sysname PE1
#
arp constant-send enable
arp constant-send maximum 1
#
evpn
local-remote frr enable
#
evpn vpn-instance evpna bd-mode
#
ip vpn-instance vpnb
ipv4-family
#
mpls lsr-id 1.1.1.1
#
mpls
#
bridge-domain 10
#
mpls ldp
#
e-trunk 1
#
interface Vbdif10
ip binding vpn-instance vpnb
ip address 192.168.1.1 255.255.255.0
arp distribute-gateway enable
#
e-trunk 1
esi 0000.1111.2222.1111.1111
#
interface Eth-Trunk10.1 mode l2
rewrite pop single
bridge-domain 10
#
undo shutdown
eth-trunk 10
#

(2020-04-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
#
bgp 100
#
ipv4-family unicast
peer 3.3.3.3 enable
#
ipv4-family vpn-instance vpnb
import-route direct
#
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
#
arp constant-send enable
arp constant-send maximum 1
#
evpn
#
mac-duplication
#
#
ipv4-family
#
mpls lsr-id 2.2.2.2
#
mpls
#
bridge-domain 10
#
mpls ldp

(2020-04-09)
#
e-trunk 1
#
interface Vbdif10
ip address 192.168.2.1 255.255.255.0
#
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
#
bgp 100
#
ipv4-family unicast
peer 3.3.3.3 enable
#
import-route direct
#
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
#
#
ipv4-family

(2020-04-09)
#
mpls lsr-id 4.4.4.4
#
mpls
#
bridge-domain 10
#
mpls ldp
#
interface Vbdif10
ip address 192.168.3.1 255.255.255.0
#
esi 0000.1111.3333.4444.5555
#
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
#
import-route direct
#
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

(2020-04-09)
#
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
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

(2020-04-09)
#
#
bridge-domain 10
#
undo shutdown
eth-trunk 20
#
undo shutdown
eth-trunk 20
#
return

#
sysname CE2
#
bridge-domain 10
#
#
bridge-domain 10
#
undo shutdown
eth-trunk 10
#
return
3.2.35.4 Example for Configuring EVPN VPWS over MPLS

This section provides an example for configuring EVPN VPWS over MPLS.
On the network shown in Figure 3-157, PE1, PE2, RR, and PE3 belong to the same
AS and use OSPF to communicate with each other. An MPLS tunnel is deployed to
carry EVPN private line services.
Figure 3-157 Networking of EVPN VPWS over MPLS

(2020-04-09)
communicate.
3. Configure an EVPN VPWS instance and an EVPL instance on each PE and bind
the EVPL instance to an access-side sub-interface.
4. Configure EVPN BGP peer relationships between PEs and the RR, and
5. Configure the FRR function on PEs.
Data Preparation
● RDs (100:1, 100:2, and 100:3) and RT (1:1) of the EVPN instance
Procedure
3-157. For configuration details, see "Configuration Files" in this section.
# Configure PE1.
[~PE1] ospf 1

(2020-04-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.

(2020-04-09)

[*RR] mpls
[*RR-mpls] quit
[*RR] mpls ldp
[*RR-mpls-ldp] quit
# Configure PE3.
[*PE3] mpls
[*PE3-mpls] quit
[*PE3] mpls ldp
Step 4 Configure an EVPN VPWS instance and an EVPL instance on each PE and bind the
EVPL instance to an access-side sub-interface.
# Configure PE1.
[*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 0/1/0] esi 0001.0002.0003.0004.0005
[*PE1-GigabitEthernet 0/1/0] quit
[*PE1] commit
# Configure PE2.
[*PE2-GigabitEthernet 0/1/0] esi 0001.0002.0003.0004.0005
[*PE2-GigabitEthernet 0/1/0] quit

(2020-04-09)

[*PE2] commit
# Configure PE3.
[*PE2] commit
Step 5 Configure EVPN BGP peer relationships between PEs and the 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

(2020-04-09)

[*RR-bgp] quit
[*RR] commit


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 6 Configure the FRR function on PEs.

# Configure PE1.
[*PE1-vpws-evpn-instance-evrf1] local-remote frr enable
[*PE1] commit
# Configure PE2.
[*PE2-vpws-evpn-instance-evrf1] local-remote frr enable
[*PE2] commit
# Configure PE3.
[*PE3-vpws-evpn-instance-evrf1] remote frr enable
[*PE3] commit

ad-route command on PE3. The command output displays information about
EVPN A-D routes.
[~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

(2020-04-09)
*>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
ad-route 0001.0002.0003.0004.0005:100 command on PE3. The command output
displays details about the EVPN A-D routes sent form PE1 and PE2 as well as the
label information about the bypass tunnel after the FRR function is configured.
BGP routing table entry information of 0001.0002.0003.0004.0005:100:
From: 3.3.3.3 (3.3.3.3)
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

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

(2020-04-09)


Remote-Cross route
From: 3.3.3.3 (3.3.3.3)
AS-path Nil, origin incomplete, localpref 100, pref-val 0, valid, internal, pre 255, IGP cost 2, not preferred
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
#

(2020-04-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
#
#
#
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

(2020-04-09)

#
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
#
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
#

(2020-04-09)
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
3.2.35.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-158, 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

(2020-04-09)
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.
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.
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.

(2020-04-09)

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
● 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] lacp e-trunk system-id 00e0-fc00-0000
[*PE1] e-trunk 1

(2020-04-09)

[*PE1] e-trunk 2
[*PE1] commit
# Configure PE2.
[~PE2] lacp e-trunk system-id 00e0-fc00-0000
[*PE2] e-trunk 1
[*PE2] e-trunk 2
[*PE2] commit
# Configure PE3.

(2020-04-09)
[~PE3] interface gigabitethernet 1/0/0.1 mode l2

[*PE3] commit
# 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] evpn redundancy-mode single-active
[*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] interface Eth-Trunk 10
[*PE1-Eth-Trunk10] esi dynamic esi1
[*PE1] commit
Repeat this step for PE2. For configuration details, see Configuration Files in this
section.

(2020-04-09)
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
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
evpn redundancy-mode all-active
#
#
#
mpls lsr-id 1.1.1.1
#
mpls
#
bridge-domain 10
#
bridge-domain 20
#
mpls ldp
#
e-trunk 1
priority 10
#

(2020-04-09)
e-trunk 2
priority 10
#
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 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

(2020-04-09)
#
#
return
#
sysname PE2
#
#
evpn
#
esi 0001.0002.0003.0004.0005
#
esi dynamic-name esi1
evpn redundancy-mode all-active
#
#
#
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
#

(2020-04-09)
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
#
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
#

(2020-04-09)
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
#
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.35.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-159 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

(2020-04-09)
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-159 Configuring EVPN E-Tree
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.

(2020-04-09)

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
● 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] interface gigabitethernet 1/0/0.1 mode l2
[*PE1] commit
# Configure PE1.

(2020-04-09)
[*PE1] commit
# Configure PE2.
[*PE2] commit
# Configure PE3.
[*PE3] commit
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.



(2020-04-09)

*>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
*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
Total routes of Route Distinguisher(2.2.2.2:0): 1
From: 2.2.2.2 (2.2.2.2)
Ext-Community: RT <11 : 1>, E-Tree <0 : 0 : 32915>
Total routes of Route Distinguisher(3.3.3.3:0): 1

(2020-04-09)

From: 3.3.3.3 (3.3.3.3)
Remote-Cross route
From: 2.2.2.2 (2.2.2.2)

Remote-Cross route
From: 3.3.3.3 (3.3.3.3)
AS-path Nil, origin incomplete, localpref 100, pref-val 0, valid, internal, pre 255, IGP cost 1, not preferred
for router ID
From: 2.2.2.2 (2.2.2.2)
0000.0000.0000.0000.0000

(2020-04-09)

Remote-Cross route
From: 2.2.2.2 (2.2.2.2)
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
#

(2020-04-09)
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
#
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

(2020-04-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
network 10.3.1.0 0.0.0.255
#
#
return
#
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

(2020-04-09)
network 10.1.1.0 0.0.0.255

network 10.3.1.0 0.0.0.255
#
#
return
3.2.35.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-160, 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-160 Configuring EVPN ORF
Precautions
When you configure EVPN ORF, note the following:

(2020-04-09)
other sites.
recommended.
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.
8. Configure the CEs and PEs to communicate.
9. Configure BGP-EVPN peer relationships between the PEs and RR, and
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

(2020-04-09)

[*PE1-bd10] quit
[*PE1-bd20] quit
[*PE1] commit
# Configure PE2.
[*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.

(2020-04-09)
[*PE2] commit
# Configure PE3.
[*PE3] commit
# Configure PE1.
[~PE1] interface gigabitethernet1/0/0
[*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

(2020-04-09)
Step 9 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
# 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

(2020-04-09)
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


*>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



(2020-04-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
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

(2020-04-09)
[*PE2] commit
# Configure PE3.
[~PE3] bgp 100
[*PE3-bgp] quit
[*PE3] commit
# 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

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


(2020-04-09)

*>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


*>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

(2020-04-09)
#
mpls ldp
#
undo shutdown
esi 0000.1111.1111.1111.1111
#
rewrite pop single
bridge-domain 10
#
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
#

(2020-04-09)
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
#
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
#

(2020-04-09)

rewrite pop single
bridge-domain 20
#
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
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

(2020-04-09)

#
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
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

(2020-04-09)
bridge-domain 10
#
return

#
sysname CE3
#
bridge-domain 20
#
undo shutdown
#
rewrite pop single
bridge-domain 20
#
return
3.2.35.8 Example for Configuring a DCI Scenario with an E2E VXLAN EVPN
Deployed on a Gateway
This section provides an example for configuring a DCI scenario with an E2E
VXLAN EVPN deployed on a gateway. In this example, an E2E VXLAN tunnel is
established between DC-GWs, and an L3VPN is deployed over the DCI backbone
network to transmit VXLAN packets.
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 a VXLAN tunnel must be established
between GW1 and GW2.
Figure 3-161 Configuring an e2e VXLAN EVPN deployed on a gateway

respectively.

(2020-04-09)
Table 3-12 Interface IP addresses

Device Interface Name IP Address
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
GW1 GigabitEthernet 1/0/0 192.168.20.2/24
GW2 GigabitEthernet 1/0/0 192.168.30.2/24

(2020-04-09)
1. Configure a VXLAN tunnel between the distributed gateways GW1 and GW2.
2. Enable OSPF on the DCI backbone network for DCI-PEs to communicate with
each other.
3. Configure an MPLS TE tunnel on the DCI backbone network.
4. Configure a VPN instance on each DCI-PE and bind the interface connected to
a GW to the VPN instance.
5. Establish an MP-IBGP peer relationship between DCI-PEs for them to
exchange VPNv4 routes.
6. Establish an EBGP peer relationship between each DCI-PE and its connected
GW for them to exchange VPNv4 routes.
Data Preparation
● MPLS LSR IDs of the DCI-PEs and P
● Route distinguisher (RD) of a VPN instance
● VPN target
Procedure
Step 1 Assign an IP address to each interface on each node, and configure loopback
interface addresses.
Step 2 Configure a VXLAN tunnel between the distributed gateways GW1 and GW2.
This following uses the current product model as an example. For configuration
details, see Configuration Files. In practice, see the related product
documentation.
Step 3 Configure an IGP on the DCI backbone network. OSPF is used as an IGP in this
example.
Step 4 Configure an MPLS TE tunnel on the DCI backbone network.
Step 5 Configure VPN instances on DCI-PEs, connect GWs to the DCI-PEs, and apply a
tunnel policy.
# Configure DCI-PE1.
[~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

(2020-04-09)
[*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] 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 6 Set up an EBGP peer relationship between each DCI-PE and its connected GW.
[~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] commit
Step 7 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

(2020-04-09)

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
------------------------------------------------------------------------------
Routing Tables: vpn1
----End
Configuration Files
● GW1 configuration file
#
sysname GW1
#
ipv4-family
vxlan vni 100
#
#
bridge-domain 10
vxlan vni 10
#
interface Vbdif10
ip address 10.1.1.1 255.255.255.0
vxlan anycast-gateway enable
#
undo shutdown
ip address 192.168.20.2 255.255.255.0
#
undo shutdown
#
rewrite pop single
bridge-domain 10
#
undo shutdown
#
rewrite pop single

(2020-04-09)
bridge-domain 10
#
interface LoopBack1
ip address 4.4.4.4 255.255.255.255
#
interface Nve1
source 4.4.4.4
vni 10 head-end peer-list protocol bgp
#
bgp 65410
peer 192.168.20.1 as-number 100
#
ipv4-family unicast
network 4.4.4.4 255.255.255.255
#
l2vpn-family evpn
policy vpn-target
peer 7.7.7.7 enable
peer 7.7.7.7 advertise encap-type vxlan
#
return

#
sysname GW2
#
ipv4-family
vxlan vni 100
#
#
bridge-domain 10
vxlan vni 10
#
interface Vbdif10
ip address 10.1.1.2 255.255.255.0
vxlan anycast-gateway enable
#
undo shutdown
ip address 192.168.30.2 255.255.255.0
#
undo shutdown
#
rewrite pop single
bridge-domain 10
#
undo shutdown
#

(2020-04-09)

rewrite pop single
bridge-domain 10
#
interface LoopBack1
ip address 7.7.7.7 255.255.255.255
#
interface Nve1
source 7.7.7.7
#
bgp 65420
peer 192.168.30.1 as-number 100
#
ipv4-family unicast
network 7.7.7.7 255.255.255.255
#
l2vpn-family evpn
policy vpn-target
peer 4.4.4.4 enable
#
return
● Device1 configuration file

#
sysname Device1
#
vlan batch 10
#
portswitch
undo shutdown
port default vlan 10
#
portswitch
undo shutdown
port trunk allow-pass vlan 10
#
return

#
sysname Device2
#
vlan batch 10
#
portswitch
undo shutdown
#
portswitch
undo shutdown
#
return

(2020-04-09)
#
sysname Device3
#
vlan batch 10
#
portswitch
undo shutdown
#
portswitch
undo shutdown
#
return

#
sysname Device4
#
vlan batch 10
#
portswitch
undo shutdown
#
portswitch
undo shutdown
#
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
#
undo shutdown
ip address 192.168.1.1 255.255.255.0
mpls
mpls te
mpls rsvp-te
#

(2020-04-09)
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
#
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

(2020-04-09)
#
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
#
#
return

(2020-04-09)
3.2.35.9 Example for Configuring a DCI Scenario with a VLAN Layer 3 Sub-
Interface Accessing a Common L3VPN
This section provides an example for configuring a DCI scenario with a VLAN Layer
3 sub-interface accessing a common L3VPN. In this example, a data center
gateway is connected to the DCI network through a VLAN Layer 3 sub-interface,
and a common L3VPN is deployed over the DCI network to implement data center
interconnection.
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-162, to allow intra-data center VM
communication, a VXLAN tunnel must be established within each data center. 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 a Layer 3 Ethernet sub-interface must be configured on
each DCI-PE, added to the same VLAN, and bound to the VPN instance of each
DCI-PE.
Figure 3-162 Configuring a DCI scenario with a VLAN Layer 3 sub-interface

accessing a common L3VPN
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-04-09)
GigabitEthernet 1/0/0.1 192.168.20.1/24
GigabitEthernet 1/0/0.1 192.168.30.1/24
each other.

(2020-04-09)

4. Establish an MP-IBGP peer relationship between DCI-PEs for them to
exchange VPNv4 routes.
5. Establish an EBGP peer relationship between each DCI-PE and its connected
GW for them to exchange VPNv4 routes.
Data Preparation
● RD of a VPN instance
● VPN target
Procedure
example.
Step 4 Configure VPN instances on DCI-PEs, connect GWs to the DCI-PEs, and apply a
tunnel policy.
[*DCI-PE1] interface gigabitethernet 1/0/0.1
[*DCI-PE1-GigabitEthernet1/0/0.1] vlan-type dot1q 10
[*DCI-PE1-GigabitEthernet1/0/0.1] ip binding vpn-instance vpn1
[*DCI-PE1-GigabitEthernet1/0/0.1] ip address 192.168.20.1 24
[*DCI-PE1-GigabitEthernet1/0/0.1] quit
[*DCI-PE1] commit

(2020-04-09)
[*DCI-PE2] interface gigabitethernet 1/0/0.1
[*DCI-PE2-GigabitEthernet1/0/0.1] vlan-type dot1q 10
[*DCI-PE2-GigabitEthernet1/0/0.1] ip binding vpn-instance vpn1
[*DCI-PE2-GigabitEthernet1/0/0.1] ip address 192.168.30.1 24
[*DCI-PE2] commit
Step 5 Set up an EBGP peer relationship between each DCI-PE and its connected GW.
[~DCI-PE1] bgp 100
[*DCI-PE1] commit
[~DCI-PE2] bgp 100
[*DCI-PE2] commit
Step 6 Set up an MP-IBGP peer relationship between DCI-PEs.

[~DCI-PE1] bgp 100
[*DCI-PE1-bgp] quit
[*DCI-PE1] commit
[~DCI-PE2] bgp 100
[*DCI-PE2-bgp] quit
[*DCI-PE2] commit

------------------------------------------------------------------------------
Routing Tables: vpn1

(2020-04-09)

----End
Configuration Files
#
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
#
undo shutdown
vlan-type dot1q 10
ip address 192.168.20.1 255.255.255.0
#
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

(2020-04-09)
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 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
#
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
#

(2020-04-09)
undo shutdown
#
undo shutdown
vlan-type dot1q 10
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
#
#
return

See the data center device configuration file.
● Device 1 configuration file

(2020-04-09)
3.2.35.10 Example for Configuring a DCI Scenario with a VXLAN EVPN

L3VPN Accessing a Common 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.
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-163 Configuring a DCI scenario with a VXLAN EVPN L3VPN accessing a
common L3VPN

(2020-04-09)

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

● VPN targets

(2020-04-09)
Procedure
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] 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-04-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-04-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-04-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

------------------------------------------------------------------------------
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-04-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
Number of vxlan tunnel : 1
Tunnel ID Source Destination State Type Uptime
-----------------------------------------------------------------------------------
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
vxlan vni 5010 split-horizon-mode
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-04-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-04-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-04-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-04-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

3.2.35.11 Example for Configuring MPLS EVPN E-LAN Option B

A single-hop MP-EBGP peer relationship can be established between the ASBRs to
exchange EVPN routes.
On the network shown in Figure 3-164, CE1 and CE2 belong to the same EVPN.
CE1 is connected to PE1 in AS100, and CE2 is connected to PE2 in AS200. A single-
hop MP-EBGP peer relationship is set up between the ASBRs to transmit all inter-
AS EVPN routing information.
Figure 3-164 Configuring MPLS EVPN E-LAN Option B networking

(2020-04-09)
Configuration Notes
When configuring inter-AS EVPN Option B with basic networking, ensure that an
MP-EBGP peer relationship is established between ASBR1 and ASBR2, and the
ASBRs do not filter received EVPN routes based on VPN targets.
1. Configure an IGP on the MPLS backbone network for IP connectivity between

the ASBR and PE in the same AS, and set up an MPLS LDP LSP between the
ASBR and PE in the same AS.
2. Configure PE and ASBR establish an IBGP peer relationship.
3. Configure EVPN instances on PEs, but not ASBRs.
4. Enable MPLS on the interface connected to ASBRs. Set up the EBGP peer
relationship between ASBRs. Configure no VPN-target filtration on the
received EVPN routes.
Data Preparation
● Interfaces and their IP addresses

● MPLS LSR IDs of the PEs and ASBRs
● Names, RDs, and EVPN targets of the EVPN instances on the PEs
Procedure
Step 1 On the MPLS backbone networks in AS100 and AS200, configure an IGP to
interconnect the PE and ASBR on each network.

(2020-04-09)
This example uses OSPF as the IGP. For configuration details, see Configuration
The 32-bit IP address of the loopback interface that functions as the LSR ID needs to be
advertised by using OSPF.
After the configurations are complete, the OSPF neighbor relationship can be
established between the ASBR and PE in the same AS. Run the display ospf peer
command. The command output shows that the neighbor relationship is in the
Full state.
The ASBR and PE in the same AS can learn and successfully ping the IP address of
each other's loopback interface.
Step 2 Configure MPLS and MPLS LDP both globally and per interface on each node of
the MPLS backbone networks in AS100 and AS200 and set up LDP LSPs.
Step 3 Configuring EVPN functions on PE1 and PE2.
The VPN targets of the EVPN instances on PE1 and PE2 must match.

Step 4 Configure inter-AS EVPN Option B.
# On ASBR 1, enable MPLS on 2/0/0connected to ASBR 2.
[~ASBR1] interface GigabitEthernet 2/0/0
[~ASBR1-GigabitEthernet2/0/0] ip address 192.168.1.1 24
[*ASBR1] commit
# On ASBR1, set up an MP-EBGP peer relationship between ASBR1 and ASBR2,

and configure ASBR1 not to filter received EVPN routes based on VPN targets.
[~ASBR1] bgp 100
[*ASBR1-bgp] peer 192.168.1.2 as-number 200
[*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 the configuration of ASBR1. For

----End
Configuration Files
#
sysname PE1
#
evpn vpn-instance evrf_1

(2020-04-09)

#
mpls lsr-id 1.1.1.9
#
mpls
#
mpls ldp
#
undo shutdown
ip address 172.21.1.2 255.255.255.0
mpls
mpls ldp
#
undo shutdown
evpn binding vpn-instance evrf_1
esi 0022.2222.2222.2222.2222
#
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
#
undo shutdown
ip address 172.21.1.1 255.255.255.0
mpls
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

(2020-04-09)

#
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
#
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
#
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

(2020-04-09)

#
sysname PE2
#
evpn vpn-instance evrf_1
#
mpls lsr-id 4.4.4.9
#
mpls
#
mpls ldp
#
undo shutdown
ip address 172.22.1.2 255.255.255.0
mpls
mpls ldp
#
undo shutdown
evpn binding vpn-instance evrf_1
esi 0011.1111.1111.1111.1111
#
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
#
#
return
3.2.35.12 Example for Configuring an MPLS EVPN L3VPN in E-LAN Option B

Mode
This section provides an example for configuring an MPLS EVPN L3VPN in E-LAN
Option B mode, which is used to carry inter-AS Layer 3 service traffic.
On the network shown in Figure 3-165, CE1 and CE2 belong to the same VPN.
CE1 is connected to PE1 in AS100, and CE2 is connected to PE2 in AS200. An
EBGP-EVPN peer relationship is configured between ASBRs 1 and 2 to exchange
EVPN routes so that an inter-AS Option B EVPN can carry Layer 3 service traffic.

(2020-04-09)
Figure 3-165 Configuring an MPLS EVPN L3VPN in E-LAN Option B mode
Precautions
When configuring an MPLS EVPN L3VPN in E-LAN Option B mode, ensure that an
EBGP-EVPN peer relationship is configured between ASBRs 1 and 2 and EVPN
routes that are being received are not filtered based on VPN targets.
1. Configure an IGP on the MPLS backbone networks of AS100 and AS200, so

that PEs on each MPLS backbone network can communicate with each other.
2. Configure basic MPLS functions and MPLS LDP on the MPLS backbone
networks of AS100 and AS200 to establish LDP LSPs.
3. Configure an L3VPN instance on each PE.
4. Establish a BGP-EVPN peer relationship between the ASBR and PE in each AS.
5. Establish a VPN BGP peer relationship between each PE and CE.
6. Enable MPLS on the ASBR interfaces that connect each other. Establish an
EBGP-EVPN peer relationship between the ASBRs and disable ASBRs from
filtering received EVPN routes based on VPN targets.

(2020-04-09)
Data Preparation

● MPLS LSR IDs of the PEs and ASBRs
● Name (vpn1), RDs 100:1 (for PE1) and 200:1 (for PE2), and VPN target (1:1)
of the L3VPN instance on each PE
Procedure
Step 1 Configure an IGP on the MPLS backbone networks of AS100 and AS200, so that
PEs on each MPLS backbone network can communicate with each other.
In this example, OSPF is used in AS100, and IS-IS is used in AS200. For
Step 2 Configure basic MPLS functions and MPLS LDP on the MPLS backbone networks
of AS100 and AS200 to establish LDP LSPs.
Step 3 Configure an L3VPN instance on each PE.
# Configure PE1.
[*PE1] commit
section.
Step 4 Establish a BGP-EVPN peer relationship between the ASBR and PE in each AS.
# Configure PE1.
[~PE1] bgp 100
[*PE1-bgp] peer 2.2.2.9 connect-interface LoopBack1
[*PE1-bgp] commit
Repeat this step for ASBR1, ASBR2, and PE2. For configuration details, see
Step 5 Establish a VPN BGP peer relationship between each PE and CE.
# Configure PE1.
[~PE1-bgp] ipv4-family vpn-instance vpn1
[*PE1-bgp] quit
[*PE1] commit

(2020-04-09)
section.
# Configure CE1.
[~CE1] bgp 65410
[*CE1-bgp] quit
[*CE1] commit
Repeat this step for CE2. For configuration details, see Configuration Files in this
section.
Step 6 Enable MPLS on the ASBR interfaces that connect each other. Establish an EBGP-
EVPN peer relationship between the ASBRs and disable ASBRs from filtering
received EVPN routes based on VPN targets.
# Configure ASBR1.
[~ASBR1] bgp 100
[*ASBR1-bgp] peer 10.2.1.2 as-number 200
[*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
Repeat this step for ASBR2. For configuration details, see Configuration Files in
this section.
# Run the display ip routing-table command on each CE. The command output
shows the route to the remote CE. The following example uses the command
output on CE1.
[~CE1] display ip routing-table
------------------------------------------------------------------------------

----End
Configuration Files
#
sysname PE1

(2020-04-09)
#
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
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

(2020-04-09)
#
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
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
#

(2020-04-09)
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
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
#

(2020-04-09)
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.35.13 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.
On the network shown in Figure 3-166, 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-166 Inter-AS EVPN Option C networking

(2020-04-09)
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.
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

(2020-04-09)
● 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.
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
[*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

(2020-04-09)
# 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.
# 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.
Step 9 Configure the access interfaces connecting PEs to CEs.
[~PE1-bgp] ipv4-family vpn-instance vpn1
[*PE1-bgp] quit
[*PE1] interface GigabitEthernet2/0/0.1 mode l2
[*PE1-bd10] quit

(2020-04-09)

[*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
*> 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

------------------------------------------------------------------------------

(2020-04-09)

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
#
undo shutdown
ip address 10.1.1.2 255.255.255.0
mpls
mpls ldp
#
rewrite pop single
bridge-domain 10
#
interface LoopBack1

(2020-04-09)
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
#
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

(2020-04-09)

#
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
#
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

(2020-04-09)

#
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
#
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

(2020-04-09)
network 10.3.1.0 0.0.0.255

#
#
return
3.2.35.14 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-167, 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-167 Splicing a VXLAN EVPN with a VPLS

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

(2020-04-09)
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
● 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

(2020-04-09)
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-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
# Configure PE2.
[*PE2-vsi-cpe] quit

(2020-04-09)
[*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
Multicast Fast Switch : disable
VSI State : up
VSI ID : 10
Negotiation-vc-id : 10

(2020-04-09)
VC Label : 48123
Peer Type : dynamic
Session : up
Tunnel ID : 0x0000000001004c4b44
CKey :1
NKey : 16777348
Stp Enable :0
PwIndex :1
BFD for PW : unavailable
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
Local VCCV : alert lsp-ping bfd
Remote VCCV : alert lsp-ping bfd
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
#
evpn vpn-instance tor bd-mode
route-distinguisher 2.2.2.100:10
#
mpls lsr-id 1.1.1.1
#

(2020-04-09)
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
#
#
return
#
sysname PE2
#

(2020-04-09)
#
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
#
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
#

(2020-04-09)
#
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
#
#
bridge-domain 10

(2020-04-09)

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

(2020-04-09)
On the network shown in Figure 3-168, 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-168 Configuring EVPN E-LAN over mLDP P2MP tunnels
Precautions
When you configure EVPN to use an mLDP P2MP tunnel for service transmission,
note the following:

(2020-04-09)
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.
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
# Configure PE2.
[~PE2] ospf 1

(2020-04-09)

[~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
[*RR-mpls-ldp] mldp p2mp
[*RR-mpls-ldp] quit

(2020-04-09)

# 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.
[*PE1] commit
# Configure PE2.
[*PE2] commit

(2020-04-09)
# Configure PE3.
[*PE3] commit
# 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.
[*PE3-Eth-Trunk10] esi 0000.1111.3333.4444.5555
[*PE3] commit

(2020-04-09)
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
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.


1.1.1.1 4 100 231 253 0 03:07:26 Established 6

(2020-04-09)
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-04-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
peer 3.3.3.3 enable
#
l2vpn-family evpn
peer 3.3.3.3 enable

(2020-04-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
#
#
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
#
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-04-09)
#
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
#
#
return
#
sysname RR
#

(2020-04-09)
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
#
bridge-domain 10
#
#

(2020-04-09)
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.35.16 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
the PW-VE sub-interface. The PW-VE sub-interface is configured as a QinQ VLAN
tag termination sub-interface.

(2020-04-09)
Figure 3-169 Splicing a VLL with a common EVPN E-LAN
Interfaces 0 through 2 in this example represent GigabitEthernet 1/0/0, GigabitEthernet 1/0/1 ,

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.
3. Configure VPWS connections on the UPE and NPE1.
4. Configure EVPN functions on NPE1 and NPE2 and establish an MPLS tunnel
between them.

(2020-04-09)
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] interface GigabitEthernet 1/0/0
[~UPE-GigabitEthernet1/0/0] mpls l2vc 1.1.1.1 1
[*UPE-GigabitEthernet1/0/0] quit
[*UPE] commit
Step 8 On NPE1, bind the VSI to the PW-VE interface and the EVPN instance to the PW-
VE sub-interface.
# Configure NPE1.
[~NPE1] mpls

(2020-04-09)
[*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
NKey : 16777487
PW redundancy mode : frr
AdminPw interface : --

(2020-04-09)
AdminPw link state : --

Forward state : send inactive, receive inactive
Service Class : --
Color : --
DomainId : --
Domain Name : --
----End
Configuration Files
● NPE1 configuration file
#
sysname NPE1
#
#
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
#
ospf 1

(2020-04-09)
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
● UPE configuration file
#
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
#
#
#
mpls
#
mpls l2vpn
#
mpls ldp
#
undo shutdown
#
undo portswitch
ip address 192.168.14.4 255.255.255.0
mpls

(2020-04-09)
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.35.17 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-170, 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-170 Splicing a VLL with an MPLS EVPN E-Line


(2020-04-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.
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

(2020-04-09)
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
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
Step 6 On NPE1, bind the VSI to the PW-VE interface and the EVPN instance to the PW-
VE sub-interface.
# Configure NPE1.
[~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

(2020-04-09)
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
Configuration Files
#
sysname NPE1
#
evpn vpn-instance evpna vpws
#

(2020-04-09)

#
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
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

(2020-04-09)
#
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
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

(2020-04-09)
#
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.35.18 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-171, 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 BUM 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-171 Accessing a BD EVPN E-LAN over MPLS tunnel in VLAN-Aware mode

(2020-04-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.
Data Preparation

(2020-04-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-04-09)

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.
[*PE2] mpls
[*PE2-mpls] quit
[*PE2] mpls ldp
# Configure the RR.

[*RR] mpls
[*RR-mpls] quit
[*RR] mpls ldp
[*RR-mpls-ldp] quit

(2020-04-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

--------------------------------------------------------------------------
--------------------------------------------------------------------------
--------------------------------------------------------------------------
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-04-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-04-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-04-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
# 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-04-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

# Configure CE1.
[*CE1-bd10] quit
[*CE1-bd20] quit
[*CE1] commit
# Configure CE2.
[*CE2-bd10] quit
[*CE2] commit

output shows that EVPN routes carrying Ethernet tag IDs are received from the
remote PEs.

(2020-04-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-04-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-04-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-04-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-04-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-04-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.35.19 Example for Accessing an EVPN E-LAN over a VXLAN Tunnel in

VLAN-Aware Mode
On the access network of EVPN E-LAN over VXLAN, the VLAN-aware mode can be
configured to allow different VLANs to be configured on a physical interface so

(2020-04-09)
that these VLANs can access the same EVPN instance (EVI) and isolate 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 service traffic. When
the sites belong to the same subnet, an EVI is configured on each PE to store
EVPN routes. A route reflector (RR) is configured to reflect EVPN routes. A VXLAN
tunnel is set up between every two PEs to carry service traffic. To balance BUM
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 an EVPN E-LAN over a VXLAN tunnel in VLAN-aware

mode
Precautions
When you configure the VLAN-aware bundle mode, note the following:
recommended.

(2020-04-09)
communicate.
2. Create a BD-EVPN instance and a BD and bind the BD to the BD-EVPN
instance with a BD tag set on each PE.
3. Configure each PE's sub-interface that connects to a CE.
Data Preparation
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.

(2020-04-09)
[~RR] ospf 1
[*RR-ospf-1] area 0
[~RR-ospf-1] quit
routes destined for each other's loopback interfaces.


Neighbors

DR: 10.1.1.1 BDR: 10.1.1.2 MTU: 0
------------------------------------------------------------------------------

Step 3 Configure an EVI on each PE.
# Configure PE1.
[*PE1-bd10] quit

(2020-04-09)

[*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
Step 4 Configure an Eth-Trunk sub-interface on each PE that connects to a CE.

# Configure PE1.
[~PE1] e-trunk 1
[*PE1] commit

(2020-04-09)
# Configure PE2.
[~PE2] e-trunk 1
[*PE2] commit
# Configure PE3.
[*PE3] commit

# Configure PE1.
[*PE1-Eth-Trunk10] esi 0000.1111.2222.1111.1111
[*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
# Configure PE1.
[~PE1] bgp 100

(2020-04-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
# Configure the RR.

[~RR] bgp 100
[*RR-bgp-af-evpn] peer 1.1.1.1 advertise encap-type vxlan
[*RR-bgp] quit
[*RR] commit
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.


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

(2020-04-09)

# Configure CE1.
[*CE1-bd10] quit
[*CE1-bd20] quit
[*CE1] commit
# Configure CE2.
[*CE2-bd10] quit
[*CE2] commit
Step 8 Configure an ingress replication list on each PE.

# Configure PE1.
[~PE1] interface Nve 1
[*PE1-Nve1] source 1.1.1.1
[*PE1-Nve1] vni 11 head-end peer-list protocol bgp
[*PE1-Nve1] quit
[*PE1] commit
# Configure PE2.
[*PE2-Nve1] quit
[*PE2] commit
# Configure PE3.

(2020-04-09)

[*PE3-Nve1] quit
[*PE3] commit
output shows that EVPN routes carrying Ethernet tag IDs are received from the
remote PEs.


*>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:100 2.2.2.2
*>i 0000.1111.2222.1111.1111:200 2.2.2.2
*>i 0000.1111.2222.1111.1111:4294967295 1.1.1.1
*> 0000.1111.3333.4444.5555:100 0.0.0.0
*> 0000.1111.3333.4444.5555:200 0.0.0.0
*>i 0000.1111.2222.1111.1111:4294967295 2.2.2.2
*> 0000.1111.3333.4444.5555:4294967295 0.0.0.0
*>i 0000.1111.2222.1111.1111:100 1.1.1.1
*i 2.2.2.2
*>i 0000.1111.2222.1111.1111:200 1.1.1.1
*i 2.2.2.2
*>i 0000.1111.2222.1111.1111:4294967295 1.1.1.1
*i 2.2.2.2
*> 0000.1111.3333.4444.5555:100 0.0.0.0
*> 0000.1111.3333.4444.5555:200 0.0.0.0

*>i 200: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 0.0.0.0
*> 100:32:4.4.4.4 127.0.0.1
*> 200:32:4.4.4.4 0.0.0.0

(2020-04-09)
*> 200:32:4.4.4.4 127.0.0.1
*>i 100:32:2.2.2.2 2.2.2.2
*> 100:32:4.4.4.4 0.0.0.0
*> 100:32:4.4.4.4 127.0.0.1
*>i 200:32:1.1.1.1 1.1.1.1
*> 200:32:4.4.4.4 0.0.0.0
*> 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
*> 0000.1111.3333.4444.5555 0.0.0.0
*> 0000.1111.3333.4444.5555 0.0.0.0
----End
Configuration Files
#
sysname PE1
#
evpn
#
#
bridge-domain 10
#
bridge-domain 20
#
e-trunk 1
#
e-trunk 1
esi 0000.1111.2222.1111.1111
#
rewrite pop single

(2020-04-09)
bridge-domain 10
#
rewrite pop single
bridge-domain 20
#
undo shutdown
eth-trunk 10
#
undo shutdown
ip address 10.1.1.1 255.255.255.0
#
interface LoopBack0
ip address 1.1.1.1 255.255.255.255
#
interface Nve1
source 1.1.1.1
#
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
#
evpn
#
#
bridge-domain 10
#
bridge-domain 20
#
e-trunk 1
#
e-trunk 1

(2020-04-09)

esi 0000.1111.2222.1111.1111
#
rewrite pop single
bridge-domain 10
#
rewrite pop single
bridge-domain 20
#
undo shutdown
eth-trunk 10
#
undo shutdown
ip address 10.2.1.1 255.255.255.0
#
interface LoopBack0
ip address 2.2.2.2 255.255.255.255
#
interface Nve1
source 2.2.2.2
#
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
#
#
bridge-domain 10
#
bridge-domain 20
#
esi 0000.1111.3333.4444.5555
#

(2020-04-09)

rewrite pop single
bridge-domain 10
#
rewrite pop single
bridge-domain 20
#
undo shutdown
ip address 10.3.1.2 255.255.255.0
#
undo shutdown
eth-trunk 10
#
interface LoopBack0
ip address 4.4.4.4 255.255.255.255
#
interface Nve1
source 4.4.4.4
#
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
#
undo shutdown
ip address 10.1.1.2 255.255.255.0
#
undo shutdown
ip address 10.2.1.2 255.255.255.0
#
undo shutdown
ip address 10.3.1.1 255.255.255.0
#
interface LoopBack0
ip address 3.3.3.3 255.255.255.255
#
bgp 100

(2020-04-09)

#
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
#
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

(2020-04-09)
#
bridge-domain 20
#
undo shutdown
eth-trunk 10
#
return
3.2.35.20 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
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
Table 3-18 IP address planning
Device Interface IP Address
CSG GigabitEthernet 1/0/1 10.1.2.1/24
GigabitEthernet 1/0/3 -

(2020-04-09)
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
RSG GigabitEthernet 1/0/0 10.2.4.2/24
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

(2020-04-09)
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
[*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

(2020-04-09)
[*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
[*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

(2020-04-09)

VSI Index :1
PW Signaling : ldp
MTU : 1500
Service Class : --
Color : --
DomainId : 255
Domain Name :
P2P VSI : disable
Multicast Fast Switch : disable
VSI State : up
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
Local VCCV : alert lsp-ping bfd
Remote VCCV : alert lsp-ping bfd
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

(2020-04-09)
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


*> 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

(2020-04-09)

*> 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
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
Prefix-sid: ::
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
Prefix-sid: ::
0000.1111.1111.1111.1111
----End
Configuration Files
● CSG configuration file
#
sysname CSG
#
mpls lsr-id 1.1.1.1
#
mpls

(2020-04-09)
#
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
#
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

(2020-04-09)
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
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

(2020-04-09)
#
esi 0000.1111.1111.1111.1111
#
#
mpls lsr-id 3.3.3.3
#
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.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

(2020-04-09)
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
#
#
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

(2020-04-09)
peer 3.3.3.3 enable

#
#
return
3.2.35.21 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-
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
Precautions
When you configure co-existence of VPLS and EVPN, note the following:
other sites.
recommended.

(2020-04-09)
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
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:

(2020-04-09)

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

(2020-04-09)
# 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
# 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
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

(2020-04-09)
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.
[~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-04-09)
Mac Flapping :0
PW Last Up Time : 2018/03/23 11:38:42
----End
Configuration Files
#
sysname PE1
#
#
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

(2020-04-09)
#
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
#
#
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

(2020-04-09)

#
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
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

(2020-04-09)
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
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

(2020-04-09)
3.2.35.22 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
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
Interfaces 1 and 2 in this example represent GigabitEthernet 1/0/0 and GigabitEthernet


(2020-04-09)

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
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
● RDs of the VPN and EVPN instances
● Import and export VPN targets of the VPN and EVPN instances

(2020-04-09)
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 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

(2020-04-09)
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
[*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

(2020-04-09)

[*DCI-PE2] commit
Step 9 Configure VXLAN tunnels between the DCI-PEs and DC-GWs.

[*DCI-PE1] commit
[*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

(2020-04-09)

[*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
[*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.
------------------------------------------------------------------------------
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

(2020-04-09)

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
#
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

(2020-04-09)

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

(2020-04-09)
#
sysname DCI-PE2
#
tnl-policy te-lsp1
#
ipv4-family
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

(2020-04-09)

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

(2020-04-09)
3.2.35.23 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
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)
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-04-09)

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
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
● Import and export VPN targets of the VPN instance
Procedure
Step 1 Assign an IP address to each node interface, including the loopback interfaces.

(2020-04-09)
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
[*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

(2020-04-09)
[*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
[*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.

(2020-04-09)
[~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


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

(2020-04-09)
[~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
#
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

(2020-04-09)
#
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
#
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

(2020-04-09)
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
#
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

(2020-04-09)
#
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
network 3.3.3.3 0.0.0.0
network 192.168.10.0 0.0.0.255
mpls-te enable
#
#
#
return

3.2.35.24 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
Interfaces 1 and 2 in this example represent GigabitEthernet 1/0/0 and GigabitEthernet


(2020-04-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.

(2020-04-09)
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.
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.
# Configure the UPE.
[~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] interface GigabitEthernet 2/0/0
[*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 vpnv4
[*UPE-bgp-af-vpnv4] peer 2.2.2.2 enable
[*UPE-bgp-af-vpnv4] quit
[*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

(2020-04-09)
[*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
[*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

(2020-04-09)
[*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
*> 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

(2020-04-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
#
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
#

(2020-04-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
#
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

(2020-04-09)
#
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
peer 2.2.2.2 enable
#
return
3.2.35.25 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
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.

(2020-04-09)
Figure 3-178 Splicing a VPLS in PW redundancy mode with an anycast VXLAN in

an EVPN active-active scenario
Interfaces 1 through 3 in this example represent GigabitEhernet 1/0/1, GigabitEhernet

1/0/2, and GigabitEhernet 1/0/3, respectively.
Device Interface IP Address and Mask

Name
GigabitEhernet 1/0/1 10.1.14.1/24
PE1 GigabitEhernet 1/0/2 10.1.13.1/24

(2020-04-09)
Device Interface IP Address and Mask

Name
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
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
● EVPN instance name
● RD and RT of the EVPN instance
Procedure
Step 1 Configure interface IP addresses, an IGP, and MPLS functions on each device.

(2020-04-09)

Step 2 Configure BGP EVPN on PE1 and PE2.
# Configure PE1.
[~PE1] evpn
[*PE1-evpn] bypass-vxlan enable
[*PE1-evpn] quit
[*PE1] bgp 100
[*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] 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] bypass source 1.1.1.100
[*PE1-Nve1] mac-address 00e0-fc12-3456
[*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

(2020-04-09)
[*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
[*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
-------------------------------------------------------------------------------

(2020-04-09)
1.1.1.1:1 1 Active
2.2.2.2:1 2 Inactive
----End
Configuration Files
#
sysname PE1
#
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

(2020-04-09)
source 1.1.1.20
bypass source 1.1.1.100
mac-address 00e0-fc12-3456
#
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.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

(2020-04-09)
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
#
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
#
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

(2020-04-09)

#
bridge-domain 10
l2 binding vsi vsi1
#
mpls ldp
#
undo shutdown
ip address 10.1.13.3 255.255.255.0
mpls
mpls ldp
#
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.35.26 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

(2020-04-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-04-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
# Configure the SPE.

[~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
# Configure the NPE.

[~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-GigabitEthernet2/0/0] quit
[*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] quit
[*NPE] route-policy SPE permit node 20
[*NPE] ip vpn-instance vpn1

(2020-04-09)
[*NPE-vpn-instance-vpn1-af-ipv4] import route-policy SPE evpn
[*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-04-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-04-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
● SPE configuration file

#
sysname SPE
#
ipv4-family
#

(2020-04-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
● NPE configuration file
#
sysname NPE
#
ipv4-family
import route-policy SPE evpn
#
mpls lsr-id 3.3.3.3

(2020-04-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.35.27 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-04-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
3. Create a VPN instance on each of the UPE and NPE.
5. Configure BGP-EVPN peer relationships between the UPE and SPE, and
between the SPE and NPE.
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-04-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-04-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-04-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-04-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-04-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.35.28 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-04-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
routes.

(2020-04-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-04-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] ipv4-family vpnv4
[*SPE-bgp-af-vpnv4] peer 3.3.3.3 enable
[*SPE-bgp-af-vpnv4] quit
[*SPE-bgp] quit
[*SPE] commit

[~NPE] bgp 100
[*NPE-bgp] ipv4-family vpnv4
[*NPE-bgp-af-vpnv4] peer 2.2.2.2 enable
[*NPE-bgp-af-vpnv4] quit
[*NPE-bgp] quit
[*NPE] commit

(2020-04-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-04-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-04-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-04-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-04-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.35.29 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

(2020-04-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-04-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-04-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] ipv4-family vpnv4
[*UPE-bgp-af-vpnv4] peer 2.2.2.2 enable
[*UPE-bgp-af-vpnv4] quit
[*UPE-bgp] quit
[*UPE] commit

[~SPE] bgp 100
[*SPE-bgp-af-vpnv4] peer 1.1.1.1 enable
[*SPE-bgp-af-vpnv4] peer 1.1.1.1 upe

(2020-04-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-04-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-04-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-04-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-04-09)
3.2.35.30 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
On the network shown in Figure 3-183, EVPN is configured on the PEs to carry
Layer 2 multicast services. PE1 is the root node, and its access side is the multicast
source. PE2 and PE3 are leaf nodes, and their access sides are receivers. 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-183 Configuring IGMP snooping over EVPN MPLS

(2020-04-09)
Precautions
When you configure IGMP snooping over EVPN MPLS, note the following:
other sites.
● The local loopback interface address is recommended as the source address
on each PE.
communicate.
2. Configure MPLS and mLDP P2MP both globally and per interface on each
node of 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.
5. Configure each PE's sub-interface connected to a CE.
6. Configure an ESI for each PE's interface connected to a CE.
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
● EVPN instance evrf1's RD on each PE: 100:1; RT: 1:1
Procedure
communicate. OSPF is used as an IGP in this example.
# Configure PE1.
[~PE1] ospf 1
[~PE1-ospf-1] quit

(2020-04-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
# Configure PE2.
[*PE2] mpls
[*PE2-mpls] quit
[*PE2] mpls ldp
# Configure the RR.

[*RR] mpls
[*RR-mpls] quit
[*RR] mpls ldp

(2020-04-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-04-09)
[*PE1] commit
# Configure PE2.
[*PE2] commit
# Configure PE3.
[*PE3] commit
Step 6 Configure an Eth-Trunk sub-interface on each PE connected to a CE.

# Configure PE1.
[*PE1] commit
# Configure PE2.
[*PE2] e-trunk 1
[*PE2] commit
# Configure PE3.
[*PE3] e-trunk 1

(2020-04-09)

[*PE3] commit
Step 7 Configure an ESI for each PE's interface connected to a CE.

# 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-04-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-04-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 following example uses the command output on PE2.

(2020-04-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 a PE. The
command output shows information about Join routes. The following 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-04-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-04-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
eth-trunk 10
#
undo shutdown
ip address 10.2.1.1 255.255.255.0
mpls
mpls ldp
#
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-04-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
eth-trunk 10
#
undo shutdown
ip address 10.3.1.1 255.255.255.0
mpls
mpls ldp
#
interface gigabitethernet 3/0/0
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
#
l2vpn-family evpn

(2020-04-09)

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
network 3.3.3.3 0.0.0.0

(2020-04-09)
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
#
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.35.31 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

(2020-04-09)
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
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
other sites.
is recommended.

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.

(2020-04-09)
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 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 3-184.
# Configure PE1.
[*HUAWEI] commit
[*PE1] commit
# Configure P.
[~HUAWEI] sysname P
[*HUAWEI] commit
[*P-LoopBack1] quit
[*P] commit
# Configure PE2.
[*HUAWEI] commit
[*PE2] commit

(2020-04-09)
# 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 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

--------------------------------------------------------------------------------
1111.1111.2222 GE2/0/0 1111.1111.2222.01 Up 8s L2 64
------------------------------------------------------------------------------


(2020-04-09)


# Configure PE1.
[*PE1] mpls
[*PE1-mpls] mpls te
[*PE1-mpls] quit
[*PE1] isis 1
[*PE1-isis-1] quit
[*PE1-Tunnel1] quit
[*PE1] commit

-----------------------------------------------------------------------------
48121 GE2/0/0 10.1.1.2 ISIS-V4 --- 1500
# Configure the P.
[*P] mpls
[*P-mpls] mpls te
[*P-mpls] quit
[*P] isis 1
[*P-isis-1] quit

(2020-04-09)

[*P-LoopBack1] quit
# Configure PE2.
[*PE2] mpls
[*PE2-mpls] mpls te
[*PE2-mpls] quit
[*PE2] isis 1
[*PE2-isis-1] quit
[*PE2-Tunnel1] quit
[*PE2] commit

Tunnel Attributes :
Traffic Switch :-
Session ID :1
FTid :1
Bfd Cap : None
Min BW :- Max BW :-
Readjust Value :-
Backup Tunnel :-

(2020-04-09)
Ip-Prefix Name : -

IncludeAll : 0x0
IncludeAny : 0x0
ExcludeAny : 0x0
FRR Flag : Disabled
IdleTime Remain :-
BFD Status :-
Pce Flag : Normal

# Configure PE1.
[*PE1-bd10] quit

(2020-04-09)
[*PE1] commit
# Configure PE2.
[*PE2-bd10] quit
[*PE2] commit

# Configure PE1.
[*PE1] commit
# Configure PE2.
[*PE2] commit
Step 6 Configure the Layer 2 Ethernet sub-interfaces connecting PEs and CEs.
# Configure PE1.
[*PE1] commit
# Configure PE2.
[*PE2] commit
Step 7 Configure a vBDIF interface on each PE and bind the vBDIF interface to a VPN
instance.
# Configure PE1.
[*PE1-Vbdif10] quit
[*PE1] commit
# Configure PE2.

(2020-04-09)

[*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] 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

(2020-04-09)
After completing the configuration, run the display bgp evpn peer command to


3.3.3.3 4 100 9 9 0 00:00:02 Established 5
Step 10 Configure CEs to communicate with PEs.

# Configure CE1.
# Configure CE2.



*> 0011.1111.1111.1111.1111:0 127.0.0.1
*>i 0011.1111.1111.1111.2222:0 3.3.3.3
*> 0011.1111.1111.1111.1111:4294967295 127.0.0.1
*>i 0011.1111.1111.1111.2222:4294967295 3.3.3.3
*> 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

(2020-04-09)

*> 0:48:00e0-fc12-7890:32:192.168.1.2 0.0.0.0
*>i 0:48:00e0-fc12-3456:32:192.168.2.2 3.3.3.3
*>i 0:48:00e0-fc12-3456:32:192.168.2.2 3.3.3.3
*> 0:48:00e0-fc12-7890:32:192.168.1.2 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

*> 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

*> 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.2 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.
From: 3.3.3.3 (10.2.1.2)

(2020-04-09)

0000.0000.0000.0000.0000
Remote-Cross route
From: 3.3.3.3 (10.2.1.2)
Relay Tunnel Out-Interface: Tunnel1
0000.0000.0000.0000.0000
From: 3.3.3.3 (10.2.1.2)
cost 20
----End
Configuration Files
#
sysname PE1
#
tnl-policy srte
#
ipv4-family

(2020-04-09)

#
mpls lsr-id 1.1.1.1
#
mpls
mpls te
#
bridge-domain 10
#
#
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 address 192.168.1.1 255.255.255.0
#
undo shutdown
esi 0011.1111.1111.1111.1111
#
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
#
bgp 100
#
ipv4-family unicast
peer 3.3.3.3 enable
#
import-route direct

(2020-04-09)

#
l2vpn-family evpn
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
#
tnl-policy srte
#
ipv4-family
#
mpls lsr-id 3.3.3.3

(2020-04-09)
#
mpls
mpls te
#
bridge-domain 10
#
#
segment-routing
#
isis 1
is-level level-2
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
peer 1.1.1.1 enable

(2020-04-09)
#
tunnel-policy srte
#
#
return

#
sysname CE1
#
undo shutdown
#
rewrite pop single
#
return

#
sysname CE2
#
undo shutdown
#
rewrite pop single
#
return
3.2.35.32 Example for Configuring the IPv4 NFVI Distributed Gateway

Function (SR Tunnels)
This section provides an example for configuring the IPv4 NFVI distributed
gateway function to carry service traffic over SR tunnels.
IPv4 mobile phone traffic is sent to vUGWs and vMSEs on the DCN. After being
traffic load-balancing on the DCN, you need to deploy the NFVI distributed
gateway function.
connected to L2GW/L3GW1 and L2GW/L3GW2 through IPUs. SR tunnels are
established between PEs and DC-GWs and between DC-GWs and L2GW/L3GWs to
carry IPv4 service traffic.

(2020-04-09)
Figure 3-185 Networking of configuring the IPv4 NFVI distributed gateway

function (SR tunnels)
Interfaces 1 through 6 in this example represent GE 1/0/1, GE 1/0/2, GE 1/0/3, GE 1/0/4, GE

1/0/5, and GE 1/0/6, respectively.

(2020-04-09)

LoopBack1 7.7.7.7
LoopBack1 8.8.8.8
DCGW1 GigabitEthernet 1/0/1 10.6.1.1/24
LoopBack2 33.33.33.33/32
LoopBack2 44.44.44.44/32
L2GW/ GigabitEthernet 1/0/1 10.6.4.1/24

L3GW1

L3GW2

(2020-04-09)
1. Configure a routing protocol between PEs, DC-GWs, and L2GW/L3GWs to
ensure Layer 3 interworking between ASs.
2. Establish EBGP peer relationships between PEs and DC-GWs and IBGP peer
relationships between DC-GWs and L2GW/L3GWs.
3. Configure SR-MPLS TE tunnels between PEs and DC-GWs and between DC-
GWs and L2GW/L3GWs.
4. Configure EVPN instances on DC-GWs and L2GW/L3GWs and bind the EVPN
instances to BDs.
5. Configure L3VPN instances on DC-GWs and L2GW/L3GWs and bind the
L3VPN instances to VBDIF interfaces.
6. Configure a tunnel policy on PEs, DC-GWs, and L2GW/L3GWs.
7. Configure the BGP EVPN function on DC-GWs and L2GW/L3GWs.
8. Configure the BGP VPNv4 function on DC-GWs and PEs.
9. Configure Layer 2 sub-interfaces on DC-GWs and L2GW/L3GWs and configure
the static VPN routes destined for VNFs on L2GW/L3GWs.
10. Configure L2GW/L3GWs to import static VPN routes through BGP EVPN.
Configure and apply a route-policy to L3VPN instances so that the static VPN
routes can retain the original next hops.
11. Configure static default VPN routes and loopback addresses on DC-GWs. The
loopback addresses are used to establish BGP VPN peer relationships with
VNFs. Configure and apply a route-policy to L3VPN instances so that DC-GWs
can advertise static default VPN routes and VPN loopback routes only through
BGP EVPN.
12. Establish BGP VPN peer relationships between DC-GWs and VNFs.
13. Configure the load balancing function on PEs, DC-GWs, and L2GW/L3GWs.
Procedure
Step 1 Configure IP addresses for all interfaces, including loopback interfaces, on PEs, DC-
GWs, and L2GW/L3GWs.
Step 2 Configure a routing protocol between PEs, DC-GWs, and L2GW/L3GWs to ensure
Layer 3 interworking between ASs.

(2020-04-09)
Step 3 Establish EBGP peer relationships between PEs and DC-GWs and IBGP peer
Step 4 Configure SR-MPLS TE tunnels between PEs and DC-GWs and between DC-GWs
and L2GW/L3GWs.
Step 5 Configure EVPN instances on DC-GWs and L2GW/L3GWs and bind the EVPN
instances to BDs.
# Configure DC-GW1.
[~DCGW1] evpn vpn-instance evrf1 bd-mode
[*DCGW1-evpn-instance-evrf1] route-distinguisher 1:1
[*DCGW1-evpn-instance-evrf1] vpn-target 1:1
[*DCGW1-evpn-instance-evrf1] quit
[*DCGW1] evpn vpn-instance evrf2 bd-mode
[*DCGW1] bridge-domain 10
[*DCGW1-bd10] evpn binding vpn-instance evrf1
[*DCGW1-bd10] quit
[*DCGW1-bd20] quit
[*DCGW1-bd30] quit
[*DCGW1-bd40] quit
[*DCGW1] commit
Repeat this step for DC-GW2 and L2GW/L3GWs. For configuration details, see
Step 6 Configure L3VPN instances on DC-GWs and L2GW/L3GWs.
# Configure DC-GW1.
[~DCGW1] ip vpn-instance vpn1
[*DCGW1-vpn-instance-vpn1] ipv4-family
[*DCGW1-vpn-instance-vpn1-af-ipv4] route-distinguisher 33:33
[*DCGW1-vpn-instance-vpn1-af-ipv4] vpn-target 11:1 evpn
[*DCGW1-vpn-instance-vpn1-af-ipv4] quit
[*DCGW1-vpn-instance-vpn1] evpn mpls routing-enable
[*DCGW1-vpn-instance-vpn1] quit
[*DCGW1] interface vbdif10
[*DCGW1-Vbdif10] ip binding vpn-instance vpn1
[*DCGW1-Vbdif10] ip address 10.1.1.1 24
[*DCGW1-Vbdif10] arp generate-rd-table enable
[*DCGW1-Vbdif10] anycast-gateway enable
[*DCGW1-Vbdif10] mac-address 00e0-fc00-0003
[*DCGW1-Vbdif10] quit

(2020-04-09)

[*DCGW1] commit
Repeat this step for DC-GW2. For configuration details, see Configuration Files in
this section.
# Configure L2GW/L3GW1.
[~L2GW/L3GW1] ip vpn-instance vpn1
[*L2GW/L3GW1-vpn-instance-vpn1] ipv4-family
[*L2GW/L3GW1-vpn-instance-vpn1-af-ipv4] route-distinguisher 11:11
[*L2GW/L3GW1-vpn-instance-vpn1-af-ipv4] vpn-target 11:1 evpn
[*L2GW/L3GW1-vpn-instance-vpn1-af-ipv4] quit
[*L2GW/L3GW1-vpn-instance-vpn1] evpn mpls routing-enable
[*L2GW/L3GW1-vpn-instance-vpn1] quit
[*L2GW/L3GW1] interface vbdif10
[*L2GW/L3GW1-Vbdif10] ip binding vpn-instance vpn1
[*L2GW/L3GW1-Vbdif10] ip address 10.1.1.1 24
[*L2GW/L3GW1-Vbdif10] arp generate-rd-table enable
[*L2GW/L3GW1-Vbdif10] anycast-gateway enable
[*L2GW/L3GW1-Vbdif10] mac-address 00e0-fc00-0003
[*L2GW/L3GW1-Vbdif10] arp collect host enable
[*L2GW/L3GW1-Vbdif10] quit
[*L2GW/L3GW1] commit
Repeat this step for L2GW/L3GW2. For configuration details, see Configuration

(2020-04-09)
Step 7 Configure a tunnel policy on PEs, DC-GWs, and L2GW/L3GWs.
# Configure PE1.
[*PE1-tunnel-policy-srte] tunnel select-seq sr-te load-balance-number 3
[*PE1-vpn-instance-vpn1-af-ipv4] tnl-policy srte
[*PE1] commit
section.
# Configure DC-GW1.
[~DCGW1] tunnel-policy srte
[*DCGW1-tunnel-policy-srte] tunnel select-seq sr-te load-balance-number 3
[*DCGW1-tunnel-policy-srte] quit
[*DCGW1] ip vpn-instance vpn1
[*DCGW1-vpn-instance-vpn1-af-ipv4] tnl-policy srte evpn
[*DCGW1-vpn-instance-vpn1-af-ipv4] tnl-policy srte
[*DCGW1] commit
this section.
[~L2GW/L3GW1] tunnel-policy srte
[*L2GW/L3GW1-tunnel-policy-srte] tunnel select-seq sr-te load-balance-number 3
[*L2GW/L3GW1-tunnel-policy-srte] quit
[*L2GW/L3GW1] ip vpn-instance vpn1
[*L2GW/L3GW1-vpn-instance-vpn1-af-ipv4] tnl-policy srte evpn
Step 8 Configure the BGP EVPN function on DC-GWs and L2GW/L3GWs.
# Configure DC-GW1.
[~DCGW1] ip ip-prefix uIP index 10 permit 10.10.10.10 32
[*DCGW1] route-policy stopuIP deny node 10
[*DCGW1-route-policy] if-match ip-prefix uIP
[*DCGW1-route-policy] quit
[*DCGW1] route-policy stopuIP permit node 20
[*DCGW1] bgp 100
[*DCGW1-bgp] l2vpn-family evpn
[*DCGW1-bgp-af-evpn] peer 1.1.1.1 enable
[*DCGW1-bgp-af-evpn] peer 4.4.4.4 route-policy stopuIP export
[*DCGW1-bgp-af-evpn] quit
[*DCGW1-bgp] quit
[*DCGW1] commit

(2020-04-09)
this section.
[~L2GW/L3GW1] bgp 100
[*L2GW/L3GW1-bgp] l2vpn-family evpn
[*L2GW/L3GW1-bgp-af-evpn] peer 2.2.2.2 enable
[*L2GW/L3GW1-bgp-af-evpn] peer 2.2.2.2 advertise arp
[*L2GW/L3GW1-bgp-af-evpn] quit
[*L2GW/L3GW1-bgp] quit
[*L2GW/L3GW1] evpn soure-address 1.1.1.1
[*L2GW/L3GW1] evpn
[*L2GW/L3GW1-evpn] vlan-extend private enable
[*L2GW/L3GW1-evpn] vlan-extend redirect enable
[*L2GW/L3GW1-evpn] local-remote frr enable
[*L2GW/L3GW1-evpn] quit
Step 9 Configure the BGP VPNv4 function on DC-GWs and PEs.
# Configure DC-GW1.
[~DCGW1-vpn-instance-vpn1] vpn-target 10:1
[*DCGW1] bgp 100
[*DCGW1-bgp] ipv4-family vpnv4
[*DCGW1-bgp-af-vpnv4] peer 7.7.7.7 enable
[*DCGW1-bgp-af-vpnv4] quit
[*DCGW1-bgp] quit
[*DCGW1] commit
this section.
# Configure PE1.
[*PE1-vpn-instance-vpn1-af-ipv4] vpn-target 10:1
[*PE1] interface GigabitEthernet1/0/3
[*PE1-GigabitEthernet1/0/3] ip address 10.7.1.1 255.255.255.0
[*PE1] bgp 200
[*PE1-bgp] quit
[*PE1] commit
section.

(2020-04-09)
Step 10 Configure Layer 2 sub-interfaces on DC-GWs and L2GW/L3GWs and configure the
static VPN routes destined for VNFs on L2GW/L3GWs.
# Configure DC-GW1.
This example binds a sub-interface of the physical interface of DC-GW1 to a BD to ensure

that the VBDIF interface is Up. In actual situations, bind service-irrelevant interfaces to BDs
to ensure network reliability.
[~DCGW1] interface GigabitEthernet1/0/2.1 mode l2

[*DCGW1-GigabitEthernet1/0/2.1] encapsulation dot1q vid 10
[*DCGW1-GigabitEthernet1/0/2.1] rewrite pop single
[*DCGW1-GigabitEthernet1/0/2.1] bridge-domain 10
[*DCGW1-GigabitEthernet1/0/2.1] quit
[*DCGW1] interface GigabitEthernet1/0/2.2 mode l2
[*DCGW1] commit
this section.
[~L2GW/L3GW1] lacp e-trunk system-id 00e0-fc00-0002
[*L2GW/L3GW1] lacp e-trunk priority 1
[*L2GW/L3GW1] e-trunk 1
[*L2GW/L3GW1-e-trunk-1] peer-address 2.2.2.2 source-address 1.1.1.1
[*L2GW/L3GW1-e-trunk-1] priority 5
[*L2GW/L3GW1-e-trunk-1] quit
[*L2GW/L3GW1] interface Eth-Trunk 10
[*L2GW/L3GW1-Eth-Trunk10] mode lacp-static
[*L2GW/L3GW1-Eth-Trunk10] e-trunk 1
[*L2GW/L3GW1-Eth-Trunk10] e-trunk mode force-master
[*L2GW/L3GW1-Eth-Trunk10] esi 0000.1111.1111.1111.1111
[*L2GW/L3GW1-Eth-Trunk10] quit

(2020-04-09)
[*L2GW/L3GW1] interface Eth-Trunk 10.1 mode l2

[*L2GW/L3GW1-Eth-Trunk10.1] encapsulation dot1q vid 10
[*L2GW/L3GW1-Eth-Trunk10.1] rewrite pop single
[*L2GW/L3GW1-Eth-Trunk10.1] bridge-domain 10
[*L2GW/L3GW1-Eth-Trunk10.1] quit
[~L2GW/L3GW1] interface GigabitEthernet1/0/3
[*L2GW/L3GW1-GigabitEthernet1/0/3] eth-trunk 10
[*L2GW/L3GW1-GigabitEthernet1/0/3] quit
[*L2GW/L3GW1] interface GigabitEthernet1/0/4
[*L2GW/L3GW1] ip route-static vpn-instance vpn1 5.5.5.5 255.255.255.255 10.1.1.2 preference 255 tag
1000 inter-protocol-ecmp
Step 11 Configure L2GW/L3GWs to import static VPN routes through BGP EVPN. Configure
and apply a route-policy for L3VPN instances so that the static VPN routes can
retain the original next hops.
[*L2GW/L3GW1-bgp] ipv4-family vpn-instance vpn1
[*L2GW/L3GW1-bgp-vpn1] import-route static
[*L2GW/L3GW1-bgp-vpn1] advertise l2vpn evpn import-route-multipath
[*L2GW/L3GW1-bgp-vpn1] quit
[*L2GW/L3GW1] route-policy sp permit node 10
[*L2GW/L3GW1-route-policy] if-match tag 1000
[*L2GW/L3GW1-route-policy] apply gateway-ip origin-nexthop
[*L2GW/L3GW1-route-policy] quit
[*L2GW/L3GW1] route-policy sp deny node 20
[*L2GW/L3GW1-vpn-instance-vpn1-ipv4] export route-policy sp evpn
[*L2GW/L3GW1-vpn-instance-vpn1-ipv4] quit

(2020-04-09)
Step 12 Configure static default VPN routes and loopback addresses on DC-GWs. The
loopback addresses are used to establish BGP VPN peer relationships with VNFs.
Configure and apply a route-policy for L3VPN instances so that DC-GWs can
advertise static default VPN routes and VPN loopback routes only through BGP
EVPN.
# Configure DC-GW1.
[~DCGW1] ip route-static vpn-instance vpn1 0.0.0.0 0.0.0.0 NULL0 tag 2000
[*DCGW1] interface LoopBack2
[*DCGW1-LoopBack2] ip binding vpn-instance vpn1
[*DCGW1-LoopBack2] ip address 33.33.33.33 255.255.255.255
[*DCGW1-LoopBack2] quit
[*DCGW1] bgp 100
[*DCGW1-bgp] ipv4-family vpn-instance vpn1
[*DCGW1-bgp-vpn1] advertise l2vpn evpn
[*DCGW1-bgp-vpn1] import-route direct
[*DCGW1-bgp-vpn1] network 0.0.0.0 0
[*DCGW1-bgp-vpn1] quit
[*DCGW1-bgp] quit
[*DCGW1] ip ip-prefix lp index 10 permit 33.33.33.33 32
[*DCGW1] route-policy dp permit node 10
[*DCGW1-route-policy] if-match tag 2000
[*DCGW1-route-policy] if-match ip-prefix lp
[*DCGW1-vpn-instance-vpn1-af-ipv4] export route-policy dp evpn
[*DCGW1] commit
this section.
# Configure DC-GW1.
[~DCGW1] route-policy p1 deny node 10
[*DCGW1] bgp 100
[*DCGW1-bgp-vpn1] peer 5.5.5.5 as-number 100
[*DCGW1-bgp-vpn1] peer 5.5.5.5 connect-interface LoopBack2
[*DCGW1-bgp-vpn1] peer 5.5.5.5 route-policy p1 export
[*DCGW1-bgp] quit
[*DCGW1] commit
# Configure DC-GW2.
[*DCGW2] bgp 100

(2020-04-09)

[*DCGW2-bgp] quit
[*DCGW2] commit
Step 14 Configure the load balancing function on PEs, DC-GWs, and L2GW/L3GWs.
# Configure PE1.
[~PE1] bgp 100
[*PE1-bgp-vpn1] maximum load-balancing 16
[*PE1-bgp] quit
[*PE1] commit
section.
# Configure DC-GW1.
[~DCGW1] bgp 100
[*DCGW1-bgp-vpn1] maximum load-balancing 16
[*DCGW1-bgp-af-evpn] peer 1.1.1.1 capability-advertise add-path both
[*DCGW1-bgp-af-evpn] peer 1.1.1.1 advertise add-path path-number 16
[*DCGW1-bgp] quit
[*DCGW1] commit
this section.
[*L2GW/L3GW1-bgp-vpn1] maximum load-balancing 16
[*L2GW/L3GW1-bgp-af-evpn] bestroute add-path path-number 16
[*L2GW/L3GW1-bgp-af-evpn] peer 3.3.3.3 capability-advertise add-path both
[*L2GW/L3GW1-bgp-af-evpn] peer 3.3.3.3 advertise add-path path-number 16
After completing the configurations, run the display ip routing-table vpn-
instance vpn1 command on PEs to view the mobile phone route information and
VNF route information in VPN routing tables.
------------------------------------------------------------------------------

(2020-04-09)
0.0.0.0/0 Static 60 0 DB 0.0.0.0 NULL0

5.5.5.5/32 EBGP 255 0 RD 1.1.1.1 Tunnel1
EBGP 255 0 RD 2.2.2.2 Tunnel2
6.6.6.6/32 EBGP 255 0 RD 1.1.1.1 Tunnel1
10.10.10.10/32 EBGP 255 0 RD 1.1.1.1 Tunnel1
33.33.33.33/32 EBGP 255 0 RD 1.1.1.1 Tunnel1
44.44.44.44/32 EBGP 255 0 RD 1.1.1.1 Tunnel2
----End
Configuration Files
#
sysname PE1
#
ipv4-family
tnl-policy srte
#
mpls lsr-id 7.7.7.7
#
mpls
mpls te
#
explicit-path PtoD74
#
#
segment-routing
#
isis 1
is-level level-2
cost-style wide
network-entity 10.0000.0000.0007.00
traffic-eng level-2
#
undo shutdown
ip address 10.6.7.1 255.255.255.0
mpls
mpls te
#
undo shutdown
ip address 10.6.5.2 255.255.255.0
mpls
mpls te
#

(2020-04-09)
undo shutdown
ip address 10.7.1.1 255.255.255.0
#
interface LoopBack1
ip address 7.7.7.7 255.255.255.255
isis enable 1
#
interface Tunnel1
destination 3.3.3.3
mpls te path explicit-path PtoD73
#
interface Tunnel2
destination 4.4.4.4
#
bgp 200
#
ipv4-family unicast
network 7.7.7.7 255.255.255.255
network 10.6.5.0 255.255.255.0
network 10.6.7.0 255.255.255.0
peer 3.3.3.3 enable
peer 4.4.4.4 enable
#
#
ipv4-family vpnv4
policy vpn-target
peer 3.3.3.3 enable
peer 4.4.4.4 enable
#
import-route direct
import-route static
maximum load-balancing 16
#
ip route-static 3.3.3.3 255.255.255.255 10.6.5.1
ip route-static 4.4.4.4 255.255.255.255 10.6.7.2
ip route-static 8.8.8.8 255.255.255.255 10.6.7.2
ip route-static vpn-instance vpn1 0.0.0.0 0.0.0.0 NULL0 tag 2000
#
tunnel-policy srte
#
return
#
sysname PE2
#

(2020-04-09)
ipv4-family
tnl-policy srte
#
mpls lsr-id 8.8.8.8
#
mpls
mpls te
#
#
#
segment-routing
#
isis 1
is-level level-2
cost-style wide
network-entity 10.0000.0000.0008.00
traffic-eng level-2
#
undo shutdown
ip address 10.6.7.2 255.255.255.0
mpls
mpls te
#
undo shutdown
ip address 10.6.6.2 255.255.255.0
mpls
mpls te
#
undo shutdown
ip address 10.8.1.1 255.255.255.0
#
interface LoopBack1
ip address 8.8.8.8 255.255.255.255
isis enable 1
#
interface Tunnel1
destination 3.3.3.3
#
interface Tunnel2
destination 4.4.4.4
#
bgp 200

(2020-04-09)

#
ipv4-family unicast
network 8.8.8.8 255.255.255.255
network 10.6.6.0 255.255.255.0
network 10.6.7.0 255.255.255.0
peer 3.3.3.3 enable
peer 4.4.4.4 enable
#
#
ipv4-family vpnv4
policy vpn-target
peer 3.3.3.3 enable
peer 4.4.4.4 enable
#
import-route direct
import-route static
#
ip route-static 3.3.3.3 255.255.255.255 10.6.7.1
ip route-static 4.4.4.4 255.255.255.255 10.6.6.1
ip route-static 7.7.7.7 255.255.255.255 10.6.7.1
#
tunnel-policy srte
#
return
● DC-GW1 configuration file
#
sysname DCGW1
#
tnl-policy srte
#
tnl-policy srte
#
tnl-policy srte
#
tnl-policy srte
#
ipv4-family

(2020-04-09)
tnl-policy srte
export route-policy dp evpn
#
mpls lsr-id 3.3.3.3
#
mpls
mpls te
#
bridge-domain 10
#
bridge-domain 20
#
bridge-domain 30
#
bridge-domain 40
#
explicit-path DtoL31
#
#
explicit-path DtoP37
#
#
segment-routing
#
interface Vbdif10
ip address 10.1.1.1 255.255.255.0
arp generate-rd-table enable
anycast-gateway enable
#
interface Vbdif20
ip address 10.2.1.1 255.255.255.0
#
interface Vbdif30
ip address 10.3.1.1 255.255.255.0
#
interface Vbdif40
ip address 10.4.1.1 255.255.255.0

(2020-04-09)
#
undo shutdown
ip address 10.6.1.1 255.255.255.0
mpls
mpls te
#
rewrite pop single
bridge-domain 20
#
rewrite pop single
bridge-domain 40
#
undo shutdown
ip address 10.6.2.1 255.255.255.0
mpls
mpls te
#
rewrite pop single
bridge-domain 10
#
rewrite pop single
bridge-domain 30
#
undo shutdown
ip address 10.6.5.1 255.255.255.0
mpls
mpls 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 Tunnel1
destination 1.1.1.1
mpls te tunnel-id 1
mpls te path explicit-path DtoL31
#
interface Tunnel2
destination 2.2.2.2
mpls te tunnel-id 2
#
interface Tunnel7
destination 7.7.7.7
mpls te tunnel-id 7

(2020-04-09)
mpls te path explicit-path DtoP37

#
interface Tunnel8
destination 8.8.8.8
mpls te tunnel-id 8
#
bgp 100
#
ipv4-family unicast
network 10.6.1.0 255.255.255.0
network 10.6.5.0 255.255.255.0
import-route static
import-route ospf 100
peer 1.1.1.1 enable
peer 2.2.2.2 enable
peer 4.4.4.4 enable
peer 7.7.7.7 enable
peer 8.8.8.8 enable
#
#
ipv4-family vpnv4
policy vpn-target
peer 7.7.7.7 enable
peer 8.8.8.8 enable
#
network 0.0.0.0
import-route direct
peer 5.5.5.5 route-policy p1 export
#
l2vpn-family evpn
peer 1.1.1.1 enable
peer 1.1.1.1 capability-advertise add-path both
peer 1.1.1.1 advertise add-path path-number 16
peer 2.2.2.2 enable

(2020-04-09)
peer 4.4.4.4 enable

peer 4.4.4.4 route-policy stopuIP export
#
ospf 100
area 0.0.0.0
network 3.3.3.3 0.0.0.0
network 10.6.1.0 0.0.0.255
network 10.6.2.0 0.0.0.255
mpls-te enable
#
route-policy dp permit node 10
if-match tag 2000
#
if-match ip-prefix lp
#
route-policy p1 deny node 10
#
route-policy stopuIP deny node 10
if-match ip-prefix uIP
#
route-policy stopuIP permit node 20
#
ip ip-prefix lp index 10 permit 33.33.33.33 32
ip ip-prefix uIP index 10 permit 10.10.10.10 32
#
ip route-static 7.7.7.7 255.255.255.255 10.6.5.2
ip route-static 8.8.8.8 255.255.255.255 10.6.1.2
#
tunnel-policy srte
#
return
#
sysname DCGW2
#
tnl-policy srte
#
tnl-policy srte
#
tnl-policy srte
#
tnl-policy srte
#
ipv4-family

(2020-04-09)
tnl-policy srte
#
mpls lsr-id 4.4.4.4
#
mpls
mpls te
#
bridge-domain 10
#
bridge-domain 20
#
bridge-domain 30
#
bridge-domain 40
#
#
#
#
#
segment-routing
#
interface Vbdif10
ip address 10.1.1.1 255.255.255.0
#
interface Vbdif20
ip address 10.2.1.1 255.255.255.0
#
interface Vbdif30
ip address 10.3.1.1 255.255.255.0
#
interface Vbdif40
ip address 10.4.1.1 255.255.255.0

(2020-04-09)
#
undo shutdown
ip address 10.6.1.2 255.255.255.0
mpls
mpls te
#
rewrite pop single
bridge-domain 10
#
rewrite pop single
bridge-domain 30
#
undo shutdown
ip address 10.6.3.1 255.255.255.0
mpls
mpls te
#
rewrite pop single
bridge-domain 20
#
rewrite pop single
bridge-domain 40
#
undo shutdown
ip address 10.6.6.1 255.255.255.0
mpls
mpls te
#
interface LoopBack1
ip address 4.4.4.4 255.255.255.255
#
interface LoopBack2
ip address 44.44.44.44 255.255.255.255
#
interface Tunnel1
destination 1.1.1.1
mpls te tunnel-id 1
#
interface Tunnel2
destination 2.2.2.2
mpls te tunnel-id 2
#
interface Tunnel7
destination 7.7.7.7
mpls te tunnel-id 7

(2020-04-09)

#
interface Tunnel8
destination 8.8.8.8
mpls te tunnel-id 8
#
bgp 100
#
ipv4-family unicast
network 10.6.1.0 255.255.255.0
network 10.6.5.0 255.255.255.0
import-route static
peer 1.1.1.1 enable
peer 2.2.2.2 enable
peer 3.3.3.3 enable
peer 7.7.7.7 enable
peer 8.8.8.8 enable
#
#
ipv4-family vpnv4
policy vpn-target
peer 7.7.7.7 enable
peer 8.8.8.8 enable
#
network 0.0.0.0
import-route direct
#
l2vpn-family evpn
peer 1.1.1.1 enable
peer 2.2.2.2 enable

(2020-04-09)
peer 3.3.3.3 enable

#
ospf 100
area 0.0.0.0
network 4.4.4.4 0.0.0.0
network 10.6.1.0 0.0.0.255
network 10.6.3.0 0.0.0.255
mpls-te enable
#
if-match tag 2000
#
#
#
#
#
#
ip route-static 7.7.7.7 255.255.255.255 10.6.1.1
ip route-static 8.8.8.8 255.255.255.255 10.6.6.2
#
tunnel-policy srte
#
return
● L2GW/L3GW1 configuration file
#
sysname L2GW/L3GW1
#
#
evpn
#
mac-duplication
#
#
#
#

(2020-04-09)

#
ipv4-family
export route-policy sp evpn
#
mpls lsr-id 1.1.1.1
#
mpls
mpls te
#
bridge-domain 10
#
bridge-domain 20
#
bridge-domain 30
#
bridge-domain 40
#
explicit-path LtoD13
#
#
explicit-path LtoL
#
e-trunk 1
priority 5
#
segment-routing
#
interface Vbdif10
ip address 10.1.1.1 255.255.255.0
#
interface Vbdif20
ip address 10.2.1.1 255.255.255.0
#
interface Vbdif30
ip address 10.3.1.1 255.255.255.0
#

(2020-04-09)
interface Vbdif40
ip address 10.4.1.1 255.255.255.0
#
mode lacp-static
e-trunk 1
esi 0000.1111.1111.1111.1111
#
rewrite pop single
bridge-domain 10
#
mode lacp-static
e-trunk 1
esi 0000.2222.2222.2222.2222
#
rewrite pop single
bridge-domain 20
#
mode lacp-static
e-trunk 1
esi 0000.3333.3333.3333.3333
#
rewrite pop single
bridge-domain 30
#
mode lacp-static
e-trunk 1
esi 0000.4444.4444.4444.4444
#
rewrite pop single
bridge-domain 40
#
undo shutdown
ip address 10.6.4.1 255.255.255.0
mpls
mpls te
#
undo shutdown
ip address 10.6.2.2 255.255.255.0
mpls
mpls te
#
undo shutdown
eth-trunk 10
#

(2020-04-09)
undo shutdown
eth-trunk 20
#
undo shutdown
eth-trunk 30
#
undo shutdown
eth-trunk 40
#
interface LoopBack1
ip address 1.1.1.1 255.255.255.255
#
interface Tunnel1
destination 3.3.3.3
mpls te tunnel-id 1
mpls te path explicit-path LtoD13
#
interface Tunnel2
destination 4.4.4.4
mpls te tunnel-id 2
#
interface Tunnel3
destination 2.2.2.2
mpls te tunnel-id 3
mpls te path explicit-path LtoL
#
bgp 100
#
ipv4-family unicast
peer 2.2.2.2 enable
peer 3.3.3.3 enable
peer 4.4.4.4 enable
#
import-route direct
import-route static
advertise l2vpn evpn import-route-multipath
#
l2vpn-family evpn
bestroute add-path path-number 16
peer 2.2.2.2 enable
peer 2.2.2.2 advertise arp
peer 3.3.3.3 enable
peer 4.4.4.4 enable

(2020-04-09)

#
ospf 100
area 0.0.0.0
network 1.1.1.1 0.0.0.0
network 10.6.2.0 0.0.0.255
network 10.6.4.0 0.0.0.255
mpls-te enable
#
route-policy sp permit node 10
if-match tag 1000
apply gateway-ip origin-nexthop
#
route-policy sp deny node 20
#
ip route-static vpn-instance vpn1 5.5.5.5 255.255.255.255 10.1.1.2 preference 255 tag 1000 inter-
protocol-ecmp
protocol-ecmp
protocol-ecmp
protocol-ecmp
#
tunnel-policy srte
#
#
return
#
sysname L2GW/L3GW2
#
#
evpn
#
mac-duplication
#
#
#
#
#

(2020-04-09)
ipv4-family
#
mpls lsr-id 2.2.2.2
#
mpls
mpls te
#
bridge-domain 10
#
bridge-domain 20
#
bridge-domain 30
#
bridge-domain 40
#
#
#
explicit-path LtoL
#
e-trunk 1
priority 5
#
segment-routing
#
interface Vbdif10
ip address 10.1.1.1 255.255.255.0
#
interface Vbdif20
ip address 10.2.1.1 255.255.255.0
#
interface Vbdif30
ip address 10.3.1.1 255.255.255.0
#
interface Vbdif40

(2020-04-09)
ip address 10.4.1.1 255.255.255.0

#
mode lacp-static
e-trunk 1
esi 0000.1111.1111.1111.1111
#
rewrite pop single
bridge-domain 10
#
mode lacp-static
e-trunk 1
esi 0000.2222.2222.2222.2222
#
rewrite pop single
bridge-domain 20
#
mode lacp-static
e-trunk 1
esi 0000.3333.3333.3333.3333
#
rewrite pop single
bridge-domain 30
#
mode lacp-static
e-trunk 1
esi 0000.4444.4444.4444.4444
#
rewrite pop single
bridge-domain 40
#
undo shutdown
ip address 10.6.4.2 255.255.255.0
mpls
mpls te
#
undo shutdown
ip address 10.6.3.2 255.255.255.0
mpls
mpls te
#
undo shutdown
eth-trunk 10
#
undo shutdown
eth-trunk 20

(2020-04-09)
#
undo shutdown
eth-trunk 30
#
undo shutdown
eth-trunk 40
#
interface LoopBack1
ip address 2.2.2.2 255.255.255.255
#
interface Tunnel1
destination 3.3.3.3
mpls te tunnel-id 1
#
interface Tunnel2
destination 4.4.4.4
mpls te tunnel-id 2
#
interface Tunnel3
destination 1.1.1.1
mpls te tunnel-id 3
#
bgp 100
#
ipv4-family unicast
peer 1.1.1.1 enable
peer 3.3.3.3 enable
peer 4.4.4.4 enable
#
import-route direct
import-route static
#
l2vpn-family evpn
peer 1.1.1.1 enable
peer 3.3.3.3 enable
peer 4.4.4.4 enable

(2020-04-09)

#
ospf 100
area 0.0.0.0
network 2.2.2.2 0.0.0.0
network 10.6.3.0 0.0.0.255
network 10.6.4.0 0.0.0.255
mpls-te enable
#
if-match tag 1000
#
#
protocol-ecmp
protocol-ecmp
protocol-ecmp
protocol-ecmp
#
tunnel-policy srte
#
#
return
● VNF1 configuration file
For details, see the configuration file of the corresponding product.

Function (SR Tunnels)
gateway function to carry service traffic over SR tunnels.
gateway function.
connected to L2GW/L3GW1 and L2GW/L3GW2 through IPUs. SR tunnels are

(2020-04-09)
established between PEs and DC-GWs and between DC-GWs and L2GW/L3GWs to
carry IPv6 service traffic.

function (SR tunnels)


(2020-04-09)

GigabitEthernet1/0/3 2001:DB8:7::1/64
LoopBack1 7.7.7.7
GigabitEthernet1/0/3 2001:DB8:8::1/64
LoopBack1 8.8.8.8
GigabitEthernet1/0/3 10.6.5.1/24
LoopBack2 2001:DB8:33::33/128
GigabitEthernet1/0/3 10.6.6.1/24
LoopBack2 2001:DB8:44::44/32

L3GW1
GigabitEthernet1/0/3 -

L3GW2

(2020-04-09)
3. Configure SR-MPLS TE tunnels between PEs and DC-GWs and between DC-
GWs and L2GW/L3GWs.
4. Configure EVPN instances on DC-GWs and L2GW/L3GWs and bind the EVPN
instances to BDs.
5. Configure L3VPN instances on DC-GWs and L2GW/L3GWs and bind the
L3VPN instances to VBDIF interfaces.
7. Configure the BGP EVPN function on DC-GWs and L2GW/L3GWs.
8. Configure the BGP VPNv6 function on DC-GWs and PEs.
9. Configure Layer 2 sub-interfaces on DC-GWs and L2GW/L3GWs and configure
the static VPN routes destined for VNFs on L2GW/L3GWs.
11. Configure static default VPN routes and loopback addresses on DC-GWs. The
loopback addresses are used to establish BGP VPN peer relationships with
VNFs. Configure and apply a route-policy to L3VPN instances so that DC-GWs
can advertise static default VPN routes and VPN loopback routes only through
BGP EVPN.
12. Establish BGP VPN peer relationships between DC-GWs and VNFs.
Procedure

(2020-04-09)
and L2GW/L3GWs.
Step 5 Configure EVPN instances on DC-GWs and L2GW/L3GWs and bind the EVPN
instances to BDs.
# Configure DC-GW1.
[~DCGW1] evpn vpn-instance evrf1 bd-mode
[*DCGW1-bd10] quit
[*DCGW1-bd20] quit
[*DCGW1-bd30] quit
[*DCGW1-bd40] quit
[*DCGW1] commit
Repeat this step for DC-GW2 and L2GW/L3GWs. For configuration details, see
Step 6 Configure L3VPN instances on DC-GWs and L2GW/L3GWs.
# Configure DC-GW1.
[*DCGW1-vpn-instance-vpn1-af-ipv6] evpn mpls routing-enable
[*DCGW1-Vbdif10] ipv6 enable
[*DCGW1-Vbdif10] ipv6 address 2001:db8:1::1 64
[*DCGW1-Vbdif10] ipv6 nd generate-rd-table enable
[*DCGW1-Vbdif10] ipv6 nd dad attempts 0

(2020-04-09)

[*DCGW1] commit
this section.
[*L2GW/L3GW1-vpn-instance-vpn1-af-ipv6] evpn mpls routing-enable
[*L2GW/L3GW1-Vbdif10] ipv6 enable
[*L2GW/L3GW1-Vbdif10] ipv6 address 2001:db8:1::1 64
[*L2GW/L3GW1-Vbdif10] ipv6 nd generate-rd-table enable
[*L2GW/L3GW1-Vbdif10] ipv6 nd collect host enable
[*L2GW/L3GW1-Vbdif10] ipv6 nd dad attempts 0

(2020-04-09)
# Configure PE1.
[*PE1] commit
section.
# Configure DC-GW1.
[*DCGW1-vpn-instance-vpn1-af-ipv6] tnl-policy srte
[*DCGW1] commit
this section.
Step 8 Configure the BGP EVPN function on DC-GWs and L2GW/L3GWs.
# Configure DC-GW1.

(2020-04-09)
[~DCGW1] ip ipv6-prefix uIP index 10 permit 2001:DB8:10::10 128

[*DCGW1-route-policy] if-match ipv6 address prefix-list uIP
[*DCGW1] bgp 100
[*DCGW1-bgp] quit
[*DCGW1] commit
this section.
[*L2GW/L3GW1-bgp-af-evpn] peer 2.2.2.2 advertise nd
[*L2GW/L3GW1] evpn
Step 9 Configure the BGP VPNv6 function on DC-GWs and PEs.
# Configure DC-GW1.
[~DCGW1-vpn-instance-vpn1] ipv6-family
[~DCGW1-vpn-instance-vpn1-af-ipv6] vpn-target 10:1
[~DCGW1-vpn-instance-vpn1] quit
[*DCGW1] bgp 100
[*DCGW1-bgp] ipv6-family vpnv6
[*DCGW1-bgp-af-vpnv6] quit
[*DCGW1-bgp] quit
[*DCGW1] commit
this section.
# Configure PE1.

(2020-04-09)

[*PE1] bgp 100
[*PE1-bgp] quit
[*PE1] commit
section.
Step 10 Configure Layer 2 sub-interfaces on DC-GWs and L2GW/L3GWs and configure the
static VPN routes destined for VNFs on L2GW/L3GWs.
# Configure DC-GW1.
This example binds a sub-interface of the physical interface of DC-GW1 to a BD to ensure

that the VBDIF interface is Up. In actual situations, bind service-irrelevant interfaces to BDs
to ensure network reliability.
[~DCGW1] interface GigabitEthernet1/0/2.1 mode l2

[*DCGW1] commit
this section.

(2020-04-09)
[*L2GW/L3GW1] ipv6 route-static vpn-instance vpn1 2001:DB8:5::5 128 2001:DB8:1::2 preference 255
tag 1000 inter-protocol-ecmp
and apply a route-policy to L3VPN instances so that the static VPN routes can

(2020-04-09)

[*L2GW/L3GW1-bgp-6-vpn1] import-route static
[*L2GW/L3GW1-bgp-6-vpn1] advertise l2vpn evpn import-route-multipath
[*L2GW/L3GW1-bgp-6-vpn1] quit
[*L2GW/L3GW1] route-policy sp deny node 20
[*L2GW/L3GW1-vpn-instance-vpn1-af-ipv6] export route-policy sp evpn
Step 12 Configure static default VPN routes and loopback addresses on DC-GWs. The
loopback addresses are used to establish BGP VPN peer relationships with VNFs.
Configure and apply a route-policy to L3VPN instances so that DC-GWs can
advertise static default VPN routes and VPN loopback routes only through BGP
EVPN.
# Configure DC-GW1.
[~DCGW1] ipv6 route-static vpn-instance vpn1 :: 0 NULL0 tag 2000
[*DCGW1] interface LoopBack2
[*DCGW1-LoopBack2] ipv6 enable
[*DCGW1-LoopBack2] ipv6 address 2001:db8:33::33 128
[*DCGW1] bgp 100
[*DCGW1-bgp-6-vpn1] advertise l2vpn evpn
[*DCGW1-bgp-6-vpn1] import-route direct
[*DCGW1-bgp-6-vpn1] network :: 0
[*DCGW1-bgp-6-vpn1] quit
[*DCGW1-bgp] quit
[*DCGW1] ip ipv6-prefix lp index 10 permit 2001:db8:33::33 128
[*DCGW1-route-policy] if-match tag 2000
[*DCGW1-route-policy] if-match ipv6 address prefix-list lp
[*DCGW1] commit
this section.
# Configure DC-GW1.
[*DCGW1] bgp 100

(2020-04-09)
[*DCGW1-bgp-6-vpn1] peer 2001:db8:5::5 as-number 100

[*DCGW1-bgp-6-vpn1] peer 2001:db8:5::5 connect-interface LoopBack2
[*DCGW1-bgp-6-vpn1] peer 2001:db8:5::5 route-policy p1 export
[*DCGW1-bgp] quit
[*DCGW1] commit
# Configure DC-GW2.
[*DCGW2] bgp 100
[*DCGW2-bgp] quit
[*DCGW2] commit
# Configure PE1.
[~PE1] bgp 100
[*PE1-bgp-6-vpn1] maximum load-balancing 16
[*PE1-bgp] quit
[*PE1] commit
section.
# Configure DC-GW1.
[~DCGW1] bgp 100
[*DCGW1-bgp-6-vpn1] maximum load-balancing 16
[*DCGW1-bgp] quit
[*DCGW1] commit
this section.
[*L2GW/L3GW1-bgp-6-vpn1] maximum load-balancing 16

(2020-04-09)

After completing the configurations, run the display ipv6 routing-table vpn-
VNF route information in VPN routing tables.









(2020-04-09)


RelayNextHop : ::FFFF:10.6.5.1 TunnelID : 0x000000000c00600000

RelayNextHop : ::FFFF:10.6.7.2 TunnelID : 0x000000000c00600001

----End
Configuration Files
#
sysname PE1
#
ipv6-family
tnl-policy srte
#
mpls lsr-id 7.7.7.7
#
mpls
mpls te
#
#
#
segment-routing
#
isis 1
is-level level-2
cost-style wide
network-entity 10.0000.0000.0007.00
traffic-eng level-2
#
undo shutdown
ip address 10.6.7.1 255.255.255.0
mpls
mpls te
#
undo shutdown
ip address 10.6.5.2 255.255.255.0
mpls

(2020-04-09)
mpls te
#
undo shutdown
ipv6 enable
#
interface LoopBack1
ip address 7.7.7.7 255.255.255.255
isis enable 1
#
interface Tunnel1
destination 3.3.3.3
#
interface Tunnel2
destination 4.4.4.4
#
bgp 200
#
ipv4-family unicast
network 7.7.7.7 255.255.255.255
network 10.6.5.0 255.255.255.0
network 10.6.7.0 255.255.255.0
peer 3.3.3.3 enable
peer 4.4.4.4 enable
#
#
ipv6-family vpnv6
policy vpn-target
peer 3.3.3.3 enable
peer 4.4.4.4 enable
#
import-route direct
import-route static
#
ip route-static 3.3.3.3 255.255.255.255 10.6.5.1
ip route-static 4.4.4.4 255.255.255.255 10.6.7.2
ip route-static 8.8.8.8 255.255.255.255 10.6.7.2
#
ipv6 route-static vpn-instance vpn1 :: 0 NULL0 tag 2000
#
tunnel-policy srte
#
return

(2020-04-09)

#
sysname PE2
#
ipv6-family
tnl-policy srte
#
mpls lsr-id 8.8.8.8
#
mpls
mpls te
#
#
#
segment-routing
#
isis 1
is-level level-2
cost-style wide
network-entity 10.0000.0000.0008.00
traffic-eng level-2
#
undo shutdown
ip address 10.6.7.2 255.255.255.0
mpls
mpls te
#
undo shutdown
ip address 10.6.6.2 255.255.255.0
mpls
mpls te
#
undo shutdown
ipv6 enable
#
interface LoopBack1
ip address 8.8.8.8 255.255.255.255
isis enable 1
#
interface Tunnel1
destination 3.3.3.3
#
interface Tunnel2
destination 4.4.4.4

(2020-04-09)

#
bgp 200
#
ipv4-family unicast
network 8.8.8.8 255.255.255.255
network 10.6.6.0 255.255.255.0
network 10.6.7.0 255.255.255.0
peer 3.3.3.3 enable
peer 4.4.4.4 enable
#
#
ipv6-family vpnv6
policy vpn-target
peer 3.3.3.3 enable
peer 4.4.4.4 enable
#
import-route direct
import-route static
#
ip route-static 3.3.3.3 255.255.255.255 10.6.7.1
ip route-static 4.4.4.4 255.255.255.255 10.6.6.1
ip route-static 7.7.7.7 255.255.255.255 10.6.7.1
#
#
tunnel-policy srte
#
return
#
sysname DCGW1
#
tnl-policy srte
#
tnl-policy srte
#
tnl-policy srte
#
tnl-policy srte

(2020-04-09)

#
ipv6-family
tnl-policy srte
#
mpls lsr-id 3.3.3.3
#
mpls
mpls te
#
bridge-domain 10
#
bridge-domain 20
#
bridge-domain 30
#
bridge-domain 40
#
#
#
#
#
segment-routing
#
interface Vbdif10
ipv6 enable
ipv6 nd dad attempts 0
ipv6 nd generate-rd-table enable
#
interface Vbdif20
ipv6 enable
#
interface Vbdif30
ipv6 enable

(2020-04-09)

#
interface Vbdif40
ipv6 enable
#
undo shutdown
ip address 10.6.1.1 255.255.255.0
mpls
mpls te
#
rewrite pop single
bridge-domain 20
#
rewrite pop single
bridge-domain 40
#
undo shutdown
ip address 10.6.2.1 255.255.255.0
mpls
mpls te
#
rewrite pop single
bridge-domain 10
#
rewrite pop single
bridge-domain 30
#
undo shutdown
ip address 10.6.5.1 255.255.255.0
mpls
mpls te
#
interface LoopBack1
ip address 3.3.3.3 255.255.255.255
#
interface LoopBack2
ipv6 enable
ipv6 address 2001:DB8:33::33/128
#
interface Tunnel1
destination 1.1.1.1
mpls te tunnel-id 1

(2020-04-09)
#
interface Tunnel2
destination 2.2.2.2
mpls te tunnel-id 2
#
interface Tunnel7
destination 7.7.7.7
mpls te tunnel-id 7
#
interface Tunnel8
destination 8.8.8.8
mpls te tunnel-id 8
#
bgp 100
#
ipv4-family unicast
network 10.6.1.0 255.255.255.0
network 10.6.5.0 255.255.255.0
import-route static
peer 1.1.1.1 enable
peer 2.2.2.2 enable
peer 4.4.4.4 enable
peer 7.7.7.7 enable
peer 8.8.8.8 enable
#
#
ipv6-family vpnv6
policy vpn-target
peer 7.7.7.7 enable
peer 7.7.7.7 advertise route-reoriginated evpn ipv6
peer 8.8.8.8 enable
#
network :: 0
import-route direct

(2020-04-09)
peer 2001:DB8:5::5 route-policy p1 export

#
l2vpn-family evpn
peer 1.1.1.1 enable
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.6.1.0 0.0.0.255
network 10.6.2.0 0.0.0.255
mpls-te enable
#
if-match tag 2000
#
if-match ipv6 address prefix-list lp
#
#
if-match ipv6 address prefix-list uIP
#
#
ip route-static 7.7.7.7 255.255.255.255 10.6.5.2
ip route-static 8.8.8.8 255.255.255.255 10.6.1.2
#
#
ip ipv6-prefix lp index 10 permit 2001:DB8:33::33 128
ip ipv6-prefix uIP index 10 permit 2001:DB8:10::10 128
#
tunnel-policy srte
#
return
#
sysname DCGW2
#
tnl-policy srte
#
tnl-policy srte
#

(2020-04-09)

tnl-policy srte
#
tnl-policy srte
#
ipv6-family
tnl-policy srte
#
mpls lsr-id 4.4.4.4
#
mpls
mpls te
#
bridge-domain 10
#
bridge-domain 20
#
bridge-domain 30
#
bridge-domain 40
#
#
#
#
#
segment-routing
#
interface Vbdif10
ipv6 enable
#
interface Vbdif20

(2020-04-09)
ipv6 enable
#
interface Vbdif30
ipv6 enable
#
interface Vbdif40
ipv6 enable
#
undo shutdown
ip address 10.6.1.2 255.255.255.0
mpls
mpls te
#
rewrite pop single
bridge-domain 10
#
rewrite pop single
bridge-domain 30
#
undo shutdown
ip address 10.6.3.1 255.255.255.0
mpls
mpls te
#
rewrite pop single
bridge-domain 20
#
rewrite pop single
bridge-domain 40
#
undo shutdown
ip address 10.6.6.1 255.255.255.0
mpls
mpls te
#
interface LoopBack1
ip address 4.4.4.4 255.255.255.255
#
interface LoopBack2

(2020-04-09)
ipv6 enable
ipv6 address 2001:DB8:44::44/128
#
interface Tunnel1
destination 1.1.1.1
mpls te tunnel-id 1
#
interface Tunnel2
destination 2.2.2.2
mpls te tunnel-id 2
#
interface Tunnel7
destination 7.7.7.7
mpls te tunnel-id 7
#
interface Tunnel8
destination 8.8.8.8
mpls te tunnel-id 8
#
bgp 100
#
ipv4-family unicast
network 10.6.1.0 255.255.255.0
network 10.6.5.0 255.255.255.0
import-route static
peer 1.1.1.1 enable
peer 2.2.2.2 enable
peer 3.3.3.3 enable
peer 7.7.7.7 enable
peer 8.8.8.8 enable
#
#
ipv6-family vpnv6
policy vpn-target
peer 7.7.7.7 enable

(2020-04-09)
peer 8.8.8.8 enable

#
network :: 0
import-route direct
#
l2vpn-family evpn
peer 1.1.1.1 enable
peer 2.2.2.2 enable
peer 3.3.3.3 enable
#
ospf 100
area 0.0.0.0
network 4.4.4.4 0.0.0.0
network 10.6.1.0 0.0.0.255
network 10.6.3.0 0.0.0.255
mpls-te enable
#
if-match tag 2000
#
#
#
#
#
ip route-static 7.7.7.7 255.255.255.255 10.6.1.1
ip route-static 8.8.8.8 255.255.255.255 10.6.6.2
#
#
#
tunnel-policy srte
#
return
#
sysname L2GW/L3GW1
#

(2020-04-09)
#
evpn
#
mac-duplication
#
#
#
#
#
ipv6-family
#
mpls lsr-id 1.1.1.1
#
mpls
mpls te
#
bridge-domain 10
#
bridge-domain 20
#
bridge-domain 30
#
bridge-domain 40
#
#
#
explicit-path LtoL
#
e-trunk 1
priority 5
#

(2020-04-09)
segment-routing
#
interface Vbdif10
ipv6 enable
ipv6 nd collect host enable
#
interface Vbdif20
ipv6 enable
#
interface Vbdif30
ipv6 enable
#
interface Vbdif40
ipv6 enable
#
mode lacp-static
e-trunk 1
esi 0000.1111.1111.1111.1111
#
rewrite pop single
bridge-domain 10
#
mode lacp-static
e-trunk 1
esi 0000.2222.2222.2222.2222
#
rewrite pop single
bridge-domain 20
#
mode lacp-static
e-trunk 1
esi 0000.3333.3333.3333.3333

(2020-04-09)
#
rewrite pop single
bridge-domain 30
#
mode lacp-static
e-trunk 1
esi 0000.4444.4444.4444.4444
#
rewrite pop single
bridge-domain 40
#
undo shutdown
ip address 10.6.4.1 255.255.255.0
mpls
mpls te
#
undo shutdown
ip address 10.6.2.2 255.255.255.0
mpls
mpls te
#
undo shutdown
eth-trunk 10
#
undo shutdown
eth-trunk 20
#
undo shutdown
eth-trunk 30
#
undo shutdown
eth-trunk 40
#
interface LoopBack1
ip address 1.1.1.1 255.255.255.255
#
interface Tunnel1
destination 3.3.3.3
mpls te tunnel-id 1
#
interface Tunnel2
destination 4.4.4.4
mpls te tunnel-id 2
#
interface Tunnel3
destination 2.2.2.2

(2020-04-09)

mpls te tunnel-id 3
#
bgp 100
#
ipv4-family unicast
peer 2.2.2.2 enable
peer 3.3.3.3 enable
peer 4.4.4.4 enable
#
import-route direct
import-route static
#
l2vpn-family evpn
peer 2.2.2.2 enable
peer 2.2.2.2 advertise nd
peer 3.3.3.3 enable
peer 4.4.4.4 enable
#
ospf 100
area 0.0.0.0
network 1.1.1.1 0.0.0.0
network 10.6.2.0 0.0.0.255
network 10.6.4.0 0.0.0.255
mpls-te enable
#
if-match tag 1000
apply ipv6 gateway-ip origin-nexthop
#
#
ipv6 route-static vpn-instance vpn1 2001:DB8:5::5 128 2001:DB8:1::2 preference 255 tag 1000 inter-
protocol-ecmp
protocol-ecmp
protocol-ecmp
protocol-ecmp
#
tunnel-policy srte
#
#
return

(2020-04-09)

#
sysname L2GW/L3GW2
#
#
evpn
#
mac-duplication
#
#
#
#
#
ipv6-family
#
mpls lsr-id 2.2.2.2
#
mpls
mpls te
#
bridge-domain 10
#
bridge-domain 20
#
bridge-domain 30
#
bridge-domain 40
#
#
#
explicit-path LtoL

(2020-04-09)

#
e-trunk 1
priority 5
#
segment-routing
#
interface Vbdif10
ipv6 enable
#
interface Vbdif20
ipv6 enable
#
interface Vbdif30
ipv6 enable
#
interface Vbdif40
ipv6 enable
#
mode lacp-static
e-trunk 1
esi 0000.1111.1111.1111.1111
#
rewrite pop single
bridge-domain 10
#
mode lacp-static
e-trunk 1
esi 0000.2222.2222.2222.2222
#
rewrite pop single
bridge-domain 20

(2020-04-09)
#
mode lacp-static
e-trunk 1
esi 0000.3333.3333.3333.3333
#
rewrite pop single
bridge-domain 30
#
mode lacp-static
e-trunk 1
esi 0000.4444.4444.4444.4444
#
rewrite pop single
bridge-domain 40
#
undo shutdown
ip address 10.6.4.2 255.255.255.0
mpls
mpls te
#
undo shutdown
ip address 10.6.3.2 255.255.255.0
mpls
mpls te
#
undo shutdown
eth-trunk 10
#
undo shutdown
eth-trunk 20
#
undo shutdown
eth-trunk 30
#
undo shutdown
eth-trunk 40
#
interface LoopBack1
ip address 2.2.2.2 255.255.255.255
#
interface Tunnel1
destination 3.3.3.3
mpls te tunnel-id 1
#
interface Tunnel2
destination 4.4.4.4
mpls te tunnel-id 2

(2020-04-09)

#
interface Tunnel3
destination 1.1.1.1
mpls te tunnel-id 3
#
bgp 100
#
ipv4-family unicast
peer 1.1.1.1 enable
peer 3.3.3.3 enable
peer 4.4.4.4 enable
#
import-route direct
import-route static
#
l2vpn-family evpn
peer 1.1.1.1 enable
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.6.3.0 0.0.0.255
network 10.6.4.0 0.0.0.255
mpls-te enable
#
if-match tag 1000
#
protocol-ecmp
protocol-ecmp
protocol-ecmp
protocol-ecmp
#
tunnel-policy srte

(2020-04-09)
#
#
return


Function (BGP VPNv4 over E2E SR Tunnels)
gateway function to carry service traffic over BGP VPNv4 over E2E SR tunnels.
gateway function.
Figure 3-187 shows the networking of an NFVI distributed gateway (BGP VPNv4
L3GW2 through IPUs. E2E SR tunnels are established between PEs and L2GW/
L3GWs to carry IPv4 service traffic.

function (BGP VPNv4 over E2E SR tunnels)


(2020-04-09)

LoopBack1 7.7.7.7

(2020-04-09)
LoopBack1 8.8.8.8
LoopBack2 33.33.33.33/32
LoopBack2 44.44.44.44/32

L3GW1

L3GW2

(2020-04-09)
3. Configure SR-MPLS TE tunnels between PEs and L2GW/L3GWs and between
DC-GWs and L2GW/L3GWs.
4. Configure EVPN instances on L2GW/L3GWs and bind the EVPN instances to
BDs.
5. Configure L3VPN instances on PEs, DC-GWs, and L2GW/L3GWs and bind the
L3VPN instances on L2GW/L3GWs to VBDIF interfaces.
7. Configure the BGP EVPN function on DC-GWs and L2GW/L3GWs and
configure DC-GWs as RRs.
8. Configure the BGP VPNv4 function on L2GW/L3GWs and PEs.
9. Configure the Eth-Trunk Layer 2 sub-interfaces connecting L2GW/L3GWs to
VNFs and the static VPN routes destined for VNFs.
11. On DC-GWs, configure the loopback addresses used to establish BGP VPN
peer relationships with VNFs. Configure and apply a route-policy to L3VPN
instances so that DC-GWs can only advertise VPN loopback routes and mobile
phone routes through BGP EVPN and the GWIP attribute is added to mobile
phone routes and deleted from the routes received by EVPN peers.
12. Establish BGP VPN peer relationships between DC-GWs and VNFs and
configure DC-GWs to function as RRs.
Procedure
and L2GW/L3GWs.

(2020-04-09)
Step 5 Configure EVPN instances on L2GW/L3GWs and bind the EVPN instances to BDs.
[~L2GW/L3GW1] evpn vpn-instance evrf1 bd-mode
[*L2GW/L3GW1-evpn-instance-evrf1] route-distinguisher 1:1
[*L2GW/L3GW1-evpn-instance-evrf1] vpn-target 1:1
[*L2GW/L3GW1-evpn-instance-evrf1] quit
[*L2GW/L3GW1] evpn vpn-instance evrf2 bd-mode
[*L2GW/L3GW1] bridge-domain 10
[*L2GW/L3GW1-bd10] evpn binding vpn-instance evrf1
[*L2GW/L3GW1-bd10] quit
Step 6 Configure L3VPN instances on PEs, DC-GWs, and L2GW/L3GWs and bind the
# Configure PE1.
[*PE1] commit
section.
# Configure DC-GW1.
[*DCGW1] commit

(2020-04-09)
this section.
[*L2GW/L3GW1-vpn-instance-vpn1-af-ipv4] vpn-target 10:1
# Configure PE1.
[*PE1] commit
section.
# Configure DC-GW1.

(2020-04-09)

[*DCGW1] commit
this section.
[*L2GW/L3GW1-vpn-instance-vpn1-af-ipv4] tnl-policy srte
Step 8 Configure the BGP EVPN function on DC-GWs and L2GW/L3GWs and configure
DC-GWs as RRs.
# Configure DC-GW1.
[*DCGW1] bgp 100
[*DCGW1-bgp-af-evpn] peer 1.1.1.1 reflect-client
[*DCGW1-bgp] quit
[*DCGW1] commit
this section.
[*L2GW/L3GW1-bgp-af-evpn] peer 3.3.3.3 import reoriginate
[*L2GW/L3GW1] evpn

(2020-04-09)

Step 9 Configure the BGP VPNv4 function on L2GW/L3GWs and PEs.
[*L2GW/L3GW1-bgp] peer 7.7.7.7 as-number 200
[*L2GW/L3GW1-bgp] peer 7.7.7.7 ebgp-max-hop 255
[*L2GW/L3GW1-bgp] peer 7.7.7.7 connect-interface LoopBack1
[*L2GW/L3GW1-bgp] ipv4-family vpnv4
[*L2GW/L3GW1-bgp-af-vpnv4] peer 7.7.7.7 enable
[*L2GW/L3GW1-bgp-af-vpnv4] peer 7.7.7.7 advertise route-reoriginated evpn ip
[*L2GW/L3GW1-bgp-af-vpnv4] peer 8.8.8.8 advertise route-reoriginated evpn ip
[*L2GW/L3GW1-bgp-af-vpnv4] quit
# Configure PE1.
[~PE1] bgp 200
[*PE1-bgp] quit
[*PE1] commit
section.
Step 10 Configure the Eth-Trunk Layer 2 sub-interfaces connecting L2GW/L3GWs to VNFs
and the static VPN routes destined for VNFs.

(2020-04-09)


(2020-04-09)
[*L2GW/L3GW1-bgp-vpn1] import-route direct
[*L2GW/L3GW1-vpn-instance-vpn1] export route-policy sp evpn
Step 12 On DC-GWs, configure the loopback addresses used to establish BGP VPN peer
relationships with VNFs. Configure and apply a route-policy to L3VPN instances so
that DC-GWs can only advertise VPN loopback routes and mobile phone routes (in
this example, the destination IP address of mobile phone routes destined for a
VNF is 10.10.10.10) through BGP EVPN and the GWIP attribute is added to mobile
# Configure DC-GW1.
[~DCGW1] interface LoopBack2
[*DCGW1] bgp 100
[*DCGW1-bgp] quit
[*DCGW1-route-policy] apply gateway-ip origin-nexthop
[*DCGW1] route-policy delGWIP permit node 10
[*DCGW1-route-policy] apply gateway-ip none
[*DCGW1-vpn-instance-vpn1] export route-policy dp evpn
[*DCGW1-vpn-instance-vpn1] import route-policy delGWIP evpn
[*DCGW1] commit
this section.
Step 13 Establish BGP VPN peer relationships between DC-GWs and VNFs and configure
DC-GWs to function as RRs.
# Configure DC-GW1.

(2020-04-09)
[*DCGW1] bgp 100

[*DCGW1-bgp-vpn1] peer 5.5.5.5 reflect-client
[*DCGW1-bgp] quit
[*DCGW1] commit
# Configure DC-GW2.
[*DCGW2] bgp 100
[*DCGW2-bgp] quit
[*DCGW2] commit
# Configure PE1.
[~PE1] bgp 100
[*PE1-bgp] quit
[*PE1] commit
section.
# Configure DC-GW1.
[~DCGW1] bgp 100
[*DCGW1-bgp] quit
[*DCGW1] commit
this section.

(2020-04-09)
VNF route information in VPN routing tables. The following example uses the
------------------------------------------------------------------------------
0.0.0.0/0 Static 60 0 DB 0.0.0.0 NULL0

5.5.5.5/32 EBGP 255 0 RD 1.1.1.1 Tunnel1
6.6.6.6/32 EBGP 255 0 RD 1.1.1.1 Tunnel1
10.10.10.10/32 EBGP 255 0 RD 1.1.1.1 Tunnel1
33.33.33.33/32 EBGP 255 0 RD 1.1.1.1 Tunnel1
44.44.44.44/32 EBGP 255 0 RD 1.1.1.1 Tunnel1
----End
Configuration Files
#
sysname PE1
#
ipv4-family
tnl-policy srte
#
mpls lsr-id 7.7.7.7
#
mpls
mpls te
#

(2020-04-09)
explicit-path PtoL71
#
#
explicit-path PtoP12
#
segment-routing
#
isis 1
is-level level-2
cost-style wide
network-entity 10.0000.0000.0007.00
traffic-eng level-2
#
undo shutdown
ip address 10.6.7.1 255.255.255.0
mpls
mpls te
#
undo shutdown
ip address 10.6.5.2 255.255.255.0
mpls
mpls te
#
undo shutdown
ip address 10.7.1.1 255.255.255.0
#
interface LoopBack1
ip address 7.7.7.7 255.255.255.255
isis enable 1
#
interface Tunnel1
destination 1.1.1.1
mpls te path explicit-path PtoL71
#
interface Tunnel2
destination 2.2.2.2
#
interface Tunnel3
destination 8.8.8.8
mpls te path explicit-path PtoP12
#
bgp 200

(2020-04-09)

#
ipv4-family unicast
network 7.7.7.7 255.255.255.255
network 10.6.5.0 255.255.255.0
network 10.6.7.0 255.255.255.0
import-route direct
peer 1.1.1.1 enable
peer 2.2.2.2 enable
peer 3.3.3.3 enable
peer 4.4.4.4 enable
#
#
ipv4-family vpnv4
policy vpn-target
peer 1.1.1.1 enable
peer 2.2.2.2 enable
#
import-route direct
import-route static
#
ip route-static 3.3.3.3 255.255.255.255 10.6.5.1
ip route-static 4.4.4.4 255.255.255.255 10.6.7.2
ip route-static 8.8.8.8 255.255.255.255 10.6.7.2
#
tunnel-policy srte
#
return
#
sysname PE2
#
ipv4-family
tnl-policy srte
#
mpls lsr-id 8.8.8.8
#
mpls
mpls te
#

(2020-04-09)
#
#
#
segment-routing
#
isis 1
is-level level-2
cost-style wide
network-entity 10.0000.0000.0008.00
traffic-eng level-2
#
undo shutdown
ip address 10.6.7.2 255.255.255.0
mpls
mpls te
#
undo shutdown
ip address 10.6.6.2 255.255.255.0
mpls
mpls te
#
undo shutdown
ip address 10.8.1.1 255.255.255.0
#
interface LoopBack1
ip address 8.8.8.8 255.255.255.255
isis enable 1
#
interface Tunnel1
destination 1.1.1.1
#
interface Tunnel2
destination 2.2.2.2
#
interface Tunnel3
destination 7.7.7.7
#
bgp 200

(2020-04-09)

#
ipv4-family unicast
network 8.8.8.8 255.255.255.255
network 10.6.6.0 255.255.255.0
network 10.6.7.0 255.255.255.0
import-route direct
peer 1.1.1.1 enable
peer 2.2.2.2 enable
peer 3.3.3.3 enable
peer 4.4.4.4 enable
#
#
ipv4-family vpnv4
policy vpn-target
peer 1.1.1.1 enable
peer 2.2.2.2 enable
#
import-route direct
import-route static
#
ip route-static 3.3.3.3 255.255.255.255 10.6.7.1
ip route-static 4.4.4.4 255.255.255.255 10.6.6.1
ip route-static 7.7.7.7 255.255.255.255 10.6.7.1
#
tunnel-policy srte
#
return
#
sysname DCGW1
#
ipv4-family
import route-policy delGWIP evpn
#
mpls lsr-id 3.3.3.3
#
mpls
mpls te
#
#

(2020-04-09)

#
segment-routing
#
undo shutdown
ip address 10.6.1.1 255.255.255.0
mpls
mpls te
#
undo shutdown
ip address 10.6.2.1 255.255.255.0
mpls
mpls te
#
undo shutdown
ip address 10.6.5.1 255.255.255.0
mpls
mpls 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 Tunnel1
destination 1.1.1.1
mpls te tunnel-id 1
#
interface Tunnel2
destination 2.2.2.2
mpls te tunnel-id 2
#
bgp 100
#
ipv4-family unicast
network 10.6.1.0 255.255.255.0
network 10.6.5.0 255.255.255.0
import-route static

(2020-04-09)

peer 1.1.1.1 enable
peer 2.2.2.2 enable
peer 4.4.4.4 enable
peer 7.7.7.7 enable
peer 8.8.8.8 enable
#
#
import-route direct
#
l2vpn-family evpn
peer 1.1.1.1 enable
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.6.1.0 0.0.0.255
network 10.6.2.0 0.0.0.255
mpls-te enable
#
route-policy delGWIP permit node 10
apply gateway-ip none
#
#
#
#
#
#
#
ip route-static 7.7.7.7 255.255.255.255 10.6.5.2
ip route-static 8.8.8.8 255.255.255.255 10.6.1.2
#

(2020-04-09)
tunnel-policy srte
#
#
return
#
sysname DCGW2
#
ipv4-family
#
mpls lsr-id 4.4.4.4
#
mpls
mpls te
#
#
#
segment-routing
#
undo shutdown
ip address 10.6.1.2 255.255.255.0
mpls
mpls te
#
undo shutdown
ip address 10.6.3.1 255.255.255.0
mpls
mpls te
#
undo shutdown
ip address 10.6.6.1 255.255.255.0
mpls
mpls te
#
interface LoopBack1
ip address 4.4.4.4 255.255.255.255
#
interface LoopBack2
ip address 44.44.44.44 255.255.255.255
#
interface Tunnel1
destination 1.1.1.1
mpls te tunnel-id 1

(2020-04-09)
#
interface Tunnel2
destination 2.2.2.2
mpls te tunnel-id 2
#
bgp 100
#
ipv4-family unicast
network 10.6.1.0 255.255.255.0
network 10.6.6.0 255.255.255.0
import-route static
peer 1.1.1.1 enable
peer 2.2.2.2 enable
peer 3.3.3.3 enable
peer 7.7.7.7 enable
peer 8.8.8.8 enable
#
#
import-route direct
#
l2vpn-family evpn
peer 1.1.1.1 enable
peer 2.2.2.2 enable
peer 3.3.3.3 enable
#
ospf 100

(2020-04-09)
area 0.0.0.0
network 4.4.4.4 0.0.0.0
network 10.6.1.0 0.0.0.255
network 10.6.3.0 0.0.0.255
mpls-te enable
#
#
#
#
#
#
#
#
ip route-static 7.7.7.7 255.255.255.255 10.6.1.1
ip route-static 8.8.8.8 255.255.255.255 10.6.6.2
#
tunnel-policy srte
#
#
return
#
sysname L2GW/L3GW1
#
#
evpn
#
mac-duplication
#
#
#
#

(2020-04-09)

#
ipv4-family
tnl-policy srte
#
mpls lsr-id 1.1.1.1
#
mpls
mpls te
#
bridge-domain 10
#
bridge-domain 20
#
bridge-domain 30
#
bridge-domain 40
#
#
#
explicit-path LtoP17
#
#
explicit-path LtoL
#
e-trunk 1
priority 5
#
segment-routing
#
interface Vbdif10
ip address 10.1.1.1 255.255.255.0
#
interface Vbdif20
ip address 10.2.1.1 255.255.255.0

(2020-04-09)
#
interface Vbdif30
ip address 10.3.1.1 255.255.255.0
#
interface Vbdif40
ip address 10.4.1.1 255.255.255.0
#
mode lacp-static
e-trunk 1
esi 0000.1111.1111.1111.1111
#
rewrite pop single
bridge-domain 10
#
mode lacp-static
e-trunk 1
esi 0000.2222.2222.2222.2222
#
rewrite pop single
bridge-domain 20
#
mode lacp-static
e-trunk 1
esi 0000.3333.3333.3333.3333
#
rewrite pop single
bridge-domain 30
#
mode lacp-static
e-trunk 1
esi 0000.4444.4444.4444.4444
#
rewrite pop single
bridge-domain 40
#
undo shutdown
ip address 10.6.4.1 255.255.255.0
mpls
mpls te
#

(2020-04-09)
undo shutdown
ip address 10.6.2.2 255.255.255.0
mpls
mpls te
#
undo shutdown
eth-trunk 10
#
undo shutdown
eth-trunk 20
#
undo shutdown
eth-trunk 30
#
undo shutdown
eth-trunk 40
#
interface LoopBack1
ip address 1.1.1.1 255.255.255.255
#
interface Tunnel1
destination 3.3.3.3
mpls te tunnel-id 1
#
interface Tunnel2
destination 4.4.4.4
mpls te tunnel-id 2
#
interface Tunnel3
destination 2.2.2.2
mpls te tunnel-id 3
#
interface Tunnel7
destination 7.7.7.7
mpls te path explicit-path LtoP17
#
interface Tunnel8
destination 8.8.8.8
#
bgp 100

(2020-04-09)

#
ipv4-family unicast
peer 2.2.2.2 enable
peer 3.3.3.3 enable
peer 4.4.4.4 enable
peer 7.7.7.7 enable
peer 8.8.8.8 enable
#
ipv4-family vpnv4
policy vpn-target
peer 7.7.7.7 enable
peer 8.8.8.8 enable
#
import-route direct
import-route static
#
l2vpn-family evpn
peer 3.3.3.3 enable
peer 4.4.4.4 enable
#
ospf 100
area 0.0.0.0
network 1.1.1.1 0.0.0.0
network 10.6.2.0 0.0.0.255
network 10.6.4.0 0.0.0.255
mpls-te enable
#
if-match tag 1000
#
ip route-static vpn-instance vpn1 5.5.5.5 255.255.255.255 10.1.1.2 tag 1000 inter-protocol-ecmp
#
tunnel-policy srte
#

(2020-04-09)
#
return
#
sysname L2GW/L3GW2
#
#
evpn
#
mac-duplication
#
#
#
#
#
ipv4-family
tnl-policy srte
#
mpls lsr-id 2.2.2.2
#
mpls
mpls te
#
bridge-domain 10
#
bridge-domain 20
#
bridge-domain 30
#
bridge-domain 40
#

(2020-04-09)
#
#
#
#
explicit-path LtoL
#
e-trunk 1
priority 5
#
segment-routing
#
interface Vbdif10
ip address 10.1.1.1 255.255.255.0
#
interface Vbdif20
ip address 10.2.1.1 255.255.255.0
#
interface Vbdif30
ip address 10.3.1.1 255.255.255.0
#
interface Vbdif40
ip address 10.4.1.1 255.255.255.0
#
mode lacp-static
e-trunk 1
esi 0000.1111.1111.1111.1111
#
rewrite pop single
bridge-domain 10
#
mode lacp-static
e-trunk 1
esi 0000.2222.2222.2222.2222

(2020-04-09)
#
rewrite pop single
bridge-domain 20
#
mode lacp-static
e-trunk 1
esi 0000.3333.3333.3333.3333
#
rewrite pop single
bridge-domain 30
#
mode lacp-static
e-trunk 1
esi 0000.4444.4444.4444.4444
#
rewrite pop single
bridge-domain 40
#
undo shutdown
ip address 10.6.4.2 255.255.255.0
mpls
mpls te
#
undo shutdown
ip address 10.6.3.2 255.255.255.0
mpls
mpls te
#
undo shutdown
eth-trunk 10
#
undo shutdown
eth-trunk 20
#
undo shutdown
eth-trunk 30
#
undo shutdown
eth-trunk 40
#
interface LoopBack1
ip address 2.2.2.2 255.255.255.255
#
interface Tunnel1
destination 3.3.3.3
mpls te tunnel-id 1
#

(2020-04-09)
interface Tunnel2
destination 4.4.4.4
mpls te tunnel-id 2
#
interface Tunnel3
destination 1.1.1.1
mpls te tunnel-id 3
#
interface Tunnel7
destination 7.7.7.7
#
interface Tunnel8
destination 8.8.8.8
#
bgp 100
#
ipv4-family unicast
peer 1.1.1.1 enable
peer 3.3.3.3 enable
peer 4.4.4.4 enable
peer 7.7.7.7 enable
peer 8.8.8.8 enable
#
ipv4-family vpnv4
policy vpn-target
peer 7.7.7.7 enable
peer 8.8.8.8 enable
#
import-route direct
import-route static
#
l2vpn-family evpn

(2020-04-09)

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.6.3.0 0.0.0.255
network 10.6.4.0 0.0.0.255
mpls-te enable
#
if-match tag 1000
#
protocol-ecmp
protocol-ecmp
protocol-ecmp
protocol-ecmp
#
tunnel-policy srte
#
#
return


Function (BGP VPNv6 over E2E SR Tunnels)
gateway function to carry service traffic over BGP VPNv6 over E2E SR tunnels.
gateway function.

(2020-04-09)
Figure 3-188 shows the networking of an NFVI distributed gateway (BGP VPNv6
L3GW2 through IPUs. E2E SR tunnels are established between PEs and L2GW/

function (BGP VPNv6 over E2E SR tunnels)


(2020-04-09)

GigabitEthernet 1/0/3 2001:DB8:7::1/64
LoopBack1 7.7.7.7

(2020-04-09)
GigabitEthernet 1/0/3 2001:DB8:8::1/64
LoopBack1 8.8.8.8
LoopBack2 2001:DB8:33::33/128
LoopBack2 2001:DB8:44::44/32

L3GW1

L3GW2

(2020-04-09)
BDs.
7. Configure the BGP EVPN function on DC-GWs and L2GW/L3GWs and
configure DC-GWs as RRs.
8. Configure the BGP VPNv6 function on L2GW/L3GWs and PEs.
instances so that DC-GWs can only advertise VPN loopback routes and mobile
phone routes through BGP EVPN and the GWIP attribute is added to mobile
Procedure
and L2GW/L3GWs.

(2020-04-09)
# Configure PE1.
[*PE1] commit
section.
# Configure DC-GW1.
[*DCGW1-vpn-instance-vpn1-af-ipv6] evpn mpls routing-enable
[*DCGW1] commit

(2020-04-09)
this section.
[*L2GW/L3GW1-vpn-instance-vpn1-af-ipv6] vpn-target 10:1
[*L2GW/L3GW1-vpn-instance-vpn1-af-ipv6] evpn mpls routing-enable
# Configure PE1.

(2020-04-09)
[*PE1] commit
section.
# Configure DC-GW1.
[*DCGW1] commit
this section.
[*L2GW/L3GW1-vpn-instance-vpn1-af-ipv6] tnl-policy srte
DC-GWs as RRs.
# Configure DC-GW1.
[~DCGW1] ip ipv6-prefix uIP index 10 permit 2001:DB8:10::10 128
[*DCGW1] bgp 100
[*DCGW1-bgp] quit
[*DCGW1] commit
this section.

(2020-04-09)

[*L2GW/L3GW1] evpn
Step 9 Configure the BGP VPNv6 function on L2GW/L3GWs and PEs.
[*L2GW/L3GW1-bgp] ipv6-family vpnv6
[*L2GW/L3GW1-bgp-af-vpnv6] peer 7.7.7.7 advertise route-reoriginated evpn ipv6
[*L2GW/L3GW1-bgp-af-vpnv6] peer 8.8.8.8 advertise route-reoriginated evpn ipv6
[*L2GW/L3GW1-bgp-af-vpnv6] quit
# Configure PE1.
[~PE1] bgp 200
[*PE1-bgp-6-vpn1] import-route static
[*PE1-bgp] quit
[*PE1] commit
section.

(2020-04-09)

[*L2GW/L3GW1] ipv6 route-static vpn-instance vpn1 2001:db8:5::5 128 2001:db8:1::2 preference 255

(2020-04-09)
[*L2GW/L3GW1-bgp-6-vpn1] import-route static
[*L2GW/L3GW1-bgp-6-vpn1] import-route direct
[*L2GW/L3GW1-bgp-6-vpn1] advertise l2vpn evpn import-route-multipath
[*L2GW/L3GW1-vpn-instance-vpn1-af-ipv6] export route-policy sp evpn
VNF is 2001:DB8:10::10) through BGP EVPN and the GWIP attribute is added to
mobile phone routes and deleted from the routes received by EVPN peers.
# Configure DC-GW1.
[*DCGW1-LoopBack2] ipv6 enable
[*DCGW1-LoopBack2] ipv6 address 2001:db8:33::33 128
[*DCGW1] bgp 100
[*DCGW1-bgp] quit
[*DCGW1] ip ipv6-prefix lp index 10 permit 2001:DB8:33::33 128
[*DCGW1-route-policy] apply ipv6 gateway-ip origin-nexthop
[*DCGW1-route-policy] if-match ipv6 address prefix-list lp
[*DCGW1-route-policy] apply ipv6 gateway-ip none

(2020-04-09)

[*DCGW1-vpn-instance-vpn1-af-ipv6] import route-policy delGWIP evpn
[*DCGW1] commit
this section.
# Configure DC-GW1.
[*DCGW1] bgp 100
[*DCGW1-bgp-6-vpn1] peer 2001:db8:5::5 reflect-client
[*DCGW1-bgp] quit
[*DCGW1] commit
# Configure DC-GW2.
[*DCGW2] bgp 100
[*DCGW2-bgp] quit
[*DCGW2] commit
# Configure PE1.
[~PE1] bgp 100
[*PE1-bgp-6-vpn1] maximum load-balancing 16
[*PE1-bgp] quit
[*PE1] commit
section.
# Configure DC-GW1.
[~DCGW1] bgp 100
[*DCGW1-bgp-6-vpn1] maximum load-balancing 16

(2020-04-09)

[*DCGW1-bgp] quit
[*DCGW1] commit
this section.
[*L2GW/L3GW1-bgp-6-vpn1] maximum load-balancing 16
After completing the configurations, run the display ipv6 routing-table vpn-





(2020-04-09)










----End
Configuration Files
#
sysname PE1
#
ipv6-family

(2020-04-09)
tnl-policy srte
#
mpls lsr-id 7.7.7.7
#
mpls
mpls te
#
#
#
#
segment-routing
#
isis 1
is-level level-2
cost-style wide
network-entity 10.0000.0000.0007.00
traffic-eng level-2
#
undo shutdown
ip address 10.6.7.1 255.255.255.0
mpls
mpls te
#
undo shutdown
ip address 10.6.5.2 255.255.255.0
mpls
mpls te
#
undo shutdown
ipv6 enable
#
interface LoopBack1
ip address 7.7.7.7 255.255.255.255
isis enable 1
#
interface Tunnel1
destination 1.1.1.1
#
interface Tunnel2
destination 2.2.2.2

(2020-04-09)

#
interface Tunnel3
destination 8.8.8.8
#
bgp 200
#
ipv4-family unicast
network 7.7.7.7 255.255.255.255
network 10.6.5.0 255.255.255.0
network 10.6.7.0 255.255.255.0
import-route direct
peer 1.1.1.1 enable
peer 2.2.2.2 enable
peer 3.3.3.3 enable
peer 4.4.4.4 enable
#
#
ipv6-family vpnv6
policy vpn-target
peer 1.1.1.1 enable
peer 2.2.2.2 enable
#
import-route direct
import-route static
#
ip route-static 3.3.3.3 255.255.255.255 10.6.5.1
ip route-static 4.4.4.4 255.255.255.255 10.6.7.2
ip route-static 8.8.8.8 255.255.255.255 10.6.7.2
#
#
tunnel-policy srte
#
return
#
sysname PE2
#
ipv6-family

(2020-04-09)
tnl-policy srte
#
mpls lsr-id 8.8.8.8
#
mpls
mpls te
#
#
#
#
segment-routing
#
isis 1
is-level level-2
cost-style wide
network-entity 10.0000.0000.0008.00
traffic-eng level-2
#
undo shutdown
ip address 10.6.7.2 255.255.255.0
mpls
mpls te
#
undo shutdown
ip address 10.6.6.2 255.255.255.0
mpls
mpls te
#
undo shutdown
ipv6 enable
#
interface LoopBack1
ip address 8.8.8.8 255.255.255.255
isis enable 1
#
interface Tunnel1
destination 1.1.1.1
#
interface Tunnel2
destination 2.2.2.2

(2020-04-09)
#
interface Tunnel3
destination 7.7.7.7
#
bgp 200
#
ipv4-family unicast
network 8.8.8.8 255.255.255.255
network 10.6.6.0 255.255.255.0
network 10.6.7.0 255.255.255.0
import-route direct
peer 1.1.1.1 enable
peer 2.2.2.2 enable
peer 3.3.3.3 enable
peer 4.4.4.4 enable
#
#
ipv6-family vpnv6
policy vpn-target
peer 1.1.1.1 enable
peer 2.2.2.2 enable
#
import-route direct
import-route static
#
ip route-static 3.3.3.3 255.255.255.255 10.6.7.1
ip route-static 4.4.4.4 255.255.255.255 10.6.6.1
ip route-static 7.7.7.7 255.255.255.255 10.6.7.1
#
#
tunnel-policy srte
#
return
#
sysname DCGW1
#
ipv6-family

(2020-04-09)

#
mpls lsr-id 3.3.3.3
#
mpls
mpls te
#
#
#
segment-routing
#
undo shutdown
ip address 10.6.1.1 255.255.255.0
mpls
mpls te
#
undo shutdown
ip address 10.6.2.1 255.255.255.0
mpls
mpls te
#
undo shutdown
ip address 10.6.5.1 255.255.255.0
mpls
mpls te
#
interface LoopBack1
ip address 3.3.3.3 255.255.255.255
#
interface LoopBack2
ipv6 enable
ipv6 address 2001:DB8:33::33/128
#
interface Tunnel1
destination 1.1.1.1
mpls te tunnel-id 1
#
interface Tunnel2
destination 2.2.2.2
mpls te tunnel-id 2
#
bgp 100

(2020-04-09)

#
ipv4-family unicast
network 10.6.1.0 255.255.255.0
network 10.6.5.0 255.255.255.0
import-route static
peer 1.1.1.1 enable
peer 2.2.2.2 enable
peer 4.4.4.4 enable
peer 7.7.7.7 enable
peer 8.8.8.8 enable
#
#
import-route direct
peer 2001:DB8:5::5 reflect-client
#
l2vpn-family evpn
peer 1.1.1.1 enable
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.6.1.0 0.0.0.255
network 10.6.2.0 0.0.0.255
mpls-te enable
#
apply ipv6 gateway-ip none
#

(2020-04-09)
#
#
#
#
#
ip route-static 7.7.7.7 255.255.255.255 10.6.5.2
ip route-static 8.8.8.8 255.255.255.255 10.6.1.2
#
#
tunnel-policy srte
#
#
return
#
sysname DCGW2
#
ipv6-family
#
mpls lsr-id 4.4.4.4
#
mpls
mpls te
#
#
#
segment-routing
#
undo shutdown
ip address 10.6.1.2 255.255.255.0
mpls
mpls te
#
undo shutdown
ip address 10.6.3.1 255.255.255.0
mpls
mpls te
#
undo shutdown
ip address 10.6.6.1 255.255.255.0
mpls
mpls te

(2020-04-09)
#
interface LoopBack1
ip address 4.4.4.4 255.255.255.255
#
interface LoopBack2
ipv6 enable
ipv6 address 2001:DB8:44::44/128
#
interface Tunnel1
destination 1.1.1.1
mpls te tunnel-id 1
#
interface Tunnel2
destination 2.2.2.2
mpls te tunnel-id 2
#
bgp 100
#
ipv4-family unicast
network 10.6.1.0 255.255.255.0
network 10.6.6.0 255.255.255.0
import-route static
peer 1.1.1.1 enable
peer 2.2.2.2 enable
peer 3.3.3.3 enable
peer 7.7.7.7 enable
peer 8.8.8.8 enable
#
#
import-route direct

(2020-04-09)

#
l2vpn-family evpn
peer 1.1.1.1 enable
peer 2.2.2.2 enable
peer 3.3.3.3 enable
#
ospf 100
area 0.0.0.0
network 4.4.4.4 0.0.0.0
network 10.6.1.0 0.0.0.255
network 10.6.3.0 0.0.0.255
mpls-te enable
#
apply ipv6 gateway-ip none
#
#
#
#
#
#
ip route-static 7.7.7.7 255.255.255.255 10.6.1.1
ip route-static 8.8.8.8 255.255.255.255 10.6.6.2
#
#
tunnel-policy srte
#
#
return
#
sysname L2GW/L3GW1
#
#
evpn
#
mac-duplication
#

(2020-04-09)

#
#
#
#
ipv6-family
tnl-policy srte
#
mpls lsr-id 1.1.1.1
#
mpls
mpls te
#
bridge-domain 10
#
bridge-domain 20
#
bridge-domain 30
#
bridge-domain 40
#
#
#
#
#
explicit-path LtoL
#
e-trunk 1

(2020-04-09)
priority 5
#
segment-routing
#
interface Vbdif10
ipv6 enable
#
interface Vbdif20
ipv6 enable
#
interface Vbdif30
ipv6 enable
#
interface Vbdif40
ipv6 enable
#
mode lacp-static
e-trunk 1
esi 0000.1111.1111.1111.1111
#
rewrite pop single
bridge-domain 10
#
mode lacp-static
e-trunk 1
esi 0000.2222.2222.2222.2222
#
rewrite pop single
bridge-domain 20
#
mode lacp-static

(2020-04-09)
e-trunk 1
esi 0000.3333.3333.3333.3333
#
rewrite pop single
bridge-domain 30
#
mode lacp-static
e-trunk 1
esi 0000.4444.4444.4444.4444
#
rewrite pop single
bridge-domain 40
#
undo shutdown
ip address 10.6.4.1 255.255.255.0
mpls
mpls te
#
undo shutdown
ip address 10.6.2.2 255.255.255.0
mpls
mpls te
#
undo shutdown
eth-trunk 10
#
undo shutdown
eth-trunk 20
#
undo shutdown
eth-trunk 30
#
undo shutdown
eth-trunk 40
#
interface LoopBack1
ip address 1.1.1.1 255.255.255.255
#
interface Tunnel1
destination 3.3.3.3
mpls te tunnel-id 1
#
interface Tunnel2
destination 4.4.4.4
mpls te tunnel-id 2

(2020-04-09)
#
interface Tunnel3
destination 2.2.2.2
mpls te tunnel-id 3
#
interface Tunnel7
destination 7.7.7.7
#
interface Tunnel8
destination 8.8.8.8
#
bgp 100
#
ipv4-family unicast
peer 2.2.2.2 enable
peer 3.3.3.3 enable
peer 4.4.4.4 enable
peer 7.7.7.7 enable
peer 8.8.8.8 enable
#
ipv6-family vpnv6
policy vpn-target
peer 7.7.7.7 enable
peer 8.8.8.8 enable
#
import-route direct
import-route static
#
l2vpn-family evpn
peer 3.3.3.3 enable
peer 4.4.4.4 enable

(2020-04-09)

#
ospf 100
area 0.0.0.0
network 1.1.1.1 0.0.0.0
network 10.6.2.0 0.0.0.255
network 10.6.4.0 0.0.0.255
mpls-te enable
#
if-match tag 1000
#
protocol-ecmp
protocol-ecmp
protocol-ecmp
protocol-ecmp
#
tunnel-policy srte
#
#
return
#
sysname L2GW/L3GW2
#
#
evpn
#
mac-duplication
#
#
#
#
#
ipv6-family

(2020-04-09)
tnl-policy srte
#
mpls lsr-id 2.2.2.2
#
mpls
mpls te
#
bridge-domain 10
#
bridge-domain 20
#
bridge-domain 30
#
bridge-domain 40
#
#
#
#
#
explicit-path LtoL
#
e-trunk 1
priority 5
#
segment-routing
#
interface Vbdif10
ipv6 enable
#
interface Vbdif20
ipv6 enable

(2020-04-09)
#
interface Vbdif30
ipv6 enable
#
interface Vbdif40
ipv6 enable
#
mode lacp-static
e-trunk 1
esi 0000.1111.1111.1111.1111
#
rewrite pop single
bridge-domain 10
#
mode lacp-static
e-trunk 1
esi 0000.2222.2222.2222.2222
#
rewrite pop single
bridge-domain 20
#
mode lacp-static
e-trunk 1
esi 0000.3333.3333.3333.3333
#
rewrite pop single
bridge-domain 30
#
mode lacp-static
e-trunk 1
esi 0000.4444.4444.4444.4444
#
rewrite pop single
bridge-domain 40
#
undo shutdown
ip address 10.6.4.2 255.255.255.0

(2020-04-09)
mpls
mpls te
#
undo shutdown
ip address 10.6.3.2 255.255.255.0
mpls
mpls te
#
undo shutdown
eth-trunk 10
#
undo shutdown
eth-trunk 20
#
undo shutdown
eth-trunk 30
#
undo shutdown
eth-trunk 40
#
interface LoopBack1
ip address 2.2.2.2 255.255.255.255
#
interface Tunnel1
destination 3.3.3.3
mpls te tunnel-id 1
#
interface Tunnel2
destination 4.4.4.4
mpls te tunnel-id 2
#
interface Tunnel3
destination 1.1.1.1
mpls te tunnel-id 3
#
interface Tunnel7
destination 7.7.7.7
#
interface Tunnel8
destination 8.8.8.8

(2020-04-09)

#
bgp 100
#
ipv4-family unicast
peer 1.1.1.1 enable
peer 3.3.3.3 enable
peer 4.4.4.4 enable
peer 7.7.7.7 enable
peer 8.8.8.8 enable
#
ipv6-family vpnv6
policy vpn-target
peer 7.7.7.7 enable
peer 8.8.8.8 enable
#
import-route direct
import-route static
#
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.6.3.0 0.0.0.255
network 10.6.4.0 0.0.0.255
mpls-te enable
#
if-match tag 1000
#
protocol-ecmp
protocol-ecmp
protocol-ecmp

(2020-04-09)
protocol-ecmp
#
tunnel-policy srte
#
#
return


Function (BGP EVPN over E2E SR Tunnels)
gateway function to carry service traffic over BGP EVPN over E2E SR tunnels.
gateway function.
L3GW2 through IPUs. BGP EVPN peer relationships are established between PEs
and L2GW/L3GWs and between DC-GWs and L2GW/L3GWs, and DC-GWs are
deployed as EVPN RRs. E2E SR tunnels are established between PEs and L2GW/

function (BGP EVPN over E2E SR tunnels)


(2020-04-09)

LoopBack1 7.7.7.7

(2020-04-09)
LoopBack1 8.8.8.8
LoopBack2 33.33.33.33/32
LoopBack2 44.44.44.44/32

L3GW1

L3GW2

(2020-04-09)
BDs.
7. Configure the BGP EVPN function on PEs, DC-GWs and L2GW/L3GWs and
configure L2GW/L3GWs as RRs.
10. Configure and apply a route-policy to L3VPN instances on PEs so that PEs can
delete the GWIP attribute carried in the VNF routes received by EVPN peers.
instances so that DC-GWs can only advertise VPN loopback routes through
BGP EVPN and delete the GWIP attribute from the routes received from EVPN
peers.
Procedure
and L2GW/L3GWs.

(2020-04-09)

# Configure PE1.
[*PE1] commit
section.
# Configure DC-GW1.

(2020-04-09)
[*DCGW1] commit
this section.
# Configure PE1.
[*PE1] commit
section.

(2020-04-09)
# Configure DC-GW1.
[*DCGW1] commit
this section.
DC-GWs as RRs.
# Configure PE1.
[~PE1] ip route-static vpn-instance vpn1 0.0.0.0 0.0.0.0 NULL0 tag 2000
[*PE1] bgp 200
[*PE1-bgp-vpn1] import-route static
[*PE1-bgp] quit
[*PE1] commit
section.
# Configure DC-GW1.
[*DCGW1] bgp 100

(2020-04-09)

[*DCGW1-bgp] quit
[*DCGW1] commit
this section.
[*L2GW/L3GW1-bgp-af-evpn] peer 3.3.3.3 reflect-client
[*L2GW/L3GW1-bgp-af-evpn] peer 4.4.4.4 reflect-client
[*L2GW/L3GW1] evpn

(2020-04-09)

[*L2GW/L3GW1-bgp-vpn1] import-route direct

(2020-04-09)
[*L2GW/L3GW1-vpn-instance-vpn1] export route-policy sp evpn
Step 11 Configure and apply a route-policy to L3VPN instances on PEs so that PEs can
delete the GWIP attribute carried in the VNF routes received by EVPN peers.
# Configure PE1.
[~PE1] route-policy delGWIP permit node 10
[*PE1-route-policy] apply gateway-ip none
[*PE1-vpn-instance-vpn1] import route-policy delGWIP evpn
[*PE1] commit
section.
VNF is 10.10.10.10) through BGP EVPN and the GWIP attribute is added to mobile
# Configure DC-GW1.
[*DCGW1] bgp 100
[*DCGW1-bgp] quit
[*DCGW1-route-policy] apply gateway-ip origin-nexthop
[*DCGW1-route-policy] apply gateway-ip none
[*DCGW1-vpn-instance-vpn1] export route-policy dp evpn
[*DCGW1-vpn-instance-vpn1] import route-policy delGWIP evpn
[*DCGW1] commit
this section.

(2020-04-09)
# Configure DC-GW1.
[*DCGW1] bgp 100
[*DCGW1-bgp] quit
[*DCGW1] commit
# Configure DC-GW2.
[*DCGW2] bgp 100
[*DCGW2-bgp] quit
[*DCGW2] commit
# Configure PE1.
[~PE1] bgp 100
[*PE1-bgp-af-evpn] peer 1.1.1.1 capability-advertise add-path both
[*PE1-bgp-af-evpn] peer 2.2.2.2 capability-advertise add-path both
[*PE1-bgp] quit
[*PE1] commit
section.
# Configure DC-GW1.
[~DCGW1] bgp 100
[*DCGW1-bgp] quit
[*DCGW1] commit

(2020-04-09)
this section.
------------------------------------------------------------------------------
0.0.0.0/0 Static 60 0 DB 0.0.0.0 NULL0

5.5.5.5/32 EBGP 255 0 RD 1.1.1.1 Tunnel1
6.6.6.6/32 EBGP 255 0 RD 1.1.1.1 Tunnel1
10.10.10.10/32 EBGP 255 0 RD 1.1.1.1 Tunnel1
33.33.33.33/32 EBGP 255 0 RD 1.1.1.1 Tunnel1
44.44.44.44/32 EBGP 255 0 RD 1.1.1.1 Tunnel1
----End
Configuration Files
#
sysname PE1
#

(2020-04-09)
ipv4-family
#
mpls lsr-id 7.7.7.7
#
mpls
mpls te
#
#
#
#
segment-routing
#
isis 1
is-level level-2
cost-style wide
network-entity 10.0000.0000.0007.00
traffic-eng level-2
#
undo shutdown
ip address 10.6.7.1 255.255.255.0
isis enable 1
mpls
mpls te
#
undo shutdown
ip address 10.6.5.2 255.255.255.0
mpls
mpls te
#
undo shutdown
ip address 10.7.1.1 255.255.255.0
#
interface LoopBack1
ip address 7.7.7.7 255.255.255.255
isis enable 1
#
interface Tunnel1
destination 1.1.1.1
#
interface Tunnel2

(2020-04-09)
destination 2.2.2.2
#
interface Tunnel3
destination 8.8.8.8
#
bgp 200
#
ipv4-family unicast
network 7.7.7.7 255.255.255.255
network 10.6.5.0 255.255.255.0
network 10.6.7.0 255.255.255.0
import-route direct
peer 1.1.1.1 enable
peer 2.2.2.2 enable
peer 3.3.3.3 enable
peer 4.4.4.4 enable
#
#
import-route direct
import-route static
#
l2vpn-family evpn
peer 1.1.1.1 enable
peer 2.2.2.2 enable
#
#
ip route-static 3.3.3.3 255.255.255.255 10.6.5.1
ip route-static 4.4.4.4 255.255.255.255 10.6.7.2
ip route-static 8.8.8.8 255.255.255.255 10.6.7.2
#
tunnel-policy srte
#
return

(2020-04-09)

#
sysname PE2
#
ipv4-family
#
mpls lsr-id 8.8.8.8
#
mpls
mpls te
#
#
#
#
segment-routing
#
isis 1
is-level level-2
cost-style wide
network-entity 10.0000.0000.0008.00
traffic-eng level-2
#
undo shutdown
ip address 10.6.7.2 255.255.255.0
isis enable 1
mpls
mpls te
#
undo shutdown
ip address 10.6.6.2 255.255.255.0
mpls
mpls te
#
undo shutdown
ip address 10.8.1.1 255.255.255.0
#
interface LoopBack1
ip address 8.8.8.8 255.255.255.255
isis enable 1
#
interface Tunnel1
destination 1.1.1.1

(2020-04-09)

#
interface Tunnel2
destination 2.2.2.2
#
interface Tunnel3
destination 7.7.7.7
#
bgp 200
#
ipv4-family unicast
network 8.8.8.8 255.255.255.255
network 10.6.6.0 255.255.255.0
network 10.6.7.0 255.255.255.0
import-route direct
peer 1.1.1.1 enable
peer 2.2.2.2 enable
peer 3.3.3.3 enable
peer 4.4.4.4 enable
#
#
import-route direct
import-route static
#
l2vpn-family evpn
peer 1.1.1.1 enable
peer 2.2.2.2 enable
#
#
ip route-static 3.3.3.3 255.255.255.255 10.6.7.1
ip route-static 4.4.4.4 255.255.255.255 10.6.6.1
ip route-static 7.7.7.7 255.255.255.255 10.6.7.1
#

(2020-04-09)
tunnel-policy srte
#
return
#
sysname DCGW1
#
ipv4-family
#
mpls lsr-id 3.3.3.3
#
mpls
mpls te
#
#
#
segment-routing
#
undo shutdown
ip address 10.6.1.1 255.255.255.0
mpls
mpls te
#
undo shutdown
ip address 10.6.2.1 255.255.255.0
mpls
mpls te
#
undo shutdown
ip address 10.6.5.1 255.255.255.0
mpls
mpls 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 Tunnel1
destination 1.1.1.1
mpls te tunnel-id 1
#
interface Tunnel2

(2020-04-09)

destination 2.2.2.2
mpls te tunnel-id 2
#
bgp 100
#
ipv4-family unicast
network 10.6.1.0 255.255.255.0
network 10.6.5.0 255.255.255.0
import-route static
peer 1.1.1.1 enable
peer 2.2.2.2 enable
peer 4.4.4.4 enable
peer 7.7.7.7 enable
peer 8.8.8.8 enable
#
#
import-route direct
#
l2vpn-family evpn
peer 1.1.1.1 enable
peer 2.2.2.2 enable
peer 4.4.4.4 enable
#
ospf 100

(2020-04-09)
area 0.0.0.0
network 3.3.3.3 0.0.0.0
network 10.6.1.0 0.0.0.255
network 10.6.2.0 0.0.0.255
mpls-te enable
#
#
#
#
#
#
#
#
ip route-static 7.7.7.7 255.255.255.255 10.6.5.2
ip route-static 8.8.8.8 255.255.255.255 10.6.1.2
#
tunnel-policy srte
#
#
return
#
sysname DCGW2
#
ipv4-family
#
mpls lsr-id 4.4.4.4
#
mpls
mpls te
#
#
#
segment-routing
#
undo shutdown
ip address 10.6.1.2 255.255.255.0
mpls
mpls te

(2020-04-09)
#
undo shutdown
ip address 10.6.3.1 255.255.255.0
mpls
mpls te
#
undo shutdown
ip address 10.6.6.1 255.255.255.0
mpls
mpls te
#
interface LoopBack1
ip address 4.4.4.4 255.255.255.255
#
interface LoopBack2
ip address 44.44.44.44 255.255.255.255
#
interface Tunnel1
destination 1.1.1.1
mpls te tunnel-id 1
#
interface Tunnel2
destination 2.2.2.2
mpls te tunnel-id 2
#
bgp 100
#
ipv4-family unicast
network 10.6.1.0 255.255.255.0
network 10.6.6.0 255.255.255.0
import-route static
peer 1.1.1.1 enable
peer 2.2.2.2 enable
peer 3.3.3.3 enable
peer 7.7.7.7 enable
peer 8.8.8.8 enable
#
#

(2020-04-09)

import-route direct
#
l2vpn-family evpn
peer 1.1.1.1 enable
peer 2.2.2.2 enable
peer 3.3.3.3 enable
#
ospf 100
area 0.0.0.0
network 4.4.4.4 0.0.0.0
network 10.6.1.0 0.0.0.255
network 10.6.3.0 0.0.0.255
mpls-te enable
#
#
#
#
#
#
#
#
ip route-static 7.7.7.7 255.255.255.255 10.6.1.1
ip route-static 8.8.8.8 255.255.255.255 10.6.6.2
#
tunnel-policy srte
#
#
return
#
sysname L2GW/L3GW1

(2020-04-09)
#
#
evpn
#
mac-duplication
#
#
#
#
#
ipv4-family
#
mpls lsr-id 1.1.1.1
#
mpls
mpls te
#
bridge-domain 10
#
bridge-domain 20
#
bridge-domain 30
#
bridge-domain 40
#
#
#
#

(2020-04-09)
#
explicit-path LtoL
#
e-trunk 1
priority 5
#
segment-routing
#
interface Vbdif10
ip address 10.1.1.1 255.255.255.0
#
interface Vbdif20
ip address 10.2.1.1 255.255.255.0
#
interface Vbdif30
ip address 10.3.1.1 255.255.255.0
#
interface Vbdif40
ip address 10.4.1.1 255.255.255.0
#
mode lacp-static
e-trunk 1
esi 0000.1111.1111.1111.1111
#
rewrite pop single
bridge-domain 10
#
mode lacp-static
e-trunk 1
esi 0000.2222.2222.2222.2222
#
rewrite pop single
bridge-domain 20
#
mode lacp-static

(2020-04-09)
e-trunk 1
esi 0000.3333.3333.3333.3333
#
rewrite pop single
bridge-domain 30
#
mode lacp-static
e-trunk 1
esi 0000.4444.4444.4444.4444
#
rewrite pop single
bridge-domain 40
#
undo shutdown
ip address 10.6.4.1 255.255.255.0
mpls
mpls te
#
undo shutdown
ip address 10.6.2.2 255.255.255.0
mpls
mpls te
#
undo shutdown
eth-trunk 10
#
undo shutdown
eth-trunk 20
#
undo shutdown
eth-trunk 30
#
undo shutdown
eth-trunk 40
#
interface LoopBack1
ip address 1.1.1.1 255.255.255.255
#
interface Tunnel1
destination 3.3.3.3
mpls te tunnel-id 1
#
interface Tunnel2
destination 4.4.4.4
mpls te tunnel-id 2

(2020-04-09)
#
interface Tunnel3
destination 2.2.2.2
mpls te tunnel-id 3
#
interface Tunnel7
destination 7.7.7.7
#
interface Tunnel8
destination 8.8.8.8
#
bgp 100
#
ipv4-family unicast
peer 2.2.2.2 enable
peer 3.3.3.3 enable
peer 4.4.4.4 enable
peer 7.7.7.7 enable
peer 8.8.8.8 enable
#
import-route direct
import-route static
#
l2vpn-family evpn
peer 3.3.3.3 enable
peer 4.4.4.4 enable
peer 7.7.7.7 enable
peer 8.8.8.8 enable

(2020-04-09)

#
ospf 100
area 0.0.0.0
network 1.1.1.1 0.0.0.0
network 10.6.2.0 0.0.0.255
network 10.6.4.0 0.0.0.255
mpls-te enable
#
if-match tag 1000
#
protocol-ecmp
protocol-ecmp
protocol-ecmp
protocol-ecmp
#
tunnel-policy srte
#
#
return
#
sysname L2GW/L3GW2
#
#
evpn
#
mac-duplication
#
#
#
#
#
ipv4-family

(2020-04-09)

#
mpls lsr-id 2.2.2.2
#
mpls
mpls te
#
bridge-domain 10
#
bridge-domain 20
#
bridge-domain 30
#
bridge-domain 40
#
#
#
#
#
explicit-path LtoL
#
e-trunk 1
priority 5
#
segment-routing
#
interface Vbdif10

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 05 Copyright © Huawei Technologies Co., Ltd. i

1 Segment Routing MPLS......................................................................................................... 1

Issue draft 05 Copyright © Huawei Technologies Co., Ltd. ii

1.1.2.12 SR Microloop Avoidance........................................................................................................................................... 85

Issue draft 05 Copyright © Huawei Technologies Co., Ltd. iii

1.2.6.2 Globally Enabling the Segment Routing Capability........................................................................................ 146

Issue draft 05 Copyright © Huawei Technologies Co., Ltd. iv

1.2.12.2 Configuring an E2E SR-MPLS TE Tunnel Interface........................................................................................ 182

Issue draft 05 Copyright © Huawei Technologies Co., Ltd. v

1.2.38 Redirecting a Public IPv4 BGP FlowSpec Route to an SR-MPLS TE Policy................................................266

2 Segment Routing IPv6....................................................................................................... 590

Issue draft 05 Copyright © Huawei Technologies Co., Ltd. vi

2.1.1 Overview of Segment Routing IPv6..........................................................................................................................590

Issue draft 05 Copyright © Huawei Technologies Co., Ltd. vii

2.2.10 Configuring an SRv6 TE Policy (Dynamic Delivery by a Controller)...........................................................697

Issue draft 05 Copyright © Huawei Technologies Co., Ltd. viii

Issue draft 05 Copyright © Huawei Technologies Co., Ltd. ix

3.2.4.5 Configuring a BGP EVPN Peer Relationship.....................................................................................................1112

Issue draft 05 Copyright © Huawei Technologies Co., Ltd. x

3.2.17 Configuring EVPN ORF............................................................................................................................................. 1178

Issue draft 05 Copyright © Huawei Technologies Co., Ltd. xi

Issue draft 05 Copyright © Huawei Technologies Co., Ltd. xii

3.2.35.13 Example for Configuring Inter-AS EVPN Option C................................................................................... 1429

Issue draft 05 Copyright © Huawei Technologies Co., Ltd. xiii

4.1.2.1 VXLAN Basic Concepts............................................................................................................................................. 1862

Issue draft 05 Copyright © Huawei Technologies Co., Ltd. xiv

4.2.7 Configuring Three-Segment VXLAN to Implement DCI.................................................................................. 1998

5 Multicast VPN.................................................................................................................... 2200

Issue draft 05 Copyright © Huawei Technologies Co., Ltd. xv

5.1.2.1 Concepts Related to Rosen MVPN...................................................................................................................... 2200

Issue draft 05 Copyright © Huawei Technologies Co., Ltd. xvi

5.3.2.4 Application Scenarios for BIER..............................................................................................................................2315

Issue draft 05 Copyright © Huawei Technologies Co., Ltd. xvii

5.5.4.2 Establishing BGP MVPN Peer Relationships.................................................................................................... 2434

Issue draft 05 Copyright © Huawei Technologies Co., Ltd. xviii

Issue draft 05 Copyright © Huawei Technologies Co., Ltd. xix

Issue draft 05 Copyright © Huawei Technologies Co., Ltd. xx

6.2.3.2 Configuring the Data to Be Sampled or a Customized Event................................................................... 2853

Issue draft 05 Copyright © Huawei Technologies Co., Ltd. xxi

1 Segment Routing MPLS

1.1 Segment Routing MPLS

1.1.1 Introduction of Segment Routing MPLS

Issue draft 05 Copyright © Huawei Technologies Co., Ltd. 1

network topology, bandwidth usage, and delay information and computes an

Figure 1-1 Service-driven network

Segment Routing emerges in this context. Segment Routing is used to simply

Issue draft 05 Copyright © Huawei Technologies Co., Ltd. 2

● Provides higher network capacity expansion capabilities.

1.1.2 Understanding Segment Routing MPLS

1.1.2.1 Segment Routing MPLS Fundamentals

Issue draft 05 Copyright © Huawei Technologies Co., Ltd. 3

Table 1-1 Segment category

Prefix Manually Identifies the prefix of a destination address.

Adjacency Allocated by Identifies an adjacency on a network.

Node Manually The node segment, a special prefix segment,

Figure 1-2 Prefix SID, Adjacency SID and Node SID

In simple words, a prefix segment indicates a destination address, and an

Issue draft 05 Copyright © Huawei Technologies Co., Ltd. 4

adjacency segments are similar to the destination IP address and outbound