New IP Technologies

New IP Technologies
Issue draft 04
Date 2019-05-20
HUAWEI TECHNOLOGIES CO., LTD.

Copyright © Huawei Technologies Co., Ltd. 2019. 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: http://www.huawei.com
Email: [email protected]
Issue draft 04 (2019-05-20) Copyright © Huawei Technologies Co., Ltd. i

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 LSP..................................................................................................................................................................... 7
1.1.2.2.1 SR and LDP Communication.............................................................................................................................. 11
1.1.2.3 IS-IS for SR............................................................................................................................................................ 13
1.1.2.4 OSPF for SR........................................................................................................................................................... 23
1.1.2.5 SR-TE..................................................................................................................................................................... 31
1.1.2.5.1 Topology Collection and Label Allocation..........................................................................................................32
1.1.2.5.2 SR-TE Tunnel Establishment.............................................................................................................................. 33
1.1.2.5.3 SR-TE Data Forwarding...................................................................................................................................... 36
1.1.2.5.4 SR-TE Tunnel Reliability.................................................................................................................................... 38
1.1.2.5.5 BFD for SR-TE....................................................................................................................................................39
1.1.2.5.6 DSCP-based Tunneling for IP Packets to Enter SR-TE Tunnels........................................................................ 41
1.1.2.6 BGP for SR............................................................................................................................................................. 43
1.1.2.7 Inter-AS E2E SR-TE.............................................................................................................................................. 47
1.1.2.7.1 Binding SID......................................................................................................................................................... 47
1.1.2.7.2 E2E SR-TE Tunnel Creation............................................................................................................................... 48
1.1.2.7.3 Data Forwarding on an E2E SR-TE Tunnel........................................................................................................ 50
1.1.2.7.4 Reliability of E2E SR-TE Tunnels...................................................................................................................... 52
1.1.2.7.5 One-Arm BFD for E2E SR-TE........................................................................................................................... 53
1.1.2.7.6 Cross-Multi-AS E2E SR-TE............................................................................................................................... 56
1.1.2.8 Importing Traffic.................................................................................................................................................... 57
1.1.2.8.1 Public IP Routes Recursive to an SR Tunnel...................................................................................................... 59
1.1.2.8.2 L3VPN Recursive to an SR Tunnel.....................................................................................................................62
1.1.2.8.3 L2VPN Recursive to an SR Tunnel.....................................................................................................................66
1.1.2.8.4 EVPN Iterated to an SR Tunnel...........................................................................................................................68
1.1.2.9 SBFD for SR...........................................................................................................................................................69
1.1.2.10 TI-LFA FRR......................................................................................................................................................... 73
1.1.2.10.1 Anycast FRR......................................................................................................................................................81
1.1.2.11 SR OAM............................................................................................................................................................... 82
Issue draft 04 (2019-05-20) Copyright © Huawei Technologies Co., Ltd. ii

1.1.3 Application Scenarios for Segment Routing MPLS..................................................................................................85

1.1.3.1 Single-AS SR..........................................................................................................................................................85
1.1.3.2 Inter-AS E2E SR-TE.............................................................................................................................................. 87
1.1.4 Terminology for Segment Routing MPLS.................................................................................................................89
1.2 Segment Routing MPLS Configuration....................................................................................................................... 89
1.2.1 Overview of Segment Routing MPLS.......................................................................................................................89
1.2.2 Licensing Requirements and Limitations for Segment Routing MPLS.................................................................... 90
1.2.3 Configuring an IS-IS SR-BE Tunnel......................................................................................................................... 93
1.2.3.1 Configuring Basic SR-BE Functions......................................................................................................................93
1.2.3.2 (Optional) Configuring a Policy for Triggering SR-LSP Establishment................................................................95
1.2.3.3 (Optional) Configuring a Policy for Preferentially Selecting an SR-BE Tunnel................................................... 95
1.2.3.4 Verifying the IS-IS SR-BE Tunnel Configuration..................................................................................................96
1.2.4 Configuring an OSPF SR-BE Tunnel........................................................................................................................96
1.2.4.1 Configuring Basic SR-BE Functions......................................................................................................................97
1.2.4.2 (Optional) Configuring a Policy for Triggering SR-LSP Establishment................................................................98
1.2.4.3 Configuring a Policy for Preferentially Selecting an SR-BE Tunnel..................................................................... 98
1.2.4.4 Verifying the OSPF SR-BE Tunnel Configuration.................................................................................................99
1.2.5 Configuring an IS-IS SR-TE Tunnel (Path Computation on the Controller)............................................................ 99
1.2.5.1 Enabling MPLS TE.............................................................................................................................................. 100
1.2.5.2 Globally Enabling the Segment Routing Capability............................................................................................ 100
1.2.5.3 Configuring the IS-IS SR-TE Capability and Topology Report Function........................................................... 101
1.2.5.4 Configuring an SR-TE Tunnel Interface.............................................................................................................. 102
1.2.5.5 (Optional) Configuring SR on a PCC...................................................................................................................104
1.2.5.6 (Optional) Enabling a Device to Simulate an SR-TE Transit Node to Perform Link Label-based Forwarding.. 104
1.2.5.7 Verifying the Configuration of an IS-IS SR-TE Tunnel (Path Computation on the Controller).......................... 105
1.2.6 Configuring an OSPF SR-TE Tunnel (Path Computation on the Controller)......................................................... 106
1.2.6.1 Enabling MPLS TE.............................................................................................................................................. 106
1.2.6.2 Globally Enabling the SR Capability................................................................................................................... 107
1.2.6.3 Configuring the OSPF SR-TE Capability and Topology Report Function.......................................................... 107
1.2.6.5 (Optional) Configuring SR on a PCC................................................................................................................... 110
1.2.6.6 (Optional) Enabling a Device to Simulate an SR-TE Transit Node to Perform Link Label-based Forwarding.. 111
1.2.6.7 Verifying the Configuration of an OSPF SR-TE Tunnel (Path Computation on the Controller)......................... 111
1.2.7 Configuring an IS-IS SR-TE Tunnel (Explicit Path Used)......................................................................................112
1.2.7.1 Enabling MPLS TE...............................................................................................................................................112
1.2.7.2 Globally Enabling the Segment Routing Capability.............................................................................................113
1.2.7.3 Configuring Basic SR-TE Functions.................................................................................................................... 113
1.2.7.4 Configuring an SR-TE Explicit Path.................................................................................................................... 115
1.2.7.5 Configuring an SR-TE Tunnel Interface...............................................................................................................116
1.2.7.6 Checking the Configurations................................................................................................................................ 117
1.2.8 Configuring an OSPF SR-TE Tunnel (Explicit Path Used).....................................................................................118
1.2.8.1 Enabling MPLS TE...............................................................................................................................................118
Issue draft 04 (2019-05-20) Copyright © Huawei Technologies Co., Ltd. iii

1.2.8.2 Globally Enabling the SR Capability....................................................................................................................118

1.2.8.4 Configuring an SR-TE Explicit Path.................................................................................................................... 120
1.2.9 Configuring an IS-IS SR-TE Tunnel (Path Computation on a Forwarder)............................................................. 123
1.2.9.1 Enabling MPLS TE.............................................................................................................................................. 123
1.2.9.2 Globally Enabling the Segment Routing Capability............................................................................................ 124
1.2.9.4 Enabling the Ingress to Compute a Path...............................................................................................................126
1.2.10 Configuring an OSPF SR-TE Tunnel (Path Computation on a Forwarder).......................................................... 128
1.2.10.1 Enabling MPLS TE............................................................................................................................................ 128
1.2.10.2 Globally Enabling the SR Capability................................................................................................................. 129
1.2.10.3 Configuring Basic SR-TE Functions.................................................................................................................. 130
1.2.10.4 Enabling the Ingress to Compute a Path.............................................................................................................131
1.2.10.5 Configuring an SR-TE Tunnel Interface............................................................................................................ 131
1.2.10.6 Checking the Configurations.............................................................................................................................. 133
1.2.11 Configuring BGP SR............................................................................................................................................. 133
1.2.12 Configuring an Inter-AS E2E SR-TE Tunnel (Path Computation on the Controller)...........................................134
1.2.12.1 Setting a Binding SID.........................................................................................................................................136
1.2.12.2 Configuring an E2E SR-TE Tunnel Interface.....................................................................................................136
1.2.12.3 (Optional) Configuring SR on a PCC.................................................................................................................137
1.2.12.4 Verifying the Configuration of an Inter-AS E2E SR-TE Tunnel........................................................................138
1.2.13 Configuring an Inter-AS E2E SR-TE Tunnel (Explicit Path Used)...................................................................... 138
1.2.13.1 Setting a Binding SID.........................................................................................................................................139
1.2.13.2 Configuring an SR-TE Explicit Path.................................................................................................................. 140
1.2.13.3 Configuring an E2E SR-TE Tunnel Interface.....................................................................................................141
1.2.13.4 Verifying the Configuration of an Inter-AS E2E SR-TE Tunnel........................................................................142
1.2.14 Configuring IS-IS SR to Communicate with LDP................................................................................................ 142
1.2.15 Configuring OSPF SR to Communicate with LDP............................................................................................... 144
1.2.16 Configuring IS-IS TI-LFA FRR............................................................................................................................ 146
1.2.17 Configuring OSPF TI-LFA FRR........................................................................................................................... 148
1.2.18 Configuring SBFD for SR-BE Tunnel...................................................................................................................150
1.2.19 Configuring SBFD for SR-TE LSP....................................................................................................................... 151
1.2.20 Configuring SBFD for SR-TE Tunnel...................................................................................................................153
1.2.21 Configuring BFD for SR LSP............................................................................................................................... 154
1.2.22 Configuring BFD for SR LSP (SR and LDP Interworking Scenario)...................................................................156
1.2.23 Configuring Static BFD for SR-TE....................................................................................................................... 158
1.2.24 Configuring Static BFD for SR-TE LSP............................................................................................................... 161
1.2.25 Configuring Dynamic BFD for SR-TE LSP..........................................................................................................165
Issue draft 04 (2019-05-20) Copyright © Huawei Technologies Co., Ltd. iv

1.2.26 Configuring One-Arm BFD for E2E SR-TE Tunnel.............................................................................................168

1.2.27 Configuring One-Arm BFD for E2E SR-TE LSP................................................................................................. 170
1.2.28 Configuring Examples for SR-BE......................................................................................................................... 172
1.2.28.1 Example for Configuring L3VPN over IS-IS SR-BE........................................................................................ 172
1.2.28.2 Example for Configuring L3VPN over OSPF SR-BE....................................................................................... 185
1.2.28.3 Example for Configuring Non-Labeled Public BGP Routes to Recurse to an SR-BE tunnel........................... 197
1.2.28.4 Example for Configuring IS-IS SR to Communicate with LDP........................................................................ 204
1.2.28.5 Example for Configuring IS-IS Anycast FRR....................................................................................................209
1.2.28.6 Example for Configuring SBFD to Monitor SR-BE Tunnels.............................................................................215
1.2.29 Configuration Examples for SR-TE...................................................................................................................... 223
1.2.29.1 Example for Configuring L3VPN over SR-TE.................................................................................................. 224
1.2.29.2 Example for Configuring LDP VPLS over SR-TE............................................................................................ 234
1.2.29.3 Example for Configuring BD EVPN IRB over SR-TE...................................................................................... 244
1.2.29.4 Example for Configuring an SR-TE Tunnel (Path Computation on the Controller)..........................................259
1.2.29.5 Example for Configuring the Controller to Run NETCONF to Deliver Configurations to Create an SR-TE
Tunnel............................................................................................................................................................................... 264
1.2.29.6 Example for Configuring Static BFD for SR-TE............................................................................................... 271
1.2.29.7 Example for Configuring Dynamic BFD for SR-TE LSP..................................................................................276
1.2.29.8 Example for Configuring an E2E SR-TE Tunnel (Explicit Path Used)............................................................. 284
1.3 Segment Routing MPLS Configuration Commands.................................................................................................. 297
1.3.1 avoid-microloop segment-routing........................................................................................................................... 297
1.3.2 avoid-microloop segment-routing rib-update-delay................................................................................................ 299
1.3.3 bfd (segment routing).............................................................................................................................................. 300
1.3.4 bfd enable................................................................................................................................................................ 301
1.3.5 display bgp egress-engineering............................................................................................................................... 303
1.3.6 display isis avoid-microloop information................................................................................................................305
1.3.7 display isis segment-routing mapping-server.......................................................................................................... 307
1.3.8 display isis ti-lfa-node............................................................................................................................................. 309
1.3.9 display mpls sr-te cspf destination...........................................................................................................................311
1.3.10 display mpls te binding-sid....................................................................................................................................314
1.3.11 display mpls te binding-sid ref-list........................................................................................................................ 315
1.3.12 display mpls te cspf tedb sid..................................................................................................................................316
1.3.13 display ospf segment-routing mapping-server...................................................................................................... 319
1.3.14 display ospf segment-routing routing.................................................................................................................... 321
1.3.15 display segment-routing adjacency mpls forwarding............................................................................................ 323
1.3.16 display segment-routing bfd tunnel session...........................................................................................................324
1.3.17 display segment-routing dynamic global-block.................................................................................................... 326
1.3.18 display segment-routing global-block................................................................................................................... 327
1.3.19 display segment-routing prefix mpls forwarding.................................................................................................. 328
1.3.20 display segment-routing seamless-bfd tunnel session........................................................................................... 331
1.3.21 display segment-routing state ip-prefix................................................................................................................. 333
1.3.22 ipv4 adjacency....................................................................................................................................................... 335
1.3.23 isis prefix-sid......................................................................................................................................................... 337
Issue draft 04 (2019-05-20) Copyright © Huawei Technologies Co., Ltd. v

1.3.24 isis ti-lfa disable.....................................................................................................................................................339

1.3.25 lsp-trigger segment-routing-interworking best-effort host.................................................................................... 341
1.3.26 mapping-server prefix-sid-mapping...................................................................................................................... 342
1.3.27 match dscp (tunnel interface view)........................................................................................................................343
1.3.28 mpls sr ttl-mode..................................................................................................................................................... 345
1.3.29 mpls te bfd tunnel block........................................................................................................................................ 348
1.3.30 mpls te bfd tunnel enable one-arm-echo................................................................................................................349
1.3.31 mpls te bfd tunnel enable seamless........................................................................................................................351
1.3.32 mpls te bfd tunnel (segment routing).....................................................................................................................352
1.3.33 mpls te binding-sid................................................................................................................................................ 353
1.3.34 mpls te cspf path-selection adjacency-sid..............................................................................................................355
1.3.35 mpls te path verification disable............................................................................................................................ 356
1.3.36 mpls te path verification enable.............................................................................................................................357
1.3.37 mpls te reverse-lsp binding-sid..............................................................................................................................358
1.3.38 next sid label.......................................................................................................................................................... 360
1.3.39 ospf prefix-sid........................................................................................................................................................361
1.3.40 ospf ti-lfa disable................................................................................................................................................... 363
1.3.41 ospf ti-lfa disable multi-area..................................................................................................................................364
1.3.42 peer egress-engineering......................................................................................................................................... 366
1.3.43 seamless-bfd (segment routing).............................................................................................................................367
1.3.44 seamless-bfd enable............................................................................................................................................... 368
1.3.45 segment-routing..................................................................................................................................................... 370
1.3.46 segment-routing auto-adj-sid disable.....................................................................................................................371
1.3.47 segment-routing global-block................................................................................................................................372
1.3.48 segment-routing lsp-trigger................................................................................................................................... 374
1.3.49 segment-routing mapping-server........................................................................................................................... 375
1.3.50 segment-routing mpls............................................................................................................................................ 377
1.3.51 sr-te-simulate static-cr-lsp transit...........................................................................................................................378
1.3.52 ti-lfa (IS-IS)........................................................................................................................................................... 380
1.3.53 ti-lfa enable (OSPF)...............................................................................................................................................382
1.3.54 tunnel-prefer segment-routing............................................................................................................................... 383
2 Segment Routing IPv6.............................................................................................................. 385

2.1 Segment Routing IPv6................................................................................................................................................385
2.1.1 Overview of Segment Routing IPv6........................................................................................................................385
2.1.2 Understanding Segment Routing IPv6.................................................................................................................... 386
2.1.2.1 Segment Routing IPv6 Fundamentals.................................................................................................................. 386
2.1.2.2 SRv6-BE............................................................................................................................................................... 390
2.1.2.2.1 Introduction to IPv4 VPN over SRv6-BE......................................................................................................... 390
2.1.2.2.2 IPv4 VPN over SRv6-BE Implementation Process...........................................................................................392
2.1.2.3 SRv6-TE............................................................................................................................................................... 394
2.1.2.3.1 SRv6-TE Tunnel Creation................................................................................................................................. 394
2.1.2.3.2 SRv6-TE Data Forwarding................................................................................................................................ 395
Issue draft 04 (2019-05-20) Copyright © Huawei Technologies Co., Ltd. vi

2.1.2.3.3 Importing Traffic to SRv6-TE Tunnel............................................................................................................... 398

2.1.2.4 IS-IS for SRv6...................................................................................................................................................... 399
2.1.2.5 IPv6 TI-LFA FRR.................................................................................................................................................406
2.1.2.6 SRv6 OAM........................................................................................................................................................... 409
2.1.3 Terminology for Segment Routing IPv6..................................................................................................................411
2.2 Segment Routing IPv6 Configuration........................................................................................................................ 412
2.2.1 Overview of Segment Routing IPv6........................................................................................................................412
2.2.2 Licensing Requirements and Limitations for Segment Routing IPv6..................................................................... 413
2.2.3 Configuring an SRv6-TE Tunnel (over a Manually Configured Explicit Path)......................................................415
2.2.3.1 Setting an IPv6 Router ID.................................................................................................................................... 416
2.2.3.2 Globally Enabling the SRv6 Capability............................................................................................................... 416
2.2.3.3 Configuring the SRv6 SID................................................................................................................................... 417
2.2.3.4 Configuring an SRv6-TE Tunnel Interface.......................................................................................................... 418
2.2.3.5 Verifying the IPv6 SR-TE Tunnel Configuration................................................................................................. 419
2.2.4 Configuring IPv4 VPN over SRv6-BE....................................................................................................................420
2.2.5 Configuring IPv6 IS-IS TI-LFA FRR......................................................................................................................423
2.2.6 Segment Routing IPv6 Configuration Examples.....................................................................................................425
2.2.6.1 Example for Configuring an IS-IS SRv6-TE Tunnel (Dynamic SID Mode)....................................................... 425
2.2.6.2 Example for Configuring an IS-IS SRv6-TE Tunnel (Static SID Mode).............................................................432
2.2.6.3 Example for Configuring IPv4 VPN over SRv6-BE............................................................................................437
2.3 Segment Routing IPv6 Configuration Commands..................................................................................................... 446
2.3.1 add sid......................................................................................................................................................................446
2.3.2 autoroute announce..................................................................................................................................................448
2.3.3 autoroute metric....................................................................................................................................................... 449
2.3.4 delete sid.................................................................................................................................................................. 450
2.3.5 destination ipv6........................................................................................................................................................451
2.3.6 display explicit-path (SRv6).................................................................................................................................... 452
2.3.7 display isis srv6 ti-lfa-node......................................................................................................................................453
2.3.8 display segment-routing ipv6 local-sid....................................................................................................................455
2.3.9 display segment-routing ipv6 locator...................................................................................................................... 458
2.3.10 display srv6 lsp...................................................................................................................................................... 460
2.3.11 display srv6 te tunnel path..................................................................................................................................... 461
2.3.12 display srv6 te tunnel-interface..............................................................................................................................463
2.3.13 encapsulation source-address................................................................................................................................ 468
2.3.14 ipv6 avoid-microloop segment-routing................................................................................................................. 470
2.3.15 ipv6 avoid-microloop segment-routing rib-update-delay......................................................................................471
2.3.16 isis ipv6 ti-lfa disable.............................................................................................................................................472
2.3.17 locator.................................................................................................................................................................... 473
2.3.18 modify sid.............................................................................................................................................................. 477
2.3.19 next sid ipv6...........................................................................................................................................................478
2.3.20 opcode....................................................................................................................................................................479
2.3.21 peer enable (BGP VPNv4 address family view)................................................................................................... 481
Issue draft 04 (2019-05-20) Copyright © Huawei Technologies Co., Ltd. vii

2.3.22 peer prefix-sid........................................................................................................................................................483

2.3.23 path explicit-path (SRv6).......................................................................................................................................484
2.3.24 segment-routing ipv6............................................................................................................................................. 485
2.3.25 segment-routing ipv6 best-effort........................................................................................................................... 486
2.3.26 segment-routing ipv6 locator (BGP VPN instance IPv4 address family view).....................................................487
2.3.27 segment-routing ipv6 (IS-IS view)........................................................................................................................ 488
2.3.28 sr-te frr enable........................................................................................................................................................491
2.3.29 statistic enable (SRv6)........................................................................................................................................... 492
2.3.30 te ipv6-router-id..................................................................................................................................................... 493
2.3.31 ti-lfa (IPv6)............................................................................................................................................................ 494
2.3.32 traffic-eng enable................................................................................................................................................... 495
2.3.33 tunnel-id (SRv6).................................................................................................................................................... 496
3 EVPN............................................................................................................................................498
3.1 EVPN..........................................................................................................................................................................498
3.1.1 Overview of EVPN..................................................................................................................................................498
3.1.2 Understanding EVPN.............................................................................................................................................. 499
3.1.3 EVPN-MPLS........................................................................................................................................................... 506
3.1.3.1 EVPN Multi-Homing Technology........................................................................................................................506
3.1.3.2 EVPN Seamless MPLS Fundamentals................................................................................................................. 509
3.1.3.3 EVPN's Service Modes.........................................................................................................................................522
3.1.4 EVPN-VXLAN....................................................................................................................................................... 524
3.1.4.1 EVPN VXLAN Fundamentals............................................................................................................................. 524
3.1.5 EVPN VPWS...........................................................................................................................................................529
3.1.5.1 EVPN VPWS Fundamentals................................................................................................................................ 529
3.1.6 PBB-EVPN.............................................................................................................................................................. 535
3.1.6.1 PBB-EVPN Fundamentals................................................................................................................................... 535
3.1.7 EVPN E-Tree...........................................................................................................................................................544
3.1.8 MAC Duplication Suppression for EVPN...............................................................................................................546
3.1.9 EVPN ORF.............................................................................................................................................................. 549
3.1.10 IGMP Snooping over EVPN MPLS...................................................................................................................... 551
3.1.11 Application Scenarios for EVPN...........................................................................................................................559
3.1.11.1 Inter-AS EVPN Option C................................................................................................................................... 559
3.1.11.2 DCI Scenarios..................................................................................................................................................... 561
3.1.11.3 Migration from an HVPLS Network to a PBB-EVPN....................................................................................... 575
3.1.11.4 Using EVPN to Interconnect Other Networks....................................................................................................576
3.1.11.5 EVPN Splicing....................................................................................................................................................577
3.1.11.6 Seamless Migration of VPLS to EVPN..............................................................................................................582
3.1.11.7 EVPN L3VPN HVPN.........................................................................................................................................583
3.2 EVPN Configuration.................................................................................................................................................. 588
3.2.1 Overview of EVPN..................................................................................................................................................588
3.2.2 Licensing Requirements and Limitations for EVPN............................................................................................... 589
3.2.3 Activating EVPN Interface Licenses on a Board.................................................................................................... 596
Issue draft 04 (2019-05-20) Copyright © Huawei Technologies Co., Ltd. viii

3.2.4 Configuring Common EVPN Functions..................................................................................................................597

3.2.4.1 Configuring an EVPN Instance............................................................................................................................ 598
3.2.4.2 Configuring an EVPN Source Address................................................................................................................ 600
3.2.4.3 Binding an Interface to an EVPN Instance...........................................................................................................600
3.2.4.4 Configuring an ESI............................................................................................................................................... 601
3.2.4.5 Configuring a BGP EVPN Peer Relationship...................................................................................................... 603
3.2.4.6 (Optional)Configuring a PE's Global Redundancy Mode.................................................................................... 604
3.2.4.7 (Optional) Configuring a BGP EVPN RR............................................................................................................605
3.2.4.8 (Optional) Associating DF with BFD...................................................................................................................606
3.2.4.9 (Optional) Board Selection for Internal Loopback on a Main Control Board......................................................607
3.2.4.10 Verifying the EVPN Configuration.................................................................................................................... 608
3.2.5 Configuring BD-EVPN Functions...........................................................................................................................608
3.2.5.1 Configuring an EVPN Instance in BD Mode....................................................................................................... 609
3.2.5.2 Configuring an EVPN Source Address................................................................................................................ 610
3.2.5.3 Configuring an ESI............................................................................................................................................... 611
3.2.5.4 Configuring a BD and Binding an EVPN Instance to the BD..............................................................................613
3.2.5.5 Creating an L3VPN Instance and Binding It to a VBDIF Interface.....................................................................614
3.2.5.6 Configuring a BGP EVPN Peer Relationship...................................................................................................... 616
3.2.5.7 (Optional)Configuring a PE's Global Redundancy Mode.................................................................................... 617
3.2.5.8 (Optional) Configuring a BGP EVPN RR............................................................................................................618
3.2.5.9 (Optional) Configuring Proxy ARP......................................................................................................................619
3.2.5.10 Checking the Configurations.............................................................................................................................. 620
3.2.6 Configuring EVPN VPWS over MPLS Functions..................................................................................................621
3.2.6.1 Configuring EVPN Functions.............................................................................................................................. 622
3.2.6.2 Configuring an EVPL Instance.............................................................................................................................622
3.2.6.3 Configuring an AC Interface................................................................................................................................ 623
3.2.6.4 Configuring an MPLS LDP Tunnel......................................................................................................................624
3.2.6.5 (Optional) Configuring DF Election.....................................................................................................................625
3.2.6.6 (Optional) Configuring FRR................................................................................................................................ 626
3.2.6.7 Verifying the Configuration of EVPN VPWS over MPLS Functions..................................................................627
3.2.7 Configuring an EVPN to Carry Layer 3 Services................................................................................................... 628
3.2.7.1 Configuring an L3VPN Instance.......................................................................................................................... 630
3.2.7.2 Configuring BGP EVPN Peer Relationships........................................................................................................631
3.2.7.3 Configuring Route Exchange Between a PE and an Access-side Device............................................................ 633
3.2.7.4 (Optional) Re-Encapsulating IRB Routes into IP Prefix Routes and ARP Routes.............................................. 633
3.2.7.5 Verifying the Configuration of an EVPN to Carry Layer 3 Services................................................................... 634
3.2.8 Splicing a Common L3VPN with an EVPN L3VPN.............................................................................................. 634
3.2.9 Splicing a VPLS in PW Redundancy Mode with an Anycast VXLAN in an EVPN Active-Active Scenario....... 637
3.2.10 Configuring EVPN E-LAN over mLDP P2MP Tunnels.......................................................................................639
3.2.11 Configuring BGP EVPN Soft Reset...................................................................................................................... 641
3.2.12 Configuring VLAN-based DF Election.................................................................................................................642
3.2.13 Configuring EVPN Reliability.............................................................................................................................. 642
Issue draft 04 (2019-05-20) Copyright © Huawei Technologies Co., Ltd. ix

3.2.14 Configuring MAC Duplication Suppression for EVPN........................................................................................ 646

3.2.15 Configuring EVPN E-Tree.................................................................................................................................... 649
3.2.16 Configuring EVPN ORF....................................................................................................................................... 650
3.2.17 Splicing a VLL with a Common EVPN E-LAN................................................................................................... 652
3.2.18 Splicing a VLL with an MPLS EVPN E-Line...................................................................................................... 654
3.2.19 Splicing a VXLAN EVPN with a VPLS............................................................................................................... 657
3.2.19.1 Creating VSIs and Configuring PW Connections.............................................................................................. 658
3.2.19.2 Configuring a VXLAN EVPN........................................................................................................................... 659
3.2.19.3 Establishing BGP Peer Relationships.................................................................................................................660
3.2.19.4 Binding EVPN Instances and VSIs to BDs........................................................................................................ 661
3.2.19.5 (Optional) Configuring BFD for VPLS PW.......................................................................................................662
3.2.19.6 Verifying the Configuration of Splicing a VXLAN EVPN with a VPLS.......................................................... 663
3.2.20 Configuring MPLS EVPN E-LAN Option B........................................................................................................ 664
3.2.20.1 Configuring MP-IBGP Between a PE and an ASBR in the Same AS............................................................... 665
3.2.20.2 Configuring MP-EBGP Between ASBRs in Different ASs............................................................................... 665
3.2.20.3 Configuring ASBRs Not to Filter EVPN Routes Based on VPN Targets.......................................................... 667
3.2.20.4 (Optional) Configuring One-Label-per-Next-Hop Label Distribution on an ASBR..........................................667
3.2.20.5 (Optional) Configuring the Protection Switching Function............................................................................... 668
3.2.20.6 (Optional) Configuring BGP-EVPN Route Reflection on an ASBR................................................................. 669
3.2.20.7 Verifying the Configuration MPLS EVPN E-Lan OptionB............................................................................... 671
3.2.21 Configuring an EVPN L3VPN HVPN.................................................................................................................. 671
3.2.21.1 Configuring an EVPN L3VPN HoVPN............................................................................................................. 672
3.2.21.2 Configuring an EVPN L3VPN H-VPN..............................................................................................................675
3.2.21.3 Splicing an EVPN L3VPN HoVPN with a Common L3VPN........................................................................... 676
3.2.21.4 Splicing an L3VPN HoVPN with an EVPN L3VPN......................................................................................... 677
3.2.21.5 Verifying the EVPN L3VPN HVPN Configuration........................................................................................... 679
3.2.22 Configuring IGMP Snooping over EVPN MPLS................................................................................................. 679
3.2.22.1 Configuring IGMP Snooping and Proxy............................................................................................................ 680
3.2.22.2 Configuring the Access Side.............................................................................................................................. 681
3.2.22.3 Verifying the Configuration................................................................................................................................683
3.2.23 Configuring DCI Functions................................................................................................................................... 683
3.2.23.1 Configuring a DCI Scenario with an E2E VXLAN EVPN Deployed on a Gateway........................................ 684
3.2.23.2 Configuring a DCI Scenario with a VLAN Layer 3 Sub-interface Accessing a Common L3VPN...................685
3.2.23.3 Configuring a DCI Scenario with a VXLAN EVPN L3VPN Accessing a Common L3VPN...........................687
3.2.23.4 Configuring a DCI Scenario with a VLAN Base Accessing an MPLS EVPN IRB.......................................... 689
3.2.23.5 Configuring a DCI Scenario with a VXLAN EVPN Accessing an MPLS EVPN IRB..................................... 695
3.2.23.6 Verifying the Configuration of DCI Functions...................................................................................................698
3.2.24 Configuration Examples for EVPN....................................................................................................................... 699
3.2.24.1 Example for Configuring a VPN to Access a Common EVPN E-LAN............................................................ 699
3.2.24.2 Example for Configuring Eth-Trunk Sub-interfaces to Access a Common EVPN E-LAN in Active-Active
Mode................................................................................................................................................................................. 713
3.2.24.3 Example for Configuring Eth-Trunk Sub-interfaces to Access a BD EVPN IRB in Active-Active Mode
(Carrying Both Layer 2 and Layer 3 Services).................................................................................................................730
Issue draft 04 (2019-05-20) Copyright © Huawei Technologies Co., Ltd. x

3.2.24.4 Example for Configuring EVPN VPWS over MPLS.........................................................................................746

3.2.24.5 Example for Configuring EVPN E-Tree............................................................................................................ 756
3.2.24.6 Example for Configuring EVPN ORF................................................................................................................764
3.2.24.7 Example for Configuring a DCI Scenario with an E2E VXLAN EVPN Deployed on a Gateway................... 777
3.2.24.8 Example for Configuring a DCI Scenario with a VLAN Layer 3 Sub-Interface Accessing a Common L3VPN
.......................................................................................................................................................................................... 784
3.2.24.9 Example for Configuring a DCI Scenario with a VXLAN EVPN L3VPN Accessing a Common L3VPN......791
3.2.24.10 Example for Configuring MPLS EVPN E-LAN Option B.............................................................................. 801
3.2.24.11 Example for Configuring an MPLS EVPN L3VPN in E-LAN Option B Mode..............................................806
3.2.24.12 Example for Configuring Inter-AS EVPN Option C........................................................................................813
3.2.24.13 Example for Splicing a VXLAN EVPN with a VPLS..................................................................................... 822
3.2.24.14 Example for Configuring EVPN E-LAN over mLDP P2MP Tunnels.............................................................830
3.2.24.15 Example for Splicing a VLL with a Common EVPN E-LAN......................................................................... 842
3.2.24.16 Example for Splicing a VLL with an MPLS EVPN E-Line.............................................................................848
3.2.24.17 Example for Accessing a BD EVPN E-LAN over an MPLS Tunnel in VLAN-Aware Mode........................ 853
3.2.24.18 Example for Accessing an EVPN E-LAN over a VXLAN Tunnel in VLAN-Aware Mode........................... 868
3.2.24.19 Example for Configuring Co-Existence of a VPLS and an EVPN.................................................................. 882
3.2.24.20 Example for Configuring a DCI Scenario with a VXLAN EVPN Accessing an MPLS EVPN IRB.............. 891
3.2.24.21 Example for Configuring a DCI Scenario with a VLAN Base Accessing an MPLS EVPN IRB (Using EVPN-
MPLS as the Bearer and PE as a GW)............................................................................................................................. 900
3.2.24.22 Example for Splicing a Common L3VPN with an EVPN L3VPN.................................................................. 909
3.2.24.23 Example for Splicing a VPLS in PW Redundancy Mode with an Anycast VXLAN in an EVPN Active-Active
Scenario............................................................................................................................................................................ 916
3.2.24.24 Example for Configuring an EVPN L3VPN HoVPN...................................................................................... 924
3.2.24.25 Example for Configuring an EVPN L3VPN H-VPN....................................................................................... 932
3.2.24.26 Example for Splicing an EVPN L3VPN HoVPN with a Common L3VPN.................................................... 938
3.2.24.27 Example for Splicing an L3VPN HoVPN with an EVPN L3VPN.................................................................. 946
3.2.24.28 Example for Configuring IGMP Snooping over EVPN MPLS....................................................................... 954
3.2.24.29 Example for Configuring BD EVPN IRB over SR-TE.................................................................................... 968
3.3 EVPN Configuration Commands............................................................................................................................... 984
3.3.1 active port-evpn....................................................................................................................................................... 984
3.3.2 display license resource usage port-evpn................................................................................................................ 985
3.3.3 black-hole-dup-mac................................................................................................................................................. 989
3.3.4 bypass-vxlan enable.................................................................................................................................................990
3.3.5 data-delay-time........................................................................................................................................................ 991
3.3.6 data-switch disable.................................................................................................................................................. 992
3.3.7 description (EVPN)................................................................................................................................................. 993
3.3.8 detect loop-times......................................................................................................................................................994
3.3.9 display bgp evpn evpl.............................................................................................................................................. 995
3.3.10 display bgp evpn esi.............................................................................................................................................. 998
3.3.11 display bgp evpn vpn-instance esi advance......................................................................................................... 1000
3.3.12 display bgp evpn peer.......................................................................................................................................... 1002
3.3.13 display bgp evpn routing-table............................................................................................................................ 1013
Issue draft 04 (2019-05-20) Copyright © Huawei Technologies Co., Ltd. xi

3.3.14 display default-parameter evpn............................................................................................................................1028

3.3.15 display evpn df result...........................................................................................................................................1029
3.3.16 display evpn df-timer state.................................................................................................................................. 1031
3.3.17 display evpn mac routing-table............................................................................................................................1033
3.3.18 display evpn mac routing-table limit................................................................................................................... 1036
3.3.19 display evpn mac routing-table statistics.............................................................................................................1037
3.3.20 display evpn recover-timer.................................................................................................................................. 1039
3.3.21 display evpn vpn-instance................................................................................................................................... 1040
3.3.22 display evpn vpn-instance inclusive-provider-tunnel.......................................................................................... 1042
3.3.23 display evpn vpn-instance mac-duplication........................................................................................................ 1044
3.3.24 display evpn vpn-instance name mac-esi............................................................................................................ 1046
3.3.25 display evpn track-peer-timer.............................................................................................................................. 1048
3.3.26 df-election ac-influence enable............................................................................................................................1049
3.3.27 df-election type vlan............................................................................................................................................ 1050
3.3.28 esi.........................................................................................................................................................................1051
3.3.29 esi (BD view).......................................................................................................................................................1052
3.3.30 es track evpn-peer(evpn)......................................................................................................................................1054
3.3.31 es track evpn-peer(BD view)............................................................................................................................... 1055
3.3.32 es track bfd...........................................................................................................................................................1057
3.3.33 etree enable.......................................................................................................................................................... 1058
3.3.34 evpl instance (interface view)..............................................................................................................................1060
3.3.35 evpl instance (system view).................................................................................................................................1061
3.3.36 evpn (system view).............................................................................................................................................. 1062
3.3.37 evpn binding vpn-instance...................................................................................................................................1063
3.3.38 evpn binding vpn-instance (EVPL)..................................................................................................................... 1065
3.3.39 evpn enhancement port........................................................................................................................................ 1066
3.3.40 evpn e-tree-leaf.................................................................................................................................................... 1067
3.3.41 evpn mpls routing-enable.................................................................................................................................... 1069
3.3.42 evpn redundancy-mode single-active.................................................................................................................. 1070
3.3.43 evpn source-address.............................................................................................................................................1071
3.3.44 evpn vpn-instance................................................................................................................................................ 1072
3.3.45 evpn access vll convergence separate disable..................................................................................................... 1073
3.3.46 evpn reserve-interface enhancement....................................................................................................................1074
3.3.47 filter-policy export (EVPN instance view).......................................................................................................... 1075
3.3.48 filter-policy import (EVPN instance view)..........................................................................................................1077
3.3.49 irb-reoriginated compatible................................................................................................................................. 1078
3.3.50 inclusive-provider-tunnel (BD-EVPN instance view).........................................................................................1079
3.3.51 isolate spoken (EVPN instance view)................................................................................................................. 1080
3.3.52 l2vpn-family evpn................................................................................................................................................1081
3.3.53 leaf (EVI I-PMSI view)....................................................................................................................................... 1082
3.3.54 local-remote frr (EVPN instance view)............................................................................................................... 1083
3.3.55 local-remote frr enable (global EVPN configuration view)................................................................................ 1084
Issue draft 04 (2019-05-20) Copyright © Huawei Technologies Co., Ltd. xii

3.3.56 local-remote vpws-frr enable(global EVPN configuration view)....................................................................... 1085

3.3.57 local-service-id.................................................................................................................................................... 1087
3.3.58 mac limit.............................................................................................................................................................. 1088
3.3.59 mac-duplication................................................................................................................................................... 1090
3.3.60 mac threshold-alarm............................................................................................................................................ 1091
3.3.61 mldp p2mp (EVI I-PMSI root view)................................................................................................................... 1092
3.3.62 mtu-match ignore (EVPL-MPLS)....................................................................................................................... 1093
3.3.63 peer advertise....................................................................................................................................................... 1095
3.3.64 peer advertise route-reoriginated (BGP-EVPN address family view).................................................................1096
3.3.65 peer advertise route-reoriginated......................................................................................................................... 1098
3.3.66 peer import reoriginate.........................................................................................................................................1100
3.3.67 peer mac-limit (BGP EVPN view)...................................................................................................................... 1101
3.3.68 peer esad-route-compatible (BGP-EVPN address family view)......................................................................... 1104
3.3.69 peer split-group.................................................................................................................................................... 1106
3.3.70 peer upe (BGP-EVPN address family view)....................................................................................................... 1107
3.3.71 peer vpn-orf disable............................................................................................................................................. 1108
3.3.72 refresh bgp evpn...................................................................................................................................................1109
3.3.73 remote frr (VPWS-EVPN instance view)............................................................................................................ 1111
3.3.74 remote vpws-frr (global EVPN configuration view)........................................................................................... 1112
3.3.75 reset bgp evpn...................................................................................................................................................... 1114
3.3.76 reset evpn vpn-instance mac-duplication.............................................................................................................1115
3.3.77 retry-cycle............................................................................................................................................................ 1117
3.3.78 root (EVI I-PMSI view)....................................................................................................................................... 1118
3.3.79 root-ip (EVI I-PMSI root mLDP view)............................................................................................................... 1119
3.3.80 root-ip use-next-hop.............................................................................................................................................1120
3.3.81 route-distinguisher (EVPN)................................................................................................................................. 1121
3.3.82 tnl-policy (EVPN instance view).........................................................................................................................1123
3.3.83 timer df-delay.......................................................................................................................................................1124
3.3.84 timer es-recovery (evpn)......................................................................................................................................1125
3.3.85 vpn-orf enable (BGP-EVPN address family view)..............................................................................................1126
3.3.86 vpn-target (EVPN)............................................................................................................................................... 1127
3.3.87 vpws-df-election type.......................................................................................................................................... 1130
3.3.88 vlan-extend private enable................................................................................................................................... 1131
3.3.89 vlan-extend redirect enable..................................................................................................................................1132
4 VXLAN...................................................................................................................................... 1134
4.1 VXLAN.................................................................................................................................................................... 1134
4.1.1 VXLAN Introduction.............................................................................................................................................1134
4.1.2 VXLAN Basics...................................................................................................................................................... 1136
4.1.2.1 VXLAN Basic Concepts.....................................................................................................................................1136
4.1.2.2 Combinations of Underlay and Overlay Networks.............................................................................................1139
4.1.2.3 VXLAN Packet Format...................................................................................................................................... 1140
4.1.2.4 EVPN VXLAN Fundamentals............................................................................................................................1142
Issue draft 04 (2019-05-20) Copyright © Huawei Technologies Co., Ltd. xiii

4.1.2.5 VXLAN Gateway Deployment.......................................................................................................................... 1146

4.1.3 Functional Scenarios..............................................................................................................................................1148
4.1.3.1 Centralized VXLAN Gateway Deployment in Static Mode.............................................................................. 1148
4.1.3.2 Centralized VXLAN Gateway Deployment Using BGP EVPN........................................................................ 1158
4.1.3.3 Distributed VXLAN Gateway Deployment Using BGP EVPN.........................................................................1170
4.1.4 Function Enhancements.........................................................................................................................................1186
4.1.4.1 Using Three-Segment VXLAN to Implement Layer 3 Interconnection Between DCs..................................... 1186
4.1.4.2 Using Three-Segment VXLAN to Implement Layer 2 Interconnection Between DCs..................................... 1190
4.1.4.3 VXLAN Active-Active Reliability.....................................................................................................................1193
4.1.4.4 NFVI Distributed Gateway.................................................................................................................................1199
4.1.5 Application Scenarios for VXLAN....................................................................................................................... 1212
4.1.5.1 Application for Communication Between Terminal Users on a VXLAN..........................................................1212
4.1.5.2 Application for Communication Between Terminal Users on a VXLAN and Legacy Network....................... 1213
4.1.5.3 Application in VM Migration Scenarios............................................................................................................ 1215
4.1.5.4 Application for BRAS Access Through VXLAN.............................................................................................. 1216
4.1.6 Terminology for VXLAN...................................................................................................................................... 1218
4.2 VXLAN Configuration.............................................................................................................................................1219
4.2.1 Overview of VXLAN............................................................................................................................................ 1219
4.2.2 Licensing Requirements and Limitations for VXLAN......................................................................................... 1225
4.2.3 Configuring VXLAN in Centralized Gateway Mode for Static Tunnel Establishment........................................ 1228
4.2.3.1 Configuring a VXLAN Service Access Point.................................................................................................... 1230
4.2.3.2 Configuring a VXLAN Tunnel...........................................................................................................................1233
4.2.3.3 Configuring a Layer 3 VXLAN Gateway.......................................................................................................... 1234
4.2.3.4 (Optional) Configuring Static MAC Address Entries and MAC Address Limiting.......................................... 1235
4.2.3.5 Verifying the Configuration of VXLAN in Centralized Gateway Mode........................................................... 1236
4.2.4 Configuring VXLAN in Centralized Gateway Mode Using BGP EVPN.............................................................1237
4.2.4.1 Configuring a Service Access Point................................................................................................................... 1239
4.2.4.5 Verifying the Configuration of VXLAN in Centralized Gateway Mode Using BGP EVPN.............................1248
4.2.5 Configuring VXLAN in Distributed Gateway Mode Using BGP EVPN............................................................. 1249
4.2.5.1 Configuring a Service Access Point................................................................................................................... 1252
4.2.5.5 Verifying the Configuration of VXLAN in Distributed Gateway Mode Using BGP EVPN............................. 1266
4.2.6 Configuring Three-Segment VXLAN to Implement DCI.....................................................................................1267
4.2.6.1 Configuring Three-Segment VXLAN to Implement Layer 3 Interworking...................................................... 1267
4.2.6.2 Configuring Three-Segment VXLAN to Implement Layer 2 Interworking...................................................... 1269
4.2.6.3 Verifying the Configuration of Using Three-Segment VXLAN to Implement DCI.......................................... 1271
4.2.7 Configuring the Static VXLAN Active-Active Scenario...................................................................................... 1272
Issue draft 04 (2019-05-20) Copyright © Huawei Technologies Co., Ltd. xiv

4.2.8 Configuring the Dynamic VXLAN Active-Active Scenario.................................................................................1275

4.2.9 Configuring BRAS Access Through a PW and a VXLAN Tunnel.......................................................................1279
4.2.10 Configuring NFVI Distributed Gateway............................................................................................................. 1282
4.2.10.1 Configuring an L3VPN Instance on a DCGW................................................................................................. 1284
4.2.10.2 Configuring Route Advertisement on a DC-GW............................................................................................. 1286
4.2.10.3 Configuring Route Advertisement on an L2GW/L3GW................................................................................. 1289
4.2.10.4 Configuring Load Balancing............................................................................................................................ 1291
4.2.10.5 Verifying the NFVI Distributed Gateway Configuration................................................................................. 1293
4.2.11 Maintaining VXLAN...........................................................................................................................................1293
4.2.11.1 Configuring the VXLAN Alarm Function........................................................................................................1293
4.2.11.2 Collecting and Checking VXLAN Packet Statistics.........................................................................................1294
4.2.11.3 Clearing VXLAN Packet Statistics...................................................................................................................1295
4.2.11.4 Checking Statistics about MAC Address Entries in a BD................................................................................1296
4.2.11.5 Clearing Statistics about Dynamic MAC Address Entries in a BD..................................................................1296
4.2.12 Configuration Examples for VXLAN................................................................................................................. 1296
4.2.12.1 Example for Configuring Users on the Same Network Segment to Communicate Through a VXLAN Tunnel
........................................................................................................................................................................................ 1297
4.2.12.2 Example for Configuring Users on Different Network Segments to Communicate Through a VXLAN Layer 3
Gateway.......................................................................................................................................................................... 1301
4.2.12.3 Example for Configuring VXLAN in Centralized Gateway Mode Using BGP EVPN................................... 1306
4.2.12.4 Example for Configuring VXLAN in Distributed Gateway Mode Using BGP EVPN................................... 1313
4.2.12.5 Example for Configuring Three-Segment VXLAN to Implement Layer 3 Interworking................................1320
4.2.12.6 Example for Configuring Three-Segment VXLAN to Implement Layer 2 Interworking................................1332
4.2.12.7 Example for Configuring the Static VXLAN Active-Active Scenario (Layer 2 Communication)................. 1340
4.2.12.8 Example for Configuring the Static VXLAN Active-Active Scenario (Layer 3 Communication)................. 1348
4.2.12.9 Example for Configuring the VXLAN over IPSec Active-Active Scenario....................................................1355
4.2.12.10 Example for Configuring the Static VXLAN Active-Active Scenario (in VLAN-Aware Bundle Mode).....1368
4.2.12.11 Example for Configuring IPv4 NFVI Distributed Gateway...........................................................................1377
4.2.12.12 Example for Configuring IPv6 NFVI Distributed Gateway...........................................................................1397
4.2.12.13 Example for Configuring the NFVI Distributed Gateway Function (Quad-Active DC-GWs)......................1419
4.3 VXLAN Configuration Commands..........................................................................................................................1451
4.3.1 active port-vxlan.................................................................................................................................................... 1451
4.3.2 advertise l2vpn evpn.............................................................................................................................................. 1452
4.3.3 bridge-domain (System view)............................................................................................................................... 1454
4.3.4 bridge-domain (Layer 2 sub-interface view)......................................................................................................... 1455
4.3.5 bypass source......................................................................................................................................................... 1456
4.3.6 description (BD view)........................................................................................................................................... 1457
4.3.7 display bridge-domain........................................................................................................................................... 1458
4.3.8 display bridge-domain statistics............................................................................................................................ 1464
4.3.9 display license resource usage port-vxlan............................................................................................................. 1466
4.3.10 display interface nve............................................................................................................................................ 1469
4.3.11 display interface vbdif......................................................................................................................................... 1471
4.3.12 display mac-address bridge-domain.................................................................................................................... 1473
Issue draft 04 (2019-05-20) Copyright © Huawei Technologies Co., Ltd. xv

4.3.13 display mac-limit bridge-domain.........................................................................................................................1475

4.3.14 display vxlan evpl................................................................................................................................................ 1477
4.3.15 display vxlan peer................................................................................................................................................ 1479
4.3.16 display vxlan tunnel.............................................................................................................................................1481
4.3.17 display vxlan vni..................................................................................................................................................1484
4.3.18 display vxlan statistics......................................................................................................................................... 1487
4.3.19 display vxlan statistics l3-mode...........................................................................................................................1489
4.3.20 encapsulation (Layer 2 sub-interface view).........................................................................................................1491
4.3.21 evpl instance (PW-VE interface view)................................................................................................................ 1493
4.3.22 evpn binding vpn-instance...................................................................................................................................1494
4.3.23 evpn vpn-instance bd-mode.................................................................................................................................1496
4.3.24 export route-policy (EVPN instance view)......................................................................................................... 1498
4.3.25 export route-policy evpn......................................................................................................................................1499
4.3.26 interface mode l2................................................................................................................................................. 1501
4.3.27 interface nve........................................................................................................................................................ 1502
4.3.28 interface vbdif......................................................................................................................................................1503
4.3.29 import route-policy (EVPN instance view)......................................................................................................... 1504
4.3.30 import route-policy evpn..................................................................................................................................... 1505
4.3.31 irb asymmetric..................................................................................................................................................... 1507
4.3.32 local-vni............................................................................................................................................................... 1508
4.3.33 mac-address (VBDIF interface view)..................................................................................................................1509
4.3.34 MAC-Address (NVE Interface View)................................................................................................................. 1511
4.3.35 mac-address static vni..........................................................................................................................................1513
4.3.36 mtu (BDIF interface view).................................................................................................................................. 1514
4.3.37 peer advertise encap-type vxlan...........................................................................................................................1516
4.3.38 peer next-hop-invariable (BGP-EVPN address family view)............................................................................. 1517
4.3.39 peer route-policy (BGP-EVPN address family view)......................................................................................... 1519
4.3.40 peer track admin-vrrp vrid................................................................................................................................... 1520
4.3.41 reset bridge-domain statistics.............................................................................................................................. 1523
4.3.42 reset mac-address bridge-domain........................................................................................................................ 1524
4.3.43 reset vxlan statistics............................................................................................................................................. 1525
4.3.44 reset vxlan statistics l3-mode...............................................................................................................................1526
4.3.45 route-distinguisher (EVPN instance view).......................................................................................................... 1527
4.3.46 source (NVE interface view)............................................................................................................................... 1529
4.3.47 statistic enable (BD view)....................................................................................................................................1530
4.3.48 statistic enable (VNI view).................................................................................................................................. 1531
4.3.49 vni........................................................................................................................................................................ 1532
4.3.50 vni evpl peer........................................................................................................................................................ 1533
4.3.51 vni head-end peer-list.......................................................................................................................................... 1534
4.3.52 vni (NVE interface view).................................................................................................................................... 1536
4.3.53 vpn-target (EVPN instance view)........................................................................................................................1537
4.3.54 vtep-src (EVPL instance in VXLAN mode view)...............................................................................................1539
Issue draft 04 (2019-05-20) Copyright © Huawei Technologies Co., Ltd. xvi

4.3.55 vxlan anycast-gateway enable............................................................................................................................. 1541

4.3.56 vxlan central-reassemble enable.......................................................................................................................... 1542
4.3.57 vxlan statistics enable.......................................................................................................................................... 1543
4.3.58 vxlan statistics l3-mode enable............................................................................................................................1544
4.3.59 vxlan vni.............................................................................................................................................................. 1546
4.3.60 vxlan vni (VPN instance view)............................................................................................................................1547
4.3.61 vxlan vni split-horizon-mode...............................................................................................................................1548
5 NG MVPN.................................................................................................................................1550
5.1 Multicast VPN in NG MVPN Mode........................................................................................................................ 1550
5.1.1 Overview of NG MVPN........................................................................................................................................1550
5.1.2 Understanding NG MVPN.................................................................................................................................... 1552
5.1.2.1 NG MVPN Control Messages............................................................................................................................ 1553
5.1.2.2 NG MVPN Private Multicast Routing................................................................................................................1565
5.1.2.2.1 PIM (S, G) Join/Prune..................................................................................................................................... 1567
5.1.2.2.2 PIM (*, G) Join/Prune..................................................................................................................................... 1570
5.1.2.3 NG MVPN Public Network Tunnel Principle.................................................................................................... 1580
5.1.2.3.1 MVPN Membership Autodiscovery................................................................................................................ 1583
5.1.2.3.2 I-PMSI Tunnel Establishment......................................................................................................................... 1584
5.1.2.3.3 Switching Between I-PMSI and S-PMSI Tunnels...........................................................................................1590
5.1.2.3.4 Transmitting multicast traffic on an NG MVPN............................................................................................. 1596
5.1.2.3.5 NG MVPN Typical Deployment Scenarios on the Public Network................................................................1598
5.1.2.4 NG MVPN Extranet........................................................................................................................................... 1600
5.1.2.5 NG MVPN Reliability........................................................................................................................................ 1603
5.1.3 Application Scenarios for NG MVPN...................................................................................................................1613
5.1.3.1 Application of NG MVPN to IPTV Services..................................................................................................... 1613
5.1.4 Terminology for NG MVPN..................................................................................................................................1615
5.2 IPv4 Multicast VPN Configuration in NG MVPN Mode........................................................................................ 1617
5.2.1 Overview of NG MVPN........................................................................................................................................1618
5.2.2 Licensing Requirements and Limitations for IPv4 Multicast VPN Configuration in NG MVPN Mode............. 1618
5.2.3 Configuring an Intra-AS NG MVPN.....................................................................................................................1621
5.2.3.1 Configuring BGP MVPN Peers..........................................................................................................................1622
5.2.3.2 Configuring a P2MP LSP to Carry Multicast Traffic.........................................................................................1623
5.2.3.3 Configuring PIM.................................................................................................................................................1626
5.2.3.4 (Optional) Configuring IGMP............................................................................................................................ 1627
5.2.3.5 (Optional) Configuring Switching Between I-PMSI and S-PMSI Tunnels....................................................... 1628
5.2.3.6 (Optional) Configuring NG MVPN ORF........................................................................................................... 1629
5.2.3.7 Verifying the Intra-AS NG MVPN Configuration............................................................................................. 1630
5.2.4 Configuring Intra-AS Segmented NG MVPN.......................................................................................................1631
5.2.4.1 Configuring Route Reflection on an ABR......................................................................................................... 1632
5.2.4.2 Establishing BGP MVPN Peer Relationships.................................................................................................... 1633
5.2.4.3 Configuring P2MP Tunnels to Bear Multicast Traffic....................................................................................... 1634
5.2.4.4 Configuring the Support for Segmented Tunnels in an AS................................................................................ 1637
Issue draft 04 (2019-05-20) Copyright © Huawei Technologies Co., Ltd. xvii

5.2.4.6 Configuring PIM.................................................................................................................................................1640
5.2.4.7 (Optional) Configuring IGMP............................................................................................................................ 1640
5.2.4.8 Verifying the Configuration of Intra-AS Segmented NG MVPN...................................................................... 1641
5.2.5 Configuring an Inter-AS or Inter-Area NG MVPN...............................................................................................1642
5.2.5.1 Configuring Inter-AS NG MVPN Option B.......................................................................................................1642
5.2.5.1.1 Configuring Global MPLS LDP Functions and Enabling MPLS LDP on Interfaces..................................... 1643
5.2.5.1.2 Configuring an Automatic mLDP P2MP Tunnel............................................................................................ 1644
5.2.5.1.3 Configuring a Static RP................................................................................................................................... 1644
5.2.5.1.4 Configuring MP-IBGP Between a PE and an ASBR in the Same AS............................................................ 1646
5.2.5.1.5 Configuring MP-EBGP Between ASBRs in Different ASs............................................................................ 1647
5.2.5.1.6 Configuring BGP MVPN Peers.......................................................................................................................1647
5.2.5.1.7 (Optional) Configuring Intra-AS MSDP Peers............................................................................................... 1648
5.2.5.1.8 Configuring a P2MP LSP to Carry Multicast Traffic......................................................................................1649
5.2.5.1.9 (Optional) Configuring Switching Between I-PMSI and S-PMSI Tunnels.................................................... 1651
5.2.5.1.10 Configuring PIM............................................................................................................................................1653
5.2.5.1.11 Configuring Route Exchange Between PEs and CEs....................................................................................1653
5.2.5.2 Configuring Inter-AS NG MVPN Option C.......................................................................................................1663
5.2.5.2.4 Configuring MP-IBGP Between a PE and an ASBR in the Same AS............................................................ 1664
5.2.5.2.5 Configuring MP-EBGP for PEs and ASBRs in Different ASs....................................................................... 1665
5.2.5.2.6 Configuring a Routing Policy to Control Label Distribution on ASBRs........................................................ 1666
5.2.5.2.10 Configuring PIM............................................................................................................................................1672
5.2.5.2.11 Configuring Route Exchange Between PEs and CEs....................................................................................1672
5.2.5.3 Configuring NG MVPN Option B in an Inter-AS Seamless MPLS Scenario................................................... 1673
5.2.5.3.4 Configuring MP-IBGP Among PEs, ABRs, and ASBRs in the Same AS......................................................1674
5.2.5.3.5 Configuring MP-EBGP Between ASBRs in Different ASs............................................................................ 1675
5.2.5.3.6 Configuring a Routing Policy to Control Label Distribution on ASBRs........................................................ 1676
5.2.5.3.7 Configuring Route Reflection on an ABR...................................................................................................... 1676
5.2.5.3.10 (Optional) Configuring Switching Between I-PMSI and S-PMSI Tunnels.................................................. 1680
5.2.5.4 Configuring NG MVPN Option C in Inter-AS Seamless MPLS Scenarios.......................................................1682
Issue draft 04 (2019-05-20) Copyright © Huawei Technologies Co., Ltd. xviii


5.2.5.4.4 Configuring MP-IBGP Among PEs, ABRs, and ASBRs in the Same AS......................................................1683
5.2.5.4.5 Configuring MP-EBGP for PEs and ASBRs in Different ASs....................................................................... 1684
5.2.5.4.6 Configuring a Routing Policy to Control Label Distribution.......................................................................... 1685
5.2.5.4.10 (Optional) Configuring Switching Between I-PMSI and S-PMSI Tunnels.................................................. 1691
5.2.5.4.11 Configuring PIM............................................................................................................................................1692
5.2.5.5 Configuring Inter-Area Seamless NG MVPN.................................................................................................... 1693
5.2.5.5.7 Configuring PIM..............................................................................................................................................1700
5.2.5.5.8 Configuring Route Exchange Between PEs and CEs......................................................................................1700
5.2.6 Configuring NG MVPN Extranet..........................................................................................................................1700
5.2.7 Configuring Dual-Root 1+1 Protection................................................................................................................. 1703
5.2.8 Configuration Examples for NG MVPN............................................................................................................... 1705
5.2.8.1 Example for Configuring an Intra-AS NG MVPN with an mLDP P2MP LSP................................................. 1706
5.2.8.2 Example for Configuring an Intra-AS NG MVPN with an RSVP-TE P2MP LSP............................................1720
5.2.8.3 Example for Configuring Dual-Root 1+1 Protection for RSVP-TE P2MP LSPs..............................................1737
5.2.8.4 Example for Configuring Dual-Root 1+1 Protection for mLDP P2MP LSPs................................................... 1754
5.2.8.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........................................................................................................1769
5.2.8.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.................................................................................................. 1783
5.2.8.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....................................................................................................1798
5.2.8.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.............................................................................................. 1809
5.2.8.9 Example for Configuring an Intra-AS NG MVPN with Segmented Tunnels.................................................... 1820
5.2.8.10 Example for Configuring Dual-Root 1+1 Protection for Intra-AS Segmented Tunnels.................................. 1835
5.2.8.11 Example for Configuring an Inter-AS NG MVPN Option B........................................................................... 1857
5.2.8.12 Example for Configuring an Inter-AS NG MVPN in Option C....................................................................... 1871
5.2.8.13 Example for Configuring an Inter-AS Seamless MPLS NG MVPN Option B................................................1881
5.2.8.14 Example for Configuring an Inter-AS Seamless MPLS NG MVPN Option C................................................1897
5.2.8.15 Example for Configuring an Inter-Area Seamless MPLS NG MVPN............................................................. 1911
5.2.8.16 Example for Configuring an Inter-area NG MVPN......................................................................................... 1926
5.2.8.17 Example for Configuring NG MVPN Extranet in the Remote Cross Scenario Where a Source VPN Instance
Needs to Be Configured on a Receiver PE.....................................................................................................................1938
Issue draft 04 (2019-05-20) Copyright © Huawei Technologies Co., Ltd. xix

5.2.8.18 Example for Configuring NG MVPN Extranet in the Remote Cross Scenario (BAS Multicast)....................1949
5.2.8.19 Example for Configuring NG MVPN Extranet in the Local Cross Scenario Where the Source and Receiver
VPN Instances Reside on the Same PE.......................................................................................................................... 1960
5.3 IPv6 Multicast VPN Configuration in NG MVPN Mode........................................................................................ 1969
5.3.1 Overview of IPv6 NG MVPN............................................................................................................................... 1969
5.3.2 Configuring an Intra-AS IPv6 NG MVPN............................................................................................................ 1969
5.3.2.1 Configuring BGP MVPN Peers..........................................................................................................................1970
5.3.2.2 Configuring a P2MP LSP to Carry Multicast Traffic.........................................................................................1971
5.3.2.3 Configuring IPV6 PIM....................................................................................................................................... 1974
5.3.2.4 (Optional) Configuring MLD............................................................................................................................. 1974
5.3.2.6 Verifying the Configuration of an Intra-AS NG MVPN.................................................................................... 1977
5.3.3 Configuration Examples for IPv6 NG MVPN...................................................................................................... 1977
5.3.3.1 Example for Configuring an Intra-AS IPv6 NG MVPN with an mLDP P2MP LSP.........................................1977
5.3.3.2 Example for Configuring Inter-AS IPv6 NG MVPN Option B......................................................................... 1988
5.3.3.3 Example for Configuring Inter-AS IPv6 NG MVPN Option C......................................................................... 2001
5.3.3.4 Example for Configuring IPv6 NG MVPN Option B in an Inter-AS Seamless MPLS Scenario...................... 2012
5.3.3.5 Example for Configuring IPv6 NG MVPN Option C in an Inter-AS Seamless MPLS Scenario...................... 2026
5.4 IPv4 Multicast VPN Configuration Commands in NG MVPN Mode..................................................................... 2040
5.4.1 auto-discovery inter-as...........................................................................................................................................2041
5.4.2 c-multicast frr........................................................................................................................................................ 2042
5.4.3 c-multicast frr flow-detection-based......................................................................................................................2044
5.4.4 c-multicast signaling..............................................................................................................................................2045
5.4.5 display mvpn inter-region-segmented................................................................................................................... 2046
5.4.6 display mvpn ipmsi................................................................................................................................................2052
5.4.7 display mvpn spmsi............................................................................................................................................... 2055
5.4.8 export msdp........................................................................................................................................................... 2059
5.4.9 group (MVPN S-PMSI view)................................................................................................................................ 2060
5.4.10 holddown-time (MVPN S-PMSI view)............................................................................................................... 2064
5.4.11 import msdp......................................................................................................................................................... 2065
5.4.12 inter-area-segmented enable................................................................................................................................ 2067
5.4.13 ipmsi-tunnel......................................................................................................................................................... 2068
5.4.14 mldp (MVPN I-PMSI view)................................................................................................................................ 2069
5.4.15 mpls te (MVPN I-PMSI view).............................................................................................................................2070
5.4.16 multicast extranet select-rpf (MVPN)................................................................................................................. 2072
5.4.17 multicast mvpn.................................................................................................................................................... 2074
5.4.18 multicast mvpn (VPN instance IPv4 address family view)................................................................................. 2075
5.4.19 multicast mvpn inter-area-segmented enable...................................................................................................... 2076
5.4.20 multicast wtr........................................................................................................................................................ 2077
5.4.21 mvpn.................................................................................................................................................................... 2079
5.4.22 ng-mvpn forwarding-mode aggregation.............................................................................................................. 2080
5.4.23 p2mp-template (I-PMSI MPLS TE view)........................................................................................................... 2081
5.4.24 rpt-spt mode......................................................................................................................................................... 2083
Issue draft 04 (2019-05-20) Copyright © Huawei Technologies Co., Ltd. xx

5.4.25 rpt-prune-delay.................................................................................................................................................... 2085

5.4.26 sender-enable....................................................................................................................................................... 2086
5.4.27 spt-only mode...................................................................................................................................................... 2087
5.4.28 spmsi-tunnel.........................................................................................................................................................2089
5.4.29 switch-delay (MVPN S-PMSI view)................................................................................................................... 2091
5.4.30 tunnel-detect-delay (MVPN view)...................................................................................................................... 2093
5.4.31 tunnel-withdraw-delay.........................................................................................................................................2094
5.4.32 vpn-target (VPN instance IPv4 address family MVPN view).............................................................................2095
5.4.33 vrf-route-import compatible draft........................................................................................................................2098
5.5 IPv6 Multicast VPN Configuration Commands in NG MVPN Mode..................................................................... 2099
5.5.1 c-multicast signaling (IPv6)...................................................................................................................................2099
5.5.2 display mvpn ipv6 ipmsi........................................................................................................................................2101
5.5.3 display mvpn ipv6 spmsi....................................................................................................................................... 2104
5.5.4 group (IPv6 MVPN S-PMSI view)....................................................................................................................... 2106
5.5.5 holddown-time (IPv6 MVPN S-PMSI view).........................................................................................................2110
5.5.6 ipmsi-tunnel (IPv6)................................................................................................................................................ 2111
5.5.7 mldp (IPv6 MVPN I-PMSI view)..........................................................................................................................2112
5.5.8 mpls te (IPv6 MVPN I-PMSI view)...................................................................................................................... 2114
5.5.9 multicast ipv6 mvpn...............................................................................................................................................2115
5.5.10 multicast ipv6 mvpn apply-label explicit-null..................................................................................................... 2116
5.5.11 mvpn (IPv6)......................................................................................................................................................... 2117
5.5.12 p2mp-template (IPv6 I-PMSI MPLS TE view)...................................................................................................2119
5.5.13 rpt-spt mode (IPv6)..............................................................................................................................................2121
5.5.14 rpt-prune-delay (IPv6)......................................................................................................................................... 2123
5.5.15 sender-enable (IPv6)............................................................................................................................................ 2124
5.5.16 spt-only mode (IPv6)........................................................................................................................................... 2125
5.5.17 spmsi-tunnel (IPv6)............................................................................................................................................. 2127
5.5.18 switch-delay (IPv6 MVPN S-PMSI view).......................................................................................................... 2129
5.5.19 tunnel-detect-delay (IPv6 MVPN view)..............................................................................................................2130
5.5.20 tunnel-withdraw-delay (IPv6)..............................................................................................................................2132
5.5.21 vpn-target (VPN instance IPv6 address family MVPN view).............................................................................2133
5.5.22 vrf-route-import compatible draft (IPv6).............................................................................................................2135
6 Telemetry.................................................................................................................................. 2138
6.1 Telemetry.................................................................................................................................................................. 2138
6.1.1 Overview of Telemetry.......................................................................................................................................... 2138
6.1.2 Understanding Telemetry.......................................................................................................................................2139
6.1.2.1 Service Process of Telemetry Static Subscription.............................................................................................. 2139
6.1.2.2 Service Process of Telemetry Dynamic Subscription.........................................................................................2141
6.1.2.3 Key Telemetry Technologies.............................................................................................................................. 2142
6.1.3 Application Scenarios for Telemetry..................................................................................................................... 2150
6.1.3.1 Telemetry Applications in a Traffic Adjustment Scenario................................................................................. 2150
6.1.3.2 Telemetry Application in a Microburst Traffic Detection Scenario................................................................... 2151
Issue draft 04 (2019-05-20) Copyright © Huawei Technologies Co., Ltd. xxi

6.1.4 Terminology for Telemetry....................................................................................................................................2152

6.2 Telemetry Configuration...........................................................................................................................................2152
6.2.1 Overview of Telemetry.......................................................................................................................................... 2152
6.2.2 Licensing Requirements and Limitations for Telemetry....................................................................................... 2154
6.2.3 Configuring Telemetry Static Subscription........................................................................................................... 2159
6.2.3.1 Configuring a Destination Collector...................................................................................................................2159
6.2.3.2 Configuring the Data to Be Sampled or a Customized Event............................................................................ 2160
6.2.3.3 Creating a Subscription...................................................................................................................................... 2162
6.2.3.4 Verifying the Telemetry Configuration...............................................................................................................2164
6.2.4 Configuring Telemetry Dynamic Subscription......................................................................................................2165
6.2.5 Configuration Examples for Telemetry................................................................................................................. 2167
6.2.5.1 Example for Configuring Telemetry Static Subscription Based on gRPC......................................................... 2167
6.2.5.2 Example for Configuring Telemetry Static Subscription Based on UDP...........................................................2169
6.2.5.3 Example for Configuring Telemetry Dynamic Subscription Based on gRPC................................................... 2171
6.3 Telemetry Configuration Commands....................................................................................................................... 2172
6.3.1 acl (gRPC server view)..........................................................................................................................................2172
6.3.2 destination-group (Subscription view).................................................................................................................. 2174
6.3.3 destination-group (Telemetry view)...................................................................................................................... 2175
6.3.4 display telemetry destination................................................................................................................................. 2176
6.3.5 display telemetry dynamic-subscription................................................................................................................ 2178
6.3.6 display telemetry sensor........................................................................................................................................ 2180
6.3.7 display telemetry sensor-path................................................................................................................................ 2183
6.3.8 display telemetry subscription............................................................................................................................... 2185
6.3.9 dscp........................................................................................................................................................................ 2187
6.3.10 grpc...................................................................................................................................................................... 2189
6.3.11 grpc client............................................................................................................................................................ 2189
6.3.12 grpc server........................................................................................................................................................... 2190
6.3.13 idle-timeout (gRPC server view)......................................................................................................................... 2191
6.3.14 ipv4-address.........................................................................................................................................................2192
6.3.15 local-source-address ipv4 (UDP).........................................................................................................................2194
6.3.16 local-source-address ipv4 (gRPC)....................................................................................................................... 2195
6.3.17 protocol (Subscription view)............................................................................................................................... 2196
6.3.18 sensor-group (subscription view)........................................................................................................................ 2198
6.3.19 sensor-group (Telemetry view)............................................................................................................................2200
6.3.20 sensor-path...........................................................................................................................................................2201
6.3.21 sensor-path self-defined-event.............................................................................................................................2204
6.3.22 server enable........................................................................................................................................................ 2207
6.3.23 server-port............................................................................................................................................................2208
6.3.24 source-ip.............................................................................................................................................................. 2209
6.3.25 ssl-policy (gRPC client view).............................................................................................................................. 2211
6.3.26 ssl-policy (gRPC server view)............................................................................................................................. 2212
6.3.27 ssl-verify peer (gRPC client view)...................................................................................................................... 2213
Issue draft 04 (2019-05-20) Copyright © Huawei Technologies Co., Ltd. xxii

6.3.28 ssl-verify peer (gRPC server view)..................................................................................................................... 2214

6.3.29 subscription..........................................................................................................................................................2216
6.3.30 telemetry.............................................................................................................................................................. 2217
Issue draft 04 (2019-05-20) Copyright © Huawei Technologies Co., Ltd. xxiii

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 network topology, bandwidth
usage, and delay information and computes an explicit path that satisfies the service
requirements.
Issue draft 04 (2019-05-20) Copyright © Huawei Technologies Co., Ltd. 1

Figure 1-1 Service-driven network

High
bandwidth
Low A
latency Controller
P
Less I EMS/NMS
packet loss
NF BG
T CO PC
P LS
NE EP EP
PC
Low-latency path High-bandwidth path
Low-packet-loss-
rate path
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:
l Extends existing protocols such as IGP to allow for better smooth evolution of live
networks.
l 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.
l Uses the source routing technique to provide capabilities of rapid interaction between
networks and upper-layer applications.
Benefits
Segment routing offers the following benefits:
l 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.
l 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.
l Provides the higher network capacity expansion capability.
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.
l Better smooth 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 networks 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:
l Segment routing domain: is a set of SR nodes.
l Segment ID (SID): uniquely identifies a segment. A SID is mapped to an MPLS label on
the forwarding plane.
l SRGB: A segment routing global block (SRGB) is a set of local labels reserved for
segment routing of users.
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.

Label Generation Function

Mode
Adjacency Allocated by Identifies an adjacency on a network.

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

Segment configured. 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
101 102 103

1001 1003 16003
16001
10.1.1.0/24 10.3.1.0/24
1002
Prefix SID: 16001, 16002, 16003

16002
Adjacency SID: 1001, 1002, 1003
10.2.1.0/24
Node SID: 101, 102, 103
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 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.
l 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.
l 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 lean 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

100 100 100
B D F
Cost:1 Cost:1
100
Cost:1 Cost:1
A Primary Z
Loopback
path
Cost:10 Cost:10 Cost:10 X.X.X.X
Secondary Prefix SID=100
path
Cost:2 Cost:2
Cost:2 Cost:2
C E G
If there are several paths have 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.
Figure 1-4 Adjacency segment-based forwarding path

2004
4005 4005
5007 5007
1002 7009 7009
2004 B D F
4005 2004
5007
7009 1002
A Z
4005
5007
7009
C E G
5007
7009 7009

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

101
4005 4005
100 100
B D Node F
101
4005 SID=101
100
A Z
Pop
4005
Loopback
X.X.X.X
Prefix SID=100
C E G
100 100
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.
Label Conflicts and Handling Rules

Prefix segments are manually configured. These settings on different devices may conflict
with one another. Label conflicts are as follows:
l Prefix conflict: The same prefix is associated with two different SIDs.
l SID conflict: The same SID is associated with different prefixes.
If label conflicts occur, handle prefix conflicts before SID conflicts and use the following
rules 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):
l a. 1.1.1.1/32 1
l b. 1.1.1.1/32 2
l c. 2.2.2.2/32 3

l d. 3.3.3.3/32 1
The process of handling the label conflicts is as follows:
1. Prefix conflicts are handled. Routers a and b lead to a prefix conflict. Route a has a
smaller SID than route b. Route a is preferred. After the conflict is handled, the
following three routes are selected:
– 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 lead to a SID conflict. Route a has a smaller
prefix than route d, route a is preferred. After the conflict is handled, the following two
routes are selected:
– a. 1.1.1.1/32 1
– c. 2.2.2.2/32 3
1.1.2.2 SR LSP
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-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:
l Devices report topology information to a controller (if the controller is used to create a
tunnel) and are assigned labels.
l 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

SRGB SRGB SRGB SRGB
[20000-23999] [26000-65535] [36000-65535] [16000-65535]
A B C D Loopback
X.X.X.X
1 1 1 Prefix SID=100
4 3 2
Label: 20100 Label: 26100 Label: 36100
Label: 16100
OuterLabel: 26100 OuterLabel: 36100 OuterLabel: 16100
1 Distribute Prefix SID and SRGB
2 3 4 Compute Label and Outerlabel

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 Dev Operation
e ice
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).
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-TE operates labels by pushing, swapping, or popping them.
l 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.
l 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.
l Pop: After the packets leave out of an SR-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

Label: 20100 Label: 26100 Label: 36100
Label: 16100
OuterLabel: 26100 OuterLabel: 36100 OuterLabel: 16100
A B C D
1 2 3 4
Push Swap Swap Pop
26100 36100 16100

Payload Payload Payload Payload Payload
Table 1-3 describes the data forwarding process on the network shown in Figure 1-7.
Table 1-3 Packet forwarding process

St Dev Operation
e ice
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 forwards
the packet.
3 C Receives the labeled packet, swaps label 36100 for label 16100, and forwards
the packet.
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 resources
supported. The EXP field is processing is on the egress
egress assigns reserved. QoS normal. are saved. If
an explicit-null is supported. E2E services
label. The IPv4 carry QoS
explicit-null attributes to be
label value is 0. contained in the
EXP field in a
label, an
explicit-null can
be used.
implicit-null PHP is There is no There is no The forwarding

supported. The MPLS EXP MPLS TTL burden on the
egress assigns field on the field on the egress is
an implicit-null egress, and QoS egress, so it reduced, and
label. The is not cannot be forwarding
implicit-null supported. copied to the IP efficiency is
label value is 3. TTL field. improved.
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.

Label Type Description MPLS EXP MPLS TTL on Scenario

(QoS) on the the Egress
Egress
non-null PHP is not The MPLS The MPLS TTL Using a non-
supported. The EXP field is processing is null label
egress assigns a reserved. QoS normal. consumes a
common label is supported. great number of
to a penultimate resources on the
hop. egress and is
not
recommended.
The non-null
label helps the
egress identify
various types of
services.
1.1.2.2.1 SR and LDP Communication
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.
l Mapping server: supports mapping between prefixes and SIDs and advertises the
mapping to a mapping client.
l 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
SRGB SRGB SRGB Loopback

[16000-65535] [26000-65535] [36000-65535] x.x.x.x
PE1 P1 P2 P3 PE2
1 LDP assigns a
2 LDP assigns a label upstream.
label upstream.
3 Creates an LDP LSP to PE2.
Configures a mapping server

4
With the prefix of x.x.x.x.
6 5
Advertises the Advertises the
Mapping TLV. Mapping TLV.
Creates an SR LSP
7
to P2.
Creates the mapping
8
between SR and LDP LSP.
The process of creating an E2E SR-to-LDP LSP is as follows:

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

Loopback x.x.x.x
PrefixSID=100
SRGB SRGB SRGB
[16000-65535] [26000-65535] [36000-65535]
PE1 P1 P2 P3 PE2
1 Advertises a
prefix and a SID. 2 Advertises a
prefix and a SID.
3 Creates an SR LSP to PE1.
4 Configure proxy LDP egress.
5 LDP assigns a LDP assigns a

label upstream. label upstream.
Create mapping Create an LDP LSP
6
between SR and the to P2.
7
LDP 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.
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 SID. l IS-IS Extended IPv4

TLV Reachability TLV-135
l IS-IS Multitopology IPv4
Reachability TLV-235
l IS-IS IPv6 IP Reachability
TLV-236
l IS-IS Multitopology IPv6 IP
Reachability TLV-237
l ...
Adj-SID Sub-TLV Advertises SR Adjacency l IS-IS Extended IS reachability

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

Sub-TLV SIDs on a LAN. TLV-22
l IS-IS IS Neighbor Attribute
TLV-23
l IS-IS inter-AS reachability
information TLV-141
l IS-IS Multitopology IS TLV-222
l IS-IS Multitopology IS 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 Binding Advertises a mapping IS-IS LSP

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

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

TLV algorithm.
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
0 7 15 23 31
Type Length Flags Algorithm
SID/Index/Label (variable)
Table 1-6 Meanings of fields in the Prefix-SID Sub-TLV

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

Flags 8 bits Flags field. Figure 1-11 shows its format.
Figure 1-11 Flags field
Flags
R N P E V L
The meaning of each flag is as follows:

l 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).
l 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.
l P: no-PHP flag. If this flag is set, PHP is disabled so that
the penultimate node sends a labeled packet to the egress.
l 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.
l 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 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:
l 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.
l If the P 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, 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:

l 0: Shortest Path First
l 1: Strict Shortest Path First
SID/Index/ Variable This field contains either of the following information based
Label length on the V and L flags:
(variable) l 4-byte label offset value, within an ID/label range. In this
case, V and L flags are not set.
l 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
0 7 15 23 31
Type Length Flags Weight
SID/Label/Index (variable)
Table 1-7 Meanings of fields in the Adj-SID Sub-TLV


Flags
F B V L S P

l F: address family flag.
– 0: IPv4
– 1: IPv6
l B: backup flag. If the flag is set, an Adj-SID is used to
protect another node.
l V: value flag. If this flag is set, an Adj-SID carries a label
value. The flag is set by default.
l L: local flag. If this flag is set, the Adj-SID value or index
is of local significance. The flag is set by default.
l S: sequence flag. If this flag is set, an Adj-SID is an
adjacency sequence.
l 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) l 3-byte local label: The rightmost 20 bits are a label value.
l 4-byte label offset value, within an ID/label range. In this
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.
Figure 1-14 shows the format of the LAN-Adj-SID Sub-TLV.

Figure 1-14 LAN-Adj-SID Sub-TLV format
0 7 15 23 31
Type Length Flags Weight
System-ID
(6 octets)
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
0 7 15 23 31
Type Length
SID/Label (variable)
Table 1-8 Meanings of fields in the SID/Label Sub-TLV
SID/Label Variable If the Length field value is set to 3, the rightmost 20 bits
(variable) length 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
0 7 15 23 31
Type Length Flags Reserved
Range Prefix Length Prefix
Prefix (continued, variable)
SubTLVs (variable)

Table 1-9 Meanings of fields in the SID/Label Binding TLV

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
0 7 15 23 31
Type Length Flags
Range
SID/Label Sub-TLV (variable)
Table 1-10 Meanings of fields in the SR-Capabilities Sub-TLV


Flags
I V

l I: MPLS IPv4 flag. If the flag is set, SR MPLS IPv4
packets received by all interfaces can be processed.
l V: MPLS IPv6 flag. If the flag is set, SR MPLS IPv6
packets received by all interfaces can be processed.
Range 8 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 included.
Sub-TLV length When multiple SRGBs are configured, ensure that the SRGB
(variable) 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.

Figure 1-19 SR-Algorithm Sub-TLV format
0 7 15 23 31
Type Length
Algorithm 1 Algorithm 2 Algorithm ... Algorithm n
Table 1-11 Meanings of fields in the SR-Algorithm Sub-TLV

Algorithm 8 bits Algorithm.
IS-IS SR LSP Creation

An intra-IGP-area SR LSP is created.
In Figure 1-20, 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-20 IS-IS SR LSP creation
SRGB SRGB
[26000-65535] [36000-65535]
Device B Device C
SRGB SRGB
[16000-23999] [16000-65535]
Device D
Device A Loopback X.X.X.X
Prefix SID=100
Device E Device F
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-21, to establish an inter-area SR LSP, the prefix SID must be advertised across
areas by penetrating these areas. This overcomes the restriction on IS-IS's flooding scope
within each area.
Figure 1-21 Inter-IGP area SR LSP
SRGB SRGB
[26000-65535] [36000-65535]
Device B Device C
Level-1/2 Level-1/2
SRGB SRGB
[16000-23999] [16000-65535]
Device D
Area2 Level-1
Device A Loopback X.X.X.X
Area1 Level-1 Prefix SID=100
Device E Device F
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-12 describes TLVs of the OSPF SR extension.
Table 1-12 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.

Type Item Function Position
SRMS Advertises the priority of Type 10 Opaque LSA

Preference TLV SR mapping server as
which a local NE
functions
Sub-TLV SID/Label Sub- Advertises SR SIDs or l SID/Label Range TLV

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

TLV 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-22 shows the format of the SR-Algorithm TLV.
Figure 1-22 SR-Algorithm TLV format
0 7 15 23 31
Type Length
Algorithm 1 Algorithm 2 Algorithm ... Algorithm n
Table 1-13 Fields in the SR-Algorithm TLV
Type 16 bits TLV type value.

Algorithm 8 bits Algorithm.
SID/Label Range TLV

The SID/Label Range TLV is used to advertise multiple SIDs or labels at a time, or a SID or
label range.
Figure 1-23 shows the format of the SID/Label Range TLV.
Figure 1-23 SID/Label Range TLV format
0 7 15 23 31
Type Length
Range Size Reserved
Sub-TLVs (variable)
Table 1-14 Fields in the SID/Label Range TLV

Range Size 24 bits SRLG range.
Reserved 8 bits Reserved field.
Sub-TLV Variable The SID/Label Sub-TLV is mainly involved. The start value
(variable) length 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-24 shows the
format of the SRMS Preference TLV.
Figure 1-24 SRMS Preference TLV format
0 7 15 23 31
Type Length
Preference Reserved

Table 1-15 Fields in the SRMS Preference TLV
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-25 shows the format of the
SID/Label Sub-TLV.
Figure 1-25 SID/Label Sub-TLV format
0 7 15 23 31
Type Length
SID/Label (variable)
Table 1-16 Field in the SID/Label Sub-TLV
SID/Label Variable If the Length field value is set to 3, the 20 rightmost bits
(variable) length 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-26.
Figure 1-26 Prefix-SID Sub-TLV format
0 7 15 23 31
Type Length
Flags Reserved MT-ID Algorithm
SID/Index/Label (variable)

Table 1-17 Fields in the Prefix-SID Sub-TLV


Flags
NP M E V L

l NP: no-PHP flag. If this flag is set, PHP is disabled so that
the penultimate node sends a labeled packet to the egress.
l M: Mapping server flag. If the flag is set, a SID is
advertised by a mapping server.
l 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.
l 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 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:
l 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.
l 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, 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:

l 0: Shortest Path First
l 1: Strict Shortest Path First
(variable) l 4-byte label offset value, within an ID/label range. In this
l 3-byte local label: The 20 rightmost bits are a label value.
Adj-SID Sub-TLV
An Adj-SID Sub-TLV is optional and carries IGP Adjacency SID information. Figure 1-28
shows its format.
Figure 1-28 Adj-SID Sub-TLV format
0 7 15 23 31
Type Length
Flags Reserved MT-ID Weight
Table 1-18 Field in the Adj-SID Sub-TLV


Flags
B V L G P

l B: backup flag. If the flag is set, an Adj-SID is used to
protect another node.
l 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 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.
l G: group flag. If this flag is set, an Adj-SID is an
adjacency group.
l 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) l 3-byte local label: The 20 rightmost bits are a label value.
l 4-byte label offset value, within an ID/label range. In this
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-30 shows the format of the LAN-Adj-SID Sub-TLV. Compared with the Adj-SID
Sub-TLV, the LAN Adj-SID Sub-TLV has an additional Neighbor ID field that represents the
router ID of a device that advertises the LAN Adj-SID Sub-TLV.

Figure 1-30 LAN-Adj-SID Sub-TLV format
0 7 15 23 31
Type Length
Flags Reserved MT-ID Weight
Neighbor ID
1.1.2.5 SR-TE
SR-Traffic Engineering (SR-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-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-TE tunnel. Therefore, the label stack is used to control the path
along which packets are transmitted on a network.
SR-TE Advantages
SR-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-19 describes the comparison between SR-TE and RSVP-TE.
Table 1-19 Comparison between SR-TE and RSVP-TE tunnels

Item SR-TE RSVP-TE
Label The extended IGP assigns and MPLS allocates and distributes labels.
allocatio distributes labels. Each link is Each LSP is assigned a label, which
n assigned only a single label, and all consumes a great number of labels
LSPs share the label, which reduces resources and results in heavy
resource consumption and workloads maintaining label
maintenance workload of label forwarding tables.
forwarding 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.
Scalabilit High scalability. Tunnel information Poor scalability. It needs to maintain

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

Item SR-TE RSVP-TE
Path A service path can be controlled by Whether it is a normal service

adjustme operating a label only on the ingress. adjustment or a passive path
nt and Configurations do not need to be adjustment of a fault scenario, the
control delivered to each node, which configurations must be delivered to
improves programmability. each node.
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-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-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:
l A forwarder runs IGP to collect network topology information and uses BGP-LS to
report the information to the controller.
l Both the controller and forwarders run IGP. Each forwarder floods network topology
information to one another. Each forwarder reports the information to the controller.
Label Allocation Modes

A forwarder runs an IGP to assign labels and runs a BGP LS to report label information to a
controller. SR-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-31, 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-31 IGP label assignment
Controller
P1 P2
BGP LS
PE1 9005 9006 PE2
9004
9003
9007
If1 If2
9002
P3 P4
Label：9002
Out Interface: If1 Label allocation by forwarders
NextHop: P4 Reporting label and topology
information
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-31, 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 information, including SR labels,
and reports topology information to the controller.
1.1.2.5.2 SR-TE Tunnel Establishment
SR-TE Tunnel
Segment Routing Traffic Engineering (SR-TE) runs the SR protocol and uses TE constraints
to create a tunnel.

Figure 1-32 SR-TE Tunnel
P1 P2
PE1 PE2
SR-TE Tunnel
P3 P4
Primary LSP
Backup LSP
In Figure 1-32, 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-TE tunnel. The LSP originates from the ingress, passes through transit
nodes, and is terminated at the egress.
SR-TE tunnel establishment involves configuring and establishing an SR-TE tunnel. Before
an SR-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-TE tunnel so
that a forwarder runs CSPF to compute a path.
SR-TE Tunnel Configuration

SR-TE tunnel attributes are used to create tunnels. An SR-TE tunnel can be configured on a
controller or a forwarder.
l An SR-TE tunnel is configured on a controller.
The controller runs NETCONF to deliver tunnel attributes to a forwarder (as shown in
Figure 1-33). The forwarder runs PCEP to delegate the tunnel to the controller for
management.
l An SR-TE tunnel is manually configured on a forwarder.
The forwarder delegates LSPs to the controller for management.
SR-TE Tunnel Establishment

If a service (for example, VPN) is bound to an SR-TE tunnel, a device establishes an SR-TE
tunnel based on the following process, as shown in Figure 1-33.

Figure 1-33 Networking for SR-TE tunnels established using configurations that a controller
runs NETCONF to deliver to a forwarder
Controller
1
BGP-LS 1005
1009
2 1010
NETCONF PCEP P1 P2
1005
1005
4
100 04 100
1080
PE1 1 0 8 PE2
ISIS
3 1006 1009
1009
1003 100 10
1006 1030 10 10
3 10
100 1007
1007
P3 P4
Uses BGP-LS to report labels and topology information.

Uses NETCONF to deliver tunnel configurations.
Users PCEP to deliver a label stack and report the LSP status.
SR-TE LSP
The process of establishing an SR-TE tunnel is as follows:

1. The controller uses SR-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-33, the controller calculates a path PE1->P3->P1->P2->P4->PE2 for an SR-
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-33, the process of delivering label stacks on the controller is as follows:
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-TE tunnel.

NOTE
An SR-TE tunnel does not support MTU negotiation. Therefore, the MTUs configured on nodes along
the SR-TE tunnel must be the same. If an SR-TE tunnel is created manually, set an MTU value on the
tunnel interface or use the default MTU of 1500 bytes. On the manual SR-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-TE Data Forwarding

A forwarder operates a label in a packet based on the label stack mapped to the SR-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-TE Data Forwarding (Adjacency)

In Figure 1-34, an example is provided to describe the process of forwarding SR-TE data
with manually specified adjacency labels.
Figure 1-34 SR-TE data packet forwarding (based on adjacency labels)

Controller
1005
1009 1009
1010 1010
Payload Payload
PCEP
C D G
1005
1004 1008
A 1011
1006 1009
1003 1003 1010

1006
1007
100 B E F
Payload 1006 1010 Payload
100 Payload
Payload
Delivers the label stack to the
ingress and stitching node.
SR-TE LSP
In Figure 1-34, the SR-TE path calculated by the controller is A -> B -> C -> D -> F -> E.
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-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-
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-TE.
SR-TE Data Forwarding (Node+Adjacency)

SR-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-TE paths.
The node+adjacency mixed label stack can be manually specified. With this stack used, the
inter-node node labels can be set. The controller runs PCEP or NETCONF to deliver the stack
to the forwarder ingress, and forwarders use the label stack to forward packets through
outbound interfaces to the destination IP address of an LSP.

Figure 1-35 SR-TE forwarding principles (node+adjacency)

Controller
101(node)
Payload
1005(adj)
PCEP
101(node)
101(node)
C D Payload G
Payload 1005
1008
1004
A 101(node) Payload 1011

1006 1009
Payload
1003(adj)
1006(adj) 1003 1010
1005(adj) 1007 Payload

101(node) B E F
1006(adj) 101
1005(adj) Delivers the label stack to the
101(node) ingress and loadblance node.
Payload SR-TE LSP
On the network shown in Figure 1-35, 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-TE.
1.1.2.5.4 SR-TE Tunnel Reliability

SR-TE tunnel reliability techniques include hot standby (HSB), in addition to TI-LFA FRR.

SR-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-36, 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-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-TE tunnel remains Up.
Figure 1-36 SR-TE HSB networking
SID List 1
1001
103
305
507 C 103 E 305 G 507 I
710
1001 710
Payload to B
A SR-TE Tunnel B
SID List 2
1002 1002 810
204
204 406 608
406 D F H J
608
810 Adjacency SID Primary LSP
Payload to B
Hot-Standby LSP
1.1.2.5.5 BFD for SR-TE

SR-TE does not use a protocol. Once a label stack is delivered to an SR-TE node, the node
establishes an SR-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-TE LSP. A fault detected by BFD triggers a primary/backup SR-TE LSP
switchover. BFD for SR-TE is an E2E rapid detection mechanism that rapidly detects faults in
links of an SR-TE tunnel. BFD for SR-TE modes are as follows:
l BFD for SR-TE LSP: SR-TE LSPs rely on BFD for link detection. If a BFD session has
not been established when an SR-TE LSP is created, the LSP remains Down. To prevent
traffic loss in the case of a primary SR-TE LSP failure, BFD for SR-TE LSP can be
configured, but a backup LSP must be available. BFD for SR-TE LSP supports both
static and dynamic BFD sessions:
– 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-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-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-TE LSP and switches traffic to the backup
SR-TE LSP.
l BFD for SR-TE tunnel: BFD for SR-TE tunnel must be used with BFD for SR-TE LSP.
– BFD for SR-TE LSP controls the status of the primary/backup LSP switchover.
BFD for SR-TE tunnel checks actual status of tunnels.
n If BFD for SR-TE tunnel is not configured, the default tunnel status keeps Up,
and the effective status cannot be determined.
n If BFD for SR-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.
n BFD for SR-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-TE tunnel keeps consistent with the status of BFD for
SR-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.
l BFD for SR-TE (one-arm mode): A Huawei device on the ingress cannot use BFD for
SR-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-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-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 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-TE LSP, in the scenario where BFD
for SR-TE LSP is used.

Figure 1-37 BFD for SR-TE

Link header
9004
9003
9005
A E
VPN label P1 P2 Link header
IP header IP header
Payload Payload
CE1 PE1 PE2 CE2

PE1->P4: 9004 P3->PE2: 9005
BFD Link header
Link header
9003 P4->P3: 9003 VPN label
9005 IP header
VPN label Payload
IP header P4 Link header P3
Payload 9005
Primary SR-TE LSP
VPN label
Backup SR-TE LSP
IP header
Payload BFD Session
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-
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-TE tunnel. If BFD enters the DetectDown state, the
VPN recurses to another SR-TE tunnel.
1.1.2.5.6 DSCP-based Tunneling for IP Packets to Enter SR-TE Tunnels
Background
Devices can divert packets to SR-TE tunnels with matching differentiated services codepoints
(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. DSCP-based forwarding takes effect only on SR-TE tunnels.
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-TE tunnels and supports more refined priority
management (0 to 63) so that SR-TE can be more flexibly deployed based on services.
Implementation
DSCP values can be specified on the tunnel interface of a tunnel to which services recurse so
that the tunnel carries services of one or more priorities. Services with specified priorities can
only be transmitted on such tunnels, not be load-balanced by all tunnels to which they may
recurse. The service class attribute of a tunnel can also be set to "default" so that the tunnel
transmits mismatching services with other priorities that are not specified.
Figure 1-38 illustrates DSCP-based tunneling. SR-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:
l Set the DSCP attribute for the SR-TE tunnel. Assume that the DSCP attributes of SR-TE
tunnels are 15 through 20, 5 through 10, and default.
l Based on traffic characteristics of video services (DSCP value in IP packets), the PE
maps video traffic to SR-TE1 and voice traffic to SR-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-TE3.
NOTE
The default DSCP attribute is not a mandatory setting. If the default attribute is not configured,
mismatching services will be transmitted along a tunnel that is assigned no DSCP attribute. If such
a tunnel does not exist, these services will be transmitted along a tunnel that is assigned the
smallest DSCP value.
Figure 1-38 DSCP-based tunneling for IP packets
SR-TE 1
DSCP 15-20
SR-TE 2
DSCP 5-10
LSRA LSRB
SR-TE 3
DSCP default
Usage Scenario
l SR-TE tunnel load balancing on the public network, LDP over SR-TE, or SR-TE tunnels
(non-load balancing) are configured on a PE.
l IP/L3VPN, including IPv4 and IPv6 services, is configured on a PE.
l In the VLL, VPLS, and BGP LSP over SR-TE scenarios, DSCP-based tunneling for IP
packets is not supported.
l This function is not supported on a P.

1.1.2.6 BGP for SR
IGP for SR allocates SIDs only within an autonomous system (AS) domain. Properly
orchestrating SIDs in the AS domain helps plan an optimal path in the AS domain. IGP for
SR, however, does not work if paths have to cross multiple AS domains to build a large-scale
network. BGP for SR is an extension of BGP for segment routing. BGP for SR allocates BGP
peer SIDs based on BGP peer information and reports the SID information to the controller.
SR-TE uses BGP peer SIDs in path orchestration to obtain the optimal path for an inter-AS
E2E SR-TE tunnel. BGP for SR includes 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 network controller. If a forwarder does not establish a BGP-LS peer relationship with
the controller, the forwarder runs BGP-LS to advertise a peer SID to a BGP peer that
establishes a BGP-LSP peer relationship with the controller. The BGP peer then runs BGP-LS
to advertise the peer SID to the network controller. In Figure 1-39, BGP EPE allocates the
peer node segment (peer-node SID) and peer adjacency segment (peer-Adj SID) to peers.
l A peer-node SID identifies a node on which a peer is configured. Each BGP session is
assigned a peer-node SID. An EBGP peer relationship established based on loopback
interfaces may pass through multiple physical links. In this case, the peer-node SID of
the peer is mapped to multiple outbound interfaces. Traffic can be forwarded through any
outbound interface or be balanced by multiple outbound interfaces.
l A peer-Adj SID identifies an adjacency to a peer. An EBGP peer relationship established
based on loopback interfaces may pass through multiple physical links. In this case, each
adjacency is assigned a peer-Adj SID. Only a specified link (mapped to a specified
outbound interface) is used for forwarding.

Figure 1-39 BGP EPE networking
Controller
AGG1 ASBR3
CSG1 ASBR1
IGP area 2
AS 65002 PE1
IGP area 1
AS 65001 ASBR4
ASBR5
IGP area 3
CSG2 ASBR2
AS 65003
PE2
AGG2 BGP EPE
Uses BGP-LS to report labels and network

topology information
Uses NETCONF to deliver tunnel configurations
Uses PCEP to deliver the label stack and report
LSP status
In Figure 1-39, two directly connected physical links exist between ASBR1 and ASBR3. An
EBGP peer relationship is established between the loopback interfaces of ASBR1 and
ASBR3. ASBR1 runs BGP EPE to assign a peer-node SID of 28001 to its peer (ASBR3) and
peer-Adj SIDs of 18001 and 18002 to the physical links. For an EBGP peer established
between directly connected physical interfaces, BGP EPE allocates a peer-node SID, not peer-
Adj SIDs. In Figure 1-39, BGP EPE allocates only peer-node SIDs of 28002, 28003, and
28004 in the ASBR1-ASBR5, ARBR2-ASBR4, ASBR2-ASBR5 peer relationships,
respectively.
Peer-node SIDs and peer-Adj SIDs are local labels and are valid on local devices. The peer-
node SIDs and peer-Adj SIDs of different devices can be identical. 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.
BGP EPE merely assigns SIDs to BGP peers and links, but is not used to construct a
forwarding tunnel. BGP peer SIDs must be used with IGP SIDs to establish an E2E tunnel.
IPv4 SR primarily establishes SR LSPs and SR-TE tunnels.
l An SR LSP is dynamically calculated by a forwarder using intra-AS IGP SIDs. Peer
SIDs that are assigned by BGP EPE cannot be used by an IGP. Therefore, inter-AS SR
LSPs cannot be supported.
l SR-TE establishes an E2E tunnel by statically specifying a path or being orchestrated by
the network controller. The specified path must contain inter-AS link information.

BGP-LS
BGP-LS reports SIDs to the controller. Inter-AS E2E SR-TE tunnels can be established
through static explicit paths or orchestrated by controllers. In a controller orchestration
scenario, intra- and inter-AS SIDs are reported to the controller using BGP-LS. In addition,
TE link attributes must be configured for inter-AS links and reported to the controller. The
controller calculates the primary and backup paths based on the SR-TE tunnel attributes. For
the network topology discovered and label information allocated by BGP EPE, BGP-LS
packages the information into the link network layer reachability information (NLRI) field
and reports it to the controller. Figure 1-40 shows the link NLRI format.
Figure 1-40 Link NLRI (Peer-Node and Peer-Adj) released by BGP-LS
Peer-Node SID Peer-Adj SID
NLRI NLRI
LocalDescriptor LocalDescriptor
RemoteDescriptor RemoteDescriptor
LinkDescriptor LinkDescriptor
LinkAttribute LinkAttribute
Peer-Node SID Peer-Adj SID
Administrative Group
Max Link BW
Max Reservable Link BW
Unreserved BW
Shared Risk Link Group
Table 1-20 Description of link information fields

Field Definition
NLRI Network layer reachability information.

l LocalDescriptor: local description,
which consists of a local router ID, a
local AS number, and a BGP-LS ID
l RemoteDescriptor: remote description,
which consists of a peer router ID and a
peer AS number
l LinkDescriptor: link description,
including addresses used by a BGP
session

Field Definition
LinkAttribute Link information, which is a part of a link

NLRI:
l Peer-Node SID: peer-node SID TLV
l Peer-Adj SID: peer-Adj SID TLV
l Administrative Group: link management
group attribute
l Max Link BW: maximum link
bandwidth, in kbit/s
l Max Reservable Link BW: maximum
link reservable bandwidth, in kbit/s
l Unreserved BW: remaining link
bandwidth
l Shared Risk Link Group: shared risk link
group (SRLG)
A peer-node SID TLV and a peer-Adj SID TLV have the same format. Figure 1-41 shows the
peer SID TLV format.
Figure 1-41 Peer SID TLV format
0 7 15 23 31
Type Length
Flags Weight Reserved
Table 1-21 Meanings of fields in a peer SID TLV

Type 16 bits TLV type.

Flags 8 bits Flags field. It is contained in a peer-Adj SID TLV. Figure

1-42 shows its format.
Figure 1-42 Flags field.
Flags
V L
The description of each flag bit is as follows:

l V: value flag. If this bit is set to 1, an Adj-SID carries a
label value. This bit is set to 1 by default.
l L: local flag. If this flag is set to 1, the value or index
carried in an Adj-SID is of local significance. This bit is
set to 1 by default.
Weight 8 bits Weight. It indicates the Adj-SID weight, which can be used
for load balancing.
SID/Index/ Variable According to the V and L flags, one of the following content
Label length may be included:
(variable) l A 3-byte local label. The rightmost 20 bits indicate a label
value. In this case, both V and L flags must be set to 1.
l A 4-byte label index, which is the offset within an SRGB
range.
1.1.2.7 Inter-AS E2E SR-TE
1.1.2.7.1 Binding SID
Similar to RSVP-TE tunnels, SR-TE tunnels can be used as forwarding adjacencies. If an SR-
TE tunnel is used as a forwarding adjacency and assigned an adjacency SID (Adj-SID), the
Adj-SID identifies the SR-TE tunnel and is used to import data traffic into the SR-TE tunnel,
implementing a TE policy. The Adj-SID of the SR-TE tunnel is called a binding SID. Traffic
that uses the binding SID is bound to an SR-TE tunnel or a TE policy.
Binding SIDs are set on forwarders within an AS domain. Each binding SID represents an
intra-AS SR-TE tunnel. In Figure 1-43, a binding SID is set on the ingress within an AS
domain.
l Set binding SIDs to 6000 and 7000 on CSG1, representing label stacks {102, 203} and
{110, 112, 213}, respectively.
l Set a binding SID to 8000 on ASBR3 to represent a label stack {405, 506}.
l 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-TE tunnel
using the binding SIDs and BGP peer SIDs. A static explicit path can be configured so that an

inter-AS E2E SR-TE tunnel is established over the path. In Figure 1-43, the label stacks of
the primary and backup LSPs in an inter-AS E2E SR-TE are {6000, 3040, 8000} and {7000,
3140, 9000}, respectively. The complete label stacks are {102, 203, 3040, 405, 506} and
{110, 112, 113, 3140, 415, 516, 660}.
Figure 1-43 Binding SID schematic diagram
E2E SR-TE tunnel label stack
Backup 110
Primary
102 SR-TE 112
SR-TE
6000 203 7000 213
3040 3040
8000 405 9000 415
506 516
660
AGG1
P1
102 203
CSG1 ASBR1 ASBR3 405 506 PE1
3040
110 IGP Domain 1 BGP EPE IGP Domain 2 660

AS 100 AS 200
3140
ASBR2 ASBR4 415 516 PE2
CSG2
P2
112 213
Primary LSP in an Binding SID Peer-Adj SID

E2E SR-TE tunnel
Backup LSP in an Adjacency SID
E2E SR-TE tunnel
A binding SID is associated with a local forwarding path by specifying a local label, and is
used for NE forwarding and encapsulation. Using biding BIDs reduces the number of labels
in a label stack on an NE, which helps build an inter-AS E2E SR-TE network.
1.1.2.7.2 E2E SR-TE Tunnel Creation
E2E SR-TE Tunnel Configuration

E2E SR-TE tunnel attributes are used to create tunnels. An E2E SR-TE tunnel can be
configured on a controller or a forwarder.
l Configure tunnels on the controller.
After an E2E SR-TE tunnel is configured on the controller, the controller runs
NETCONF to deliver tunnel attributes to a forwarder (as shown in Figure 1-44). The
forwarder runs PCEP to delegate the tunnel to the controller for management.

l 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-TE tunnel. Manual E2E SR-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-TE Tunnel Establishment

If a service (for example, VPN) needs to be bound to an SR-TE tunnel, a device establishes an
E2E SR-TE tunnel based on the following process, as shown in Figure 1-44. In the following
example, the tunnel configuration on the controller is described.
Figure 1-44 E2E SR-TE Tunnel Establishment
E2E SR-TE
tunnel label stack
Primary 2 Controller
SR-TE 102
6000 203
3040 3
3
8000 405
506 1
4
AGG1
P1
102 203
3040

AS 100 AS 200
3140
CSG2
P2
112 213
Uses BGP-LS to report labels Uses PCEP to deliver the label

and network topology information stack and report LSP status
Uses NETCONF to deliver E2E SR-TE tunnel

tunnel configurations
The process of creating a tunnel is as follows:

1. Before creating an E2E SR-TE tunnel, the controller needs to create an SR-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-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-44, the controller calculates an SR-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-44, the process of delivering label stacks on the controller is as follows:
a. The controller delivers the label stacks {102, 203} and {405, 506} within the AS
domain to the ingress CSG1 and ASBR3, respectively.
b. The controller delivers the E2E SR-TE tunnel label stack {6000, 3040, 8000} to
CSG1 that is the ingress of an inter-AS E2E SR-TE tunnel.
4. CSG1 establishes an inter-AS E2E SR-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-TE Tunnel
A forwarder operates a label in a packet based on the label stack mapped to the SR-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.
In Figure 1-45, the controller calculates an SR-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-45 Data forwarding on an E2E SR-TE tunnel
102
203
3040 405
8000 506
Payload Payload
6000 203
3040 3040 3040
8000 8000 8000 8000 506
Payload Payload Payload Payload Payload Payload
AGG1
P1
102 203
3040

AS 100 AS 200
3140
CSG2
P2
112 213
E2E SR-TE tunnel
The E2E SR-TE data packet forwarding process is as follows:

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

Hot standby (HSB) is supported by E2E SR-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-46, HSB is configured on the ingress CGS1. After CSG1 creates the primary LSP,
it immediately creates an HSB LSP. An SR-TE tunnel contains two LSPs. If the ingress
detects a primary LSP fault, the ingress switches traffic to the HSB LSP. After the primary
LSP recovers, the ingress switches traffic back to the primary LSP. During the process, the
SR-TE tunnel remains Up.
Figure 1-46 E2E SR-TE HSB networking
Label stack of the CSG1-to- Label stack of the CSG1-to-PE1

PE1 E2E primary SR-TE LSP E2E hot-standby SR-TE LSP
415
102 516
6000 203 7000 660
3040 3140
8000 9000 415
405
Payload Payload 516
506
660
AGG1
P1
102 203
3040

AS 100 AS 200
3140
CSG2
P2
112 213
Primary E2E SR-TE LSP

Hot-Standby E2E SR-TE LSP
In Figure 1-46, the controller calculates a path CSG1->AGG1->ASBR1->ASBR3->P1->PE1

for the primary LSP of an E2E SR-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-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-TE Tunnel Protection

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

CSG2
P2
AGG2
Intra-AS SR-TE hot standby Intra-AS SR-TE hot standby

(BFD/SBFD for SR-TE LSP) (BFD/SBFD for SR-TE LSP)
E2E SR-TE hot standby (one-arm BFD for primary E2E SR-TE LSP)
VPN FRR (one-arm BFD for E2E SR-TE tunnel)
Intra-AS hot-standby
Primary E2E SR-TE LSP
E2E SR-TE LSP
Hot-Standby E2E SR-TE LSP
1.1.2.7.5 One-Arm BFD for E2E SR-TE
E2E SR-TE does not use a protocol to establish tunnels. Once a label stack is delivered to an
SR-TE node, the node establishes an SR-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-TE LSP. A fault detected by BFD triggers a primary/
backup SR-TE LSP switchover. BFD for E2E SR-TE is an E2E rapid detection mechanism

that rapidly detects faults in links of an SR-TE tunnel. BFD for E2E SR-TE modes are as
follows:
l One-arm BFD for E2E SR-TE LSP: When an E2E SR-TE LSP is established and a BFD
session fails to be negotiated, the SR-TE LSP cannot go Up. BFD for E2E SR-TE LSP
rapidly triggers a primary/HSB LSP switchover if the primary LSP fails.
l BFD for E2E SR-TE tunnel: The E2E SR-TE tunnel status is monitored using both BFD
for E2E SR-TE tunnel and BFD for E2E SR-TE LSP.
– BFD for E2E SR-TE LSP controls the primary/HSB LSP switchover and
switchback status, whereas BFD for E2E SR-TE tunnel controls the effective status
of a tunnel. If BFD for E2E SR-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-TE tunnel keeps consistent with the status of
BFD for E2E SR-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-48, the implementation of one-arm BFD for E2E SR-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-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-TE tunnel on the
ingress.

Figure 1-48 One-arm BFD for E2E SR-TE (BFD loopback packets are forwarded through a
tunnel.)
102
203
3040 405
8000 506 BFD packet carries
BFD pkt BFD pkt the binding SID of
6000 203 the reverse tunnel
3040 3040 3040
8000 8000 8000 8000 506
BFD pkt BFD pkt BFD pkt BFD pkt BFD pkt BFD pkt
504 8100
4030 4030 4030
201 6100 6100 6100 6100
605
504
302 3040
1. Enable one- 201 6100
arm BFD to BFD pkt BFD pkt
monitor tunnel1.
2. Set a binding
201 AGG1 302
504 P1 605 SID for tunnel2 and
102 203 direct BFD packets
3. Bind BFD 4030
CSG1 ASBR1 ASBR3 405 506 PE1 to tunnel2.
to tunnel2's 3040
binding SID.
660
110 IGP Domain 1 IGP Domain 2
AS 100 BGP EPE AS 200 661
111
3140
ASBR2 415 516 PE2
CSG2 4130 ASBR4
112 213 514 P2 615
211 AGG2 312
One-arm BFD packet E2E SR-TE tunnel1
Binding SID Reverse E2E SR-TE tunnel2
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-TE tunnel, the forwarding plane removes the
MPLS label from the BFD packet and associates it with the reverse SR-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-TE tunnel and looped back to the ingress through the transit node
along the SR-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-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-49.

Figure 1-49 One-arm BFD for E2E SR-TE (BFD loopback packets are forwarded over IP
links.)
102
203
3040 405
8000 506
BFD pkt BFD pkt
6000 203
3040 3040 3040
8000 8000 8000 8000 506
The reverse tunnel
Enable one-arm is unavailable.
BFD to monitor BFD packets are
tunnel1. 201 AGG1 302 forwarded over IP
504 P1 605 routes.
102 203
4030
3040
660
110 IGP Domain 1 IGP Domain 2
AS 100 BGP EPE AS 200 661
111
3140
ASBR2 415 516 PE2
CSG2 4130 ASBR4
112 213 514 P2 615
211 AGG2 312
One-arm BFD
E2E SR-TE tunnel1
packets
Binding SID Reverse IP link
1.1.2.7.6 Cross-Multi-AS E2E SR-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-50, the network is connected to three AS domains. If PE1 establishes an E2E SR-
TE network over a multi-hop explicit path to PE3, the traffic path from AS y to AS z can be
determined in AS x. AS y and AS z, however, may belong to different management
organizations than AS x. In this situation, the traffic path may not be accepted by AS y or AS
z, and the great depth of the label stack decreases forwarding efficiency. AS y and AS z may
be connected to a controller different than AS x, leading to a difficult in establishing an E2E
SR-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-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-
TE tunnel from AS x to AS z.

Figure 1-50 Cross-multi-AS E2E SR-TE
Controller
ASBR1 ASBR3 ASBR5 ASBR7 PE3

PE1
AS x AS y AS z
PE2 ASBR6 ASBR8 PE4

ASBR2 ASBR4
IGP area 1 BGP EPE IGP area 2 BGP EPE IGP area 3
SR-TE tunnel BGP peer SR-TE tunnel BGP peer SR-TE tunnel
(Binding SID1) SID2 (Binding SID3) SID4 (Binding SID5)
Inter-AS E2E SR-TE tunnel1(AS y->z)

(Binding SID3 + peer SID4+ Binding SID5)
(Binding SID6)
Inter-AS E2E SR-TE tunnel2 (AS x->z)

(Binding SID1 + peer SID2 + Binding SID6)
The process of hierarchically establishing a cross-multi-AS E2E SR-TE tunnel is as follows:

1. Layer 1: Establish an E2E SR-TE tunnel from AS y to AS z. Create an SR-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-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-TE tunnel from AS x to AS z. Create an SR-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 peer SID2. The controller establishes
a unidirectional inter-AS E2E SR-TE Tunnel2 from AS x to AS z using binding SID1,
peer SID2, and binding SID6.
An E2E SR-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-TE Tunnel2, and the SID
participates in path computation. Repeat the preceding process to construct an E2E SR-TE
tunnel that spans more AS domains.
1.1.2.8 Importing Traffic
After an SR LSP or SE-TE tunnel is established, service traffic needs to be imported to the SR
LSP or SR-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-22 Support for tunnels

Traffic Direction SR LSP SR-TE Tunnel
Mode/Tunnel
Type
Static route No tunnel interface is available. A tunnel interface is available.

Therefore, you can configure a A static route can direct traffic
static route to specify the next to an SR-TE tunnel.
hop, 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, whereas a sequence method or a tunnel
tunnel binding policy cannot be binding policy can be used.
used.
Auto route No tunnel interface is available. A tunnel interface is available.

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

Routing Therefore, policy-based routing policy-based routing can direct
cannot be used to direct traffic traffic to an SR-TE tunnel.
to SR 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-TE tunnel work in the same way as common static routes. When
configuring a static route, set the outbound interface of a static route to an SR-TE tunnel
interface so that traffic transmitted over the route is directed to the SR-TE tunnel.
Tunnel Policy
By default, VPN traffic is forwarded through LDP LSPs, not SR LSPs or SR-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-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:
l Select-seq mode: This policy changes the type of tunnel selected for VPN traffic. An SR
LSP or SR-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.
l Tunnel binding mode: This policy defines a specific destination IP address, and this
address is bound to an SR-TE tunnel for VPN traffic to guarantee QoS.
Auto Route
An IGP uses an auto route related to an SR-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:
l Forwarding shortcut: The node does not advertise an SR-TE tunnel to its neighbor nodes.
The SR-TE tunnel can be involved only in local route calculation, but cannot be used by
the other nodes.
l Forwarding adjacency: The node advertises an SR-TE tunnel to its neighbor nodes. The
SR-TE tunnel is involved in global route calculation and can be used by the other nodes.
NOTE
l Forwarding shortcut and forwarding adjacency are mutually exclusive, and cannot be used
simultaneously.
l 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-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-TE
tunnel interface used as an outbound interface. If packets do not match PBR rules, they are
properly forwarded using IP; if they match PBR rules, they are forwarded over specific
tunnels.
1.1.2.8.1 Public IP Routes Recursive to an SR Tunnel
Public Network BGP Route Recursive to an SR Tunnel

If an Internet user performs IP forwarding to access the Internet, core devices on a forwarding
path must learn many Internet routes. This imposes a heavy load on the core devices and
deteriorates their performance. To tackle the problems, a user access device can be configured
to recurse non-labeled public network BGP or static routes to a segment routing (SR) tunnel.
User packets travel through the SR 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-51, the deployment of public network BGP route recursive to an SR LSP is as
follows:
l 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.
l A BGP peer relationship between PEs is established to enable the PEs to learn the peer
routes.
l A BGP route recurses to an SR LSP on each PE.

Figure 1-51 Public network BGP route recursive to an SR LSP
SRGB SRGB SRGB SRGB

[16000-65535] [26000-65535] [36000-65535] [16000-65535]
PE1 P1 Segment P2 PE2 Loopback
Routing X.X.X.X
Prefix SID=100
Internet BGP
Push Swap Swap
Pop
26100 36100 16100
IP head IP head IP head IP head IP head
In Figure 1-52, the deployment of public network BGP route recursive to an SR-TE tunnel is
as follows:
devices, and segment routing is configured on PEs and Ps. An SR-TE tunnel is
established between PEs.
l A BGP peer relationship between PEs is established to enable the PEs to learn the peer
routes.
l Configure a tunnel policy on the PE to make the BGP service route iterate over the SR-
TE tunnel at PE1.
Figure 1-52 Public network BGP route recursive to an SR-TE tunnel
PE1 P1 P2 PE2
9001 9002 9003
Segment
Routing
Internet
Pop BGP
9002
Pop
9003 9003
9001
Push Pop
9002
9003
IP head
Payload
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-53, the deployment of static route recursive to an SR LSP is as follows:

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

[16000-65535] [26000-65535] [36000-65535] [16000-65535]
Routing X.X.X.X
Prefix SID=100
Internet
Push Swap Swap
Pop
26100 36100 16100
In Figure 1-54, the deployment of static route recursive to an SR-TE tunnel is as follows:
devices, and segment routing is configured on PEs and Ps. PE1 establishes an SR-TE
tunnel destined for PE2's loopback IP address.
l A static route is configured on PE1. The next-hop IP address is set to PE2's loopback IP
address.
l Configure a tunnel policy on the PE to allow the PE to iterate to the SR-TE tunnel. After
receiving the IP packet, PE1 encapsulates the packet with SR-TE tunnel labels and then
forwards the packet.

Figure 1-54 Static route recursive to an SR-TE tunnel
PE1 P1 P2 PE2
9001 9002 9003
Segment
Routing
Internet Pop
9002
Pop
9003 9003
9001
Push Pop
9002
9003
IP head
Payload
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-55 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:
l An IS-IS neighbor relationship is established between each pair of directly connected
devices on the public network to implement route reachability.
l A BGP peer relationship is established between the two PEs to learn peer VPN routes of
each other.
l The PEs establish an IS-IS SR LSP to assign public network labels and compute a label
switched path.
l BGP is used to assign a private network label, for example, label Z, to a VPN instance.
l VPN routes recurse to the SR LSP.
l 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-55 Basic VPN recursive to an SR LSP
SRGB SRGB SRGB SRGB

[16000-65535] [26000-65535] [36000-65535] [16000-65535]
Routing X.X.X.X
Prefix SID=100
CE1 CE2
Swap BGP
Push
26100 36100 Pop (PHP)
Label Z Label Z Label Z

The network shown in Figure 1-56 consists of inconsecutive L3VPN subnets with a backbone
network in between. PEs establish an SR-TE tunnel to forward L3VPN packets. PEs run BGP
to learn VPN routes. The deployment is as follows:
l An IS-IS neighbor relationship is established between each pair of directly connected
devices on the public network to implement route reachability.
l A BGP peer relationship is established between the two PEs to learn peer VPN routes of
each other.
l The PEs establish an IS-IS SR-TE tunnel to assign public network labels and compute a
label switched path.
l BGP is used to assign a private network label, for example, label Z, to a VPN instance.
l A tunnel policy is configured on the PE to allow the private network route to be iterated
to the SR-TE tunnel.
l 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-56 Basic VPN recursive to an SR-TE tunnel
PE1 P1 P2 PE2
9001 9002 9003
Segment
CE1 Routing CE2
BGP
Pop
9002
Pop
9003 9003
Label Z Label Z Label Z
9001
Push Pop
9002
9003
Label Z
IP head
Payload
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-57 HVPN recursive to an SR LSP
SRGB SRGB
[16000-65535] Lv Lu [16000-65535]
L4 L3
UPE SPE NPE
Payload Payload
SRGB
Payload [16000-65535] Payload
CE2
CE1
VPN1 VPN1
Site 1 Site 2
In Figure 1-57, the deployment is as follows:

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

l 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-58, 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-58 VPN FRR networking
PE1 P1 P3 PE3
LSP1
LSP2
CE1 CE2
LSP3
PE2 P2 P4 PE4

Table 1-23 Typical fault-triggered switching scenarios

Faulty Point Protection Switching
P1-to-P3 link failure PE1 does not support BFD for SR-BE and
cannot detect an LSP Down event. As a
result, PE2 cannot perform VPN FRR
switching to switch traffic to PE4 along
LSP3 over a path in Figure 1-58.
After IS-IS/OSPF FRR is configured, P1
performs FRR switching to switch traffic to
LSP2 over the path PE1->P1->P2->P4->P3-
>PE3, shown in Figure 1-58.
PE3 node failure If PE3 fails, traffic on LSP1 cannot be

switched to an FRR backup path, and LSP2
cannot converge. PE1 uses IS-IS/OSPF
protocol packets to detect the PE3 fault and
performs path convergence. Then the LSP
goes Down, and BGP switches traffic to
LSP3 along the path PE1->PE2->P2->P4-
>PE4, shown in Figure 1-58.
1.1.2.8.3 L2VPN Recursive to an SR Tunnel

Figure 1-59 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-59, the process of recursing VPLS services to an SR LSP is as follows:
l CE1 sends a packet with Layer 2 encapsulation to PE1.
l PE1 establishes an E2E SR LSP to PE2.
l A tunnel policy is configured on PE1 to select the SR LSP, and the VSI forwarding
entries are associated with the SR forwarding entries.
l 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.
l Upon receipt of the packet, PE2 decapsulates the packet.
l PE2 forwards the original packet to CE2.

Figure 1-59 VPLS recursive to an SR LSP
SRGB SRGB SRGB SRGB

[16000-65535] [16000-65535] [16000-65535] [16000-65535]
PE1 P1 P2 PE2
Loopback
X.X.X.X
Prefix SID=100
CE1 Push Swap CE2

Pop (PHP) VPN1
VPN1 L2 head L2 head
Site1 Site2
16100 16100 L2 head
VC Label VC Label VC Label
L2 head L2 head L2 head L2 head L2 head
AC
PW
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-TE Tunnel

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

Figure 1-60 VPLS recursive to an SR-TE tunnel
9001 9002 9003

PE2
PE1
CE1 CE2
Pop
L2 head Pop
VPN1 VPN1
9002 L2 head
Site1 Site2
9003 9003 L2 head
VC Label VC Label VC Label
L2 head L2 head L2 head L2 head L2 head
L2 head
Push Pop
9001
9002 AC
9003
VC Label PW
L2 head
SR-TE
IP head
Payload
The process of recursing HVPLS services to an SR-TE tunnel is similar to that of recursing
VLL and VPLS services to an SR-TE tunnel. The process is not described.
1.1.2.8.4 EVPN Iterated 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 Iterated to an SR LSP

In Figure 1-61, 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.

Figure 1-61 Unicast traffic transmission in EVPN recursive to an SR LSP scenario
SRGB SRGB SRGB SRGB

[16000-65535] [16000-65535] [16000-65535] [16000-65535]
PE1 P1 P2 PE2
Loopback
X.X.X.X
Prefix SID=100
SR LSP
CE1 CE2
Push Swap EVPN1
EVPN1
Pop (PHP) Site2
Site1 16100 16100
Private Label Private Label Private Label
L2 Payload L2 Payload L2 Payload L2 Payload L2 Payload
EVPN Iterated to an SR-TE Tunnel

In Figure 1-62, after the PEs learn the MAC addresses of VPN sites and establish a public
network SR-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-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-62 Unicast traffic transmission in EVPN recursive to an SR-TE tunnel scenario
PE1 9001 P1 9002 P2 9003 PE2
SR-TE
CE1 CE2
Pop
EVPN1
9002 EVPN1
Pop
Site1 9003 9003 Site2
Private Label Private Label Private Label
L2 Payload L2 Payload L2 Payload L2 Payload L2 Payload
Push 9001 Pop

9002
9003
Private Label
L2 Payload
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-63 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.
l 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.
l 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-63 SBFD principles
Initiator Reflector
SBFD Control packet
SBFD Control packet
SBFD Echo packet
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-64 shows the SBFD state machine running on the initiator.

Figure 1-64 SBFD initial state machine
Admin Down,
Timer Up
Up
Down Up
Admin Down,
Timer
l Initial state: The initiator sets the initial state to Down in an SBFD packet to be sent to
the reflector.
l 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.
l 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 and SBFD for SR-TE LSP 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-65.
Assume that the SRGB scope [16000-16100] is set on each PE and P on the network shown in
Figure 1-65. 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. When A
sends packets destined for E and the packets arrive at PE1, PE1 adds a VPN label into the
packets based on the VPN to which the packets belong, recurses the packets to an SR LSP
based on the destination IP address carried in the packets, adds an SR label of 16100, and
forwards the packets hop by hop along the path PE1->P4->P3->PE2.
After SBFD is configured, PE1 rapidly detects a fault and switch traffic to a backup SR LSP
once a link or P on the primary LSP fails.

Figure 1-65 SBFD for SR LSP networking
Link header
16100 Cost:10
A E
IP header Cost:10 Cost:10 IP header
Payload Loopback1 Payload
x.x.x.x
Prefix SID=100
CE1 PE1 PE2 CE2
Cost:1 Cost:1
SBFD Link header
Link header 16100
Cost:1
16100 VPN label
VPN label IP header
IP header P4 Link header P3 Payload
Payload 16100
Primary SR LSP
VPN label
IP header Backup SR LSP
Payload SBFD Detection
SBFD for SR-TE LSP

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

Figure 1-66 SBFD for SR-TE LSP networking

Link header
9004
9003
9005
A E
IP header IP header
Payload Payload
CE1 PE1 PE2 CE2

PE1->P4: 9004 P3->PE2: 9005
SBFD
Link header Link header
9003 P4->P3: 9003 VPN label
9005 IP header
VPN label Payload
IP header P4 Link header P3
Payload 9005
Primary SR-TE LSP
VPN label
Backup SR-TE LSP
IP header
Payload SBFD Detection
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-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-TE LSP once a link or P on the primary LSP fails.
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-24 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.

Concep Definition
t
Extende The extended P space contains nodes reachable to the root nodes on links, not
dP the protected link, along the SPF trees originating from the root nodes that are
space 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 node A PQ node resides in both the extended P space and Q space. The PQ 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 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-67, 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-67 RLFA networking
Device A 1 Device B 2 Device C

P
Cost: 10 space
3
Cost: 10 Cost: 1000
Q
Cost: 10 space
Device F Device E Device D
Faulty
Path before the fault
point
Path after the fault
TI-LFA can be used to solve this problem. In Figure 1-68, 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.
Figure 1-68 TI-LFA networking

103 New path
16001 information
106 106
IP head IP head Node
Payload Payload SID: 103
P
Cost: 10 space
Cost: 10 Cost: 1000

3
Adjacency
4 SID: 16001
Node Q
SID: 106 Cost: 10 space
Faulty
Path before the fault
point
Path after the fault
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-69, 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.
l Link protection: protects traffic passing through a specific link.
l Node protection: protects traffic passing through a specific node. Node protection takes
precedence over link protection.
Figure 1-69 Typical TI-LFA networking
PE3
10 P5 Q Space
40
39 P4
P1 40
20 SID: 9304
P3 Node SID:
15 100
10
20
PE1
P2
interface1 Extended
40 10
Repair List PE2 P Space
100
9304
Faulty Point
In the following example, the process of node protection is as follows. In Figure 1-69, 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-69,
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:

l A node SID advertised by the repair node is preferentially selected.
l The smallest prefix SID of a single source on a repair node is preferentially selected.
l A non-multiple-source prefix on a repair node is preferentially selected.
l 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-70, 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-70 TI-LFA FRR backup path forwarding
Prefix
SID=10
Device A Device B Device C
SRGB
Label 720 [600-700]
Label 130
Label 240 Label 610
Label 310 IP head
Payload
IP head
Payload Device E
SRGB
Device D [500-600]
SRGB
Label 510
[700-800]
Label 120 IP head
Label 130 Payload
Label 240
130 240
Label 310
IP head
Payload Device F Label 240 Device G Device H
SRGB Label 310 Label 310 SRGB
[100-200] IP head IP head [300-400]
Node SID=20 Payload Payload
Faulty
point

Table 1-25 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 list from
A 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 table based
D 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.
Device F Upon receipt of the packet, Device F searches the label forwarding 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 table based
G 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 table based
H 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-26 TI-LFA FRR protection usage scenarios

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

protects IP an IP routed primary path, relationship between each pair of
forwarding. and a TI-LFA FRR backup directly connected nodes on a
path is computed. network. Enable 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 Description Deployment

Protection
TI-LFA FRR Traffic is transmitted over a 1. Establish an IS-IS neighbor

protects traffic on a primary segment routing relationship between each pair of
segment routing tunnel, and a TI-LFA FRR directly connected nodes on a
tunnel. backup path is computed. network. Enable 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.
Anti-Micro-Loop Switchover
In Figure 1-71, 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-71 Anti-micro-loop switchover
Device D Device E
Device F Device G Device H
The path before Backup path

convergence
The path after Faulty point
convergence

Configure the anti-micro-loop switchover function on the source node.
The delayed route switchover must meet the following conditions:

l The interface directly connected to the local interface fails, or local BFD goes Down.
l No network topology change occurs during the delay time.
l A backup next hop for a route is available.
l The primary next hop of the route is the faulty interface.
l The primary and backup next hops are different after the path convergence is complete.
l During the delay of the multi-source route convergence, the route source change event
occurs, and the delay stops.
Anti-Micro-Loop Switchback
In Figure 1-72:
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-72 Anti-micro-loop switchback

1001
1003 1003
Payload Payload
Device A 3 Device B Device C
1001 1 1003 2
Faulty
Switchback path
node
Backup path
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.10.1 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-73, 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 label, 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 label device through the other protection
path. The anycast label 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-73 Anycast SID
Non-SR area
Device B Prefix SID index 11
Device D
Device A SR area
Device E
Device C Prefix SID index 11
Faulty
Before a fault occurs
point
Backup path after a
fault occurs
Anycast FRR
In anycast FRR, multiple nodes advertise the same prefix label. In other words, anycast FRR
is multi-source prefix label FRR. The common FRR algorithms use the SPT to compute the
backup next hops. This applies to single-source route scenarios but not to multi-source route
scenarios.
Before a device computes the backup next hop of a prefix label in a multi-source route
scenario, the multi-source route must be converted to a single-source route. Anycast FRR
constructs a virtual node to convert multi-source routes to single-source routes and uses the
TI-LFA algorithm to compute a backup next hop of the virtual node. The anycast prefix label

inherits the backup next hop from the created virtual node. This solution does not involve any
modification of the backup next hop algorithm. 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-74 IGP FRR networking in a multi-source route scenario
Prefix SID index 11/cost 0

Device B Device B
Virtual
Device A Device A Node
0 0
2 2
= =
t t
s s
o o
c c
Device C Device C
Prefix SID index 11/cost 0
(a) (b)
On the network shown in Figure 1-74 (a), the cost of Device A-to-Device B link is 5, and that
of Device A-to-Device C is 10. Device B and Device C advertise the route source of
10.1.1.0/24 simultaneously. TI-LFA FRR is enabled on Device A. Because the single-source
TI-LFA condition is not met, Device A cannot compute the backup next hop of the route
destined for 10.1.1.0/24. To address this problem, TI-LFA FRR in a multi-source route
scenario can be used. Implementation is as follows:
On the network shown in Figure 1-74 (b), 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. The virtual node advertises a prefix of 10.1.1.0/24,
converts the multi-source route to a single-source route, and uses TL-LFA to compute a
backup next hop to the virtual node. The multi-source route destined for 10.1.1.0/24 inherits
the computation result. On the network shown in Figure 1-74 (b), Device A computes two
links to the virtual node. The active link is Device A to Device B, and the standby link is
Device A to Device C.
1.1.2.11 SR OAM
SR Operation, Administration, and Maintenance (OAM) monitors LSP connectivity and

rapidly detects faults. SR OAM is implemented using ping and tracert.

SR-BE Ping
On the network shown in Figure 1-75, PE1, P1, P2, and PE2 are all capable of SR. An SR
LSP is established between PE1 and PE2.
Figure 1-75 SR-BE ping/tracert

16302
IP header
UDP header
MPLS ECHO
(request)
16202 [16200,16999] [16300,16999]
IP header IP header
UDP header UDP header
MPLS ECHO MPLS ECHO
P1 P2 (request)
(request)
IP header
UDP header
[16100,16999] MPLS ECHO
(response)
CE1 PE1 PE2 CE2
SR LSP
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-BE IPv4.
– If the specified tunnel type is not SR-BE IPv4, PE1 reports an error message
indicating a tunnel type mismatch and stops the ping test.
– If the specified tunnel type is SR-BE IPv4, the following operations are performed:
2. PE1 constructs an MPLS Echo Request packet encapsulating the outer label of the
initiator and carrying destination address 127.0.0.0/8 in the IP header of the packet.
3. PE1 forwards the packet to P1. After receiving the packet, P1 swaps the outer MPLS
label of the packet and forwards the packet to P2.
4. Similar to P1, P2 swaps the outer MPLS label of the received packet and determines
whether it is the penultimate hop. If yes, P2 removes the outer label and forwards the
packet to PE2. PE2 sends the packet to the Rx/Tx module for processing.
5. PE2 returns an MPLS Echo Reply packet to PE1 and generates the ping test result.
SR-BE Tracert
On the network shown in Figure 1-75, the process of initiating an SR-BE IPv4 tracert test
from PE1 is as follows:
1. PE1 initiates a ping test and checks whether the specified tunnel type is SR-BE IPv4.
– If the specified tunnel type is not SR-BE IPv4, PE1 reports an error message
indicating a tunnel type mismatch and stops the tracert test.

– If the specified tunnel type is SR-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-TE Ping
On the network shown in Figure 1-76, PE1, P1, and P2 all support SR. An SR-TE tunnel is
established between PE1 and PE2. The devices assign adjacency labels as follows:
l PE1 assigns adjacency label 9001 to PE1-P1 adjacency.
l P1 assigns adjacency label 9002 to P1-P2 adjacency.
l P2 assigns adjacency label 9005 to P2-PE2 adjacency.
Figure 1-76 SR-TE ping and tracert
9005
P2: IP header PE2:
9002 payload 9005
9002
9005
IP header P1 P2 IP header
payload payload
IP header IP header
payload payload
P1:
9001
CE1 PE1 PE2 CE2
SR-TE tunnel
The process of initiating an SR-TE ping test from PE1 is as follows:

1. PE1 initiates a ping test and checks whether the specified tunnel type is SR-TE.
– If the specified tunnel type is not SR-TE, PE1 reports an error message indicating a
tunnel type mismatch and stops the ping test.
– If the specified tunnel type is SR-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-TE Tracert
On the network shown in Figure 1-76, the process of initiating an SR-TE tracert test from
PE1 is as follows:
1. PE1 initiates a tracert test and checks whether the specified tunnel type is SR-TE.
– If the specified tunnel type is not SR-TE, PE1 reports an error message indicating a
tunnel type mismatch and stops the tracert test.
– If the specified tunnel type is SR-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. After receiving the packet, P1 determines 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,
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,
PE2.
5. P2 forwards the packet to PE2, and PE2 returns an MPLS Echo Reply packet to PE1.
1.1.3 Application Scenarios for Segment Routing MPLS
1.1.3.1 Single-AS SR

Single-AS Strict Explicit Path

In Figure 1-77, 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-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-77 Single-AS strict explicit path
PCE IGP flood

Controller
BGP-LS: collects network
topology and distributes
labels to forwarders
PCEP: delivers label stack
PCEP information to the ingress
BGP-LS
PCEP
Single-AS Loose Explicit Path

In Figure 1-78, 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.

Figure 1-78 Single-AS loose explicit path
Controller
BGP-LS/
NETCONF SR-TE path1
SR-TE path2
IGP
IDC 1 IDC 2
L3VPN over SR-TE
An L3VPN within the network carries DCI services in per tenant per VPN mode. Within a
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-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-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-79 illustrates the typical application of the inter-AS E2E SR-TE technology on a
bearer network. The overall service model is EVPN over SR-TE. An E2E SR-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.

Figure 1-79 Application of inter-AS E2E SR-TE on the bearer network
Controller
AGG1
CSG1 ASBR1 ASBR3 PE1 RNC
eNodeB
Access Aggregate Core
STB
ASBR2 ASBR4 PE2 IDC
CSG2 Server
Enterprise AGG2
AS x AS y
IGP Domain1 IGP Domain2 BGP EPE IGP Domain3
Control
Intra-AS SR-TE tunnel BGP Peer Intra-AS SR-TE
protocol tunnel
(Binding SID) SID
(Binding SID)
Inter-AS E2E SR-TE tunnel
Data
EVPN（VPLS/VPWS/L3VPN）
service
Intra-AS SR-TE HSB Intra-AS SR-TE HSB

(BFD/SBFD) (BFD/SBFD)
Reliability
E2E SR-TE HSB (one-arm BFD for primary E2E SR-TE LSP)
E2E SR-TE VPN FRR (one-arm BFD for E2E SR-TE tunnel)
Feature Deployment
When an inter-AS E2E SR-TE network is used to carry EVPN services, the service
deployment is as follows:
l Configure IGP SR within an AS domain to establish an intra-AS SR-TE tunnel and BGP
EPE between AS domains to assign inter-AS SIDs. Binding SIDs are used to combine
SR-TE tunnels in multiple AS domains into an inter-AS E2E SR-TE tunnel.
l 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-TE tunnel.
l In terms of reliability, intra-AS SR-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-TE tunnels are monitored by one-arm BFD. TE HSB is used to switch

traffic between the primary and HSB TE LSPs. VPN FRR is used to switch traffic
between the primary and HSB E2E SR-TE tunnels.
1.1.4 Terminology for Segment Routing MPLS
Terms
Term Definition
SR-BE Segment Routing Best Effort (SR-BE) uses an IGP to run the
shortest path algorithm to compute an optimal SR LSP.
SR-TE Segment Routing Traffic Engineering (SR-TE) runs the SR

protocol and uses TE constraints to create a tunnel.
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

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.
Segment routing offers the following benefits:
l 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.
l 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.
l Provides the higher network capacity expansion capability.
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.
l Better smooth 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 networks 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 Licensing Requirements and Limitations for Segment

Routing MPLS
Licensing Requirements
This feature is a basic feature and is not under license control.

Restrictions and Guidelines

Restrictions Guidelines Impact
Traffic over Segment None NetStream sampling on the

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

function is not supported on the bandwidth of the
Segment Routing tunnels delivered Segment Routing
using node SIDs. tunnels established using
node SIDs.
Local FRR protection is not Configure hot standby If hot standby is not
supported on Segment protection. configured and the primary
Routing tunnels using node LSP of a Segment Routing
SIDs. tunnel fails, traffic is
switched to the hot-standby
LSP only after convergence.
An SR-BE Prefix/Node SID If prefix SIDs conflict, the The labeled forwarding path
must be unique on an entire IGP mechanism can be used computation is affected.
network. The SID value to preferentially select a
must be within the SRGB prefix SID.
range.
A single binding sid (BSID) None No impact.

is configured for each
tunnel. Each BSID can be
referenced by only a single
tunnel.
After a BSID is configured None No impact.

for a tunnel and is
referenced by an explicit
path, the BSID of the tunnel
cannot be modified or
deleted.
When the outer label in the None No impact.

label stack of an SR-TE
explicit path is a BSID, the
maximum SID depth (MSD)
cannot exceed three.

If the first hop of an explicit None No impact.

path is assigned a BSID
(indicating that the tunnel
that references the explicit
path needs to be forwarded
through a tunnel assigned
the BSID), the first hop of
the explicit path used by the
tunnel assigned the BSID
cannot be assigned a BSID.
When a BSID label is Configure BFD. The tunnel is Up but fails to

configured for an explicit forward traffic, affecting
path, the system does not service traffic.
check whether the tunnel
mapped to the BSID 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.
If a BSID is configured for a None No impact.

tunnel and is referenced by
an explicit path, the tunnel
cannot be deleted.
If BFD is configured on the Configure a tunnel mapped A BFD session cannot go

ingress and the reverse BFD to the BSID on the egress to Up.
path is over a BSID tunnel ensure that the reverse BFD
but the tunnel mapped to the path can go Up.
BSID on the egress does not
exist, the BFD session goes
Down.

l For an inter-AS SR-TE Plan services properly. Services are interrupted.

tunnel in BSID mode, if
the number of labels in a
label stack exceeds three,
the tunnel cannot go Up.
l If a label is configured
for an inter-AS SR-TE
tunnel in BSID mode and
the label type is BSID,
the following functions
are not supported for the
tunnel: packet priority-
based mapping, statistics,
MTU, TTL, and so on
l For an SR-TE 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.
1.2.3 Configuring an IS-IS SR-BE Tunnel

This section describes the detail steps for configuring a SR-BE tunnel.
Usage Scenario
Creating an SR-BE tunnel involves the following operations:
Pre-configuration Tasks
Before configuring a manual SR-TE tunnel, complete the following tasks:
l Configure IS-IS to implement network layer connectivity for NEs.

l Set an LSR ID for each NE.
l Enable MPLS globally on all NEs.
1.2.3.1 Configuring Basic SR-BE Functions

This section describes how to configure basic SR-BE functions.

Context
Basic SR-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
The system view is displayed.
2. Run segment-routing
Segment routing is globally enabled, and the segment routing view is displayed.
3. Run commit
The configuration is committed.
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.2 (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 1 Run system-view
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:
l none: does not allow the ingress to use any routes to establish SR-LSPs.
l host: allows the ingress to use host routes with 32-bit masks to establish SR-LSPs.
l 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.3 (Optional) Configuring a Policy for Preferentially Selecting an SR-BE

Tunnel
A policy for preferentially selecting an SR-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-BE tunnel, improve the SR-BE
tunnel priority so that the SR-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-BE tunnels are configured to take precedence over LDP tunnels.
Step 4 Run commit
----End
1.2.3.4 Verifying the IS-IS SR-BE Tunnel Configuration

After configuring an SR-BE tunnel, verify the configuration of the SR-BE tunnel.
Prerequisites
The SR-BE functions have been configured.
Procedure
After completing the configurations, you can run the following command to check the
configurations.
l 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.
l 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-BE Tunnel

This section describes how to configure an OSPF SR-BE tunnel.
Usage Scenario
Creating an SR-BE tunnel involves the following operations:
Before configuring an SR-BE tunnel, complete the following tasks:
l Configure OSPF to implement the connectivity of NEs at the network layer.

l Set an LSR ID for each LSR.

l Enable MPLS globally on all LSRs.
1.2.4.1 Configuring Basic SR-BE Functions

This section describes how to configure basic SR-BE functions.
Context
Basic SR-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
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.
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.2 (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
configured. The policy allows the ingress to use only allowed routes to establish SR-LSPs.
Procedure
Step 2 Run ospf [ process-id ]
Step 3 Run segment-routing lsp-trigger { none | host | ip-prefix ip-prefix-name }
A policy for establishing LSPs is configured.
l host: allows the ingress to use host routes with 32-bit masks to establish SR-LSPs.
l ip-prefix: allows the ingress to use the routes that match an IP prefix list to establish SR-
LSPs.
l none: does not allow the ingress to use any routes to establish SR-LSPs.
Step 4 Run commit
----End
1.2.4.3 Configuring a Policy for Preferentially Selecting an SR-BE Tunnel

A policy for preferentially selecting an SR-BE tunnel is configured to allow a device to select
an SR tunnel, not an LDP tunnel.

Context
default. To enable a device to preferentially select an SR-BE tunnel, improve the SR-BE
tunnel priority so that the SR-BE tunnel takes preference over the LDP tunnel.
Procedure
Step 3 Run tunnel-prefer segment-routing
SR-BE tunnels are configured to take precedence over LDP tunnels.
Step 4 Run commit
----End
1.2.4.4 Verifying the OSPF SR-BE Tunnel Configuration

After successfully configure SR-BE, verify SR-BE configurations.
Prerequisites
All SR-BE functions have been configured.
Procedure
After completing the configurations, you can run the following commands to check the
configurations.
l 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-TE Tunnel (Path Computation on

the Controller)
An SR-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-TE can be used. It offers the following
benefits:
l A controller generates labels, which reduces the burden for the forwarder.

l 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-TE tunnel, complete the following tasks:
l Configure IS-IS to implement network layer connectivity for LSRs.
l Configure an IS-IS neighbor between the controller and forwarder. See Creating an IS-IS
Process and Enabling an IS-IS Interface.
NOTE
A controller must be configured to generate labels and calculate an LSP path for an SR-TE tunnel to be
established.
1.2.5.1 Enabling MPLS TE

Enabling MPLS TE on each node in an MPLS domain is the prerequisites for all TE features.
Procedure
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:
l LSR IDs must be set before other MPLS commands are run.
l No default LSR ID is available.
l 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 mpls te
MPLS TE is enabled globally.
Step 5 Run quit
Return to the system view.
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
SR is enabled globally.
Step 3 Run commit
----End
1.2.5.3 Configuring the IS-IS SR-TE Capability and Topology Report Function
Before an SR-TE tunnel is established, the IS-IS SR-TE capability and IS-IS topology report
function must be enabled.
Context
Before an SR-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-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-TE capability.
Perform the following steps on each node of an SR-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-TE is enabled.
NOTE
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.
Step 2 Configure a device to report topology information to the controller.
Perform the following steps on one or multiple nodes of an SR-TE tunnel:
NOTE
l 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.
l 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
multiple 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

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-TE Tunnel Interface

A tunnel interface must be configured on an ingress so that the interface is used to establish
and manage an SR-TE tunnel.

Procedure
Step 2 Run interface tunnel tunnel-number
A tunnel interface is created, and the tunnel interface view is displayed.
Step 3 Run either of the following commands to assign an IP address to the tunnel interface:
l 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.
l To configure the tunnel interface to borrow the IP address of another interface, run ip
address unnumbered interface interface-type interface-number
NOTE
The MPLS TE tunnel is unidirectional and does not need a peer IP address. A separate IP address for the
tunnel interface is not recommended. Use the LSR ID of the ingress as the tunnel interface's IP address.
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-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 { default | { dscp-value1 | to dscp-value2 ] } &<1-32> }
A DSCP value is set for IPv4 packets that enter an SR-TE tunnel.

The DSCP setting on an SR-TE tunnel interface is mutually exclusive with the service-class
command. If both of them are configured, an error message is displayed.
Step 11 Run commit
----End
1.2.5.5 (Optional) Configuring SR on a PCC

The SR capability is configured on a PCC. After a controller calculates a path and delivers
path information to the forwarder (PCC), the SR-enabled PCC can establish an SR-TE tunnel.
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).
NOTE
The path information can also be delivered by a third-party adapter to the forwarder. In this situation, SR
does not need to be configured on the PCC, and the following operation can be skipped.
Procedure
Step 2 Run pce-client
A PCC is configured, and the PCE client view is displayed.
Step 3 Run capability segment-routing
Step 4 Run connect-server ip-address
A candidate server is specified for the PCC.
Step 5 Run commit
----End
1.2.5.6 (Optional) Enabling a Device to Simulate an SR-TE Transit Node to

Perform Link Label-based Forwarding
An SR-TE-incapable device on an SR-TE network must be configured to simulate an SR-TE
transit node to perform link label-based forwarding.

Context
An SR-TE-incapable device on an SR-TE network can be configured to simulate an SR-TE
transit node to perform link label-based forwarding. The function resolves the forwarding
issue on the SR-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-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.7 Verifying the Configuration of an IS-IS SR-TE Tunnel (Path Computation

on the Controller)
After configuring an automatic SR-TE tunnel, verify information about the SR-TE tunnel and
its status statistics.
Prerequisites
The SR-TE tunnel functions have been configured.
Procedure
l 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 ] ]
l 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.
l Run the display mpls te tunnel statistics or display mpls sr-te-lsp command to check
LSP statistics.
l Run the display mpls te tunnel-interface [ tunnel tunnel-number ] command to check
information about a tunnel interface on the ingress.

l (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-TE Tunnel (Path Computation on

the Controller)
An SR-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-TE can be used. The manual SR-
TE tunnel technique offers the following benefits:
l A controller generates labels, which reduces the burden for the PCC (forwarder).
l 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-TE tunnel, complete the following tasks:
l Configure OSPF to implement LSR connectivity at the network layer.
l Configure an OSPF neighbor relationship between the controller and forwarder. See
create an OSPF process.
NOTE
A controller must be configured to generate labels and calculate an LSP path for an SR-TE tunnel to be
established.

Procedure

Step 3 Run mpls
Step 4 Run mpls te
Step 5 Run quit
Step 6 Run commit
----End
1.2.6.2 Globally Enabling the SR Capability

Context
Procedure
Step 3 Run commit
----End
1.2.6.3 Configuring the OSPF SR-TE Capability and Topology Report Function
Before an SR-TE tunnel is established, the OSPF SR-TE capability and OSPF topology report
function must be enabled.
Context
Before an SR-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-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-TE capability.
Perform the following steps on each node of an SR-TE tunnel to be established:
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 multiple nodes of an SR-TE tunnel:
NOTE
l 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.
l 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
multiple 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.
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
6. Run commit
----End

Procedure
l To configure the IP address of the tunnel interface, run ip address ip-address { mask |
mask-length } [ sub ]
l To configure the tunnel interface to borrow the IP address of another interface, run ip
address unnumbered interface interface-type interface-number
NOTE
A tunnel ID is set.

MPLS view.
Step 11 Run commit
----End

path information to the forwarder (PCC), the SR-enabled PCC can establish an SR-TE tunnel.
Context
NOTE
Procedure
Step 2 Run pce-client
A PCC is configured, and the PCE client view is displayed.
Step 3 Run capability segment-routing

Step 4 Run connect-server ip-address
A candidate server is specified for the PCC.
Step 5 Run commit
----End
1.2.6.6 (Optional) Enabling a Device to Simulate an SR-TE Transit Node to

Perform Link Label-based Forwarding
An SR-TE-incapable device on an SR-TE network must be configured to simulate an SR-TE
transit node to perform link label-based forwarding.
Context
An SR-TE-incapable device on an SR-TE network can be configured to simulate an SR-TE
transit node to perform link label-based forwarding. The function resolves the forwarding
issue on the SR-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-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.7 Verifying the Configuration of an OSPF SR-TE Tunnel (Path Computation

on the Controller)
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
----End
1.2.7 Configuring an IS-IS SR-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-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-TE.
Before configuring an IS-IS SR-TE tunnel, configure IS-IS to implement network layer
connectivity.

Procedure
Step 3 Run mpls

Step 4 Run mpls te
Step 5 Run quit
Step 6 Run commit
----End

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

This section describes how to configure basic SR-TE functions.
Context
SR-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-TE tunnel is configured, the
adjacency and node SIDs must be configured.
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.
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-TE Explicit Path

An explicit path over which an SR-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-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 as needed:

l To specify a next-hop label for the explicit path, run the next sid label label-value type
{ adjacency | prefix } command.
l 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.
NOTE
When you configure an explicit path for an SR-TE tunnel, the next sid label command and
the next hop command cannot be run at the same time.
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.
Step 4 Run commit
----End

Procedure
l To configure the IP address of the tunnel interface, run:
ip address ip-address { mask | mask-length } [ sub ]
l To configure the tunnel interface to borrow the IP address of another interface, run:
ip address unnumbered interface interface-type interface-number
NOTE

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.
MPLS view.
Step 11 Run commit
----End
1.2.7.6 Checking the Configurations

Prerequisites
Procedure
name ] ]
LSP statistics.
----End

1.2.8 Configuring an OSPF SR-TE Tunnel (Explicit Path Used)

If no controller is deployed to compute paths, an explicit path can be manually configured to
perform SR-TE.
Usage Scenario
deployed to compute paths, an explicit path can be manually configured to perform SR-TE.
Before configuring an OSPF SR-TE tunnel, configure OSPF to implement connectivity at the
network layer.

Procedure
Step 3 Run mpls
Step 4 Run mpls te
Step 5 Run quit
Step 6 Run commit
----End


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


Procedure
Step 2 Run explicit-path path-name
Step 3 Perform either of the following operations as needed:

l To specify a next-hop label for the explicit path, run the next sid label label-value type
{ adjacency | prefix } command.
l 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.
NOTE
When you configure an explicit path for an SR-TE tunnel, the next sid label command and
the next hop command cannot be run at the same time.
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.
Step 4 Run commit
----End

Procedure

NOTE
A tunnel ID is set.
command.
MPLS view.

Step 11 Run commit
----End

Prerequisites
Procedure
statistics.
----End
1.2.9 Configuring an IS-IS SR-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-TE.
Usage Scenario
deployed to compute paths, CSPF can be configured on the ingress to perform SR-TE.
Before configuring an IS-IS SR-TE tunnel, configure IS-IS to implement network layer
connectivity.


Procedure
Step 3 Run mpls
Step 4 Run mpls te
Step 5 Run quit
Step 6 Run commit
----End

Context
Procedure
Step 3 Run commit
----End


Context
Procedure
1. Run system-view
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-TE tunnel.
Procedure
Step 1 Run:
system-view
Step 2 Run:
mpls
Step 3 Run:
mpls te
MPLS TE is enabled.
Step 4 Run:
mpls te cspf
CSPF is enabled on the ingress to compute paths.
Step 5 Run:
commit
----End

Procedure

NOTE
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-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-TE tunnel.
MPLS view.
Step 11 Run commit
----End


Prerequisites
Procedure
name ] ]
LSP statistics.
----End
1.2.10 Configuring an OSPF SR-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-TE.
Usage Scenario
deployed to compute paths, CSPF can be configured on the ingress to perform SR-TE.
Before configuring an OSPF SR-TE tunnel, configure OSPF to implement connectivity at the
network layer.


Procedure
Step 3 Run mpls
Step 4 Run mpls te
Step 5 Run quit
Step 6 Run commit
----End

Context
Procedure
Step 3 Run commit
----End


Context
Procedure
1. Run system-view
6. Run area area-id
8. Run commit
1. Run system-view

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-TE tunnel.
Procedure
Step 1 Run:
system-view
Step 2 Run:
mpls
Step 3 Run:
mpls te
MPLS TE is enabled.
Step 4 Run:
mpls te cspf
CSPF is enabled on the ingress to compute paths.
Step 5 Run:
commit
----End

Procedure

NOTE
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-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-TE tunnel.
MPLS view.
Step 11 Run commit
----End


Prerequisites
Procedure
statistics.
----End
1.2.11 Configuring BGP SR

BGP SR allocates BGP peer SIDs. The controller orchestrates IGP SIDs and BGP peer SIDs
to implement inter-AS optimal path forwarding.
Context
The Border Gateway Protocol (BGP) is a dynamic routing protocol used between autonomous
systems (ASs). BGP SR is an extension of BGP for segment routing and is used to implement
source routing between ASs.
The BGP egress peer engineering (EPE) extension is used to allocate peer-node SIDs and
peer-Adj SIDs to peers. These SIDs can be reported to the controller using BGP-LS, and the
controller completes E2E SR-TE tunnel orchestration.
Procedure
l Configure BGP SR.
a. Run system-view
b. Run segment-routing
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.
f. Run peer ipv4-address egress-engineering
BGP EPE is enabled.
g. Run commit
l Configure BGP-LS.
BGP-LS is a network topology collection method, which enables topology collection to
be more simple and efficient. The BGP-LS capability must be configured on the
forwarders and controller to implement topology reporting. Perform the following steps
on a forwarder. The configuration of the forwarder is similar to that of the controller. The
configuration details on the controller are not provided.
a. Run system-view
b. Run bgp { as-number-plain | as-number-dot }
c. Run peer ipv4-address as-number as-number-plain
A BGP peer is created.
d. Run link-state-family unicast
BGP-LS is enabled, and the BGP-LS address family view is displayed.
e. Run peer { group-name | ipv4-address } enable
f. Run commit
----End
Verifying the BGP SR Configuration

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

Computation on the Controller)
An inter-AS E2E SR-TE tunnel can connect SR-TE tunnels in multiple AS domains to build a
large-scale TE network.
Usage Scenario
SR-TE, a new MPLS TE tunneling technology, has unique advantages in label distribution,
protocol simplification, large-scale expansion, and fast path adjustment. SR-TE can better
cooperate with SDN.

The SR that is extended through an IGP can implement SR-TE only within an AS domain. To
implement inter-AS E2E SR-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-80.
In addition, the label depth supported by an ordinary forwarder is limited, whereas the depth
of the label stack of an inter-AS SR-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-TE tunnel, set a binding SID for the tunnel.
The binding SID identifies an SR-TE tunnel and replaces the label stack of an SR-TE tunnel.
Figure 1-80 Inter-AS E2E SR-TE tunnel networking
Controller
AGG1
RNC
CSG1 ASBR1 ASBR3 PE1
IGP Domain 1 BGP EPE IGP Domain 2

AS 100 AS 200
ASBR2 ASBR4 PE2 Server

CSG2
AGG2
SR-TE Tunnel 1 Peer SID SR-TE Tunnel 2
(Binding SID 1) (Binding SID 2)
Intra-AS E2E SR-TE Tunnel
(Binding SID 1 + Peer SID + Binding SID 2)
Uses BGP-LS to report labels and network topology information

Uses NETCONF to deliver tunnel configurations
Uses PCEP to deliver the label stack and report LSP status
Before configuring an inter-AS E2E SR-TE tunnel, complete the following tasks:
l Configure an intra-AS SR-TE tunnel.
l 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-TE tunnel. After binding
SIDs and BGP peer SIDs are orchestrated properly, E2E SR-TE LSPs can be established.
An SR-TE tunnel is unidirectional. In the following operations, the binding SID is set for the
unidirectional SR-TE tunnel only within an AS domain.
l To set a binding SID of a reverse SR-TE tunnel, perform the configuration on the ingress
of the reverse tunnel.
l To set a binding SID of an SR-TE tunnel in another AS domain, perform the
configuration on the ingress of the specific AS domain.
Procedure
Step 1 Enter the system view.
system-view
Step 2 Enter the intra-AS SR-TE tunnel interface view.

interface tunnel tunnel-number
Step 3 Set a binding SID for the intra-AS SR-TE tunnel.

mpls te binding-sid label label-value
Step 4 Commit the configuration.

commit
----End
1.2.12.2 Configuring an E2E SR-TE Tunnel Interface

and manage an E2E SR-TE tunnel.
Context
An SR-TE tunnel is unidirectional. To configure a reverse tunnel, perform the configuration
on the ingress of the reverse tunnel.
Procedure
An inter-AS E2E tunnel interface is created, and the tunnel interface view is displayed.

l To configure an IP address for the tunnel interface, run:

NOTE
The SR-TE tunnel is unidirectional and does not need a peer IP address. A separate IP address for the
A tunnel destination address, which is usually the LSR ID of the egress, is configured.
A tunnel ID is set.
Step 10 Run commit
----End

path information to a forwarder (PCC), the SR-enabled PCC can establish an SR-TE tunnel.
Context

NOTE
Procedure
system-view
Step 2 Configure a PCC and enter the PCC view.

pce-client
Step 3 Enable the segment routing capability.

capbility segment-routing
Step 4 Configure a candidate PCE server for a PCC.

connect-server ip-address

commit
----End
1.2.12.4 Verifying the Configuration of an Inter-AS E2E SR-TE Tunnel

After configuring an inter-AS E2E SR-TE tunnel, verify information about the SR-TE tunnel
and its status statistics.
Prerequisites
The inter-AS E2E SR-TE tunnel has been configured.
Procedure
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.13 Configuring an Inter-AS E2E SR-TE Tunnel (Explicit Path

Used)
An inter-AS E2E SR-TE tunnel can connect SR-TE tunnels in multiple AS domains to build a
large-scale TE network.

Usage Scenario
SR-TE, a new MPLS TE tunneling technology, has unique advantages in label distribution,
protocol simplification, large-scale expansion, and fast path adjustment. SR-TE can better
cooperate with SDN.
The SR that is extended through an IGP can implement SR-TE only within an AS domain. To
implement inter-AS E2E SR-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-81.
In addition, the label depth supported by an ordinary forwarder is limited, whereas the depth
of the label stack of an inter-AS SR-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-TE tunnel, set a binding SID for the tunnel.
The binding SID identifies an SR-TE tunnel and replaces the label stack of an SR-TE tunnel.
Figure 1-81 Inter-AS E2E SR-TE tunnel networking

AGG1
CSG1 ASBR1 ASBR3 PE1 RNC
IGP Domain 1 BGP EPE IGP Domain 2

AS 100 AS 200
ASBR2 ASBR4 PE2 Server

CSG2
AGG2
Intra-AS E2E SR-TE Tunnel
Before configuring an inter-AS E2E SR-TE tunnel, complete the following tasks:
l Configure an intra-AS SR-TE tunnel.
l Configure BGP EPE between ASBRs. For details, see Configuring BGP SR.
1.2.13.1 Setting a Binding SID

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-TE tunnel. After binding
SIDs and BGP peer SIDs are orchestrated properly, E2E SR-TE LSPs can be established.

An SR-TE tunnel is unidirectional. In the following operations, the binding SID is set for the
unidirectional SR-TE tunnel only within an AS domain.
l To set a binding SID of a reverse SR-TE tunnel, perform the configuration on the ingress
of the reverse tunnel.
l To set a binding SID of an SR-TE tunnel in another AS domain, perform the
configuration on the ingress of the specific AS domain.
Procedure
system-view
Step 2 Enter the intra-AS SR-TE tunnel interface view.

interface tunnel tunnel-number
Step 3 Set a binding SID for the intra-AS SR-TE tunnel.


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-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
Procedure
system-view
Step 2 Create an explicit path and enter the explicit path view.
explicit-path
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. Specify a binding SID label of the first AS domain on an explicit path.

next sid label label-value type binding-sid
NOTE
When the first hop of an explicit path is assigned a binding SID, the explicit path supports a maximum
of three hops.

2. Specify an inter-AS adjacency label.

next sid label label-value type adjacency
3. Specify a binding SID label of the second AS domain on an explicit path.

next sid label label-value type binding-sid
In the case of multiple AS domains, this binding SID can be the binding SID of a new
E2E SR-TE tunnel.

commit
----End
1.2.13.3 Configuring an E2E SR-TE Tunnel Interface

and manage an E2E SR-TE tunnel.
Context
An SR-TE tunnel is unidirectional. To configure a reverse tunnel, perform the configuration
on the ingress of the reverse tunnel.
Procedure
An inter-AS E2E tunnel interface is created, and the tunnel interface view is displayed.
l To configure an IP address for the tunnel interface, run:
NOTE
The SR-TE tunnel is unidirectional and does not need a peer IP address. A separate IP address for the
A tunnel destination address, which is usually the LSR ID of the egress, is configured.

A tunnel ID is set.
command.
Step 10 Run commit
----End
1.2.13.4 Verifying the Configuration of an Inter-AS E2E SR-TE Tunnel

After configuring an inter-AS E2E SR-TE tunnel, verify information about the SR-TE tunnel
and its status statistics.
Prerequisites
The inter-AS E2E SR-TE tunnel has been configured.
Procedure
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 IS-IS SR to Communicate with LDP

This section describes how to configure IS-IS SR to communicate with LDP.

Usage Scenario
In Figure 1-82, 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-82 Communication between SR and LDP

PE1 P PE2
SR LSP LDP LSP
Mapping client Mapping server
Before you configure IS-IS SR to communicate with LDP, complete the following tasks:
l Configure an SR LSP from PE1 to the P. See Configuring an IS-IS SR-BE Tunnel.
l Configure an LDP LSP from the P to PE2. See Configuring an LDP LSP.
Procedure
l Configure the mapping server.
a. Run system-view
c. Run mapping-server prefix-sid-mapping ip-address mask-length begin-value
[ range range-value ] [ attached ]
Mapping between the prefix and SID is configured.
d. Run quit
Exist the SR view.
e. Run isis [ process-id ]
f. Run segment-routing mapping-server send
The local node is enabled to advertise the local SID label mapping.
g. (Optional) Run segment-routing mapping-server receive
The local node is enabled to receive SID label mapping messages.

h. Run commit
l (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
l 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.15 Configuring OSPF SR to Communicate with LDP

This section describes how to configure OSPF SR to communicate with LDP.
Usage Scenario
In Figure 1-83, 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.

PE1 P PE2
SR LSP LDP LSP
Mapping client Mapping server
Before you configure OSPF SR to communicate with LDP, complete the following tasks:
l Configure an SR LSP from PE1 to the P. See Configuring an OSPF SR-BE Tunnel.
l Configure an LDP LSP from the P to PE2. See Configuring an LDP LSP.
Procedure
l Configure the mapping server.
a. Run system-view
c. Run mapping-server prefix-sid-mapping ip-address mask-length begin-value
[ range range-value ] [ attached ]
Mapping between the prefix and SID is configured.
d. Run quit
Exist the SR view.
e. Run ospf [ process-id ]
f. Run segment-routing mapping-server send
The local node is enabled to advertise the local SID label mapping.
g. (Optional) Run segment-routing mapping-server receive
h. Run commit
l (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

l 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.16 Configuring IS-IS TI-LFA FRR

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

Before configuring IS-IS TI-LFA FRR, complete the following tasks:
l Configure IP addresses for interfaces to implement connectivity at the network layer.
l Configure basic IPv4 IS-IS functions.
l Globally enable the segment routing capability.
l 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) 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.
3. Run interface interface-type interface-number
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 7 Run commit
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 system-view


The IS-IS process is created, and the IS-IS view is displayed.
3. Run avoid-microloop segment-routing
The anti-micro-loop function is enabled.
4. (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.
5. Run commit
----End

All IS-IS TI-LFA FRR configurations are complete.
l 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.17 Configuring OSPF TI-LFA FRR

This section describes how to configure OSPF TI-LFA FRR.
Usage Scenario
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:
l Configure IP addresses for interfaces to implement connectivity at the network layer.
l Configure basic OSPF functions
l Globally enable the segment routing capability.
l 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:
– 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.
Step 7 Run commit
Step 8 If a network fault occurs or is rectified, an IGP performs route convergence. A transient
devices, which poses the risk of micro loops. To prevent micro loops, perform the following
steps:
1. Run system-view
The OSPF process is created, and the OSPF view is displayed.
3. Run avoid-microloop segment-routing
The anti-micro-loop function is enabled.
4. (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.
5. Run commit
----End
Example
All OSPF TI-LFA FRR configurations are complete.

l 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.
# Display OSPF SR routing table information.
<HUAWEI> display ospf 1 segment-routing routing
OSPF Process 1 with Router ID 2.2.2.2
Destination : 10.2.1.1/32
AdverRouter : 1.1.1.1 Area : 0.0.0.0
In-Label : 153871 Out-Label : 170012
Type : Stub Age : 27h11m17s
Prefix-sid : 1 Flags : -|
N|-|-|-|-|-|-
SR-Flags : -|-|-|-|-|-|-|-
NextHop : 10.1.1.1 Interface : Eth1/0/0
ULoopLsIndex : 2000016385
ULoopStack : {32789, 32789}
Backup NextHop : - Backup Interface : -
Backup Type : -
BakLabelStack : -
1.2.18 Configuring SBFD for SR-BE Tunnel

SBFD for SR-BE tunnel can be configured to monitor SR-TE tunnels.
Usage Scenario
If SBFD for SR-BE detects a fault on the primary tunnel, VPN FRR rapidly switches traffic,
which minimizes the impact on traffic.
Before configuring SBFD for SR-BE tunnel:
l Configure an SR-BE tunnel.
l Run the mpls lsr-id lsr-id command to set the LSR ID, and ensure the peer to local end
lsr-id address is reachable.
Procedure
l 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

h. Run seamless-bfd enable mode tunnel [ [ filter-policy ip-prefix ip-prefix-name ] |
[ effect-sr-lsp ] ] *
SBFD for SR-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

l Configuring an SBFD Reflector
a. Run system-view

b. Run bfd
BFD is globally enabled.
BFD.
c. Run quit

d. Run sbfd
SBFD is globally enabled.

e. Run reflector discriminator { unsigned-integer-value | ip-address-value }
A discriminator is configured for the SBFD reflector.

f. Run commit
----End

After successfully configuring SBFD for SR-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-BE tunnel.
1.2.19 Configuring SBFD for SR-TE LSP

This section describes how to configure SBFD to detect SR-TE LSP faults.

Usage Scenario
If SBFD for SR-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-TE LSP, complete the following task:
l Configure an SR-TE tunnel.

l Set each LSR ID using the mpls lsr-id lsr-id command. Ensure that the route to the local
lsr-id is reachable.
Procedure
l Configure an SBFD initiator.
a. Run system-view

b. Run bfd
BFD is enabled globally.
BFD.
c. Run quit

d. Run sbfd
SBFD is enabled globally.

e. Run quit

f. Run interface tunnel tunnel-number
The SR-TE tunnel interface view is displayed.

g. Run mpls te bfd enable seamless
SBFD for SR-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-TE tunnel.
h. Run commit

l Configure the SBFD reflector.
a. Run system-view

b. Run bfd

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-TE LSP, run the display bfd session { all | discriminator
discr-value } [ verbose ] command to check information about the SBFD session that
monitors an SR-TE tunnel.
1.2.20 Configuring SBFD for SR-TE Tunnel

This section describes how to configure SBFD to detect SR-TE tunnel faults.
Usage Scenario
If SBFD for SR-TE tunnel detects a fault on the primary tunnel, traffic is rapidly switched to
the backup tunnel, which minimizes the impact on traffic.
Before configuring SBFD for SR-TE tunnel, complete the following task:
l Configure an SR-TE tunnel.
Procedure
l Configure an SBFD initiator.
a. Run system-view
b. Run bfd
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-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-TE tunnel.
h. Run commit

l Configure the SBFD reflector.
a. Run system-view

b. Run bfd
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-TE tunnel, run the display bfd session { all |
discriminator discr-value } [ verbose ] command to check information about the SBFD
session that monitors an SR-TE tunnel.
1.2.21 Configuring BFD for SR LSP

BFD for SR LSP can be configured to detect faults of SR tunnels (SR-BE).

Usage Scenario
If BFD for SR LSP detects a fault on the primary tunnel, VPN FRR rapidly switches 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:
l Configure an IS-IS SR-BE tunnel or configure an OSPF SR-BE tunnel.

Procedure
Step 2 Run bfd
The BFD view is displayed.
Step 3 Run mpls-passive
The egress is enabled to create a BFD session passively.
The egress has to receive an LSP ping request carrying a BFD TLV before creating a BFD
session.
Step 4 Run quit
Step 6 Run bfd enable mode tunnel [ filter-policy ip-prefix ip-prefix-name | effect-sr-lsp ] *
BFD is enabled for SR-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

Verifying the Configuration

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.22 Configuring BFD for SR LSP (SR and LDP Interworking

Scenario)
BFD for SR LSP 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:
l Configure IS-IS SR to communicate with LDP or OSPF SR to communicate with
LDP.
Procedure
l Create a BFD session on the SR side.
a. Run system-view
b. Run bfd
c. Run mpls-passive
The egress has to receive an LSP ping request carrying a BFD TLV before creating
a BFD session.
d. Run quit
e. Run segment-routing
f. Run bfd enable mode tunnel [ filter-policy ip-prefix ip-prefix-name | effect-sr-lsp
| nil-fec ] *
BFD is enabled for SR-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

l Create a BFD session on the LDP side.
a. Run system-view

b. Run bfd

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

e. Run mpls

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

l 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.23 Configuring Static BFD for SR-TE

This section describes how to configure static BFD for SR-TE to detect SR-TE tunnel faults.
Usage Scenario
BFD can be used to monitor to SR-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-TE, configure SR-TE tunnels.
Procedure
Step 1 Enable BFD globally.
1. Run system-view
2. Run bfd
BFD is enabled globally, and the BFD view is displayed.
You can set BFD parameters only after running the bfd command to enable BFD
globally.
3. Run commit
Step 2 Set ingress BFD parameters.
1. Run system-view
2. Run bfd cfg-name bind mpls-te interface interface-type interface-number
BFD is configured to monitor an SR-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
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.
– On the remote device, the actual interval between sending BFD packets is 300 ms
by 4.
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-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.

by 5.
by 4.
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-TE, check the configurations.
l Run the display bfd session mpls-te interface tunnel tunnel-name [ verbose ]
command to check BFD session information on the tunnel ingress.
l 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.
l 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.
– 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.24 Configuring Static BFD for SR-TE LSP

Static BFD for SR-TE LSP can be configured to detect faults on SR-TE LSP links.
Usage Scenario
BFD detects the connectivity of SR-TE LSPs. If a BFD session fails to go Up through
negotiation, an SR-TE LSP cannot go Up. Static BFD for SR-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-TE LSP, you should configure an SR-TE Tunnel.
Procedure
Step 1 Enabling BFD Globally
1. Run system-view
2. Run bfd
globally.
3. Run commit


Step 2 Configuring 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-TE
tunnel.
If one-arm-echo is configured, a one-arm BFD echo session is established to monitor an
LSP bound to the SR-TE tunnel. A Huawei device at the ingress cannot use BFD for SR-
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-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.
by 5.

by 4.
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.
8. Run commit
Step 3 Configuring 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-TE
tunnel.
If one-arm-echo is configured, a one-arm BFD echo session is established to monitor an

LSP bound to the SR-TE tunnel. A Huawei device at the ingress cannot use BFD for SR-
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-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.


by 5.
by 4.
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.
The BFD detection multiplier is set.
8. Run commit
----End

After successfully configuring BFD for SR-TE LSP, you can verify the configurations. For
example, the BFD session is Up.
l Run the display bfd session mpls-te interface tunnel-name te-lsp [ verbose ] command
to check information on BFD sessions on the ingress.
l Run the following commands to check BFD session information on the egress:
– Run the display bfd session all [ for-ip | for-lsp | for-te ] [ verbose ] command to
check the configurations of all BFD sessions.
– Run the display bfd session static [ for-ip | for-lsp | for-te ] [ verbose ] command
to check the configurations of static BFD sessions.
l 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.25 Configuring Dynamic BFD for SR-TE LSP

Dynamic BFD for SR-TE LSP rapidly detects faults of SR-TE LSPs, which protects traffic
transmitted on SR-TE LSPs.
Usage Scenario
BFD detects the connectivity of SR-TE LSPs. If a BFD session fails to go Up through
negotiation, an SR-TE LSP cannot go Up. Dynamic BFD for SR-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-TE LSP, dynamic BFD for SR-TE LSP simplifies the configuration and
minimizes manual configuration errors.
Dynamic BFD can only monitor a part of an SR-TE tunnel.
Before configuring dynamic BFD for SR-TE LSP, you should configure an SR-TE Tunnel.
Procedure
Step 1 Enabling BFD Globally
1. Run system-view
2. Run bfd
globally.
3. Run commit
Step 2 Enabling the Ingress to Dynamically Create a BFD Session to Monitor SR-TE LSPs
Perform either of the following operations to enable the ingress to dynamically create a BFD
Session to monitor SR-TE LSPs:
l Globally enable the capability if BFD sessions need to be automatically created for most
SR-TE tunnels on the ingress.
l Enable the capability on a specific tunnel interface if a BFD session needs to be
automatically created for a specific or some SR-TE tunnels on the ingress.
Please select the appropriate configuration according to your actual needs.
l 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-TE
tunnel.
After this command is run in the MPLS view, BFD for SR-TE LSP is enabled on all
tunnel interfaces, except the tunnel interfaces on which BFD for SR-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-TE tunnel. A Huawei device at the ingress cannot
use BFD for SR-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-TE tunnel, configure a one-arm BFD echo session.
d. (Optional) If some SR-TE tunnels do not need to be monitored using BFD for SR-
TE LSP, block BFD for SR-TE LSP on each tunnel interface:
n Run the interface tunnel interface-number
n Run the mpls te bfd block
The tunnel interface is disabled from automatically creating a BFD session to
monitor an SR-TE tunnel.
e. Run commit
l 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.
If one-arm-echo is configured, a one-arm BFD echo session is established to
monitor an LSP bound to the SR-TE tunnel. A Huawei device at the ingress cannot
use BFD for SR-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-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

The egress has to receive an LSP ping request carrying a BFD TLV before creating a
BFD session.
4. Run commit
Step 4 (Optional) Adjusting BFD Parameters on the Ingress
Adjust BFD parameters on the ingress in either of the following modes:
l Adjust BFD parameters globally. This method is used when BFD parameters for most
SR-TE tunnels need to be adjusted on the ingress.
l Adjust BFD parameters on a specific tunnel interface. If an SR-TE tunnel interface needs
BFD parameters different from the globally configured ones, adjust BFD parameters on
the specific tunnel interface.
NOTE
l 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 }
l 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 }
l Effective local BFD detection period = Effective local interval at which BFD packets are received
x Remotely configured BFD detection multiplier
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-TE tunnel is as follows:
l Effective detection period on the ingress = Configured interval at which BFD packets are received
on the ingress x 3
l 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.

l 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
l 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-TE LSP is complete, verify the
configurations.
l Run the display bfd session dynamic [ verbose ] command to check information about
BFD sessions on the ingress.
l 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.
l 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.26 Configuring One-Arm BFD for E2E SR-TE Tunnel

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

bfd
3. Commit the configuration.

commit
Step 2 Enable the ingress to dynamically create a BFD session to monitor E2E SR-TE tunnels.
Perform either of the following operations:
l Globally enable the capability if BFD sessions need to be automatically created for most
E2E SR-TE tunnels on the ingress.
l Enable the capability on a specific tunnel interface if a BFD session needs to be
automatically created for some E2E SR-TE tunnels on the ingress.
Run the following commands as needed.
l Enable the capability globally.
a. Enter the system view.
system-view
b. Enter the MPLS view.

mpls
c. Enable one-arm BFD for E2E SR-TE tunnel.

mpls te bfd tunnel enable one-arm-echo
d. Enter the view of the E2E SR-TE tunnel interface.

interface tunnel interface-number
e. Set a binding SID for a reverse LSP in the E2E SR-TE tunnel.
mpls te reverse-lsp binding-sid label label-value
Ensure that the mpls te binding-sid label label-value command has been run on the
ingress of the reverse LSP.
f. (Optional) Run the command to block the capability of automatically creating BFD
sessions for the E2E SR-TE tunnel.
mpls te bfd block
If some SR-TE tunnels do not need to be monitored using BFD for E2E SR-TE
tunnel, block this capability on each tunnel interface:
g. Commit the configuration.
commit
l Enable the capability on a tunnel interface.

– Enter the system view.
system-view
– Enter the view of the E2E SR-TE tunnel interface.

– Enable one-arm BFD for E2E SR-TE tunnel.

This command run in the tunnel interface view takes effect only on the tunnel
interface.
– Set a binding SID for a reverse LSP in the E2E SR-TE tunnel.
– Commit the configuration.
commit
Step 3 (Optional) Adjust BFD parameters on the ingress.


E2E SR-TE tunnels need to be adjusted on the ingress.
l Adjust BFD parameters on a specific tunnel interface. If an E2E SR-TE tunnel interface
needs BFD parameters different from the globally configured ones, adjust BFD
parameters on the specific tunnel interface.
NOTE
In one-arm BFD for E2E SR-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.

system-view
– Enter the MPLS view.

mpls
– Set BFD parameters.

mpls te bfd tunnel { min-rx-interval rx-interval | detect-multiplier
multiplier } *

commit

system-view
– Enter the tunnel interface view.


mpls te bfd tunnel { min-rx-interval rx-interval | detect-multiplier
multiplier } *

commit
----End
Verifying the Configuration of One-Arm BFD for E2E SR-TE Tunnel

After successfully configuring one-arm BFD for E2E SR-TE tunnel, verify the configurations.
1.2.27 Configuring One-Arm BFD for E2E SR-TE LSP

One-arm BFD for E2E SR-TE LSP quickly detects faults on inter-AS E2E SR-TE LSPs and
protects traffic on E2E SR-TE LSPs.

Usage Scenario
One-arm BFD monitors inter-AS E2E SR-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-TE LSP enabled, if the reflector can successfully iterate
packets to the E2E SR-TE LSP using the IP address of the initiator, the reflector forwards the
packets through the E2E SR-TE LSP. Otherwise, the reflector forwards the packets over IP
routes.
Before configuring one-arm BFD for E2E SR-TE LSP, configure an inter-AS E2E SR-TE
tunnel.
Procedure
Step 1 Enabling Global BFD
system-view
2. Enable BFD.
bfd

commit
Step 2 Enable the ingress to dynamically create a one-arm BFD session to monitor E2E SR-TE
LSPs.
system-view
2. Enter the view of the E2E SR-TE tunnel interface.

3. Trigger the automatic creation of a one-arm BFD session to monitor E2E SR-TE LSPs.
mpls te bfd enable one-arm-echo [ primary ]
4. Set a binding SID for a reverse LSP in the E2E SR-TE tunnel.
commit
Step 3 (Optional) Adjust BFD parameters on the ingress.
E2E SR-TE tunnels need to be adjusted on the ingress.
l Adjust BFD parameters on a specific tunnel interface. If an E2E SR-TE tunnel interface
needs BFD parameters different from the globally configured ones, adjust BFD
parameters on the specific tunnel interface.

NOTE
In one-arm BFD for E2E SR-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.

system-view
– Enter the MPLS view.

mpls

mpls te bfd { min-rx-interval tx-interval | detect-multiplier
multiplier } *

commit

system-view
– Enter the tunnel interface view.


mpls te bfd { min-rx-interval rx-interval | detect-multiplier
multiplier } *

commit
----End
Verifying the Configuration of One-arm BFD for E2E SR-TE LSP

After successfully configuring one-arm BFD for E2E SR-TE LSP, verify the configurations.
1.2.28 Configuring Examples for SR-BE

This section provides several configuration examples of SR-BE.
1.2.28.1 Example for Configuring L3VPN over IS-IS SR-BE

L3VPN services are configured to allow users within the same VPN to securely access each
other.

Networking Requirements
In Figure 1-84,
l CE1 and CE2 belong to vpna.
l The VPN-target attribute of vpna is 111:1.
L3VPN services recurse to an IS-IS SR-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-84 L3VPN recursive to an IS-IS SR-BE tunnel

NOTE
Interface 1, interface 2, and interface 3 stand for GE 1/0/0, GE 2/0/0, and GE 3/0/0, respectively.
SR Domain Loopback1
AS: 100 2.2.2.9/32
Interface3
PE1 Interface3 172.2.1.2/24 PE2
172.1.1.1/24
Loopback1 Interface1 P1 Interface2 Loopback1
1.1.1.9/32 172.1.1.2/24 172.2.1.1/24 3.3.3.9/32
Interface1 P2
Interface2 Interface1 Interface2
10.1.1.2/24 172.3.1.1/24 172.4.1.2/24 10.2.1.2/24
Interface1 Interface2
172.3.1.2/24 172.4.1.1/24
Loopback1
4.4.4.9/32
AS: 65410 10.1.1.1/24 AS: 65420
10.2.1.1/24
CE1 CE2
Loopback1 Loopback1
11.1.1.1/32 22.2.2.2/32
Configuration Notes
When configuring L3VPN recursion to an IS-IS SR-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:
l MPLS LSR IDs of the PEs and P
l vpna's VPN-target and RD
l 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.3.1.1 24
[*PE1-GigabitEthernet1/0/0] quit
[*PE1] commit
# Configure P1.
[~HUAWEI] sysname P1
[*HUAWEI] commit
[~P1] interface loopback 1
[*P1-LoopBack1] ip address 2.2.2.9 32
[*P1-LoopBack1] quit
[*P1] interface gigabitethernet1/0/0
[*P1-GigabitEthernet1/0/0] ip address 172.1.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
[*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
[~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
NOTE
The value range of SRGB changes dynamically, depending on the actual situation of the equipment.
Here is an example only.

[*PE1-isis-1] frr
[*PE1-isis-1-frr] loop-free-alternate level-1
[*PE1-isis-1-frr] ti-lfa level-1
[*PE1-isis-1-frr] quit
[*PE1-isis-1] quit
[*PE1-LoopBack1] isis prefix-sid index 10
[*PE1] commit
# Configure P1.
[~P1] segment-routing
[*P1-segment-routing] quit
[*P1] 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
NOTE
[*P1-isis-1] frr
[*P1-isis-1-frr] loop-free-alternate level-1
[*P1-isis-1-frr] ti-lfa level-1
[*P1-isis-1-frr] quit
[*P1-isis-1] quit
[*P1] interface loopback 1
[*P1-LoopBack1] isis prefix-sid index 20
[*P1] commit
# Configure PE2.
[*PE2] commit
[~PE2] isis 1
NOTE
[*PE2-isis-1] frr
[*PE2-isis-1] quit
[*PE2] commit
# Configure P2.
[*P2] commit
[~P2] isis 1
NOTE

[*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.
[~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
PrefRcv
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
# Assign an IP address to each interface on CEs as shown in Figure 1-84. 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.
NOTE
If a PE has multiple interfaces bound to the same VPN instance, you must specify a source IP addresses
by specifying -a source-ip-address in the ping -vpn-instance vpn-instance-name -a source-ip-address
dest-ip-address command to ping the CE connected to the remote PE. Otherwise, the ping fails.
Step 7 Configure a tunnel policy on each PE to preferentially select an SR LSP.

# Configure PE1.
[~PE1] 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 11.1.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 11.1.1.1 32
[*CE1-bgp] quit
[*CE1] commit
NOTE
The configuration of CE2 is similar to the configuration of CE1, and are not provided here. For details,
see Configuration Files.
# Configure PE1.
[~PE1] bgp 100
[*PE1-bgp] ipv4-family vpn-instance vpna
[*PE1-bgp-vpna] peer 10.1.1.1 as-number 65410
[*PE1-bgp-vpna] commit
[*PE1-bgp-vpna] quit
NOTE
The procedure for configuring PE2 is similar to the procedure for configuring PE1, and the detailed
configuration is not provided here. For details, see Configuration Files.
After the configuration, run the display bgp vpnv4 vpn-instance peer command on the PEs,
and you can view that BGP peer relationships between PEs and CEs have been established
and are in the Established state.
In the following example, the peer relationship between PE1 and CE1 is used.
[~PE1] display bgp vpnv4 vpn-instance vpna peer
VPN-Instance vpna, Router ID 1.1.1.9:

PrefRcv
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.1.1.2/32 Direct 0 0 D 127.0.0.1
10.1.1.255/32 Direct 0 0 D 127.0.0.1
11.1.1.1/32 EBGP 255 0 RD 10.1.1.1 GigabitEthernet1/0/0
22.2.2.2/32 IBGP 255 0 RD 3.3.3.9 GigabitEthernet1/0/0
IBGP 255 0 RD 3.3.3.9
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
22.2.2.2.
[~CE1] ping -a 11.1.1.1 22.2.2.2
PING 22.2.2.2: 56 data bytes, press CTRL_C to break
Reply from 22.2.2.2: bytes=56 Sequence=1 ttl=251 time=72 ms
--- 22.2.2.2 ping statistics ---
0.00% packet loss
----End
Configuration Files
l 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.3.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.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
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
l 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.1.1.2 255.255.255.0
isis enable 1

#
undo shutdown
ip address 172.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
#
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.4.1.2 255.255.255.0
isis enable 1
#
undo shutdown
ip address 10.2.1.2 255.255.255.0
#
undo shutdown
ip address 172.2.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.3.1.2 255.255.255.0
isis enable 1
#
undo shutdown
ip address 172.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
l CE1 configuration file
#
sysname CE1
#
undo shutdown
ip address 10.1.1.1 255.255.255.0
#
interface LoopBack1
ip address 11.1.1.1 255.255.255.255
#
bgp 65410
network 11.1.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 22.2.2.2 255.255.255.255
#
bgp 65420
network 22.2.2.2 255.255.255.255
#
ipv4-family unicast
#
return
1.2.28.2 Example for Configuring L3VPN over OSPF SR-BE

L3VPN services are configured to allow users within the same VPN to securely access each
other.
In Figure 1-85,
l The VPN-target attribute of vpna is 111:1.
L3VPN services recurse to an OSPF SR-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-85 L3VPN recursive to an OSPF SR-BE tunnel

NOTE
SR Domain Loopback1
AS: 100 2.2.2.9/32
Interface3
PE1 Interface3 172.2.1.2/24 PE2
172.1.1.1/24
Loopback1 Interface1 P1 Interface2 Loopback1
1.1.1.9/32 172.1.1.2/24 172.2.1.1/24 3.3.3.9/32
Interface1 P2
Interface2 Interface1 Interface2
10.1.1.2/24 172.3.1.1/24 172.4.1.2/24 10.2.1.2/24
172.3.1.2/24 172.4.1.1/24
Loopback1
4.4.4.9/32
AS: 65410 10.1.1.1/24 AS: 65420
10.2.1.1/24
CE1 CE2
Loopback1 Loopback1
11.1.1.1/32 22.2.2.2/32

Configuration Notes
When configuring L3VPN recursion to an OSPF SR-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.
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
l vpna's VPN-target and RD
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
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
[*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
NOTE
[*PE1-ospf-1] frr
[*PE1-ospf-1-frr] loop-free-alternate
[*PE1-ospf-1-frr] ti-lfa enable
[*PE1-ospf-1-frr] quit
[*PE1-ospf-1] quit
[*PE1-LoopBack1] ospf prefix-sid index 10
[*PE1] commit
# Configure P1.
[*P1] commit
[~P1] ospf 1
[*P1-ospf-1] segment-routing mpls
[*P1-ospf-1] segment-routing global-block 16000 23999
NOTE
[*P1-ospf-1] frr
[*P1-ospf-1-frr] loop-free-alternate
[*P1-ospf-1-frr] ti-lfa enable
[*P1-ospf-1-frr] quit
[*P1-ospf-1] quit
[*P1-LoopBack1] ospf prefix-sid index 20
[*P1] commit
# Configure PE2.
[*PE2] commit
[~PE2] ospf 1
NOTE

[*PE2-ospf-1] frr
[*PE2-ospf-1-frr] loop-free-alternate
[*PE2-ospf-1-frr] ti-lfa enable
[*PE2-ospf-1-frr] quit
[*PE2-ospf-1] quit
[*PE2-LoopBack1] ospf prefix-sid index 30
[*PE2] commit
# Configure P2.
[*P2] commit
[~P2] ospf 1
[*P2-ospf-1] segment-routing mpls
[*P2-ospf-1] segment-routing global-block 16000 23999
NOTE
[*P2-ospf-1] frr
[*P2-ospf-1-frr] loop-free-alternate
[*P2-ospf-1-frr] ti-lfa enable
[*P2-ospf-1-frr] quit
[*P2-ospf-1] quit
[*P2-LoopBack1] ospf prefix-sid index 40
[*P2] commit
# 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.
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:

CTRL_C to break
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.
PrefRcv
3.3.3.9 4 100 5 5 0 00:00:12 Established 0
PrefRcv
3.3.3.9 4 100 12 18 0 00:09:38 Established 1
# Configure PE1.
[*PE1] commit
# Configure PE2.
[*PE2] commit

# Assign an IP address to each interface on CEs as shown in Figure 1-85. 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.
NOTE
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
[*PE2] commit
Step 8 Set up EBGP peer relationships between PEs and CEs.
# Configure CE1.
[*CE1] bgp 65410
[*CE1-bgp] quit
[*CE1] commit
NOTE
The configuration of CE2 is similar to the configuration of CE1, and are not provided here. For details,
see Configuration Files.
# Configure PE1.
[~PE1] bgp 100

NOTE
The procedure for configuring PE2 is similar to the procedure for configuring PE1, and the detailed
configuration is not provided here. For details, see Configuration Files.

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

------------------------------------------------------------------------------
10.1.1.0/24 Direct 0 0 D 10.1.1.2
10.1.1.2/32 Direct 0 0 D 127.0.0.1
10.1.1.255/32 Direct 0 0 D 127.0.0.1
11.1.1.1/32 EBGP 255 0 RD 10.1.1.1 GigabitEthernet1/0/0
22.2.2.2/32 IBGP 255 0 RD 3.3.3.9 GigabitEthernet1/0/0
IBGP 255 0 RD 3.3.3.9
CEs within the same VPN can ping each other. For example, CE1 successfully pings CE2 at
22.2.2.2.
[~CE1] ping -a 11.1.1.1 22.2.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.3.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
ip address 172.1.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.1.1.2 255.255.255.0
#
undo shutdown
ip address 172.2.1.1 255.255.255.0
#
interface LoopBack1
ip address 2.2.2.9 255.255.255.255
#
return
#
sysname PE2
#
ipv4-family
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.4.1.2 255.255.255.0
#
undo shutdown
ip address 10.2.1.2 255.255.255.0

#
undo shutdown
ip address 172.2.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
#
ospf 1
frr
loop-free-alternate
ti-lfa enable
area 0.0.0.0
#
undo shutdown
ip address 172.3.1.2 255.255.255.0
#
undo shutdown
ip address 172.4.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 11.1.1.1 255.255.255.255
#
bgp 65410
network 11.1.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 22.2.2.2 255.255.255.255
#
bgp 65420
network 22.2.2.2 255.255.255.255
#
ipv4-family unicast
#
return
1.2.28.3 Example for Configuring Non-Labeled Public BGP Routes to Recurse to

an SR-BE tunnel
Non-labeled public BGP routes are configured to recurse to an SR-BE tunnel, so that public
network BGP traffic can be transmitted along the SR-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-86, non-labeled public BGP routes are configured to recurse to an SR-BE tunnel.
Figure 1-86 Non-labeled public BGP route recursion to an SR-BE tunnel

NOTE
Interface 1 and interface 2 stand for GE 1/0/0 and GE 2/0/0, respectively.

SR Domain
AS: 100
Uer loopback1 loopback1 loopback1
Network 1.1.1.9/32 2.2.2.9/32 3.3.3.9/32
172.1.1.2/24 172.2.1.2/24
Uer PE1 172.1.1.1/24 P1 172.2.1.1/24 PE2
Network
BGP
Configuration Notes
When configuring non-labeled public BGP route recursion to an SR-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.
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-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.1.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.
[~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
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
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.
PrefRcv
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-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.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
#
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
l 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.1.1.2 255.255.255.0
isis enable 1
#
undo shutdown
ip address 172.2.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
cost-style wide
network-entity 10.0000.0000.0003.00
#
undo shutdown
ip address 172.2.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.28.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-87, 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.

NOTE
In this example, interfaces 1 and 2 stand for GE 1/0/0 and GE 2/0/0, respectively.
Loopback1 Loopback1 Loopback1

1.1.1.9/32 2.2.2.9/32 3.3.3.9/32
172.1.1.1/24 172.2.1.2/24
PE1 172.1.1.2/24 P 172.2.1.1/24 PE2
SR LSP LDP LSP
Configuration Notes
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.
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
l SRGB ranges on the PE1 and P
Procedure

# Configure PE1.
[*HUAWEI] commit
[*PE1] commit
# Configure the P.
[~HUAWEI] sysname P
[*HUAWEI] commit
[*P-LoopBack1] ip address 2.2.2.9 32
[*P-LoopBack1] quit
[*P] commit
# Configure PE2.
[*HUAWEI] commit
[*PE2] commit
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
[~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
[*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
#
mpls
#
segment-routing
#
isis 1
cost-style wide
network-entity 10.0000.0000.0001.00
#
undo shutdown
ip address 192.1.1.1 255.255.255.0
isis enable 1
#
interface LoopBack1
ip address 1.1.1.9 255.255.255.255
isis enable 1
#
return
#
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.1.1.2 255.255.255.0
isis enable 1
#
undo shutdown
ip address 172.2.1.1 255.255.255.0
isis enable 1
mpls
mpls ldp
#
interface LoopBack1
ip address 2.2.2.9 255.255.255.255
isis enable 1
#
return

#
sysname PE2
#
mpls lsr-id 3.3.3.9
#
mpls
#
mpls ldp
#
isis 1
cost-style wide
network-entity 10.0000.0000.0003.00
#
undo shutdown
ip address 172.2.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.28.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-88, 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-88 IS-IS anycast FRR protection networking

NOTE
Loopback1
2.2.2.9/32
Prefix SID index 20
Interface1
172.1.1.2/24
Interface2
PE1 172.1.1.1/24 CE1
Cost: 10 PE2
Loopback1
1.1.1.9/32
Cost: 100
Interface1 PE3
172.3.1.1/24
Interface1
Loopback1
172.3.1.2/24
2.2.2.9/32
Prefix SID index 20
Loopback0
4.4.4.9/32
Configuration Notes
None
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
l 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
[*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
# 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
NOTE
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
NOTE
an example.
[*PE2] commit
# Configure PE3.
[*PE3] commit
[~PE3] isis 1
NOTE
an example.
[*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

--------------------------------------------------------------
Prefix Label OutLabel Interface NextHop Role

MPLSMtu Mtu State
----------------------------------------------------------------------------------
-------------------------------
2.2.2.9/32 160020 3 GE1/0/0 172.1.1.2 I&T
--- 1500 Active
160020(B) GE2/0/0 172.3.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.3.1.1 255.255.255.0
isis enable 1
#
undo shutdown
ip address 172.1.1.1 255.255.255.0
isis enable 1
#
interface LoopBack1
ip address 1.1.1.9 255.255.255.255
isis enable 1
#
return

#
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.1.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.3.1.2 255.255.255.0
isis enable 1
#
interface LoopBack0
ip address 4.4.4.9 255.255.255.255
#
interface LoopBack1
ip address 2.2.2.9 255.255.255.255
isis enable 1
#
return
1.2.28.6 Example for Configuring SBFD to Monitor SR-BE Tunnels

This section provides an example for configuring SBFD to monitor SR-BE tunnels, which
improves network reliability.
On the network shown in Figure 1-89, SR-BE tunnels between public network PEs are
deployed. To improve network reliability, SBFD is to be deployed. If SBFD detects a fault on
an SR-BE tunnel, a protection application, for example, VPN FRR, rapidly switches traffic,
Figure 1-89 SBFD for SR-BE tunnel

NOTE
In this example, interfaces 1 and 2 stand for GE 1/0/0 and GE 2/0/0, respectively.

Loopback1
SR Domain 2.2.2.9/32
172.1.1.2/24 172.2.1.1/24
Interface2 Interface2 L
1 3 o
kc 2 PE1172.1.1.1/24 172.2.1.2/24 PE2 .3 o
3
/ P1 .3 p
a 9
. .9 b
b 1 a
p . SBFD /3 c
o 1
. 2 k
o 1 Interface1 P2 1
L Interface1
172.3.1.1/24 172.4.1.2/24
172.3.1.2/24 172.4.1.1/24
Loopback1
4.4.4.9/32
Configuration Notes
None
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-BE tunnels.
Data Preparation
l 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
[*P2] commit
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
[*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
NOTE
The SRGB range various according to a live network. Set a range as needed. The SRGB setting here is
an example.
[*PE1-isis-1] frr
[*PE1-isis-1] quit
[*PE1] commit
# Configure P1.
[*P1] commit
[~P1] isis 1
NOTE
an example.
[*P1-isis-1] frr
[*P1-isis-1] quit
[*P1] commit
# Configure PE2.
[*PE2] commit
[~PE2] isis 1

NOTE
an example.
[*PE2-isis-1] frr
[*PE2-isis-1] quit
[*PE2] commit
# Configure P2.
[*P2] commit
[~P2] isis 1
NOTE
an example.
[*P2-isis-1] frr
[*P2-isis-1] quit
[*P2] commit
# After completing the configuration, run the display tunnel-info all command on a PE. The
SR LSP has been established. In the following example, the command output on PE1 is used.
Status
----------------------------------------------------------------------------------
------
0x000000002900000003 srbe-lsp 4.4.4.9
UP
0x000000002900000004 srbe-lsp 2.2.2.9
UP
0x000000002900000005 srbe-lsp 3.3.3.9
UP
# Use ping to monitor SR LSP connectivity on PE1.

CTRL_C to break
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
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.3.1.1 255.255.255.0
isis enable 1
#
undo shutdown
ip address 172.1.1.1 255.255.255.0
isis enable 1
#
interface LoopBack1
ip address 1.1.1.9 255.255.255.255
isis enable 1
#
return
#
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.1.1.2 255.255.255.0
isis enable 1
#
undo shutdown
ip address 172.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
#
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.4.1.2 255.255.255.0
isis enable 1
#
undo shutdown
ip address 172.2.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
frr
ti-lfa level-1
#
undo shutdown
ip address 172.3.1.2 255.255.255.0
isis enable 1
#
undo shutdown
ip address 172.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
1.2.29 Configuration Examples for SR-TE

This section provides several configuration examples of SR-TE.

1.2.29.1 Example for Configuring L3VPN over SR-TE

This section provides an example for configuring L3VPN over an SR-TE tunnel to ensure
secure communication between users of the same VPN.
On the network shown in Figure 1-90:
l The VPN target used by vpna is 111:1.
To ensure secure communication between CE1 and CE2, configure L3VPN over an SR-TE
tunnel.
Figure 1-90 Configuring L3VPN over an SR-TE tunnel

NOTE
In this example, Interface 1 and Interface 2 refer to GE 1/0/0 and GE 2/0/0, respectively.
SR Domain Loopback1
AS: 100 2.2.2.9/32
PE1 PE2
Loopback1 172.1.1.1/24 P1 172.2.1.2/24 Loopback1
1.1.1.9/32 Interface1 Interface2 3.3.3.9/32
172.1.1.2/24 172.2.1.1/24
Interface1 P1 Interface1
10.1.1.2/24 10.2.1.2/24
AS: 65410 Interface1 AS: 65420 Interface1

10.1.1.1/24 10.2.1.1/24
CE1 CE2
Loopback1 Loopback1
11.1.1.1/32 22.2.2.2/32
Precautions
When you configure L3VPN over an SR-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-TE tunnel, specify the tunnel IP address, tunnel protocol, and destination IP address,
and use explicit paths for path computation.
3. On each PE, configure a VPN instance, enable the IPv4 address family, and bind each PE
interface that connects to a CE to the corresponding VPN instance.
4. Configure MP-IBGP between PEs to exchange VPN routing information.
5. Configure EBGP between CEs and PEs to exchange VPN routing information.
Data Preparation
l MPLS LSR IDs on the PEs and P1
l VPN target and RD of vpna
l SRGB range on the PEs and P1
Procedure
Step 1 Configure an IP address for each interface.
Assign IP addresses and masks to interfaces. For configuration details, see "Configuration
Files" in this section.
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
[*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-TE tunnel, specify the tunnel IP
address, tunnel protocol, and destination IP address, and use explicit paths for path
computation.
# Configure PE1.
[*PE1] commit
[~PE1] isis 1
[*PE1-isis-1] traffic-eng level-2
[*PE1-isis-1] quit
NOTE
The SRGB value range varies according to a live network. The following example is for reference only.
[*PE1-LoopBack1] isis prefix-sid absolute 16100
[*PE1] commit
[~PE1] explicit-path pe2
[*PE1-explicit-path-pe2] next sid label 16200 type prefix
[*PE1-explicit-path-pe2] quit
[*PE1] interface tunnel1
[*PE1-Tunnel1] ip address unnumbered interface LoopBack1
[*PE1-Tunnel1] tunnel-protocol mpls te
[*PE1-Tunnel1] destination 3.3.3.9
[*PE1-Tunnel1] mpls te tunnel-id 1

[*PE1-Tunnel1] mpls te signal-protocol segment-routing

[*PE1-Tunnel1] mpls te path explicit-path pe2
[*PE1-Tunnel1] commit
[~PE1-Tunnel1] quit
# Configure P1.
[*P1] commit
[~P1] isis 1
[*P1-isis-1] traffic-eng level-2
[*P1-isis-1] quit
NOTE
[*P1-LoopBack1] isis prefix-sid absolute 16200
[*P1] commit
# Configure PE2.
[*PE2] commit
[~PE2] isis 1
[*PE2-isis-1] quit
NOTE
[*PE2] commit
[~PE2] explicit-path pe1
[*PE2-explicit-path-pe1] quit
[*PE2-Tunnel1] ip address unnumbered interface LoopBack1
[*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-TE tunnel has been established. The command output
on PE1 is used as an example.
Status
----------------------------------------------------------------------------------
------
1 sr-te 3.3.3.9
UP

# Run the ping command on PE1 to check the connectivity of the SR-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 Reply from 3.3.3.9: bytes=100 Sequence=1 time=7 ms
Reply from 3.3.3.9: bytes=100 Sequence=2 time=11 ms Reply from 3.3.3.9: bytes=100
Sequence=3 time=11 ms Reply from 3.3.3.9: bytes=100 Sequence=5 time=10 ms ---
FEC: SEGMENT ROUTING TE TUNNEL IPV4 SESSION QUERY Tunnel1 ping statistics --- 5
packet(s) transmitted 5 packet(s) received 0.00% packet loss round-trip min/avg/
max = 5/8/11 ms
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-IBGP peer relationship has
been set up and is in the Established state. The command output on PE1 is used as an
example.

PrefRcv
3.3.3.9 4 100 2 6 0 00:00:12 Established 0

PrefRcv
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-90. 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.
NOTE
If a PE has multiple interfaces bound to the same VPN instance, specify a source IP address using the -a
source-ip-address parameter in the ping -vpn-instance vpn-instance-name -a source-ip-address dest-ip-
address command to ping the CE that is connected to the remote PE. If the source IP address is not
specified, the ping operation fails.
Step 7 Configure a tunnel policy on each PE, and specify SR-TE as the preferred tunnel.
# Configure PE1.
[*PE1-tunnel-policy-p1] tunnel select-seq sr-te load-balance-number 1
[*PE1] commit
[*PE1] commit
# Configure PE2.
[*PE2-tunnel-policy-p1] tunnel select-seq sr-te load-balance-number 1
[*PE2] commit
[*PE2] commit
Step 8 Set up EBGP peer relationships between the PEs and CEs.
# Configure CE1.


[*CE1] bgp 65410
[*CE1-bgp] quit
[*CE1] commit
NOTE
Repeat this step on CE2. For configuration details, see "Configuration Files" in this section.
# Configure PE1.
[~PE1] bgp 100
NOTE
Repeat this step on PE2. For configuration details, see "Configuration Files" in this section.
After the configuration is complete, run the display bgp vpnv4 vpn-instance peer command
on each PE. The command output shows that the BGP peer relationships have been
established and are in the Established state.
The BGP peer relationship between PE1 and CE1 is used as an example.

PrefRcv
10.1.1.1 4 65410 11 9 0 00:06:37 Established 1

Run the display ip routing-table vpn-instance command on each PE. The command output
shows the routes to CE loopback interfaces.
The command output on PE1 is used as an example.
------------------------------------------------------------------------------
10.1.1.0/24 Direct 0 0 D 10.1.1.2 GigabitEthernet
1/0/0
1/0/0
1/0/0
11.1.1.1/32 EBGP 255 0 RD 10.1.1.1 GigabitEthernet
1/0/0
22.2.2.2/32 IBGP 255 0 RD 3.3.3.9 Tunnel1
The CEs can ping each other. For example, CE1 can ping CE2 (22.2.2.2).

[~CE1] ping -a 11.1.1.1 22.2.2.2

0.00% packet loss
----End
Configuration Files
#
sysname PE1
#
ipv4-family
tnl-policy p1
#
mpls lsr-id 1.1.1.9
#
mpls
mpls te
#
explicit-path pe2
next sid label 16200 type prefix
#
segment-routing
#
isis 1
is-level level-2
cost-style wide
network-entity 10.0000.0000.0001.00
traffic-eng level-2
#
undo shutdown
ip address 10.1.1.2 255.255.255.0
#
undo shutdown
ip address 172.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
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.1.1.2 255.255.255.0
isis enable 1
#
undo shutdown
ip address 172.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
#
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.2.1.2 255.255.255.0
isis enable 1
#
interface LoopBack1
ip address 3.3.3.9 255.255.255.255
isis enable 1
#
interface Tunnel1
destination 1.1.1.9
mpls te tunnel-id 1
mpls te path explicit-path pe1
#
bgp 100
#
ipv4-family unicast
peer 1.1.1.9 enable
#
ipv4-family vpnv4
policy vpn-target
peer 1.1.1.9 enable
#
#
tunnel-policy p1
tunnel select-seq sr-te load-balance-number 1
#
return
#
sysname CE1
#
interface GigabitEthernet 1/0/0
undo shutdown
ip address 10.1.1.1 255.255.255.0
#
interface LoopBack1

ip address 11.1.1.1 255.255.255.255

#
bgp 65410
network 11.1.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 22.2.2.2 255.255.255.255
#
bgp 65420
network 22.2.2.2 255.255.255.255
#
ipv4-family unicast
#
return
1.2.29.2 Example for Configuring LDP VPLS over SR-TE

The public network tunnel for an LDP VPLS network can be an SR-TE tunnel.
Figure 1-91 Configuring LDP VPLS over SR-TE

NOTE
l In this example, interface 1, interface 2, sub-interface 1.1, and sub-interface 2.1 are GE1/0/0,
GE2/0/0, GE1/0/0.1, and GE2/0/0.1, respectively.

1.1.1.9/32 2.2.2.9/32 3.3.3.9/32
interface1 interface2
10.10.1.1/24 10.20.1.1/24
PE1 PE2
subinterface2.1 10.10.1.2/24 P 10.20.1.2/24 subinterface2.1
SR-TE Tunnel
subinterface1.1 subinterface1.1
10.1.1.1/24 10.1.1.2/24
CE1 CE2

On the network shown in Figure 1-91, 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.
It is required that LDP VPLS and the SR-TE tunnel is established between PE1 and PE2 to
transmit VPLS services.
Configuration Notes
When configuring LDP VPLS over SR-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-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-TE tunnel.
Data Preparation
l OSPF areas enabled with SR-TE
l Names and IDs of VSIs
l IP addresses of peers and the tunnel policy
l AC interfaces to which VSIs are bound
Procedure
Step 1 Assign IP addresses to interfaces and configure OSPF.
For configuration details, see Configuration Files in this section.
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-GigabitEthernet1/0/1] mpls te
[*PE1] commit
# Configure the P.


[*P] mpls
[*P-mpls] mpls te
[*P-mpls] quit
[*P-GigabitEthernet1/0/1] mpls te
[*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
[*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] quit
[*PE1] commit
# Configure PE2.
[*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.
Tunnel ID Type Destination Status

-----------------------------------------------------------------------------
0x000000000300000001 sr-te 3.3.3.9 UP
Step 7 Configure remote LDP sessions.

Set up remote peer sessions between PE1 and PE2.
# Configure PE1.
[~PE1] mpls ldp
[*PE1-mpls-ldp] 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
[*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
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-GigabitEthernet1/0/0.1] vlan-type dot1q 10
[*CE2-GigabitEthernet1/0/0.1] ip address 10.1.1.2 255.255.255.0
[*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
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
Configuration Files
#
sysname CE1
#
undo shutdown
#
interface GigabitEthernet1/0/1.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
mpls
mpls te
#

undo shutdown
#
undo shutdown
vlan-type dot1q 10
l2 binding vsi a2
#
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
mpls te path explicit-path path2pe2
#
ospf 1
area 0.0.0.0
network 1.1.1.9 0.0.0.0
network 10.10.1.0 0.0.0.255
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
mpls
mpls te
#
undo shutdown
ip address 10.20.1.1 255.255.255.0
ospf cost 1
mpls
mpls te
#
interface LoopBack1
ip address 2.2.2.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 2.2.2.9 0.0.0.0

network 10.10.1.0 0.0.0.255

network 10.20.1.0 0.0.0.255
mpls-te enable
#
return
#sysname PE2
#
mpls lsr-id 3.3.3.9
#
mpls
mpls te
#
mpls l2vpn
#
vsi a2
pwsignal ldp
vsi-id 2
peer 1.1.1.9 tnl-policy policy1
#
#
segment-routing
#
undo shutdown
#
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
mpls
mpls te
#
undo shutdown
#
undo shutdown
vlan-type dot1q 10
l2 binding vsi a2
#
interface LoopBack1
ip address 3.3.3.9 255.255.255.255
#
interface Tunnel10
destination 1.1.1.9
#
ospf 1
area 0.0.0.0
network 3.3.3.9 0.0.0.0
network 10.20.1.0 0.0.0.255

mpls-te enable
#
#
return

#
sysname CE2
#
undo shutdown
#
undo shutdown
vlan-type dot1q 10
ip address 10.1.1.2 255.255.255.0
#
return
1.2.29.3 Example for Configuring BD EVPN IRB over SR-TE

This section provides an example for configuring BD EVPN IRB over SR-TE.
On the network shown in Figure 1-92, 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-TE tunnels.
Figure 1-92 Networking of BD EVPN IRB over SR-TE

NOTE
In this example, interface1, interface2, and interface3 refer to GE 1/0/0, GE 2/0/0, and GE 3/0/0, respectively.
SR-TE
PE1 PE2
sub-interface1.1 P sub-interface1.1
sub-interface1.1 sub-interface1.1
CE1 CE2

Table 1-27 Interface IP addresses
Device Interface IP Address
GigabitEthernet 1/0/0.1 -
GigabitEthernet 2/0/0 10.1.1.1/24

PE1
Vbdif10 192.168.1.1/24
LoopBack1 1.1.1.1/32
P GigabitEthernet 2/0/0 10.2.1.1/24

PE2
Vbdif10 192.168.2.1/24
Configuration Notes
When configuring BD EVPN IRB over SR-TE, note the following:
l 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.
l 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-TE tunnel on the backbone network.
3. Configure an EVPN instance and a VPN instance on each PE.
4. Configure an EVPN source address on each PE.
5. Configure the Layer 2 Ethernet sub-interfaces connecting PEs and CEs.
6. Configure a vBDIF interface on each PE and bind the vBDIF interface to a VPN
instance.
7. Configure and apply a tunnel policy so that EVPN can recurse to SR-TE tunnels.
8. Establish BGP EVPN peer relationships between PEs.
9. Configure CEs to communicate with PEs.

Data Preparation
l EVPN instance name (evrf1) and VPN instance name (vpn1)

l 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-92.
For configuration details, see the configuration files in this section.
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 Eth0/1/7 1111.1111.2222.01 Up 8s L2 64
[~PE1] display ip routing-table
------------------------------------------------------------------------------
Routing Table : _public_
1.1.1.1/32 Direct 0 0 D 127.0.0.1 LoopBack1

2.2.2.2/32 ISIS-L2 15 10 D 10.1.1.2
3.3.3.3/32 ISIS-L2 15 20 D 10.1.1.2
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 ISIS-L2 15 20 D 10.1.1.2
Step 3 Configure an SR-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] interface gigabitethernet 2/0/0
[*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] mpls te reserved-for-binding
[*PE1-Tunnel1] quit
[*PE1] commit
NOTE
The next sid label command uses the adjacency label from PE1 to P which is dynamically generated using
IS-IS. This adjacency label can be obtained using the display segment-routing adjacency mpls forwarding
command.
[~PE1] display segment-routing adjacency mpls forwarding
Segment Routing Adjacency MPLS Forwarding Information
Label Interface NextHop Type MPLSMtu Mtu

-----------------------------------------------------------------------------
48121 GE2/0/0 10.1.1.2 ISIS-V4 --- 1500
# Configure the P.
[*P] mpls
[*P-mpls] mpls te
[*P-mpls] quit
[*P] segment-routing
[*P] isis 1
[*P-isis-1] traffic-eng level-2
[*P-isis-1] quit
[*P-LoopBack1] isis prefix-sid absolute 153710
[*P-LoopBack1] quit
[*P] interface gigabitethernet 1/0/0
# 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
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
[*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
[*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-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] quit
[*PE1-bgp] ipv4-family vpn-instance vpn1
[*PE1-bgp-vpn1] import-route direct
[*PE1-bgp-vpn1] advertise l2vpn evpn
[*PE1-bgp-vpn1] quit
[*PE1-bgp] quit
[*PE1] commit
# Configure PE2.
[~PE2] bgp 100
[*PE2-bgp] quit
[*PE2] commit
After completing the configuration, run the display bgp evpn peer command to check that
BGP peer relationships have been established between PEs and are in the Established state.
[~PE1] display bgp evpn peer


PrefRcv
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:
*> 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:0:0.0.0.0 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:0:0.0.0.0 3.3.3.3
*> 0:48:00e0-fc12-7890:0:0.0.0.0 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
EVPN-Instance __RD_1_100_2__:
*> 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:0:0.0.0.0 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:0:0.0.0.0

Total routes of Route Distinguisher(200:1): 1
BGP routing table entry information of 0:48:00e0-fc12-3456:0:0.0.0.0:
Label information (Received/Applied): 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: SRBE LSP
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
best, select, pre 255
0.0.0.0/0, ESI: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:
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
Remote-Cross route
From: 3.3.3.3 (10.2.1.2)
internal, best, select, pre 255
0000.0000.0000.0000.0000, GW IP Address: 0.0.0.0
----End
Configuration Files
#
sysname PE1
#

evpn vpn-instance evrf1 bd-mode

tnl-policy srte
#
ip vpn-instance vpn1
ipv4-family
vpn-target 2:2 export-extcommunity evpn
vpn-target 2:2 import-extcommunity evpn
tnl-policy srte evpn
evpn mpls routing-enable
#
mpls lsr-id 1.1.1.1
#
mpls
mpls te
#
bridge-domain 10
evpn binding vpn-instance evrf1
#
explicit-path pe1tope2
next sid label 48121 type adjacency
#
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
mpls
mpls te
#
interface LoopBack1
ip address 1.1.1.1 255.255.255.255
isis enable 1
#
interface Tunnel1
destination 3.3.3.3
mpls te reserved-for-binding
mpls te tunnel-id 1
mpls te path explicit-path pe1tope2

#
interface NULL0
#
bgp 100
#
ipv4-family unicast
peer 3.3.3.3 enable
#
ipv4-family vpn-instance vpn1
import-route direct
advertise l2vpn evpn
#
l2vpn-family evpn
undo policy vpn-target
peer 3.3.3.3 enable
#
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
mpls
mpls te
#
undo shutdown
ip address 10.2.1.1 255.255.255.0
isis enable 1
mpls
mpls te
#
interface LoopBack1
ip address 2.2.2.2 255.255.255.255
isis enable 1
#
return
#
sysname PE2
#


tnl-policy srte
#
ipv4-family
#
mpls lsr-id 3.3.3.3
#
mpls
mpls te
#
bridge-domain 10
#
#
segment-routing
#
isis 1
is-level level-2
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
mpls
mpls te
#
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
#
tunnel-policy srte
#
#
return

#
sysname CE1
#
undo shutdown
#
rewrite pop single
#
return

#
sysname CE2
#
undo shutdown
#
rewrite pop single
#
return
1.2.29.4 Example for Configuring an SR-TE Tunnel (Path Computation on the

Controller)
This section provides an example for configuring an SR-TE tunnel. The procedure involves
enabling MPLS TE, configuring IS-IS SR-TE, and configuring a tunnel interface.
In Figure 1-93, 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 functions as the ingress, and PE2
functions as the egress. P1 collects network topology information and runs IS-IS to flood the
information to the controller. The controller uses the topology information to calculate a path
and delivers path information to a third-party adapter. The adapter delivers the path
information to the ingress PE1.

NOTE
There is no need to configure a PCE client (PCC) because the third-party adapter is used to deliver
paths.
Figure 1-93 Manual SR-TE tunnel

NOTE
Interfaces 1 to 3 in this example indicate GE 1/0/0, GE 2/0/0, and GE1/0/1, respectively.
Third-party
adapter
NETCONF
Controller
7.1.2.9
NETCONF IS-IS
Interface3
7.1.2.10/24
PE1 Interface1 P1 Interface2 PE2
IS-IS 10.1.23.3/24 IS-IS 20.1.34.4/24
10.1.23.2/24 20.1.34.3/24
2.1.2.9 3.1.2.9 4.1.2.9
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 IS-IS TE on each node.
5. Establish an IS-IS neighbor relationship between P1 and the controller so that P1 can
flood network topology information to the controller.
6. Configure a tunnel interface on the ingress PE1 and configure the IP address, tunneling
protocol, destination IP address, and tunnel bandwidth.
Data Preparation
l IP addresses of interfaces as shown in Figure 1-93

l IS-IS process ID (1), IS-IS system ID of each node (converted from a loopback0 IP
address), and IS-IS level (level-2)
l IS-IS neighbor relationship between the controller and P1, as shown in Figure 1-93

Procedure
Step 1 Assign an IP address and a mask to each interface.
Assign IP addresses and masks to interfaces. For configuration details, see Configuration
Files in this section.
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 IS-IS on each node to implement network layer connectivity. For configuration
details, see Configuration Files in this section.
Step 3 Configure an IS-IS neighbor relationship between the controller and P1.
Running IS-IS between the controller and P1 allows the two devices to communicate with
each other so that P1 can flood network topology information to the controller. For detailed
configurations, 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] commit
[~PE1-GigabitEthernet1/0/0] quit
The configurations on P1 and PE2 are similar to the configuration on PE1, except for the LSR
ID. The configuration details are not provided.
Step 5 Enable SR globally on each node.
# Configure PE1.
[~PE1-segment-routing] commit
The configurations on P1 and PE2 are the same as the configuration on PE1. The
configuration details are not provided.
Step 6 Configure IS-IS TE on each node.
# Configure PE1.
[~PE1] isis 1
[*PE1-isis-1] commit
[~PE1-isis-1] quit
Step 7 Configure the tunnel interface on the ingress PE1.
# Configure PE1.
[~PE1] interface tunnel1


[~PE1-Tunnel1] quit

# After completing the configuration, run the display interface tunnel command on PE1. The
tunnel interface is Up.
# Run the display mpls te tunnel command on PE1 to view information about MPLS TE
tunnels.
------------------------------------------------------------------------------
Ingress LsrId Destination LSPID In/Out Label R Tunnel-name
------------------------------------------------------------------------------
2.1.2.9 4.1.2.9 1 --/864256 I Tunnel1
-------------------------------------------------------------------------------
R: Role, I: Ingress, T: Transit, E: Egress
# Run the display segment-routing adjacency mpls forwarding command on PE1 to

display the segment routing label forwarding table.
<~PE1> display segment-routing adjacency mpls forwarding
----------------------------------------------------------------------------
864256 GE1/0/0 10.1.23.3 STATIC-V4 ----
1500
Total information(s):1
----End
Configuration Files
#
sysname PE1
#
mpls lsr-id 2.1.2.9
#
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
#
undo shutdown
ip address 10.1.23.2 255.255.255.0
isis enable 1
mpls
mpls te
#
interface LoopBack0
ip address 2.1.2.9 255.255.255.255

isis enable 1
#
interface Tunnel1
destination 4.1.2.9
mpls te tunnel-id 1
#
return
#
sysname P1
#
mpls lsr-id 3.1.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.3 255.255.255.0
isis enable 1
mpls
mpls te
#
undo shutdown
ip address 7.1.2.10 255.255.255.0
isis enable 1
#
undo shutdown
ip address 20.1.34.3 255.255.255.0
isis enable 1
mpls
mpls te
#
interface LoopBack0
ip address 3.1.2.9 255.255.255.255
isis enable 1
#
return
#
sysname PE2
#
mpls lsr-id 4.1.2.9
#
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 20.1.34.4 255.255.255.0
isis enable 1
mpls
mpls te
#
interface LoopBack0
ip address 4.1.2.9 255.255.255.255
isis enable 1
#
return
1.2.29.5 Example for Configuring the Controller to Run NETCONF to Deliver

Configurations to Create an SR-TE Tunnel
This section provides an example for configuring the controller to run NETCONF to deliver
configurations to create an SR-TE tunnel.
In Figure 1-94, 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.
Figure 1-94 Example for configuring the controller to run NETCONF to deliver
configurations to create an SR-TE tunnel
NOTE
In this example, interfaces 1 to 3 indicate GE 1/0/0, GE 2/0/0, and GE 3/0/0, respectively.
Controller
Interface3
10.2.1.2/24
PCEP
BGP-LS
Interface3
10.2.1.1/24 P1
IS-IS IS-IS
PE1 PE2
Interface1 Interface1 Interface2 Interface2
10.1.2.1/24 10.1.2.2/24 10.1.3.2/24 10.1.3.1/24
1.1.1.1 2.2.2.2 3.3.3.3

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
l BGP-LS peer relationship between the controller and P1, as shown in Figure 1-94.
Procedure
Step 3 Configure PCE on the forwarders and controller. For configuration details, see Configuration
# Configure PE1.
[*PE1] mpls
[*PE1-mpls] mpls te
[*PE1-mpls] quit
# Configure PE1.

[~PE1] segment routing

[*PE1] commit
Step 6 Configure a label allocation mode and a topology information collection mode. In this
example, the forwarders assign labels.
l Enable IS-IS SR-TE.
[~PE1] isis 1
[*PE1-isis-1] bgp-ls enable level-2
[~PE1-isis-1] quit
l Configure the BGP-LS route advertisement capability on P1.
# Enable BGP-LS on P1 and establish a BGP-LS peer relationship with the controller.
[~P1] bgp 100
[*P1-bgp] peer 10.2.1.2 as-number 100
[*P1-bgp] link-state-family unicast
[*P1-bgp-af-ls] peer 10.2.1.2 enable
[*P1-bgp-af-ls] commit
[~P1-bgp-af-ls] quit
[~P1-bgp] quit
# Enable BGP-LS on the controller and establish a BGP-LS peer relationship with P1.
[~Controller] bgp 100
[*Controller-bgp] peer 10.2.1.1 as-number 100
[*Controller-bgp] link-state-family unicast
[*Controller-bgp-af-ls] peer 10.2.1.1 enable
[*Controller-bgp-af-ls] commit
[~Controller-bgp-af-ls] quit
[~Controller-bgp] quit
After completing the configuration, run the display mpls te tunnel-interface command on
PE1. The tunnel interface is Up.
[~PE1] display mpls te tunnel-interface tunnel1
Tunnel Attributes :
Traffic Switch : -
Session ID : 1
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 : -
IPTN InLabel : - Tunnel BFD 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

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
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 : -
Pce Flag : Normal
Path Setup Type : CSPF
Run the display mpls te tunnel command on PE1 to view SR-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
-------------------------------------------------------------------------------
Run the display mpls te tunnel path command on PE1 to view path information on the SR-
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
#
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
#
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
#
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
l 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
ip address 10.2.1.2 255.255.255.0
isis enable 1
#
bgp 100
#
ipv4-family unicast
#
#
return

1.2.29.6 Example for Configuring Static BFD for SR-TE

This section provides an example for configuring static BFD for SR-TE to implement rapid
traffic switching if a tunnel fault occurs.
On the network shown in Figure 1-95, 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.
NOTE
You do not need to configure a PCE client (PCC) because the third-party adapter delivers the path
information.
If a Huawei device connects to a non-Huawei device but the non-Huawei device does not support BFD,
configure one-arm BFD to monitor the link.
Figure 1-95 Configuring static BFD for SR-TE

NOTE
In this example, Interface1, Interface2, and Interface3 represent GE 1/0/0, GE 2/0/0, and GE 1/0/1,
respectively.
Third-party
adapter Controller
NETCONF
10.7.2.9
NETCONF IS-IS
Interface3
10.7.2.10/24
PE1 Interface1 P1 Interface2 PE2
IS-IS 10.1.23.3/24 IS-IS 10.20.34.4/24
10.1.23.2/24 10.20.34.3/24
10.21.2.9 10.31.2.9 10.41.2.9
1. Assign an IP address and a mask to each interface, and configure a loopback address as
an LSR ID on each node.
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-TE tunnel.
Data Preparation
l IP address of each interface, as shown in Figure 1-95
l IS-IS process ID: 1; system ID: loopback0 address; IS-IS level: level-2
l IS-IS neighbor relationship between P1 and the controller, as shown in Figure 1-95
l Name of a BFD session
l Local and remote discriminators of a BFD session
Procedure
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 IS-IS on each node to ensure device connectivity. For configuration details, see
Configuration Files in this section.
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
# Configure PE1.
[~PE1] mpls lsr-id 10.21.2.9
[~PE1] mpls
[*PE1-mpls] mpls te
[*PE1-mpls] quit
The configurations except the LSR ID configuration on P1 and PE2 are the same as those on
PE1.
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.

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.
------------------------------------------------------------------------------
------------------------------------------------------------------------------
10.21.2.9 10.41.2.9 1 --/20 I Tunnel10
------------------------------------------------------------------------------
------------------------------------------------------------------------------
10.41.2.9 10.21.2.9 1 --/120 I Tunnel10
Step 9 Configure BFD for SR-TE.

# On PE1, configure a BFD session to monitor an SR-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-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
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
#
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
1.2.29.7 Example for Configuring Dynamic BFD for SR-TE LSP

This section provides an example for configuring dynamic BFD for SR-TE LSP. Dynamic
BFD for SR-TE LSP rapidly detects faults of SR-TE LSPs, which protects traffic transmitted
on SR-TE LSPs.
In Figure 1-96, 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.
NOTE
There is no need to configure a PCE client (PCC) because the third-party adapter is used to deliver
paths.
If a Huawei device connects to a BFD-incapable non-Huawei device, one-arm BFD can be configured to
monitor links.
Figure 1-96 Networking diagram for configuring dynamic BFD for SR-TE LSP
NOTE
In this example, interfaces 1 to 3 indicate GE 1/0/0, GE 2/0/0, and GE 3/0/0, respectively.

Third-party Controller
adapter NETCONF Interface3
10.2.1.2/24
IS-IS
NETCONF
Interface3
10.2.1.1/24
10.1.1.1/24 10.1.1.2/24 PE2
PE1
Interface2 IS-IS Interface3
10.1.2.1/24 10.1.3.1/24
Loopback0 Loopback0
1.1.1.1 3.3.3.3
IS-IS IS-IS
P1
Primary LSP
10.1.2.2/24 Backup LSP
10.1.3.2/24
Loopback0
2.2.2.2
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

l IS-IS neighbor relationship between the controller and PE2, as shown in Figure 1-96
l Name of the BFD session
l Local and remote discriminators of the BFD session
Procedure
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.
[*PE1] mpls
[*PE1-mpls] mpls te
[*PE1-mpls] quit
# 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

After completing the configuration, run the display mpls te tunnel-interface command on
PE1. The tunnel interface is Up.
Tunnel Attributes :
Traffic Switch : -
Session ID : 1
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 : -
IPTN InLabel : - Tunnel BFD 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

IncludeAll : 0x0
IncludeAny : 0x0
ExcludeAny : 0x0
Explicit Path Name : main Hop Limit: -
FRR Flag : Disabled
IdleTime Remain : -
BFD Status : -
Reroute Flag : Disabled
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 : -
Pce Flag : Normal
Run the display mpls te tunnel command on PE1 to view SR-TE tunnel information.

-------------------------------------------------------------------------------
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
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-
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
[*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
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
#
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
l Controller configuration file
#
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.29.8 Example for Configuring an E2E SR-TE Tunnel (Explicit Path Used)
An inter-AS E2E SR-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-97, 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 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-97 E2E SR-TE tunnel networking

NOTE
Loopback1 Loopback1 Loopback1 Loopback1

1.1.1.1/32 AS 100 2.2.2.2/32 3.3.3.3/32
AS 200 4.4.4.4/32
interface1 interface1 interface1 interface1
10.0.1.1/24 10.1.1.1/24 10.1.1.2/24 10.9.1.2/24
10.0.1.2/24 ASBR1 10.2.1.1/24
PE1 10.2.1.2/24 ASBR2 10.9.1.1/24 PE2

Intra-AS E2E SR-TE Tunnel 3
1. Configure intra-AS SR-TE tunnels in AS 100 and AS 200. Set binding SIDs for the SR-
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-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

l 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)
l AS number (100) of PE1 and ASBR1 and that (200) of PE2 and ASBR2

l SR-TE tunnel interface names in AS 100 (tunnel 1) and AS 200 (tunnel 2); tunnel
interface name of the PE1-to-PE2 E2E SR-TE tunnel (tunnel 3) and that of the PE2-to-
PE1 E2E SR-TE tunnel (tunnel 3)
Procedure
Step 2 Configure an intra-AS SR-TE tunnel in AS 100.
# Configure PE1.
[~PE1] mpls
[*PE1-mpls] mpls te
[*PE1-mpls] quit
[*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
NOTE
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-LoopBack1] quit
[*ASBR1] interface gigabitethernet3/0/0
[*ASBR1-GigabitEthernet3/0/0] isis enable 1
[*ASBR1-GigabitEthernet3/0/0] mpls
[*ASBR1-GigabitEthernet3/0/0] mpls te
[*ASBR1-GigabitEthernet3/0/0] quit
[*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
NOTE
In the preceding step, an ASBR1-to-PE1 adjacency label is used in the next sid label command and is
[~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-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] is-level level-2
[*ASBR2-isis-1] network-entity 10.0000.0000.0002.00
[*ASBR2-isis-1] cost-style wide
[*ASBR2-isis-1] traffic-eng level-2
[*ASBR2-isis-1] segment-routing mpls
[*ASBR2-isis-1] quit
[*ASBR2] commit
[*ASBR2] interface loopback 1

[*ASBR2-LoopBack1] isis enable 1

[*ASBR2-LoopBack1] isis prefix-sid absolute 16300
[*ASBR2-LoopBack1] quit
[*ASBR2] interface gigabitethernet3/0/0
[*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
NOTE
In the preceding step, an ASBR2-to-PE2 adjacency label is used in the next sid label command and is
[~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
NOTE
In the preceding step, a PE2-to-ASBR2 adjacency label is used in the next sid label command and is

-----------------------------------------------------------------------------
330403 GE1/0/0 10.9.1.1 ISIS-V4 --- 1500
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.
asbr2toasbr1
asbr2toasbr1
[~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
[*ASBR1-bgp] link-state-family unicast
[*ASBR1-bgp-af-ls] quit
[*ASBR2-bgp] ipv4-family unicast

[*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
Nexthop : 20.1.1.2
Out interface : GigabitEthernet2/0/0
Nexthop : 10.1.1.2
Peer Adj : 20.1.1.2

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

Local ASN : 100
Remote ASN : 200
SID Label : 32770
Nexthop : 10.1.1.2
[~ASBR2] display bgp egress-engineering
Peer Node : 2.2.2.2

Peer Adj Num : 2
Local ASN : 200
Remote ASN : 100
SID Label : 31768
Nexthop : 20.1.1.1
Nexthop : 10.1.1.1
Peer Adj : 20.1.1.1

Local ASN : 200
Remote ASN : 100

SID Label : 31769

Nexthop : 20.1.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-TE tunnels within AS domains.
In the direction from PE1 to PE2:
# Configure PE1.
[*PE1-Tunnel1] mpls te binding-sid label 1000
[~PE1-Tunnel1] quit
# Configure ASBR2.
[~ASBR2] interface tunnel2
[*ASBR2-Tunnel2] mpls te binding-sid label 2000

# Configure PE2.
[*PE2-Tunnel2] mpls te binding-sid label 3000
[~PE2-Tunnel2] quit
# Configure ASBR1.
[~ASBR1] interface tunnel1
[*ASBR1-Tunnel1] mpls te binding-sid label 4000
Step 6 Configure a bidirectional E2E SR-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
[~PE2-Tunnel3] quit
After completing the configuration, run the display mpls te tunnel-interface tunnel-name
command. The command output shows that the E2E SR-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
Readjust Value : -
Backup Tunnel : -
IPTN InLabel : - Tunnel BFD Status : Down


Ip-Prefix Name : -
Binding Sid : 2001 Reverse Binding Sid : 2002

IncludeAll : 0x0
IncludeAny : 0x0
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
Readjust Value : -

Backup Tunnel : -
Ip-Prefix Name : -
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
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
#
l 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
isis enable 1
mpls
mpls te
#
ip route-static 3.3.3.3 32 gigabitethernet1/0/0 10.1.1.2 description
asbr1toasbr2
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
#
undo shutdown
ip address 10.9.1.1 255.255.255.0
isis enable 1
mpls
mpls te
#
asbr2toasbr1
asbr2toasbr1
#
bgp 200
peer 2.2.2.2 connect-interface loopback 1
peer 2.2.2.2 egress-engineering
ipv4-family unicast
network 3.3.3.3 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
#
#
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.3 Segment Routing MPLS Configuration Commands
1.3.1 avoid-microloop segment-routing
Function
The avoid-microloop segment-routing command enables the anti-microloop function in
segment routing.
The undo avoid-microloop segment-routing command disables the anti-microloop function

in segment routing.
By default, this function is disabled.

Format
avoid-microloop segment-routing
undo avoid-microloop segment-routing
Parameters
None
Views
IS-IS view, OSPF view
Default Level
2: Configuration level
Task Name and Operations

Task Name Operations
isis/ospf write
Usage Guidelines
Usage Scenarios
If a network fault occurs or is rectified, an IGP performs route convergence. A transient
devices, which poses the risk of micro-loops. After anti-micro loop is enabled for segment
routing, the ingress forwards packets strictly along an explicit path during IGP convergence.
The forwarding is irrelevant to IGP convergence of devices, which prevents loops.
Follow-up Procedure
Run the avoid-microloop segment-routing rib-update-delay command to set a switchback
time.
Example
# Enable anti-micro loop function for an IS-IS process in segment routing.
[~HUAWEI] segment-routing
[*HUAWEI-segment-routing] commit
[~HUAWEI-segment-routing] quit
[*HUAWEI] isis 1
[*HUAWEI-isis-1] cost-style wide
[*HUAWEI-isis-1] segment-routing mpls
[*HUAWEI-isis-1] avoid-microloop segment-routing
# Enable anti-micro loop function for an OSPF process in segment routing.


[*HUAWEI] ospf 1
[*HUAWEI-ospf-1] opaque-capability enable
[*HUAWEI-ospf-1] segment-routing mpls
[*HUAWEI-ospf-1] avoid-microloop segment-routing
1.3.2 avoid-microloop segment-routing rib-update-delay

Function
The avoid-microloop segment-routing rib-update-delay command sets a delay in
delivering IS-IS/OSPF routes in segment routing.
The undo avoid-microloop segment-routing rib-update-delay command deletes a delay in
delivering IS-IS/OSPF routes in segment routing.
By default, the delay in delivering IS-IS/OSPF routes in segment routing is 5000 ms.
Format
avoid-microloop segment-routing rib-update-delay rib-update-delay
undo avoid-microloop segment-routing rib-update-delay
Parameters
Parameter Description Value
rib-update-delay Sets a delay in delivering IS-IS/ The value is an integer ranging from
OSPF routes. 1000 to 10000 in milliseconds.
Views
Default Level

isis/ospf write
Usage Guidelines
If a network fault occurs or is rectified, an IGP performs route convergence. A transient
devices, which poses the risk of micro-loops. After anti-micro loop is enabled for segment
routing, the ingress forwards packets strictly along an explicit path during IGP convergence.
The forwarding is irrelevant to IGP convergence of devices, which prevents loops. To set a
delay in delivering IS-IS/OSPF routes in segment routing, run the avoid-microloop segment-
routing rib-update-delay command.

Example
# Set a delay in delivering IS-IS route in a segment routing scenario to 6000 ms.
[*HUAWEI] isis 1
[*HUAWEI-isis-1] avoid-microloop segment-routing rib-update-delay 6000
# Set a delay in delivering OSPF route in a segment routing scenario to 6000 ms.
[*HUAWEI] ospf 1
[*HUAWEI-ospf-1] avoid-microloop segment-routing rib-update-delay 6000
1.3.3 bfd (segment routing)

Function
The bfd enable command enables bidirectional forwarding detection (BFD) for Segment
Routing tunnels created by the SEGR module.
The undo bfd command deletes BFD parameters for Segment Routing tunnels.
By default, no BFD parameters are set for Segment Routing tunnels.
Format
bfd tunnel { min-rx-interval receive-interval | min-tx-interval transmit-interval | detect-
multiplier multiplier-value } *
undo bfd tunnel { min-rx-interval [ receive-interval ] | min-tx-interval [ transmit-interval ]
| detect-multiplier [ multiplier-value ] } *
Parameters
tunnel Indicates Segment Routing -
tunnels.
min-rx-interval Specifies the minimum interval at The value is an integer ranging

receive-interval which BFD packets are received from 10 to 1000, in milliseconds.
from the peer end.
min-tx-interval Specifies the minimum interval at The value is an integer ranging

transmit-interval which BFD packets are sent to the from 10 to 1000, in milliseconds.
peer end.


detect-multiplier Specifies a local detection The value is an integer ranging
multiplier-value multiplier. from 3 to 50.
Views
Segment routing view
Default Level

segr write
Usage Guidelines
Usage Scenario
To set BFD parameters for Segment Routing tunnels, run the bfd command, which helps
devices adapt to various network requirements.
Prerequisites
BFD has been enabled using the bfd and bfd enable mode tunnel commands.
Example
# Set the minimum interval at which SBFD packets are sent to monitor Segment Routing
tunnels to 300 ms.
[~HUAWEI] bfd
[*HUAWEI-bfd] commit
[~HUAWEI-bfd] quit
[*HUAWEI-segment-routing] bfd enable mode tunnel
[*HUAWEI-segment-routing] bfd tunnel min-tx-interval 300
1.3.4 bfd enable
Function
The bfd enable command enables bidirectional forwarding detection (BFD) for SR-BE
tunnels created by the SEGR module.
The undo bfd enable command disables BFD for SR-BE tunnels created by the SEGR
module.
This function is disabled by default.

Format
bfd enable mode tunnel [ filter-policy ip-prefix ip-prefix-name | effect-sr-lsp | nil-fec ] *
undo bfd enable mode tunnel [ filter-policy ip-prefix ip-prefix-name | effect-sr-lsp | nil-
fec ] *
Parameters

mode tunnel Indicates SR-BE tunnels. -
filter-policy Indicates a filter policy. -
ip-prefix ip- Specifies an IP prefix list. The name is a string

prefix-name of 1 to 169 case-
sensitive characters,
with spaces not
supported. When
double quotation
marks are used
around the string,
spaces are allowed in
the string.
effect-sr-lsp Specifies whether to affect the SR LSP. -
If the effect-sr-lsp parameter is specified, if BFD

Down, SEGR module cancels the SR LSP.
nil-fec Specifies whether to use nil FEC. -
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.
Views
Default Level


segr write
Usage Guidelines
Usage Scenario
To enable BFD for SR-BE tunnels created by the SEGR module, run the bfd enable
command, which improves reliability.
Prerequisites
BFD has been enabled using the bfd command.
Example
# Enable BFD for SR-BE tunnels created using the SEGR module.
[~HUAWEI] bfd
[*HUAWEI-bfd] commit
[~HUAWEI-bfd] quit
[*HUAWEI-segment-routing] bfd enable mode tunnel
1.3.5 display bgp egress-engineering
Function
The display bgp egress-engineering command displays BGP EPE information.
Format
display bgp egress-engineering
Parameters
None
Views
All views
Default Level
1: Monitoring level


bgp read
Usage Guidelines
to the network controller. The controller uses the explicit paths to orchestrate IGP SIDs and
BGP peer SIDs to implement inter-AS optimal path forwarding.
To view peer-node SIDs and peer-Adj SIDs, run the display bgp egress-engineering
command.
Example
# Display BGP EPE information.
<HUAWEI> display bgp egress-engineering
Peer Node : 2.2.2.2
Peer Adj Num : 2
Local ASN : 100
Remote ASN : 200
SID Label : 32768
Nexthop : 20.1.1.2
Nexthop : 10.1.1.2
Peer Adj : 20.1.1.2
Local ASN : 100
Remote ASN : 200
SID Label : 32769
Nexthop : 20.1.1.2
Peer Adj : 10.1.1.2
Local ASN : 100
Remote ASN : 200
SID Label : 32770
Nexthop : 10.1.1.2
Table 1-28 Description of the display bgp egress-engineering command output
Project Description
Peer Node Peer IP address

Project Description
Peer Adj Num Number of LDP peer adjacencies
Local ASN Local AS number
Remote ASN Peer AS number
Local Router Id Local router ID
Remote Router Id Peer router ID
Local Interface Address IP address of the local interface
Remote Interface Address IP address of the remote interface
SID Label SID value
Nexthop Next-hop IP address
Out interface Outbound interface name
Peer Adj Peer adjacency IP address
Interface Identifier Interface ID
1.3.6 display isis avoid-microloop information
Function
The display isis avoid-microloop information command displays anti-micro-loop
information.
Format
display isis [ process-id ] avoid-microloop information [ ipv6 ] [ level-1 | level-2 ]
[ systemid systemid ]
Parameters

process-id Displays anti-micro-loop information on The value is an integer
nodes in a specified process. ranging from 1 to
4294967295.
If this parameter is not configured, anti-
micro-loop information of all processes is
displayed.
ipv6 Displays anti-micro-loop information in IPv6 -

topology.


level-1 Displays anti-micro-loop information on -
nodes in Level-1 areas.
level-2 Displays anti-micro-loop information on -

nodes in Level-2 areas.
NOTE
If no level is specified, anti-micro-loop
information of nodes in all areas is displayed.
systemid Specifies the system ID of a node. The value is a string of 1 to

systemid 19 characters.
The value is a string of 1 to
19 characters.
Views
All views
Default Level
1: Monitor level

isis read
Usage Guidelines
After the SR anti-micro-loop function is enabled, run the display isis avoid-microloop
information command to view anti-micro-loop information on nodes. The command output
contains the anti-micro-loop type, cause for failures, and date and time when the device
entered and exited the anti-microloop state.
Example
# Display anti-micro-loop information on nodes.
<HUAWEI> display isis 1 avoid-microloop information level-1
Avoid Microloop Information For ISIS(1)
--------------------------------------
Level-1 Avoid Microloop Information
DestNode :0000.0000.0002
Avoid-Microloop-Technology :segment-routing
Failed-Reason :Stack length exceeds maximum (9 layers).
More-Recent-Details:
Entry time :00:00:17.012 , Exit time :00:00:20.120

Table 1-29 Description of the display isis avoid-microloop information command output
Item Description
DestNode Destination node
Avoid-Microloop-Technology Anti-micro-loop type
Failed-Reason Cause for a failure to prevent a micro loop
More-Recent-Details Detailed information:

l Entry time: Date and time when the
device entered the anti-microloop state.
l Exit time: Date and time when the
device exited the anti-microloop state.
1.3.7 display isis segment-routing mapping-server
Function
The display isis segment-routing mapping-server command displays mapping between
prefixes and SIDs in an IS-IS process.
Format
display isis [ process-id ] segment-routing mapping-server [ ip-address mask-length ]
Parameters

process-id Specifies the ID of an IS-IS The value is an integer ranging from 1 to
process. 4294967295.
ip-address Specifies the IP address of an The value is in dotted decimal notation.

interface.
mask-length Specifies a mask length. The value is an integer ranging from 0 to

32.
Views
All views
Default Level
1: Monitoring level


isis read
Usage Guidelines
In LDP and SR interworking scenarios, if SR is not supported on the LDP side, run the
mapping-server prefix-sid-mapping command on an SR device to map the LDP prefixes to
SIDs and advertise the mapping to the SR domain. To view mapping between prefixes and
SIDs in an IS-IS process, run the display isis segment-routing mapping-server command.
Example
# Display mapping between prefixes and SIDs in an IS-IS process on the transmit end.
<HUAWEI> display isis 1 segment-routing mapping-server
ISIS 1 MappingNodeInfo
Total Count: 4
Destination AdverRouter Sid

-------------------------------------------
2.2.2.2/32 1111.1111.1111* 22
3.3.3.3/32 1111.1111.1111* 20000
5.5.5.5/32 1111.1111.1111* 5000
5.5.5.6/32 1111.1111.1111* 5001
# Display mapping between prefixes and SIDs in an IS-IS process on the transmit end.
<HUAWEI> display isis 1 segment-routing mapping-server
ISIS 1 MappingNodeInfo
Total Count: 4
Destination AdverRouter Sid

-------------------------------------------
2.2.2.2/32 1111.1111.1111-L1 22
2.2.2.2/32 1111.1111.1111-L2 22
3.3.3.3/32 1111.1111.1111-L1 20000
3.3.3.3/32 1111.1111.1111-L2 20000
5.5.5.5/32 1111.1111.1111-L1 5000
5.5.5.5/32 1111.1111.1111-L2 5000
5.5.5.6/32 1111.1111.1111-L1 5001
5.5.5.6/32 1111.1111.1111-L2 5001
Table 1-30 Description of the display isis segment-routing mapping-server command

output
Item Description
Destination Destination prefix
AdverRouter Advertising device
Sid SID value

1.3.8 display isis ti-lfa-node
Function
The display isis ti-lfa-node command displays TI-LFA information on a specified node.
Format
display isis ti-lfa-node [ process-id ] [ level-1 | level-2 ] [ systemid systemid ]
display isis [ process-id ] ti-lfa-node [ level-1 | level-2 ] [ systemid systemid ]
Parameters

process-id Displays TI-LFA information on nodes in a The value is an integer
specified process. ranging from 1 to
4294967295.
If this parameter is not configured, TI-LFA
information of all processes is displayed.
level-1 Displays TI-LFA information on nodes in -

Level-1 areas.

Level-2 areas.
NOTE
If no level is specified, TI-LFA information of nodes
in all areas is displayed.
systemid Specifies the system ID of a node. The value is a string of 1

systemid to 19 characters.
Views
All views
Default Level
1: Monitor level

isis read

Usage Guidelines
After IS-IS TI-LFA FRR is configured on a device, run the display isis ti-lfa-node command
to view TI-LFA information. The command output contains the P node's prefix, outbound
interface name, next-hop IP address, P and Q nodes, P-to-Q label stack, and extended policy.
Example
# Display TI-LFA information on nodes in Level 1 areas in an IS-IS process numbered 1.
<HUAWEI> display isis ti-lfa-node 1 level-1
Topology Independent LFA Node Table for ISIS(1)

-----------------------------------------
ISIS(1) Level-1 Topology Independent LFA Node Table

-----------------------------------------------
DestNode : 2222.2222.2222 NextNearPrefix : -

PNode : 4444.4444.4444 QNode : 3333.3333.3333
PInterface : GE1/0/0 PrimaryBkpNbr : 4444.4444.4444
Protect : LINK AdjLabelStack (P->Q) : 32848, 32848
SRGB : {162000, 163000}
AdjLabel : (1111.1111.1111-00, 32848) (3333.3333.3333-00, 32849)

PNode : 4444.4444.4444 QNode : 3333.3333.3333
Protect : LINKNODE AdjLabelStack (P->Q) : 32848, 32848
SRGB : {164000, 165000}
AdjLabel : (2222.2222.2222-00, 32848) (5555.5555.5555-00, 32849)

PNode : 3333.3333.3333 QNode : 3333.3333.3333
Protect : LINK AdjLabelStack (P->Q) : -
SRGB : {168000, 169000}
AdjLabel : (1111.1111.1111-00, 32849) (5555.5555.5555-00, 32848)

PNode : 4444.4444.4444 QNode : 5555.5555.5555
Protect : LINKNODE AdjLabelStack (P->Q) : 32848
SRGB : {166000, 167000}
AdjLabel : (3333.3333.3333-00, 32848) (4444.4444.4444-00, 32849)
Table 1-31 Description of the display isis ti-lfa-node command output

Item Description
DestNode System ID of the destination node
PNode System ID of the P node
PInterface Backup outbound interface name
Protect Protection mode:

l LINK: link protection
l LINKNODE: node protection

Item Description
NextNearPrefix Preferentially selected prefix on the P node
QNode System ID of the Q node
PrimaryBkpNbr Backup next-hop node
AdjLabelStack (P->Q) P-to-Q label stack
SRGB SRGB information of the destination node
AdjLabel Link label assigned by the destination node
1.3.9 display mpls sr-te cspf destination
Function
The display mpls sr-te cspf destination command checks for paths that satisfy specified
constraints. The constraints are specified using parameters.
Format
display mpls sr-te cspf destination ip-address [ adjacency-sid | metric-type { igp | te } |
srlg-strict exclude-path-name | explicit-path path-name | affinity { properties [ mask mask-
value ] | { { include-all | include-any } { pri-in-name-string } &<1-32> | exclude { pri-ex-
name-string } &<1-32> } * } | hop-limit hop-limit-number ] * [ hot-standby [ explicit-path
hsb-path-name | overlap-path | affinity { hsb-properties [ mask hsb-mask-value ] | { { hsb-
include-all | hsb-include-any } { hsb-in-name-string } &<1-32> | hsb-exclude { hsb-ex-
name-string } &<1-32> } * } | hop-limit hsb-hop-limit-number | srlg { preferred | strict } ]
*]
Parameters

ip-address Specifies the destination IP address of a tunnel. -
adjacency-sid Specifies an adjacency SID. -
metric-type igp Indicates the IGP metric. -
metric-type te Indicates the TE metric. -
srlg-strict exclude- Specifies the name of a path based on an SRLG. -
path-name
explicit-path path- Specifies the name of an explicit path. -
name
affinity properties Specifies an affinity of a tunnel. -
mask mask-value Specifies the mask of an affinity. -


include-all Allows CSPF to include a link when calculating a path, -
only if each link administrative group bit has the same
name as each affinity bit.
include-any Allows CSPF to include a link when calculating a path, if -
at least one link administrative group bit has the same
name as an affinity bit.
pri-in-name-string Specifies a name of an included affinity. -
exclude Allows CSPF to exclude a link when calculating a path, if -
any link administrative group bit has the same name as an
affinity bit.
pri-ex-name-string Specifies a name of an excluded affinity. -
hop-limit hop-limit- Specifies the number of hops on a path. -
number
priority setup-priority Specifies the setup priority. -
hot-standby Indicates a hot-standby path. -
explicit-path hsb-path- Specifies the name of an explicit path over which a hot- -
name standby LSP is established.
overlap-path Indicates that a hot-standby LSP can overlap the primary -
LSP.
affinity hsb-properties Specifies the affinity name of a hot-standby LSP. -
mask hsb-mask-value Specifies the mask of an affinity of a hot-standby LSP. -
hsb-include-all Allows CSPF to include a link when calculating a hot- -
standby LSP, only if each link administrative group bit has
the same name as each affinity bit.
hsb-include-any Allows CSPF to include a link when calculating a hot- -
standby LSP, if at least one link administrative group bit
has the same name as an affinity bit.
hsb-in-name-string Specifies a name of an included affinity of a hot-standby -
LSP.
hsb-exclude Allows CSPF to exclude a link when calculating a hot- -
standby LSP, if any link administrative group bit has the
same name as an affinity bit.
hsb-ex-name-string Specifies a name of an excluded affinity of a hot-standby -
LSP.
hop-limit hsb-hop- Specifies the maximum number of hops on a path over -
limit-number which a hot-standby LSP is established.
srlg preferred Preferentially selects the SRLG attribute as an optional -
constraint used by CSPF to calculate a path for a hot-
standby LSP. If CSPF fails to calculate a path for a hot-
standby CR-LSP based on the SRLG attribute, CSPF
recalculates the path, regardless of the SRLG attribute.


srlg strict Indicates that the links calculated by CSPF for a hot- -
standby LSP must in a different SRLG from those of the
primary LSP.
Views
All views
Default Level
1: Monitoring level

mpls-te read
Usage Guidelines
Usage Scenario
To check for a path that satisfies specified constraints between the specified ingress and
egress, run the display mpls sr-te cspf destination command.
Example
# Display information about SR-TE paths that CSPF uses the primary/backup disjoint
mechanism to compute.
<HUAWEI> display mpls sr-te cspf destination 6.6.6.6 adjacency-sid
Path for the given constraints is:
--------------------------------------------------------------------
Label Type Address
--------------------------------------------------------------------
33844 Adj-SID NAI: 1.3.0.1/1.3.0.3
32910 Adj-SID NAI: 3.4.0.3/3.4.0.4
32909 Adj-SID NAI: 4.5.0.4/4.5.0.5
32909 Adj-SID NAI: 5.6.0.5/5.6.0.6
The total metrics of the calculated path is : 40
Table 1-32 Description of the display mpls sr-te cspf destination 6.6.6.6 adjacency-sid
command output
Item Description
Label Label
Type SID type
Address IP address

Related Topics
explicit-path
1.3.10 display mpls te binding-sid
Function
The display mpls te binding-sid command displays the mapping between binding SIDs and
tunnels.
Format
display mpls te binding-sid [ label label-value ]
Parameters
label label-value Specifies the binding SID label value The value is an integer ranging
of an SR-TE tunnel. from 16 to 1048575.
Views
All views
Default Level
1: Monitoring level

mpls-base read
Usage Guidelines
When configuring an intra-AS SR-TE tunnel, set a binding SID for the tunnel. The binding
SID identifies an SR-TE tunnel and replaces the label stack of an SR-TE tunnel. To view the
mapping between binding SIDs and tunnels, run the display mpls te binding-sid command.
Example
# Display the mapping between binding SIDs and tunnels.
<HUAWEI> display mpls te binding-sid
-------------------------------------------------------------------------------
Label value Tunnel type Tunnel name

10000 Segment-Routing Tunnel10
10001 Segment-Routing Tunnel11
-------------------------------------------------------------------------------

Table 1-33 Description of the display mpls te binding-sid command output
Project Description
Label value Binding SID label value
Tunnel type Tunnel type
Tunnel name Tunnel name
1.3.11 display mpls te binding-sid ref-list
Function
The display mpls te binding-sid ref-list command displays information about explicit paths
that reference a specified binding SID.
Format
display mpls te binding-sid ref-list [ label label-value ]
Parameters
label label-value Specifies the binding SID label value The value is an integer ranging
of an SR-TE tunnel. from 16 to 1048575.
Views
All views
Default Level
1: Monitoring level

mpls-base read
Usage Guidelines
SID identifies an SR-TE tunnel and replaces the label stack of an SR-TE tunnel. To view
information about explicit paths that reference a specified binding SID, run the display mpls
te binding-sid ref-list command.

Example
# Display information about explicit paths that reference a specified binding SID.
<HUAWEI> display mpls te binding-sid ref-list
--------------------------------------------------------------------------------
Binding Sid: 4000 Reference Count: 1
Explicit Path Reference List:
p2
--------------------------------------------------------------------------------
Table 1-34 Description of the display mpls te binding-sid ref-list command output
Project Description
Binding Sid Binding SID label value
Reference Count Number of times when a binding SID is

referenced
Explicit Path Reference List List of names of explicit paths that uses a
binding SID
1.3.12 display mpls te cspf tedb sid

Function
The display mpls te cspf tedb sid command displays CSPF-based SID information that
meets the specified conditions.
Format
display mpls te cspf tedb sid { all | srv4 } [ igp-type { isis | ospf } ]
display mpls te cspf tedb sid area area-id [ igp-type { isis | ospf } ] [ srv4 ]
display mpls te cspf tedb sid node [ router-id ] [ igp-type { isis | ospf } ]
display mpls te cspf tedb sid interface ip-address [ igp-type { isis | ospf } ]
Parameters
all Displays all SID node -
information.
srv4 Displays SR-TE information. -
igp-type { isis | ospf } Specifies an IGP type. -
area area-id Specifies an area ID. For IS-IS, the value can be 1 or 2.
For OSPF, the value ranges from
0 to 4294967295.
node Displays node information. -


router-id Specifies a router ID of a device. The value is in dotted decimal
notation.
interface ip-address Specifies an IP address of an The value is in dotted decimal
interface. notation.
Views
All views
Default Level
1: Monitoring level

mpls-base read
Usage Guidelines
To view CSPF-based SID information that meets the specified conditions, run the display
mpls te cspf tedb sid command. You can use regular expressions to filter output.
l display mpls te cspf tedb sid all: displays all summary SID information of an IGP.
l display mpls te cspf tedb sid all igp-type isis: displays summary IS-IS SID
information.
l display mpls te cspf tedb sid area area-id: displays summary node SID information in
a specific area.
l display mpls te cspf tedb sid area area-id igp-type isis: displays SID information of a
specified IS-IS level.
l display mpls te cspf tedb sid interface ip-address: displays SID information with a
specified interface IP address.
l display mpls te cspf tedb sid interface ip-address igp-type isis: displays summary SID
information of a specified IS-IS interface.
l display mpls te cspf tedb sid node router-id: displays SID information that contains
router information and information about interfaces on each router.
l display mpls te cspf tedb sid node router-id igp-type isis: displays IS-IS SID
information that contains router information and information about interfaces on each
router.
Example
# Display summary information about all SIDs.
<HUAWEI> display mpls te cspf tedb sid all
Current Total Node SID Number: 2
Current Total Adjacency SID Number: 6
Id Node-Id IGP Process-Id Area Node-SID Adj-SID-

Count
1 2.2.2.2 ISIS 1 Level-2 10
3
2 1.1.1.1 ISIS 1 Level-2 0 3
Table 1-35 Description of the display mpls te cspf tedb sid all command output
Item Description
Current Total Node SID Number Number of node SIDs
Current Total Adjacency SID Number Number of adjacency SIDs
Id Sequence number
Node-Id Router ID, in dotted decimal notation
IGP IGP
Process-Id IGP process ID
Area Area to which a device belongs
Node-SID Node SID
Adj-SID-Count Number of Ajd-SIDs with a specified IGP

type and a process ID
# Display all SID node information.

<HUAWEI> display mpls te cspf tedb sid node
Router ID: 128.255.200.24
SRGB Base: 210000 Range: 10000
IGP Type: ISIS Process ID: 100 IGP Area: Level-2
Node SID[SRv4]:
Index Value Flags
11 - Node-SID, no-PHP
Link Count: 9
Link[1]:
Interface Address: 10.113.0.2
Link Type: Multi-access
Neighbor Id: 1002.5520.0003.00
Adj SID[SRv4]:
21548 Flags: Value, Local
Link[2]:
Neighbor Id: 1002.5520.0003.00
Adj SID[SRv4]:
Link[3]:
Neighbor Id: 1002.5520.0003.00
Adj SID[SRv4]:
Link[4]:
Neighbor Id: 1002.5520.0003.00
Adj SID[SRv4]:


Link[5]:
Peer Interface Address: 10.113.7.2
Link Type: point-to-point
Adj SID[SRv4]:
Link[6]:
Neighbor Id: 1002.5520.0025.00
Adj SID[SRv4]:
Table 1-36 Description of the display mpls te cspf tedb sid node command output
Item Description
Router ID Router ID, in dotted decimal notation
SRGB Base SRGB baseline
Range SRGB range
IGP Type IGP, either OSPF or IS-IS
Process Id Process ID
IGP Area Area ID
Node SID Node SID
Index Index
Value SID value
Flags SID flag
Link Count Number of links
Interface Address Interface IP address
Link Type Link type
Neighbor Id Neighbor ID
Adj SID[SRv4] Adj-SID value
Flags Adj-SID flag
Peer Interface Address IP address of the remote interface
1.3.13 display ospf segment-routing mapping-server
Function
The display ospf segment-routing mapping-server command displays mapping between
prefixes and SIDs in an OSPF process.

Format
display ospf [ process-id ] segment-routing mapping-server [ ip-address mask-length ]
Parameters

process-id Specifies the ID of an OSPF The value is an integer ranging from 1 to
process. 4294967295.
ip-address Specifies the IP address of an The value is in dotted decimal notation.

interface.
mask-length Specifies a mask length. The value is an integer ranging from 0 to

32.
Views
All views
Default Level
1: Monitoring level

ospf read
Usage Guidelines
SIDs and advertise the mapping to the SR domain. To view mapping between prefixes and
SIDs in an OSPF process, run the display ospf segment-routing mapping-server command.
Example
# Display mapping between prefixes and SIDs in an OSPF process.
<HUAWEI> display ospf 1 segment-routing mapping-server
Mapping-Server Information
Destination AdverRouter Area Sid

-----------------------------------------------------------
6.6.6.6/32 2.2.2.2 0.0.0.0 6
6.6.6.6/32 2.2.2.2 0.0.0.1 6

Table 1-37 Description of the display ospf segment-routing mapping-server command

output
Item Description
Destination Destination prefix
Area OSPF area
Sid SID value
1.3.14 display ospf segment-routing routing
Function
The display ospf segment-routing routing command displays routing table information on
OSPF segment routing.
Format
display ospf [ process-id ] segment-routing routing [ ip-address [ mask | mask-length ] ]
Parameters

process-id Specifies the ID of an OSPF process. The value is an integer ranging from
1 to 4294967295.
If no process ID is set, information
about all processes numbered in
ascending order is displayed.
ip-address Specifies a destination IP address. The value is in dotted decimal

notation.
mask Specifies a subnet mask. The value is in dotted decimal
notation.
mask-length Specifies a mask length. The value is an integer ranging from
0 to 32.
Views
All views
Default Level
1: Monitoring level


ospf read
Usage Guidelines
In routine SR maintenance, to view OSPF SR routing table information, run the display ospf
segment-routing routing command.
Example
# Display OSPF SR routing table information.
<HUAWEI> display ospf 1 segment-routing routing
Destination : 10.2.1.1/32
AdverRouter : 1.1.1.1 Area : 0.0.0.0
In-Label : 153871 Out-Label : 170012
Type : Stub Age : 27h11m17s
Prefix-sid : 1 Flags : -|N|-|-|-|-|-|-
SR-Flags : -|-|-|-|-|-|-|-
NextHop : 10.1.1.1 Interface : Eth1/0/0
ULoopLsIndex : 2000016385
ULoopStack : {32789, 32789}
Backup NextHop : - Backup Interface : -
Backup Type : -
BakLabelStack : -
Table 1-38 Description of the display ospf segment-routing routing command output
Item Description
Destination Destination network
Area Area to which the advertising device belongs
In-Label Incoming label value
Out-Label Outgoing label value
Type Type of destination network:

l Direct: direct route
l Inter-area: inter-area route
l Inter-area: inter-area route
l Stub: Routes advertised using router LSAs. The routes
correspond to the direct routes of non-broadcast and non-
NBMA networks.
l Transit: Routes advertised using network LSAs
l Type1: type 1 imported route
l Type2: type 2 imported route
Age Date and time when a route was generated

Item Description
Prefix-sid Prefix SID
Flags Flags field
SR-Flags SR TLV flags
NextHop Next hop address
Interface Outbound interface name carried in a route
ULoopLsIndex Index of a label stack of SR anti-micro loop
ULoopStack Label stack of SR anti-micro loop
Backup NextHop Backup next hop address
Backup Interface Backup outbound interface in a route
Backup Type Backup type
BakLabelStack Backup label stack
1.3.15 display segment-routing adjacency mpls forwarding
Function
The display segment-routing adjacency mpls forwarding command displays the segment
routing adjacency label forwarding table.
Format
display segment-routing adjacency mpls forwarding
Parameters
None
Views
All views
Default Level
1: Monitoring level

segment-routing read

Usage Guidelines
To check the segment routing adjacency label forwarding table, run the display segment-
routing adjacency mpls forwarding command. There is a one-to-one mapping between this
table and the one delivered to the FES.
No entry will be displayed in the segment routing label forwarding table after the undo
Segment-routing command is run.
Example
# Display the segment routing adjacency label forwarding table.
<HUAWEI> display segment-routing adjacency mpls forwarding

----------------------------------------------------------------------------
22145 Eth0/3/0/0 192.168.1.2 ISIS-V4 1400 1500
45000 Eth0/3/0/1 192.168.2.2 STATIC-V4 1400 1500
Table 1-39 Description of the display segment-routing adjacency mpls forwarding

command output
Item Description
Label Label value (SID specified in the ipv4

adjacency command)
Interface IP address of the local interface specified in the

ipv4 adjacency command
NextHop IP address of the remote interface specified in

the ipv4 adjacency command
Type Connection type:

l ISIS-V4
l STATIC-V4
MPLSMtu MPLS maximum transmission unit (MTU)
Mtu MTU
1.3.16 display segment-routing bfd tunnel session
Function
The display segment-routing bfd tunnel session command displays information about BFD
sessions that monitor Segment Routing tunnels.
Format
display segment-routing bfd tunnel session [ prefix ip-address [ mask | mask-length ] ]

Parameters
prefix Specifies the prefix of an IP address. -
ip-address Specifies a destination IP address of a The value is in dotted decimal

Segment Routing tunnel. notation.
mask Specifies a subnet mask. The value is in dotted decimal

notation.
mask-length Specifies a mask length. The value is an integer

ranging from 0 to 32.
Only the IP address with a 32-bit prefix can be
configured on a loopback interface.
Views
All views
Default Level
1: Monitoring level

segr read
Usage Guidelines
After BFD is configured for SR tunnels, run the display segment-routing bfd tunnel session
command to view information about BFD sessions that monitor the tunnels.
If the prefix ip-address parameter is configured, information about a BFD session monitoring
a Segment Routing tunnel with a specified destination IP address is displayed. If this
parameter is not configured, information about all BFD sessions that monitor Segment
Routing tunnels is displayed.
Example
# Display information about BFD sessions that monitor Segment Routing tunnels.
<HUAWEI> display segment-routing bfd tunnel session prefix 10.2.2.2 32
BFD Information for SR Tunnel
-------------------------------------------------------------------
-------------------------------------------------------------------
2.2.2.2/32 16385 Up
-------------------------------------------------------------------

Table 1-40 Description of the display segment-routing bfd tunnel session command output
Project Description
Prefix Destination IP address of a segment routing

tunnel
Discriminator BFD local discriminator
State BFD session status
1.3.17 display segment-routing dynamic global-block
Function
The display segment-routing dynamic global-block command displays the range of
dynamic global labels reserved for segment routing.
Format
display segment-routing dynamic global-block rangecount
Parameters
rangecount Specifies the range of dynamic global labels. The value is an integer
Only the scope of the label segment greater than or
equal to rangecount is displayed.
Views
All views
Default Level
1: Monitoring level

Usage Guidelines
To check the range of dynamic global labels reserved for segment routing, run the display
segment-routing dynamic global-block command.

Example
# Display the range of dynamic global labels reserved for segment routing.
<HUAWEI> display segment-routing dynamic global-block 2
Segment Routing Dynamic Global Block Information
--------------------------------------------------
Begin Value End Value Range

--------------------------------------------------------------
153616 156245 2630
156502 284687 128186
Table 1-41 Description of the display segment-routing dynamic global-block command

output
Item Description
Begin Value The begin value of dynamic global block.
End Value The end value of dynamic global block.
Range The value range of dynamic global block.
1.3.18 display segment-routing global-block
Function
The display segment-routing global-block command displays the range of global labels
reserved for segment routing.
Format
display segment-routing global-block
Parameters
None
Views
All views
Default Level
1: Monitoring level


Usage Guidelines
To check the range of global labels reserved for segment routing, run the display segment-
routing global-block command.
Example
# Display global labels available for segment routing.
<HUAWEI> display segment-routing global-block
Segment Routing Global Block

----------------------------------
Lower SID Upper SID Total
------------------------------------------------------
10000 29999 20000
Table 1-42 Description of the display segment-routing global-block command output
Item Description
Lower SID Minimum SID available
Upper SID Maximum SID available
Total Total number of SIDs available
1.3.19 display segment-routing prefix mpls forwarding
Function
The display segment-routing prefix mpls forwarding command displays the label
Format
display segment-routing prefix mpls forwarding [ ip-prefix ip-prefix mask-length | label
label ] [ verbose ]
Parameters

ip-prefix ip-prefix Displays information about a route with a The value is in dotted
specified IP prefix. decimal notation.
mask-length The value is an integer

Specifies a mask length.
label label Specifies a prefix label value. -


verbose Displays detailed information about the -
label forwarding table.
Views
All views
Default Level
1: Monitoring level

Usage Guidelines
To view the label forwarding table for segment routing, run the display segment-routing
prefix mpls forwarding command. Each entry in the label forwarding table for segment
routing is mapped to that in the label forwarding table delivered to the FES module.
After the undo segment-routing command is run, all records are deleted.
Example
# Display information about the label forwarding table for segment routing.
<HUAWEI> display segment-routing prefix mpls forwarding
i
--------------------------------------------------------------
Role : I-Ingress, T-Transit, E-Egress, I And Transit

MPLSMtu Mtu State
----------------------------------------------------------------------------------
------------------------
1.1.1.1/32 160001 3 GE1/0/0 20.1.1.1 I&T
--- 1500 Active
2.2.2.2/32 160002 NULL Loop1 127.0.0.1 E
--- 1500 Active
# Display detailed information about the label forwarding table for segment routing (IS-IS is
used as an IGP).
<HUAWEI> display segment-routing prefix mpls forwarding verbose

--------------------------------------------------------------
Role : I-Ingress, T-Transit, E-Egress, I And Transit

MPLSMtu Mtu State
----------------------------------------------------------------------------------

------------------------
1.1.1.1/32 160001 3 GE1/0/0 20.1.1.1 I&T
--- 1500 Active
12147(B) GE2/0/0 192.168.1.3 I&T
1400 1500 Inactive
1:52:19.120
BFD State: --
Backup UpdateTime: 2017-1-13 12:22:19.514
Backup Label Stack (Top -> Bottom): { 34570, 34571 }

MPLSMtu Mtu State
----------------------------------------------------------------------------------
------------------------
2.2.2.2/32 160002 NULL Loop1 127.0.0.1 E
--- 1500 Active
1:52:30.375
Label Stack (Top -> Bottom): { }
Table 1-43 Description of the display segment-routing prefix mpls forwarding command
output
Item Description
Prefix IP prefix
Label Incoming label value
OutLabel Outgoing label value
Interface Outbound interface name
NextHop Next-hop IP address
Role Local device role on a tunnel:

l Ingress
l Transit
l Egress
l Ingress and Transit
MPLSMtu MPLS maximum transmission unit (MTU), in

bytes
Mtu IP MTU value, in bytes
State Prefix label status:

l Active
l Inactive
Protocol Protocols used in segment routing
SubProtocol Sub-protocols used in segment routing

Item Description
Process ID Protocol ID
Cost Prefix cost
Weight Prefix weight
UpdateTime Date and time when the label stack was updated
BFD State BFD state
Label Stack Information about a label stack
Backup UpdateTime Date and time when the backup label stack was
updated
Backup Label Stack (Top -> Bottom) Backup label stack
# Display detailed information about the Segment Routing forwarding table (OSPF is used as
an IGP).
<HUAWEI> display segment-routing prefix mpls forwarding verbose
--------------------------------------------------------------

MPLSMtu Mtu State
----------------------------------------------------------------------------------
-------------------------------
1.1.1.1/32 16011 NULL Loop0 127.0.0.1 E
--- 1500 Active
Protocol : OSPF SubProtocol : - Process ID : 10
11:37:48.000
BFD State: --
Label Stack (Top -> Bottom): { }

MPLSMtu Mtu State
----------------------------------------------------------------------------------
-------------------------------
2.2.2.2/32 16021 3 GE1/0/0 192.168.2.2 I&T
--- 1500 Active
Protocol : OSPF SubProtocol : - Process ID : 10
11:38:30.296
BFD State: Up
1.3.20 display segment-routing seamless-bfd tunnel session
Function
The display segment-routing seamless-bfd tunnel session command displays information
about an SBFD session that monitors a segment routing tunnel.

Format
display segment-routing seamless-bfd tunnel session [ prefix ip-address [ mask | mask-
length ] ]
Parameters
prefix Specifies the prefix of an IP address. -
ip-address Specifies the destination IP address of a The value is in dotted decimal

segment routing tunnel. notation.
mask Specifies the subnet mask. The value is in dotted decimal

notation.

Only the IPv6 address with a 32-bit prefix can
be configured on a loopback interface.
Views
All views
Default Level
1: Monitoring level

segr read
Usage Guidelines
After SBFD is configured to monitor a segment routing tunnel, run the display segment-
routing seamless-bfd tunnel session command to view information about the SBFD session.
If the prefix ip-address parameter is configured, information about an SBFD session
monitoring a segment routing tunnel with a specified destination IP address is displayed. If
this parameter is not configured, information about all SBFD sessions that monitor segment
routing tunnels is displayed.
Example
# Display information about all SBFD sessions that monitor segment routing tunnels.
<HUAWEI> display segment-routing seamless-bfd tunnel session prefix 10.2.2.2 32
Seamless BFD Information for SR Tunnel

-------------------------------------------------------------------
-------------------------------------------------------------------
3.3.3.9/32 16385 Up
-------------------------------------------------------------------
Table 1-44 Description of the display segment-routing seamless-bfd tunnel session

command output
Item Description
Prefix Destination IP address of a segment routing

tunnel
Discriminator SBFD local discriminator
State SBFD session status
1.3.21 display segment-routing state ip-prefix

Function
The display segment-routing state ip-prefix command displays segment routing status
information based on a specified address prefix.
Format
display segment-routing state ip-prefix ip-prefix mask-length
Parameters
ip-prefix Displays status information with a The value is in dotted decimal
specified IP prefix. notation.
mask-length The value is an integer ranging from 0

Specifies a mask length.
to 32.
Views
All views
Default Level
1: Monitoring level


segr read
Usage Guidelines
To view segment routing status information based on a specified address prefix, run the
display segment-routing state ip-prefix command. The command output helps query the
status of key elements used in the establishment of a segment routing tunnel based on the
specified prefix and mask.
Example
# Display segment routing status information (IS-IS).
<HUAWEI> display segment-routing state ip-prefix 10.7.7.7 32
Segment Routing State IP-Prefix 10.7.7.7 32
-----------------------------------------------------------------
Protocol : ISIS-L1
Process ID : 1
Prefix-sid : 77
Route active state : Y
Eligible within process : Y
Eligible between processes or protocols : Y
SR nexthop exist : Y
Prefix-sid within min SRGB range : Y
Protocol : ISIS-L2
Process ID : 1
Prefix-sid : 77
Eligible between processes or protocols : NA
SR nexthop exist : N
Table 1-45 Description of the display segment-routing state ip-prefix command output
Item Description
Protocol Protocol.
Process ID Process ID.
Prefix-sid Prefix SID.

This is the preferentially selected prefix SID in
a process mapped to a specified prefix. If the
same prefix and different SIDs are set on
different nodes, a process preferentially selects
an active SID based on a specified rule.
Route active state Whether a route is active.

If a service component does not obtain the
status, NA is displayed, for example, when a
prefix SID that NE-B sends to NE-A is out of
the local SRGB scope of NE-A.

Item Description
Eligible within process Whether a SID is preferentially selected within

a process.
l The value is fixed at Y.
l The output is empty if no SID information is
found based on the specified prefix and
mask.
Eligible between processes or protocols Whether the segment routing next hop is
preferentially selected within a process or
between protocols.
NA indicates that the SEGR does not receive
segment routing information. The possible
cause can be inactive routes or a failure to
compute a segment routing next hop.
SR nexthop exist Whether a segment routing next hop exists.
Prefix-sid within min SRGB range Whether a prefix SID is within the smallest
SRGB scope.
The smallest SRGB scope is determined among
all SRGB scopes on all nodes on a whole path
including the root node.
# Display segment routing status information (OSPF).

<HUAWEI> display segment-routing state ip-prefix 10.3.3.3 32
Segment Routing State IP-Prefix 10.3.3.3 32
-----------------------------------------------------------------
Protocol : OSPF
Process ID : 1
Prefix-sid : 77
Eligible between processes or protocols : Y
SR nexthop exist : Y
1.3.22 ipv4 adjacency

Function
The ipv4 adjacency command configures a static adjacency segment ID (SID) for the
segment routing connection to be established between the local and remote interfaces.
The undo ipv4 adjacency command deletes the static adjacency SID configured for the
segment routing connection to be established between the local and remote interfaces.
By default, no static adjacency SID is configured for the segment routing connection to be
established between the local and remote interfaces.

Format
ipv4 adjacency local-ip-addr local-ip-address remote-ip-addr remote-ip-address sid sid-
value
undo ipv4 adjacency local-ip-addr local-ip-address remote-ip-addr remote-ip-address [ sid

sid-value ]
Parameters
local-ip-addr local-ip- Specifies the IP address of the The value is in dotted
address local interface. decimal notation.
remote-ip-addr remote- Specifies the IP address of the The value is in dotted

ip-address remote interface. decimal notation.
sid sid-value Specifies a static adjacency SID. The value is an integer

ranging from 321536 to
331775.
Views
Default Level

cli write
Usage Guidelines
Usage Scenario
Each SID uniquely identifies an MPLS label. After segment routing is enabled, an adjacency
SID needs to be configured for the segment routing connection to be established between the
local and remote interfaces.
Configuration Impact
Running the command may cause the tunnel to go Down.
Precautions
If no direct routes are available on the local interface specified by local-ip-addr local-ip-
address, no forwarding entries will be generated.

MPLS links are bidirectional, but each SID takes effect unidirectionally. Therefore, if the IP
addresses of the local and remote interfaces on one MPLS link are swapped, a different SID is
required.
Example
# Configure a static adjacency SID for the segment routing.
[*HUAWEI-segment-routing] ipv4 adjacency local-ip-addr 1.1.1.1 remote-ip-addr
1.1.1.2 sid 330000
1.3.23 isis prefix-sid

Function
The isis prefix-sid command configures the prefix segment ID (SID) for the IP address of the
loopback interface.
The undo isis prefix-sid command deletes the prefix SID.
By default, no prefix SID is configured for the IP address of the loopback interface.
Format
isis prefix-sid { absolute sid-value | index index-value } [ node-disable ]
undo isis prefix-sid [ { absolute sid-value | index index-value } [ node-disable ] ]
isis process-id process-id prefix-sid { absolute sid-value | index index-value } [ node-
disable ]
undo isis process-id process-id prefix-sid [ { absolute sid-value | index index-value }
[ node-disable ] ]
Parameters
absolute sid- Specifies an absolute label value, which is The value will change
value effective SID value. dynamically,
depending on the
actual situation of the
equipment.


index index- Specifies a relative label value, also called an The value is an integer
value offset value. A relative label value plus the ranging from 0 to
smallest value in an SRGB is equal to an absolute 65534.
value. Effective SID value = index-value + Start
SRGB value.
NOTE
The relative label value cannot be out of the SRGB
configured locally.
A relative label value must be unique in an IS-IS
process.
If index-value is specified, a local node advertises
index-value as a prefix SID. If sid-value is specified, a
local node advertises the prefix SID equal to sid-value
minus the start SRGB value.
node-disable Sets the node flag to 0. -

NOTE
This parameter disables the TI-LFA algorithm from
preferentially selecting nodes with the N flag set to 0.
process-id The value is an integer

Specifies the IID of an IS-IS multi-instance
process-id ranging from 1 to
process.
4294967295.
Views
Loopback interface view
Default Level

isis write
Usage Guidelines
Usage Scenario
To enable a device to advertise a prefix SID to network-wide routers, run the isis prefix-sid
command to configure the prefix SID for the IP address of the loopback interface. The prefix
SID is used to forward packets along a calculated path.
Prerequisites
IS-IS has been enabled on a loopback interface using the isis enable command.

Segment routing has been enabled for a specific IS-IS topology using the segment-routing
mpls command.
Precautions
A loopback interface can be assigned an IP address. The prefix SIDs take effect only if an IP
address with a 32-bit mask is assigned to the loopback interface.
This command takes effect only on the primary IP address of a loopback interface.
If the prefix SID value beyonds the SRGB range, the prefix SID will not be advertised.
Example
# Set a prefix SID for the IP address of the loopback interface.
[*HUAWEI] isis 1
[*HUAWEI-isis-1] quit
[*HUAWEI] interface loopback0
[*HUAWEI-loopback0] isis enable 1
[*HUAWEI-loopback0] isis prefix-sid index 100
1.3.24 isis ti-lfa disable
Function
The isis ti-lfa disable command disables TI-LFA on an IS-IS interface.
The undo isis ti-lfa disable command enables TI-LFA on an IS-IS interface.
By default, TI-LFA is enabled automatically on IS-IS interfaces if the ti-lfa command is run.
Format
isis [ process-id process-id ] ti-lfa disable [ level-1 | level-2 | level-1-2 ]
undo isis [ process-id process-id ] ti-lfa disable [ level-1 | level-2 | level-1-2 ]
Parameters

level-1 Enables or disables TI-LFA on an IS-IS Level-1 -
interface.
level-2 Enables or disables TI-LFA on an IS-IS Level-2 -

interface.


level-1-2 Enables or disables TI-LFA on all IS-IS -
interfaces.
NOTE
If no level is specified, TI-LFA is disabled by default
on all IS-IS interfaces.
process-id The value is an

Specifies the IID of an IS-IS multi-instance
process-id integer ranging from
process.
1 to 4294967295.
Views
Interface view
Default Level

isis write
Usage Guidelines
Usage Scenario
After the ti-lfa command is run, TI-LFA is automatically enabled on all IS-IS interfaces. To
disable TI-LFA on a specified interface, run the isis ti-lfa disable command in the interface
view.
Precautions
If the ti-lfa command is not run, the isis ti-lfa disable command can be run but cannot take
effect on an interface.
If the isis ti-lfa disable and ti-lfa commands are run in sequence, the isis ti-lfa disable
command still takes effect.
If an interface bound to a VPN instance, the interface does not support TI-LFA.
Example
# Disable TI-LFA on IS-IS Level-1 interfaces.
[*HUAWEI] isis 1

[*HUAWEI] interface gigabitethernet 1/0/0

[*HUAWEI-GigabitEthernet1/0/0] isis enable 1
[*HUAWEI-GigabitEthernet1/0/0] isis ti-lfa disable level-1
Related Topics
1.3.52 ti-lfa (IS-IS)
1.3.25 lsp-trigger segment-routing-interworking best-effort host

Function
The lsp-trigger segment-routing-interworking best-effort host command enables a device
to stitch SR LSPs to the proxy egress LSPs and transit LSPs that are established over non-
local host routes with 32-bit mask.
The undo lsp-trigger segment-routing-interworking best-effort host command disables
this function.
Format
lsp-trigger segment-routing-interworking best-effort host
undo lsp-trigger segment-routing-interworking best-effort host
Parameters
None
Views
MPLS view
Default Level

mpls-base write
Usage Guidelines
Usage Scenarios
When an SR network needs to be connected to an LDP network, LDP LSPs need to be
stitched to SR LSPs so that traffic along the LDP LSP can enter the SR LSP for transmission.
To enable a device to stitch SR LSPs to the proxy egress LSPs and transit LSPs that are
established over non-local host routes with 32-bit masks, run the lsp-trigger segment-
routing-interworking best-effort host command. After an SR LSP is stitched to a proxy
egress LSP and a transit LSP, traffic over the LDP LSPs can enter the SR LSP.

Prerequisites
MPLS LDP has been enabled globally using the mpls command in the system view.
Example
# Enable a device to stitch SR LSPs to the proxy egress LSPs and transit LSPs that are
established over non-local host routes with 32-bit masks
[~HUAWEI] mpls
[*HUAWEI-mpls] lsp-trigger segment-routing-interworking best-effort host
1.3.26 mapping-server prefix-sid-mapping
Function
The mapping-server prefix-sid-mapping command configures mapping between a specific
or multiple pairs of prefixes and SIDs.
The undo mapping-server prefix-sid-mapping command deletes mapping between a

specific or multiple pairs of prefixes and SIDs.
By default, no mapping between prefixes and SIDs is configured.
Format
mapping-server prefix-sid-mapping ip-address mask-length begin-value [ range range-
value ] [ attached ]
undo mapping-server prefix-sid-mapping [ ip-address mask-length [ begin-value [ range

range-value ] [ attached ] ] ]
Parameters

ip-address Specifies the IP address of an interface. The value is in dotted
decimal notation.

Only the IP address with a 32-bit prefix can be
configured on a loopback interface.
begin-value Specifies a start SID value. The value is an integer

ranging from 0 to
l If a single prefix is configured, the start SID 65534.
value is set to the mapped prefix SID value.
l If prefixes are configured in a batch, the start
SID value is set to the mapped start prefix
SID value.


range range- Specifies the number of successive SIDs to be The value is an integer
value assigned. ranging from 1 to
65535.
attached Indicates whether the mapped prefix belongs to -

a local directly connected network.
Views
Default Level

segr write
Usage Guidelines
Usage Scenario
SIDs and advertise the mapping to the SR domain. This command is run on a mapping server.
Precautions
The Mapping SID is assigned to the IP address prefix with 32-bit mask only.
Example
# Configure mapping between two pairs of prefixes and SIDs. Prefixes 10.1.1.1/32 and
10.1.1.2/32 are assigned SIDs 16000 and 16001, respectively.
[~HUAWEI-segment-routing] mapping-server prefix-sid-mapping 10.1.1.1 32 16000
range 2 attached
1.3.27 match dscp (tunnel interface view)
Function
The match dscp command sets a DSCP value for IPv4 and IPv6 packets.
The undo match dscp command deletes the DSCP value for IPv4 and IPv6 packets.

By default, no DSCP value is specified for packets to be allowed to pass through an MPLS
SR-TE tunnel.
Format
match dscp { ipv4 | ipv6 } { default | { dscp-value1 | to dscp-value2 ] } &<1-32> }
undo match dscp { ipv4 | ipv6 } { [ default ] | { dscp-value1 | to dscp-value2 ] } &<1-32> }
Parameters
ipv4 Specifies a DSCP value of IPv4 packets that enter an -
MPLS SR-TE tunnel.
ipv6 Specifies a DSCP value of IPv6 packets that enter an -

MPLS SR-TE tunnel.
default Forwards traffic to pass through the default MPLS -

SR-TE tunnel if the traffic has the DSCP values that
do not match the specified value.
dscp-value1 Sets a start DSCP value for packets that enter an The value is an
MPLS SR-TE tunnel. integer ranging
from 0 to 63.
to dscp-value2 Sets an end DSCP value for packets that enter an The value is an
MPLS SR-TE tunnel. integer ranging
from 0 to 63.
Views
Tunnel interface view
Default Level

forwarding write
Usage Guidelines
Usage Scenario
In an SR-TE scenario, DSCP values can be set for packets so that the packets can pass
through tunnels that match the specified DSCP values. The priority setting in CBTS mode for
traffic transmitted over MPLS TE tunnels cannot meet service requirements because service

segments are increasing. Similar to CBTS, DSCP values can be set for IPv4 and IPv6 packets.
Each packet with a specified DSCP value enters a specific SR-TE tunnel.
Prerequisites
SR-TE tunnels have been configured on tunnel interfaces.
Precautions
The match dscp command takes effect on IPv4 and IPv6 services only in the EVPN L3VPN,
IP/L3VPN over SR-TE, and IP/L3VPN over LDP over SR-TE (on a node where LDP and
SR-TE LSPs overlap) scenarios.
l When L3VPNv4/v6 services are transmitted, they can enter intra-domain SR-TE tunnels
or inter-domain E2E SR-TE tunnels that match specified DSCP values in the following
scenarios:
– L3VPNv4/v6 over SR-TE and its load balancing scenarios
– L3VPNv4/v6 over LDP over SR-TE and its load balancing scenarios
l When IPv4 (IPv6) services are transmitted, they can enter intra-domain SR-TE tunnels
or inter-domain E2E SR-TE tunnels that match specified DSCP values in the following
scenarios:
– IPv4 (IPv6) over SR-TE scenario
– IPv4 (IPv6) over LDP over SR-TE scenario
If the match dscp command is run repeatedly on a tunnel interface, the latest configuration
overrides the previous one.
Both the match dscp ipv4 and match dscp ipv6 commands can be run to set a maximum of
32 DSCP values (DSCP ranges) in total.
The match dscp command is mutually exclusive with the service-class command on the SR-
TE tunnel interface. If both commands are run, an error message is displayed.
When IPv4 (IPv6) packets enter SR-TE tunnels based on DSCP values, a maximum of 16
public network tunnels that match the same DSCP value can work in load balancing mode.
Example
# Set a DSCP range from 20 to 30 for IPv4 packets that can pass through MPLS SR-TE
tunnels.
[~HUAWEI] mpls
[*HUAWEI-mpls] mpls te
[*HUAWEI-mpls] quit
[~HUAWEI] interface tunnel 102
[~HUAWEI-tunnel102] tunnel-protocol mpls te
[~HUAWEI-tunnel102] mpls te signal-protocol segment-routing
[*HUAWEI-tunnel102] match dscp ipv4 20 to 30
1.3.28 mpls sr ttl-mode

Function
The mpls sr ttl-mode command configures a mode for processing TTLs in packets
transmitted over SR-TE and SR-BE LSPs.
The undo mpls sr ttl-mode command restores the default mode for processing TTLs in
packets transmitted over SR-TE and SR-BE LSPs.

By default, the uniform mode is used to process TTLs in packets transmitted over SR-TE and
SR-BE LSPs.
Format
mpls sr ttl-mode { pipe | uniform }
undo mpls sr ttl-mode
Parameters

pipe Indicates the pipe mode used to process TTLs in packets transmitted -
over SR-TE and SR-BE LSPs.
uniform Indicates the uniform mode used to process TTLs in packets -
transmitted over SR-TE and SR-BE LSPs.
Views
MPLS view
Default Level

segr write
Usage Guidelines
Usage Scenario
TTLs in packets transmitted over SR-TE and SR-BE LSPs are processed in either of the
following modes:
l Uniform Mode
The IP TTL value reduces by one each time it passes through a node in an MPLS
network.
When IP packets enter the MPLS network shown in Figure 1-98, the ingress reduces the
IP TTL value by one and copies the IP TTL value to the MPLS TTL field. Each transit
node only processes the MPLS TTL. The egress reduces the MPLS TTL by one,
compares the MPLS TTL with the IP TTL, and obtains the smaller value to map it to the
IP TTL.

Figure 1-98 TTL processing in Uniform mode
MPLS
CE PE P PE CE
MPLS MPLS
TTL 254 TTL 253
IP TTL IP TTL IP TTL IP TTL
255 254 254 252
l Pipe Mode
The IP TTL value decreases by one only when passing through the ingress and egress.
On the network shown in Figure 1-99, the ingress reduces the IP TTL value in packets
by one and sets the MPLS TTL to a specific value. Transit nodes only process the MPLS
TTL. When the egress receives the packets, it removes the MPLS label carrying the
MPLS TTL from each packet and reduces the IP TTL value by one.
Figure 1-99 TTL processing in Pipe mode
MPLS
CE PE P PE CE
MPLS MPLS
TTL 100 TTL 99
MPLS MPLS
TTL 100 TTL 100
IP TTL IP TTL IP TTL IP TTL
255 254 254 253
When Virtual Circuit Connectivity Verification (VCCV) tracert is used to trace routes of MS-
PWs, all nodes on an LSP must use the same TTL processing mode. A mode inconsistency
causes a tracert failure.

If the TTL processing mode is changed to pipe on a node of an MPLS network, the tracert
and tracert lsp command output does not contain information about this node.
Example
# Configure the device to process TTLs in packets transmitted over an SR-LSP in pipe mode.
[~HUAWEI] mpls
[*HUAWEI-mpls] mpls sr ttl-mode pipe
1.3.29 mpls te bfd tunnel block
Function
The mpls te bfd tunnel block command blocks the one-arm BFD capability on a specified
SR-TE tunnel interface.
The undo mpls te bfd tunnel block command enables the one-arm BFD capability.
By default, the one-arm BFD capability of SR-TE tunnel interfaces is not blocked.
Format
mpls te bfd tunnel block
undo mpls te bfd tunnel block
Parameters
None
Views
Default Level

mpls-te write
Usage Guidelines
Usage Scenario
and protects traffic on the E2E SR-TE tunnels. After the mpls te bfd tunnel enable one-arm-

ehco command is run in the MPLS view, one-arm BFD is enabled for all E2E SR-TE tunnels.
To disable this function on a specified tunnel, run the mpls te bfd tunnel block command.
Precautions
The relationships between the mpls te bfd tunnel enable one-arm-echo and mpls te bfd
tunnel block commands are as follows:
l By default, if the mpls te bfd tunnel enable one-arm-echo command is run in the
MPLS view, one-arm BFD for SR-TE is still enabled on the tunnel interface.
l If the mpls te bfd tunnel block command is run in the tunnel interface view, one-arm
BFD for SR-TE is disabled even if the mpls te bfd tunnel enable one-arm-echo
command is run in the MPLS view.
NOTE
To enable one-arm BFD for SR-TE for a majority of tunnel interfaces, run the mpls te bfd tunnel block
command for each tunnel interface that does not need the function and then run the mpls te bfd tunnel
enable one-arm-echo command in the MPLS view.
To enable one-arm BFD for SR-TE for a small number of tunnel interfaces, run the mpls te bfd tunnel
enable one-arm-echo command on each of these interfaces.
Example
# Block the BFD capability on an E2E SR-TE tunnel interface named Tunnel1.
[~HUAWEI] mpls lsr-id 1.1.1.1
[*HUAWEI] mpls
[*HUAWEI-mpls] commit
[*HUAWEI] quit
[~HUAWEI] interface Tunnel1
[*HUAWEI-Tunnel1] tunnel-protocol mpls te
[*HUAWEI-Tunnel1] mpls te signal-protocol segment-routing
[*HUAWEI-Tunnel1] mpls te bfd tunnel block
1.3.30 mpls te bfd tunnel enable one-arm-echo
Function
The mpls te bfd tunnel enable one-arm-echo command enables one-arm BFD for SR-TE
tunnel.
The undo mpls te bfd tunnel enable one-arm-echo command disables one-arm BFD for
SR-TE tunnel.
Format
undo mpls te bfd tunnel enable one-arm-echo
Parameters
None

Views
MPLS view or tunnel interface view
Default Level

mpls-base write
Usage Guidelines
Usage Scenario
and protects traffic on the E2E SR-TE tunnels. To enable one-arm BFD for SR-TE tunnel, run
the mpls te bfd tunnel enable one-arm-echo command.
Precautions
The undo mpls te bfd tunnel enable one-arm-echo command in the tunnel interface view is
different from the mpls te bfd tunnel block command:
l After the undo mpls te bfd tunnel enable one-arm-echo command is run in the tunnel
interface view, the tunnel interface is still capable of one-arm BFD for SR-TE tunnel if
the mpls te bfd tunnel enable one-arm-ehco command is run in the MPLS view.
l If the mpls te bfd tunnel block command is run in the tunnel interface view, one-arm
BFD for SR-TE is disabled even if the mpls te bfd tunnel enable one-arm-ehco
command is run in the MPLS view.
l To enable one-arm BFD for SR-TE tunnel for a majority of tunnel interfaces, run the
mpls te bfd tunnel block command for each tunnel interface that does not need the
function and then run the mpls te bfd tunnel enable one-arm-echo command in the
MPLS view.
l To enable one-arm BFD for SR-TE tunnel for a small number of tunnel interfaces, run
the mpls te bfd tunnel enable one-arm-echo command on each of these interfaces.
Example
# Globally enable one-arm BFD for SR-TE tunnel.
[*HUAWEI] mpls
[*HUAWEI-mpls] mpls te bfd tunnel enable one-arm-echo
# Enable one-arm BFD for SR-TE tunnel on a tunnel interface named Tunnel1.
[*HUAWEI] mpls

[*HUAWEI] quit
[*HUAWEI-Tunnel1] mpls te bfd tunnel enable one-arm-echo
1.3.31 mpls te bfd tunnel enable seamless
Function
The mpls te bfd tunnel enable seamless command enables SBFD for SR-TE tunnel.
The undo mpls te bfd tunnel enable seamless command disables SBFD for SR-TE tunnel.
Format
mpls te bfd tunnel enable seamless
undo mpls te bfd tunnel enable seamless
Parameters
None
Views
Default Level

mpls-base write
Usage Guidelines
SBFD for SR-TE tunnel quickly detects faults on SR-TE tunnels. If the primary tunnel fails,
SBFD instructs applications such as VPN FRR to quickly switch traffic, minimizing the
impact on services.
Example
# Enable SBFD for SR-TE tunnel on a tunnel interface named Tunnel1.
[*HUAWEI] mpls

[*HUAWEI] quit
[*HUAWEI-Tunnel1] mpls te bfd tunnel enable seamless
1.3.32 mpls te bfd tunnel (segment routing)
Function
The mpls te bfd tunnel command sets BFD for SR-TE parameters.
The undo mpls te bfd tunnel command restores the default configuration.
By default, the minimum interval at which BFD packets are sent and the minimum interval at
which BFD packets are received are 10 ms, and the detection multiplier is 3 after BFD for
SR-TE is enabled.
Format
mpls te bfd tunnel { min-tx-interval tx-interval | min-rx-interval rx-interval | detect-
multiplier multiplier } *
undo mpls te bfd tunnel { min-tx-interval [tx-interval ] | min-rx-interval [ rx-interval ] |
detect-multiplier [ multiplier ] } *
Parameters
min-tx-interval tx- Specifies the minimum The value is an integer ranging
interval interval at which BFD packets from 3 to 20000, in milliseconds.
are sent.
min-rx-interval rx- Specifies the minimum The value is an integer ranging
interval interval at which BFD packets from 3 to 20000, in milliseconds.
are received.
detect-multiplier Specifies a BFD detection The value is an integer ranging
multiplier multiplier. from 3 to 50.
Views
Default Level

mpls-te write

Usage Guidelines
Usage Scenario
and protects traffic on the E2E SR-TE tunnels. To set BFD for SR-TE parameters, run the
mpls te bfd tunnel command.
Prerequisites
BFD has been enabled globally.
Precautions
The mpls te bfd tunnel command run in the MPLS view takes effect globally and that run in
the tunnel interface view takes effect only on a local interface and overwrites the BFD for SR-
TE parameters configured in the MPLS view.
The min-tx-interval tx-interval parameter does not take effect in one-arm BFD for SR-TE.
Example
# Set one-arm BFD for SR-TE parameters for a specified tunnel interface.
[*HUAWEI] mpls
[*HUAWEI] quit
[*HUAWEI-Tunnel1] mpls te bfd tunnel enable one-arm-echo
[*HUAWEI-Tunnel1] mpls te bfd tunnel min-rx-interval 500 detect-multiplier 5
# Set global one-arm BFD for SR-TE parameters.

[*HUAWEI] mpls
[*HUAWEI-mpls] mpls te bfd tunnel min-rx-interval 500 detect-multiplier 5
1.3.33 mpls te binding-sid
Function
The mpls te binding-sid command sets a binding SID for an SR-TE tunnel.
The undo mpls te binding-sid command deletes a binding SID for an SR-TE tunnel.
By default, no binding SID is set for an SR-TE tunnel.
Format
undo mpls te binding-sid label label-value

Parameters

label label-value Specifies a label value of a binding The value is an integer ranging from
SID. 16 to 1048575.
Views
Default Level

mpls-te write
Usage Guidelines
Usage Scenario
SID identifies an SR-TE tunnel and replaces the label stack of an SR-TE tunnel.
a large-scale network. The controller uses both binding SIDs and BGP peer SIDs to compute
a path over which an inter-AS E2E SR-TE tunnel is established.
Precautions
Binding SIDs are set only on SR-TE tunnels. If binding SIDs are referenced by an explicit
path, they cannot be modified or deleted, and the tunnel type cannot be modified.
Example
# Set a binding SID for an SR-TE tunnel.
[*HUAWEI] mpls
[*HUAWEI] quit
[*HUAWEI-Tunnel1] mpls te binding-sid label 1000

1.3.34 mpls te cspf path-selection adjacency-sid
Function
The mpls te cspf path-selection adjacency-sid command enables a device to run CSPF to
compute an LSP in an SR-TE strictly based on adjacency SIDs.
The undo mpls te cspf path-selection adjacency-sid command disables a device from
running CSPF to compute an LSP in an SR-TE strictly based on adjacency SIDs.
Format
mpls te cspf path-selection adjacency-sid
undo mpls te cspf path-selection adjacency-sid
Parameters
None
Views
Default Level

mpls-te write
Usage Guidelines
Usage Scenarios
If the SR-TE ingress computes path, to enable the ingress to run CSPF to compute an LSP in
an SR-TE strictly based on adjacency SIDs, run the mpls te cspf path-selection adjacency-
sid command.
Prerequisites
The following operations have been performed:
1. An MPLS TE tunnel has been established using the interface tunnel command.
2. MPLS TE has been configured as a tunneling protocol using the tunnel-protocol
command.
3. SR-TE has been configured using the mpls te signal-protocol segment-routing
command to establish TE tunnels.

Example
# Enable a device to run CSPF to compute an LSP in an SR-TE strictly based on adjacency
SIDs.
[*HUAWEI] mpls
[*HUAWEI] quit
[*HUAWEI-Tunnel1] mpls te cspf path-selection adjacency-sid
1.3.35 mpls te path verification disable

Function
The mpls te path verification disable command disables path verification for SR-TE
tunnels. If a label is defective, a device cannot set the LSP that uses the label to Down.
The undo mpls te path verification disable command restores the default configuration.
By default, the configuration of the mpls te path verification enable command takes effect.
Format
mpls te path verification disable
undo mpls te path verification disable
Parameters
None
Views
Default Level

mpls-base write
Usage Guidelines
Usage Scenario
The mpls te path verification disable command is primarily used together with the mpls te
path verification enable command run in the MPLS view. After the mpls te path

verification enable command is run in the MPLS view, the device verifies the path over
which an SR-TE tunnel is established. If a label is defective, the device sets the LSP that uses
the label to Down, preventing a traffic blackhole caused by a tunnel fault. If path verification
is not needed for some SR-TE tunnels, to disable this function, run the mpls te path
verification disable command.
Precautions
Path verification takes effect only on SR-TE tunnels.
Example
# Disable path verification for an SR-TE tunnel named Tunnel1.
[*HUAWEI] mpls
[*HUAWEI] quit
[*HUAWEI-Tunnel1] mpls te path verification disable
1.3.36 mpls te path verification enable
Function
The mpls te path verification enable command enables path verification for SR-TE tunnels.
If a label is defective, a device can set the LSP that uses the label to Down.
The undo mpls te path verification enable command disables path verification for SR-TE
tunnels. If a label is defective, a device cannot set the LSP that uses the label to Down.
By default, path verification is disabled for SR-TE tunnels.
Format
mpls te path verification enable
undo mpls te path verification enable
Parameters
None
Views
Default Level


mpls-base write
Usage Guidelines
Usage Scenario
SR-TE cannot detect tunnel status changes by itself. SR-TE uses the controller or BFD to
detect status changes. If neither a controller nor BFD is available, run the mpls te path
verification enable command to enable path verification for SR-TE tunnels. With this
function enabled, if a label becomes defective, the device sets the LSP that uses the label in an
SR-TE tunnel to Down, preventing a traffic blackhole caused by a tunnel fault.
If a controller or BFD is configured, run the undo mpls te path verification enable
command to disable path verificaiton.
Precautions
The MPLS view is used for global configuration, whereas the tunnel interface view is for
local configuration. The configuration in the tunnel interface view takes percendence over that
in the MPLS view. If a configuration in the MPLS view conflicts with that in the tunnel
interface view, the configuration in the tunnel interface view takes effect.
Path verification takes effect only on SR-TE tunnels.
Prerequisites
MPLS TE has been enabled globally using the mpls te command.
If the function is to be configured in the tunnel interface view, an SR-TE tunnel has been
configured using the mpls te signal-protocol segment-routing command.
Example
# Enable path verification for SR-TE tunnels globally.
[*HUAWEI] mpls
[*HUAWEI-mpls] mpls te path verification enable
# Disable path verification for an SR-TE tunnel named Tunnel1.

[*HUAWEI] mpls
[*HUAWEI] quit
[*HUAWEI-Tunnel1] mpls te path verification enable
1.3.37 mpls te reverse-lsp binding-sid

Function
The mpls te reverse-lsp binding-sid command sets a binding SID for a reverse SR-TE
tunnel.
The undo mpls te reverse-lsp binding-sid command deletes a binding SID for a reverse SR-
TE tunnel.
By default, no binding SID is set for a reverse SR-TE tunnel.
Format
undo mpls te reverse-lsp binding-sid label label-value
Parameters
label label-value Specifies the binding SID label value of a The value is an integer
reverse LSP in an SR-TE tunnel. ranging from 16 to 1048575.
Views
Default Level

mpls-te write
Usage Guidelines
Usage Scenario
A forward LSP and a reverse LSP between two nodes are established. Each LSP is bound to
the ingress of its reverse CR-LSP. The two LSPs then form an associated bidirectional tunnel.
The associated bidirectional tunnel is primarily used to prevent traffic congestion. If a fault
occurs on one end, the other end is notified of the fault so that both ends trigger traffic
switchovers, which ensures that traffic transmission is uninterrupted.
To set a binding SID for a reverse LSP in an SR-TE tunnel, run the mpls te reverse-lsp
binding-sid command. Using binding BIDs reduces the number of labels in a label stack on
an NE, which helps build a large-scale network. The controller uses both binding SIDs and
BGP peer SIDs to compute a path over which an inter-AS E2E SR-TE tunnel is established.
Precautions

Binding SIDs are set only on SR-TE tunnels. If binding SIDs are referenced by an explicit
path, they cannot be modified or deleted, and the tunnel type cannot be modified.
Example
# Set a binding SID of a reverse LSP in an SR-TE tunnel.
[*HUAWEI] mpls
[*HUAWEI] quit
[*HUAWEI-Tunnel1] mpls te reverse-lsp binding-sid label 2000
1.3.38 next sid label
Function
The next sid label command sets a next-hop label on an explicit path to be established using
labels configured in sequence.
undo next sid label command deletes a specified next-hop label from an explicit path.
By default, no next-hop label is specified on an explicit path.
Format
next sid label label-value type { adjacency | prefix | binding-sid }
undo next sid label label-value [ type { adjacency | prefix | binding-sid } ]
Parameters
label-value Specifies a label value. The value is an integer ranging from 16 to
1048575.
type Specifies a label type. -
adjacency Indicates an adjacency label. -
prefix Indicates a node label. -
binding-sid Indicates a binding SID. -
Views
Explicit path view
Default Level


mpls-base write
Usage Guidelines
Usage Scenarios
To set a next-hop label on an explicit path to be established using labels configured in

sequence, run the next sid label command. The command helps plan a labeled path for an
SR-TE tunnel to be established over an explicit path.
Prerequisites
MPLS TE has been enabled using the mpls te command in the MPLS view.
Follow-up Procedure
Run the display explicit-path command to view information about the explicit path.
Example
# Set an adjacency label to 284689 for an MPLS explicit path.
[~HUAWEI] mpls
[*HUAWEI-mpls] quit
[*HUAWEI] explicit-path path1
[*HUAWEI] next sid label 284689 type adjacency
Related Topics
explicit-path
1.3.39 ospf prefix-sid
Function
The ospf prefix-sid command configures the prefix segment ID (SID) for the IP address of
the loopback interface.
The undo ospf prefix-sid command deletes the prefix SID.
By default, no prefix SID is configured for the IP address of the loopback interface.
Format
ospf prefix-sid { absolute sid-value | index index-value } [ node-disable ]
undo ospf prefix-sid [ { absolute sid-value | index index-value } [ node-disable ] ]

Parameters
absolute sid- Specifies an absolute label value, which is effective The value will
value SID value. change dynamically,
depending on the
actual situation of
the equipment.
index index- Specifies a relative label value, also called an offset The value is an
value value. A relative label value plus the smallest value integer ranging from
in an SRGB is equal to an absolute value. Effective 0 to 65534.
SID value = index-value + Start SRGB value.
NOTE
The relative label value cannot be out of the SRGB
configured locally.
A relative label value must be unique in an OSPF process.
If index-value is specified, a local node advertises index-
value as a prefix SID. If sid-value is specified, a local node
advertises the prefix SID equal to sid-value minus the start
SRGB value.
node-disable Sets the node flag to 0. -

NOTE
This parameter disables the TI-LFA algorithm from
preferentially selecting nodes with the N flag set to 0.
Views
Loopback interface view
Default Level

ospf write
Usage Guidelines
Usage Scenario
To enable a device to advertise a prefix SID to network-wide routers, run the ospf prefix-sid
command to configure the prefix SID for the IP address of the loopback interface. The prefix
SID is used to forward packets along a calculated path.
Prerequisites

OSPF has been enabled on a loopback interface using the ospf enable command.
Segment routing has been enabled for a specific OSPF topology using the segment-routing
mpls command in an OSPF process.
Precautions
A loopback interface can be assigned an IP address. The prefix SIDs take effect only if an IP
address with a 32-bit mask is assigned to the loopback interface.
This command takes effect only on the primary IP address of a loopback interface.
If the prefix SID value beyonds the SRGB range, the prefix SID will not be advertised.
Example
# Set a prefix SID for the IP address of the loopback interface.
[*HUAWEI] ospf 1
[*HUAWEI-ospf-1] quit
[*HUAWEI] interface loopback0
[*HUAWEI-loopback0] ospf enable 1 area 1
[*HUAWEI-loopback0] ospf prefix-sid index 100
1.3.40 ospf ti-lfa disable
Function
The ospf ti-lfa disable command disables TI-LFA on an OSPF interface.
The undo ospf ti-lfa disable command enables TI-LFA on an OSPF interface.
By default, TI-LFA is enabled automatically on OSPF interfaces if the ti-lfa enable command
is run.
Format
ospf ti-lfa disable
undo ospf ti-lfa disable
Parameters
None
Views
Interface view
Default Level


ospf write
Usage Guidelines
Usage Scenario
After the ti-lfa enable command is run, TI-LFA is automatically enabled on all OSPF
interfaces. To disable TI-LFA on a specified interface, run the ospf ti-lfa disable command in
the interface view.
Precautions
If the ti-lfa enable command is not run, the OSPF ti-lfa disable command can be run but
cannot take effect on an interface.
If the ospf ti-lfa disable and ti-lfa enable commands are run in sequence, the ospf ti-lfa
disable command still takes effect.
Example
# Disable TI-LFA on an OSPF interface.
[*HUAWEI] ospf 1
[*HUAWEI-GigabitEthernet1/0/0] ospf ti-lfa disable
1.3.41 ospf ti-lfa disable multi-area
Function
The ospf ti-lfa disable multi-area command disables TI-LFA on an OSPF multi-area
interface.
The undo ospf ti-lfa disable multi-area command enables TI-LFA on an OSPF multi-area
interface.
By default, TI-LFA is enabled automatically on OSPF multi-area interfaces if the ti-lfa
enable command is run.
Format
ospf ti-lfa disable multi-area area-id
undo ospf ti-lfa disable multi-area area-id

Parameters

area-id Specifies the ID of an area in The value can be a decimal integer or an IP
which the OSPF TI-LFA is address. When the value is an integer, the
enabled. value ranges from 0 to 4294967295.
Views
Interface view
Default Level

ospf write
Usage Guidelines
Usage Scenario
After the ti-lfa enable command is run, TI-LFA is automatically enabled on all OSPF multi-
area interfaces. To disable TI-LFA on a specified multi-area interface, run the ospf ti-lfa
disable multi-area command in the interface view.
Precautions
If the ti-lfa enable command is not run, the ospf ti-lfa disable multi-area command can be
run but cannot take effect on an interface.
If the ospf ti-lfa disable and ti-lfa enable commands are run in sequence, the ospf ti-lfa
disable multi-area command still takes effect.
Example
# Disable TI-LFA on an OSPF multi-area interface.
[*HUAWEI] ospf 1
[*HUAWEI-GigabitEthernet1/0/0] ospf ti-lfa disable multi-area 1

1.3.42 peer egress-engineering
Function
The peer egress-engineering command enables BGP egress peer engineering (EPE).
The undo peer egress-engineering command disables BGP EPE.
By default, the function is disabled.
Format
peer ipv4-address egress-engineering
undo peer ipv4-address egress-engineering
Parameters
ipv4-address Specifies a BGP peer IP address. The value is in dotted decimal notation.
Views
BGP view
Level

bgp write
Usage Guidelines
Usage Scenario
The Border Gateway Protocol (BGP) is a dynamic routing protocol used between autonomous
systems (ASs). BGP EPE is a BGP extension to segment routing and is used to implement
source routing between ASs.
to the network controller. The controller properly orchestrates IGP SIDs and BGP peer SIDs
to implement inter-AS optimal path forwarding.
After the peer egress-engineering command is run, a local device can assign peer node
segment (peer-node SID) and peer adjacency segment (peer-Adj SID) values.
l A peer-node SID identifies a node on which a peer is configured.
l A peer-Adj SID identifies an adjacency to a peer.

Precautions
BGP EPE can take effect only after BGP-LS is enabled using the link-state-family unicast
command and segment routing is enabled using the segment-routing command.
Example
# Enable BGP EPE.
[*HUAWEI] bgp 100
[*HUAWEI-bgp] peer 10.1.1.1 as-number 200
[*HUAWEI-bgp] peer 10.1.1.1 egress-engineering
1.3.43 seamless-bfd (segment routing)

Function
The seamless-bfd command sets SBFD parameters for segment routing tunnels.
The undo seamless-bfd command deletes SBFD parameters for segment routing tunnels.
By default, no SBFD parameters are set for segment routing tunnels.
Format
seamless-bfd tunnel { min-rx-interval receive-interval | min-tx-interval transmit-interval |
detect-multiplier multiplier-value } *
undo seamless-bfd tunnel { min-rx-interval [ receive-interval ] | min-tx-interval
[ transmit-interval ] | detect-multiplier [ multiplier-value ] } *
Parameters
tunnel Indicates segment routing -
tunnels.
min-rx-interval Specifies the minimum interval The value is an integer ranging

receive-interval at which BFD packets are from 3 to 1000, in milliseconds.
received.
min-tx-interval Specifies the minimum interval The value is an integer ranging

transmit-interval at which BFD packets are sent to from 3 to 1000, in milliseconds.
the peer end.
detect-multiplier Specifies the local detection The value is an integer ranging

multiplier-value multiplier. from 3 to 50.
Views

Default Level

segr write
Usage Guidelines
Usage Scenario
the negotiation time and improves network-wide flexibility.To adjust SBFD parameters, run
the seamless-bfd command in the segment routing view to adapt to various networks.
Precautions
In the SBFD scenario, the min-rx-interval receive-interval parameter will not take effect.
Prerequisites
The bfd, sbfd, and seamless-bfd enable commands have been run.
Example
# Set the minimum interval at which SBFD packets are sent to monitor segment routing
tunnels to 300 ms.
[~HUAWEI] bfd
[~HUAWEI-bfd] quit
[~HUAWEI] sbfd
[~HUAWEI-sbfd] quit
[*HUAWEI-segment-routing] seamless-bfd enable mode tunnel
[*HUAWEI-segment-routing] seamless-bfd tunnel min-tx-interval 300
1.3.44 seamless-bfd enable

Function
The seamless-bfd enable command configures Seamless Bidirectional Forwarding Detection
(SBFD) for SR-BE tunnels.
The undo seamless-bfd enable command deletes the SBFD function for SR-BE tunnels.
By default, the SBFD function is disabled for SR-BE tunnels.
Format
seamless-bfd enable mode tunnel [ [ filter-policy ip-prefix ip-prefix-name ] | [ effect-sr-
lsp ] ] *

undo seamless-bfd enable mode tunnel [ [ filter-policy ip-prefix ip-prefix-name ] | [ effect-

sr-lsp ] ] *
Parameters
mode tunnel Indicates SR-BE tunnels. -
filter-policy Indicates a filter policy. -
ip-prefix ip-prefix- Specifies an IP prefix list. The name is a string of 1 to

name 169 case-sensitive characters,
with spaces not supported.
When double quotation marks
are used around the string,
spaces are allowed in the
string.
effect-sr-lsp Specify whether to affect the SR LSP. -
If the effect-sr-lsp parameter is
specified, if SBFD Down, SEGR
module cancels the SR LSP.
Views
Default Level

segr write
Usage Guidelines
Usage Scenario
the negotiation time and improves network-wide flexibility. To enable SBFD to monitor SR-
BE tunnels, run the seamless-bfd enable command.
Prerequisites
BFD and SBFD have been enabled using the bfd and sbfd commands, respectively.

Example
# Enable SBFD to monitor SR-BE tunnels.
[~HUAWEI] bfd
[~HUAWEI-bfd] quit
[~HUAWEI] sbfd
[~HUAWEI-sbfd] quit
[*HUAWEI-segment-routing] seamless-bfd enable mode tunnel
1.3.45 segment-routing
Function
The segment-routing command enables segment routing.
The undo segment-routing command disables segment routing.
By default, segment routing is disabled.
Format
segment-routing
undo segment-routing
Parameters
None
Views
System view
Default Level

cli write
Usage Guidelines
Usage Scenario
source routes. 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. To enable segment routing,
run the segment-routing command.

Ensure that segment routing has been disabled in the IS-IS process before you run the undo
segment-routing command in the system view.
Example
# Enable segment routing globally.
1.3.46 segment-routing auto-adj-sid disable

Function
The segment-routing auto-adj-sid disable command disables the dynamic adjacency label
capability.
The undo segment-routing auto-adj-sid disable command enables the dynamic adjacency
label capability.
By default, a device automatically computes a dynamic adjacency label once the node label
capability is enabled.
Format
segment-routing auto-adj-sid disable
undo segment-routing auto-adj-sid disable
Parameters
None
Views
IS-IS view
Default Level

isis write
Usage Guidelines
Usage Scenarios
In the SR-TE technique, an IGP collects network-wide topology information and assigns a
label to each router. Enabling segment routing for an IGP is mandatory. If IS-IS is used, to
disable the device from distributing adjacency labels, run the segment-routing auto-adj-sid
disable command in the IS-IS view.

Prerequisites
Segment routing has been enabled for a specific IS-IS topology using the segment-routing
mpls command.
Example
# Disable the dynamic adjacency label capability.
[~HUAWEI] isis
[*HUAWEI-isis-1] segment-routing auto-adj-sid disable
1.3.47 segment-routing global-block
Function
The segment-routing global-block command configures a segment routing global block
(SRGB) in an existing IS-IS/OSPF instance.
The undo segment-routing global-block command deletes an SRGB from an existing IS-IS/
OSPF instance.
By default, no SRGB is configured for an existing IS-IS/OSPF instance.
Format
segment-routing global-block begin-value end-value
undo segment-routing global-block [ begin-value end-value ]
Parameters

begin-value Sets a start label value in an SRGB. The value will change dynamically,
depending on the actual situation of
the equipment.
end-value Sets an end label value in an SRGB. The value will change dynamically,
depending on the actual situation of
NOTE
The maximum SRGB length of a single
the equipment.
process in an IS-IS or OSPF instance is
65535.
Views

Default Level

isis/ospf write
Usage Guidelines
Usage Scenario
To configure an SRGB in an existing IS-IS/OSPF instance, run the segment-routing global-
block command.
Precautions
The segment-routing global-block command is related to the prefix SID generation. The
prefix SID is used in an SR-BE or loose SR-TE scenario, and therefore, the segment-routing
global-block command must be run. If the segment-routing global-block command is not
run in an SR-BE or loose SR-TE scenario, segment routing does not take effect, whereas
segment routing configurations can be performed.
The SR route's next hop cannot recurse to a tunnel interface. If an SRGB-enabled IS-IS/OSPF
process is configured on an FA tunnel interface, traffic with SR labels may be discarded after
the SRGB is configured.
It is recommended that you set the same SRGB range on all devices to simplify network. If
only Huawei devices are deployed on the network, setting the SRGB to the range of 36000 to
47999 is recommended.
If the system displays a message indicating that the SRGB is used, run the display segment-
routing dynamic global-block command to view the SRGB ranges that can be set.
Alternatively, delete unwanted configurations related to the used label to release the label
space.
Example
# Configure an SRGB in an existing IS-IS instance. (The value range of SRGB changes
dynamically, depending on the actual situation of the equipment. Here is an example only.)
[~HUAWEI] isis 1
[*HUAWEI-isis-1] segment-routing global-block 153616 153800
# Configure an SRGB in an existing OSPF instance. (The value range of SRGB changes
dynamically, depending on the actual situation of the equipment. Here is an example only.)

[~HUAWEI] ospf 1
[*HUAWEI-ospf-1] segment-routing global-block 153616 153800
1.3.48 segment-routing lsp-trigger

Function
The segment-routing lsp-trigger command configures a policy for establishing SR-LSPs on
the ingress. This command enables the ingress to use IGP routes that match IP routes with 32-
bit masks or an IP prefix list to establish SR-LSPs.
The undo segment-routing lsp-trigger command restores the default policy.
By default, the ingress establishes SR-LSPs over IP routes with 32-bit masks.
Format
segment-routing lsp-trigger { none | host | ip-prefix ip-prefix-name }
undo segment-routing lsp-trigger [ none | host | ip-prefix ip-prefix-name ]
Parameters
none Disables the ingress from establishing SR- -
LSPs.
host Allows the ingress to use host routes with -
32-bit masks to establish SR-LSPs.
ip-prefix ip-prefix- Allows the ingress to use an IP prefix list The value is a string of 1
name to establish SR-LSPs. to 169 case-insensitive
characters, spaces not
supported.
Views
Default Level

isis/ospf write
Usage Guidelines
Usage Scenario

configured.
The segment-routing lsp-trigger command configures a policy to allow the ingress to use
specified routes to establish SR-LSPs. This prevents unwanted SR-LSPs from being
established and reduces resource wastes.
Prerequisites
Segment routing has been enabled using the segment-routing command.
Segment routing has been enabled for a specific IS-IS/OSPF topology using the segment-
routing mpls command.
If ip-prefix is to be used, an IP prefix list must have been created using the ip ip-prefix
command.
Precautions
The segment-routing lsp-trigger command takes effect on the ingress, not on transit nodes or
the egress.
Example
# Disables the ingress from establishing an SR-LSP by IS-IS.
[~HUAWEI] isis
[*HUAWEI-isis-1] segment-routing lsp-trigger none
# Disables the ingress from establishing an SR-LSP by OSPF.

[~HUAWEI] ospf
[*HUAWEI-ospf-1] segment-routing lsp-trigger none
1.3.49 segment-routing mapping-server
Function
The segment-routing mapping-server command enables a device to advertise or receive
SIDs.
The undo segment-routing mapping-server command disables a device from advertising or

receiving SIDs.
By default, the device is enabled to receive SIDs.

Format
segment-routing mapping-server { send | receive }
undo segment-routing mapping-server { send | receive }
Parameters
send Enables a local node to advertise the local SID label mapping -
messages. The local active prefix SIDs are carried in Label Mapping
messages to be advertised.
receive Enables a local node to receive remote SID label mapping messages. -
The local node parses SIDs carried in SID label mapping messages
sent by a remote label mapping server.
Views
Default Level

isis/ospf write
Usage Guidelines
SIDs and advertise the mapping to the SR domain. The segment-routing mapping-server
command enables a local device to advertise or receive the SID label mapping.
Example
# Enable a local IS-IS node to advertise local SID label mapping messages.
[~HUAWEI] isis 1
[~HUAWEI-isis-1] segment-routing mpls
[~HUAWEI-isis-1] segment-routing mapping-server send
# Enable a local IS-IS node to receive remote SID label mapping messages.

[~HUAWEI] isis 1
[~HUAWEI-isis-1] segment-routing mpls
[~HUAWEI-isis-1] segment-routing mapping-server receive
# Enable a local OSPF node to advertise local SID label mapping messages.
[~HUAWEI] ospf 1
[~HUAWEI-ospf-1] opaque-capability enable
[~HUAWEI-ospf-1] segment-routing mpls
[~HUAWEI-ospf-1] segment-routing mapping-server send
1.3.50 segment-routing mpls
Function
The segment-routing mpls command enables segment routing for an IS-IS/OSPF process.
The undo segment-routing mpls command disables segment routing for an IS-IS/OSPF
process.
By default, segment routing is disabled for IS-IS/OSPF processes.
Format
undo segment-routing mpls
Parameters
None
Views
Default Level

isis/ospf write
Usage Guidelines
Usage Scenario

In segment routing implementation, an IGP is used to collect topology information and

allocate labels for each router. Therefore, segment routing must be enabled for the IGP. If IS-
IS is used as the IGP, run the segment-routing mpls command in the IS-IS view to enable
segment routing. If OSPF is used as the IGP, run the segment-routing mpls command in the
OSPF view to enable segment routing.
Prerequisites
Segment routing has been enabled globally if IS-IS is used as the IGP, and the device has been
enabled to receive and send only the routes with the cost type being wide using the cost-style
command.
Segment routing has been enabled globally if OSPF is used as the IGP, and opaque LSA has
been enabled using the opaque-capability enable command.
Example
# Enable segment routing for an IS-IS process.
[*HUAWEI] isis
# Enable segment routing for an OSPF process.

[~*HUAWEI] segment-routing
[*HUAWEI] ospf 1
1.3.51 sr-te-simulate static-cr-lsp transit
Function
The sr-te-simulate static-cr-lsp transit command enables an SR-TE-incapable device on an
SR-TE network to simulate an SR-TE transit node to perform link label-based forwarding.
The undo sr-te-simulate static-cr-lsp transit command disables an SR-TE-incapable device

on an SR-TE network from simulating an SR-TE transit node to perform link label-based
forwarding.
By default, no SR-TE-incapable device is enabled to simulate an SR-TE transit node to

perform link label-based forwarding.
Format
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
undo sr-te-simulate static-cr-lsp transit lsp-name

Parameters
lsp-name Specifies the name of a CR-LSP. The value is a string of 1
to 19 case-sensitive
characters, spaces not
supported.
NOTE
The string can contain
spaces if it is enclosed with
double quotation marks (").
incoming-interface Specifies the type and number of an -

interface-type inbound interface. This parameter can
interface-number be configured only when a P2P link is
used.
sid segmentid Sets a label value in a segment label The value is an integer
stack. ranging from 16 to
1048575.
nexthop next-hop- Specifies a next-hop IP address. -
address
outgoing-interface Specifies the type and number of an -
interface-type outbound interface. This parameter can
interface-number be configured only when a P2P link is
used.
out-label implicit- Indicates an outgoing implicit-null -
null label.
Views
System view
Default Level

mpls-te write
Usage Guidelines
Usage Scenario
To enable an SR-TE-incapable device on an SR-TE network to simulate an SR-TE transit

node to perform link label-based forwarding, run the sr-te-simulate static-cr-lsp transit
command. The command tackles the forwarding issue on the SR-TE-incapable device.

To modify the inbound interface name, segment label value, next-hop IP address, outbound
interface name, or outbound interface name, run the sr-te-simulate static-cr-lsp transit
command to set a new value. There is no need to run the undo sr-te-simulate static-cr-lsp
transit command before changing a setting. These parameters can be dynamically updated.
Prerequisites
MPLS TE has been enabled globally using the mpls te command.
Example
# Enable an SR-TE-incapable device to simulate an SR-TE transit node to perform link label-
based forwarding, with a stack CR-LSP named Tunnel20, the inbound interface named GE
2/0/0, the segment ID of 253, the outbound interface named GE 2/0/1, and the next-hop IP
address of 3.3.3.3.
[*HUAWEI] mpls
[*HUAWEI] quit
[~HUAWEI] sr-te-simulate static-cr-lsp transit tunnel20 incoming-interface
gigabitethernet2/0/0 sid 253 outgoing-interface gigabitethernet2/0/1 nexthop
3.3.3.3 out-label implicit-null
1.3.52 ti-lfa (IS-IS)
Function
The ti-lfa command enables IS-IS topology independent-loop free alternate (TI-LFA).
The undo ti-lfa command disables IS-IS TI-LFA.
By default, IS-IS TI-LFA is disabled.
Format
ti-lfa [ level-1 | level-2 | level-1-2 ]
undo ti-lfa [ level-1 | level-2 | level-1-2 ]
Parameters

level-1 Enables or disables IS-IS Level-1 TI-LFA. -
level-2 Enables or disables IS-IS Level-2 TI-LFA. -
level-1-2 Enables or disables IS-IS Level-1-2 TI-LFA. -
NOTE
If no level is specified, IS-IS Level-1-2 TI-LFA is enabled by default.

Views
IS-IS FRR view
Default Level

isis write
Usage Guidelines
Usage Scenario
resulting in a failure to meet reliability requirements.
To satisfy network reliability requirement, TI-LFA is configured to pre-calculate backup links.

If a fault occurs, traffic rapidly switches to a backup link before convergence on the control
plane is complete. The TI-LFA algorithm is used to calculate the backup links. This algorithm
excludes the next hop on the primary LSP or the primary link, re-calculates a shortest path
tree (also called a post-convergence tree), and selects a P node and a Q node along the tree.
Based on the P and Q node information (see TI-LFA FRR), a label stack for a backup tunnel
is generated.
Prerequisites
Global segment routing has been enabled using the segment-routing command.
FRR has been enabled and the FRR view has been displayed using the frr command, and IS-
IS LFA has been enabled using the loop-free-alternate command.
Precautions
The level specified in the ti-lfa command depends on the level configured in the loop-free-
alternate command. TI-LFA can take effect in a level-specific IS-IS area only after the level-
specific LFA is enabled.
Example
# Enable IS-IS Level-2 TI-LFA.
[~HUAWEI] isis
[*HUAWEI-isis-1] frr
[*HUAWEI-isis-1-frr] loop-free-alternate level-2
[*HUAWEI-isis-1-frr] ti-lfa level-2

1.3.53 ti-lfa enable (OSPF)
Function
The ti-lfa enable command enables OSPF topology independent-loop free alternate (TI-LFA).
The undo ti-lfa enable command disables OSPF TI-LFA.
By default, OSPF TI-LFA is disabled.
Format
ti-lfa enable
undo ti-lfa enable
Parameters
None
Views
OSPF FRR view
Default Level

ospf write
Usage Guidelines
Usage Scenario

Based on the P and Q node information (see TI-LFA FRR), a label stack for a backup tunnel
is generated.
Prerequisites
Global segment routing has been enabled using the segment-routing command.

FRR has been enabled and the FRR view has been displayed using the frr command, and
OSPF LFA has been enabled using the loop-free-alternate command.
Example
# Enable OSPF TI-LFA.
[~HUAWEI] ospf 1
[*HUAWEI-ospf-1] frr
[*HUAWEI-ospf-1-frr] loop-free-alternate
[*HUAWEI-ospf-1-frr] ti-lfa enable
1.3.54 tunnel-prefer segment-routing

Function
The tunnel-prefer segment-routing command enables SR-BE tunnels to take precedence
over LDP tunnels.
The undo tunnel-prefer segment-routing command disables SR-BE tunnels from taking
precedence over LDP tunnels.
By default, LDP tunnels take precedence over SR-BE tunnels.
Format
undo tunnel-prefer segment-routing
Parameters
None
Views
Default Level

segr write
Usage Guidelines
Usage Scenario
default. To enable a device to preferentially select an SR-BE tunnel, run the tunnel-prefer
segment-routing command.

Example
# Enable SR-BE tunnels to take precedence over LDP tunnels.
[~HUAWEI-segment routing] tunnel-prefer segment-routing
[*HUAWEI-segment routing] commit

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 based on source routes. IPv6 forwarding plane-based SRv6 enables the ingress to add
a segment routing header (SRH) into IPv6 packets. An explicit IPv6 address stack is pushed
into the SRH. Transit nodes continue to update IPv6 destination IP addresses and offset the
address stack to implement per-hop forwarding.
Purpose
Future networks will be 5G oriented. Bearer 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 impalement
VPNs. The SRv6 technique uses the 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:
l Streamlines network configurations to more easier to 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 forwarding.
Transit nodes can be incapable of SRv6 and forward IPv6 packets carrying the SRH over
routes.

l Provides topology independent-loop-free alternate (TI-LFA), which improves FRR

protection.
SRv6, in combination with the RLFA algorithm, supports any topology in theory and
overcomes drawbacks in conventional tunnel protection.
l Facilitates traffic optimization on IPv6 forwarding paths.
SIDs with various service types are used to flexible plan explicit paths on the ingress to
adjust service traffic.
2.1.2 Understanding Segment Routing IPv6
2.1.2.1 Segment Routing IPv6 Fundamentals
SRH
An IPv6 packet consists of a standard IPv6 header, extended headers (0...n), and payload. To
implement Segment Routing IPv6 (SRv6) based on the IPv6 forwarding plane, an IPv6
extension header, called segment routing header (SRH), is added. An SRH specifies an
explicit path and stores IPv6 segment list information. The contained IPv6 segment lists
function the same as those contained in SR MPLS.
The ingress adds an SRH to an IPv6 packet, and each transit node forwards the packet based
on path information carried in the SRH. Figure 2-1 shows the SRH header format.
Figure 2-1 SRH format
IPv6 Packet Header Segment Routing Header IPv6 Payload
0 7 15 23 31
Next Header Hdr Ext Len Routing Type Segments Left
Last Entry Flags Tag
Segment List [0] (128 bits IPv6 address)
...
Segment List [n] (128 bits IPv6 address)

Table 2-1 describes the meanings of fields carried in an SRH.
Table 2-1 Meanings of fields in an SRH
Next Header 8 bits Header type following an SRH.
Hdr Ext Len 8 bits SRH header length. It covers the length from Segment List
[0] to Segment List [n].
Routing 8 bits Route header type. Value 4 identifies an SRH type.

Type
Segments 8 bits Number of transit nodes between the existing node and the
Left egress.
Last Entry 8 bits Index of the last segment in a segment list.
Flags 8 bits Identifiers in a data packet.
Tag 16 bits Same group of packets.
Segment 128xn bits Label segment list. A segment list is numbered from the last
List[n] segment of a path. The Segment List is in the format of an
IPv6 address.
Figure 2-2 shows the abstract SRH format.
Figure 2-2 Abstract SRH format
IPv6 Destination Address=Segment List [n]
SRH(Segments Left=n)
<Segment List [0], Segment List [1], Segment
List [2], ..., Segment List [n]>
The meaning of each field is as follows:

l IPv6 Destination Address: IPv6 destination address in a packet. It is also called IPv6
DA. The IPv6 DA is a fixed value in an ordinary IPv6 packet. In SRv6, an IPv6 DA only
identifies a next hop of an existing packet and is changeable.
l <Segment List [0], Segment List [1], Segment List [2],..., Segment List [n]>: SRv6
packet segment list. Similar to an MPLS label stack in SR MPLS, it is generated on the
ingress. A segment list is numbered from the last segment of a path. Segment List [0]
identifies the last segment of a path; Segment List [1] identifies the penultimate segment
of the path; Segment List [n] identifies the last n+1st segment, and so on. These lists are
pushed into a label stack in a down-top order and numbered in an ascending order.
As shown in Figure 2-3, each time a packet passes through an SRv6 node, the Segments Left
(SL) field value decreases by 1, and the IPv6 DA changes. Both the Segments Left and
Segments List fields determine IPv6 DA information.

l If the SL value is n, the IPv6 DA value is equal to the Segments List [n] value.
l ...
l If the SL value is 1, the IPv6 DA value is equal to the Segments List [1] value.
l If the SL value is 0, the IPv6 DA value is equal to the Segments List [0] value.
Figure 2-3 IPv6 DA transformation
Ingress Segment Segment Segment Segment

List [0] List [1] List [2] ... List [n]
IPv6 DA= IPv6 DA= IPv6 DA= IPv6 DA=

Segment List [0] Segment List [1] Segment List [2] Segment List [n]
SRH(SL=n) SRH(SL=n-1) SRH(SL=n-2) SRH(SL=0)
(Segment List [n] (Segment List [n] (Segment List [n] (Segment List [n]
..., ..., ..., ...,
Segment List [2], Segment List [2], Segment List [2], Segment List [2],
Segment List [1], Segment List [1], Segment List [1], Segment List [1],
Segment List [0]) Segment List [0]) Segment List [0]) Segment List [0])
SRv6 Segment
An SRv6 segment is in IPv6 address format, which is also called an SRv6 segment identifier
(SID). Each SRv6 SID consists of the Locator and Function parts, expressed in the
Locator:Function format, as shown in Figure 2-4. The Locator part occupies the most
significant bits of an IPv6 address, and the Function part occupies the remaining bits.
Figure 2-4 SRv6 SID
128 bits
Locator Function (Arguments)
The Locator part enables a node to be located by the other nodes and must be unique in an SR
domain. After a locator is configured for a node, the system generates a locator network
segment route and advertises the route information within the SR domain through an IGP. The
other nodes on the network obtain and use the route information to locate the node. In
addition, all the SRv6 SIDs advertised by the node can be reached through the route. The
Function part identifies a preset device instruction that instructs the SRv6 SID generation
node to implement the corresponding function. You can also define an optional Arguments
part following the Function part, occupying the least significant bits of the IPv6 address. If
this is the case, the SRv6 SID is expressed in the Locator:Function:Arguments format. The
Arguments part is used to define packet flow and service information. The Function and
Arguments parts can both be defined, indicating that the SRv6 SID structure facilitates
network programmability.
An SRv6-capable node maintains a local SID table. This table contains all SRv6 SID
information generated by the local node. Based on the table, the local node generates an SRv6
forwarding information base (FIB). The local SID table provides the following functions:

l Defines locally generated SIDs, for example, End.X SID.

l Specifies which instruction is bound to the SID.
l Stores the parameters associated with the instruction, such as the outbound interface and
next hop.
SRv6 SIDs are of various types. Each type of SRv6 SID indicates a specific function. Table
2-2 lists SRv6 segment types.
Table 2-2 SRv6 SID types

Label Function Example
End SID Endpoint SID, which is used to identify the prefix of a Figure 2-5
destination address on a network. The End SID is similar to
the Prefix SID in SR MPLS.
An IGP floods the End SID to the other NEs. The End SID is
visible globally and takes effect globally.
End.X Endpoint SID of a Layer 3 cross-connection, which is used to Figure 2-6

SID identify a link on a network. The End.X SID is similar to
Adjacency SID in SR MPLS.
An IGP floods the End.X SID to the other NEs. The End.X
SID visible globally and takes effect locally.
End.DT4 An End.DT4 SID stands for a PE endpoint SID that identifies Figure 2-7
SID an IPv4 VPN instance on a network. The forwarding behavior
mapped to an End.DT4 SID is to decapsulate packets and
search the routing table of an IPv4 VPN instance for an entry
to forward the packets. The End.DT4 SID is an equivalence to
an IPv4 VPN label used in VPN scenarios.
End.OTP An End.OTP SID (OAM Endpoint with Timestamp and Punt) Figure 2-8
SID is an OAM SID that implements the timestamp and punt
behavior for an OAM packet. It is used in ping and tracert
scenarios. On the network shown in Figure 2-8, 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 responds to the ICMPv6 Echo Request packet sent by
node A. When constructing the packet, node A needs to insert
End.OTP 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.OTP 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-5 End SID
A:: B:: C::

Figure 2-6 End.X SID
A::
A::1 A::2
A::3
Figure 2-7 End.DT4 SID

END.DT4 SID END.DT4 SID
A1::1:100 PE1 P PE2 A1::2:100
IPv4 VPNA IPv4 VPNA
IPv4 VPNB IPv4 VPNB

END.DT4 SID SRv6 END.DT4 SID
A2::1:100 A2::2:100
Figure 2-8 End.OTP SID
IPv6 SA=A1:1::
IPv6 DA=A4:4::1
SRH(SL=1)
(A4:4::45,A4:4::1,
A2:2::23)
ICMPv6 Echo
IPv6 SA=A1:1:: Request
IPv6 DA=A2:2::23
END.OTP SID
SRH(SL=2) A4:4::1
(A4:4::45,A4:4::1,
A2:2::23) B C D
END.X SID
ICMPv6 Echo A2:2::23
Request END.X SID
A4:4::45
A IPv6-Capable only E
A1:1:: A:5::
2.1.2.2 SRv6-BE
2.1.2.2.1 Introduction to IPv4 VPN over SRv6-BE
IPv4 VPN over SRv6-BE (SRv6-BE VPN) transmits IPv4 VPN data along SRv6-BE paths.
Table 2-3 describes the comparison between the SRv6-BE VPN and BGP/MPLS IPv6 VPN.
Table 2-3 Comparison between the SRv6-BE VPN and BGP/MPLS IPv6 VPN
Item SRv6-BE VPN BGP/MPLS IPv6 VPN
VPN service type IPv4 VPN over SRv6-BE IPv6 VPN over MPLS tunnel

Item SRv6-BE VPN BGP/MPLS IPv6 VPN
VPNv4 route RD: identifies a specified VPN RD: identifies a specified VPN
identifier and address space. address space.
crossing RT: the local import RT must be RT: the local import RT must be
the same as the peer export RT. the same as the peer export RT.
Route transfer The IPv6 peer relationship is The IPv4 peer relationship is
enabled in the BGP VPNv4 enabled in the BGP VPNv6
address family to transfer IPv4 address family to transfer IPv6
route information. route information.
Public network route BGP + IS-IS BGP + IGP or static route

interworking
VPN label VPN labels do not exist. SRv6 BGP assigns VPN labels.
VPN SIDs are used instead. VPN labels are inner labels
carried in BGP/MPLS IPv6
VPN public-network packets
and used to identify VPN
instances.
MPLS label MPLS labels do not exist. MPLS LDP or TE assigns

labels.
MPLS labels are outer labels
carried in BGP/MPLS IPv6
VPN public-network packets
and used to identify tunnels.
Private network table The egress removes SRv6 VPN The egress removes MPLS
lookup SIDs, identifies VPN instances labels and VPN labels,
based on SRv6 VPN SIDs, and identifies VPN instances based
searches the local SID table of on VPN labels, searches VPN
each VPN instance. routing tables, and forwards
packets over IP.
Figure 2-9 shows the typical SRv6-BE VPN networking.

Figure 2-9 Typical SRv6-BE VPN networking
Site 1 Site3
CE CE
VPN1 MP-BGP VPN2

IPv4 SRv6 IPv4
VPN2 PE P PE VPN1
IPv4 IPv4
CE CE
Site 2 Site4
SRv6-BE VPN characteristics are as follows:

l Transmits packets using extended BGP.
l Encapsulates and transmits private network data packets over SRv6-BE.
l Allows a device that may play PE, P, and CE roles to play only a single role at a time.
2.1.2.2.2 IPv4 VPN over SRv6-BE Implementation Process
The implementation of IPv4 VPN over SRv6-BE involves establishing SRv6-BE paths,
implementing VPN route interworking, and forwarding data.
Figure 2-10 shows the implementation of IPv4 VPN over SRv6-BE.
Figure 2-10 IPv4 VPN over SRv6-BE implementation
MP-BGP
SRv6
VPN1 VPN1
IPv4 IPv4
CE1 PE1 P PE2 CE2

1 Configure SRv6 VPN. 1 Configure SRv6 VPN.
2 Advertises SRv6 Advertises SRv6

3 Advertises
VPN SIDs VPN SIDs. IPv4 routes.
Install VPN instance routes
4 and generates VPNv4 routes.
5 Advertises VPNv4 routes carrying VPN SIDs.
Receives VPNv4 routes and

6 install VPN instance routes
carrying SRv6 VPN SIDs.
7 Advertises
IPv4 routes.
IPv4 VPN over SRv6-BE implementation is as follows:

1. SRv6 and SRv6 VPN functions are configured on each PE, and IPv6 must be supported
on intermediate devices.
2. CEs and PEs exchange route information.
CE2 advertises an IPv4 route to the local site to PE2. The CEs can communicate with the
PEs over static routes or routes created using RIP, OSPF, IS-IS, or BGP.
3. PEs advertise route information to each other.
After learning VPN route information advertised by CE2, PE1 installs these routes to
VRF routing tables. PE1 then converts them to VPNv4 routes and runs MP-BGP to
advertise them to the egress PE1. Update packets carry the RT attribute and SRv6 VPN
SID attribute.
4. PE1 receives VPNv4 route information.
If the next hop carried in the VPNv4 route is reachable and the route matches the BGP
import policy, PE1 injects the route into the local routing table, iterates the route to an
SRv6-BE path, and filters the route based on a VRF import policy. PE1 then decides
whether to add the route to its VRF routing table. The VPN route to be delivered is
associated with an SRv6 VPN SID.
5. CEs and PEs exchange route information.
CE1 can learn VPN routes from PE1 over static routes or routes established using RIP,
OSPF, IS-IS, or BGP. Route advertisement from CE2 to PE2 is similar to that from CE1
to PE2.
Figure 2-11 describes the process of advertising the routes and forwarding data in IPv4 VPN
over SRv6-BE.
Figure 2-11 Process of advertising the routes and forwarding data in IPv4 VPN over SRv6-
BE
Configure Locator A2:1::.

Configure Locator A1::/64. Generate END SID A2:1::1.
Generate END SID A1:1::1. Configure VPN SID A2:1::B100.
Locator Opcode
MP-BGP
END.DT4 SID A2:1::B100
SRv6
VPN1 VPN1
IPv4 IPv4
CE1 PE1 P PE2 CE2

A
d
Advertises an IS-IS Advertises an IS-IS v
e R
route to A2:1::/64. route to A2:1::/64. rt o
is u
Advertises an Advertises a VPNv4 route to 2.2.2.2/32. Advertises an e m
te
IPv4 route to Next-hop A2:1::, VPN SID A2:1::B100 IPv4 route to e
2.2.2.2/32. 2.2.2.2/32.
n
t
SA=A1:1::1 SA=A1:1::1
g
a in DA=A2:1::B100 DA=A2:1::B100
t d
r SA=1.1.1.1 SA=1.1.1.1 SA=1.1.1.1 SA=1.1.1.1
a a DA=2.2.2.2
D w DA=2.2.2.2 DA=2.2.2.2 DA=2.2.2.2
o Payload Payload Payload Payload
F
In the route advertisement phase:

1. An END.SID is set on PE2 and advertised to PE1 using an IGP.

2. PE1 runs an IGP to learn the network segment route to A2:1::/64 that is mapped to the
SRv6 SID.
3. PE2 automatically generates an END.DT4 SID of A2:1::B100 within the END.SID
range for the VPN instance and a local SID table.
4. After receiving the VPNv4 route advertised by CE2, PE2 converts it to a BGP VPNv4
route and advertises the route to PE1 through a BGP peer relationship. The route carries
the SRv6 VPN SID that is the END.DT4 SID of A2:1::B100 in the VPN instance.
5. Upon receipt of the VPNv4 route, PE1 injects the route to the VRF routing table,
converts it to 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 private network packet on an interface bound to a VPN instance, PE1
searches a VRF routing table for an IPv4 prefix matching the destination and finds an
associated SRv6 VPN SID and next hop information. PE1 encapsulates the SRv6 VPN
SID of A2:1::B100 as a destination address into the IPv6 packet.
3. PE1 finds the route to A2:1::/64 based on the longest match rule and forwards the packet
to the P over the shortest path.
4. The P finds the route to A2:1::/64 based on the longest match rule and forwards the
packet to PE2 over the shortest path.
5. PE2 searches the local SID table for a behavior matching A2:1::B100, removes the IPv6
packet header, matches the packet against a VPN instance based on the END.DT4 SID,
and searches for a matching entry in the VRF routing table for forwarding. The packet is
restored to a common IPv4 packet.
2.1.2.3 SRv6-TE
2.1.2.3.1 SRv6-TE Tunnel Creation
An SRv6-TE tunnel is configured based on a TE explicit path. The ingress runs CSPF to
compute a path. The End SID and END.X SID are primarily used. The whole TE explicit path
can use End SIDs only, End.X SIDs only, or the combination of these two types of SIDs.
SRv6-TE tunnel creation involves configuring and establishing a tunnel. Figure 2-12
illustrates the process of establishing an SRv6-TE tunnel.

Figure 2-12 Process of establishing an SRv6-TE tunnel
EMS/NMS
1
3
B D F
A 2 Z
C E G
IGP and SRv6 configuration

IGP flooding
SRv6 tunnel configuration
1. IPv6 IGP neighbor relationships are established to implement connectivity at the

network layer and collect network topology information on nodes. SRv6 is enabled on
nodes to assign SIDs.
2. An IGP floods the topology information and SIDs across the whole network.
3. Attributes and an explicit path of an SRv6-TE tunnel are configured on the ingress.
4. The ingress uses the configurations to compute a path for the SRv6-TE tunnel. The
ingress directs traffic to the SRv6-TE tunnel for forwarding.
2.1.2.3.2 SRv6-TE Data Forwarding
SRv6-TE data is forwarded based on End SIDs and End.X SIDs. After receiving SRv6
packets, a node searches the local SID table based on IPv6 destination addresses (IPv6 DAs)
and checks whether End or End.X SIDs are used.
l If End SIDs are used, the node searches the IPv6 FIB table, finds a matching outbound
interface and a next hop, and forwards the packets.
l If End.X DISs are used, the node forwards the packets through an outbound interface to
a next hop specified in an End.X SID.
End SID-based data forwarding

Figure 2-13 demonstrates the process of forwarding data based on End SIDs:
1. Node A pushes an SRH into a data packet. The path information is <Z::, F::, D::, B::>,
and the IPv6 DA is B::.
2. Each time the packet passes through a node, for example, nodes B and D, a node
searches the local SID table based on the IPv6 DA, checks the End type, searches the

IPv6 FIB table, finds a matching outbound interface and next hop, reduces the SL value
by one, and changes the IPv6 DA at a time.
3. After the packet arrives at node F, node F searches the local SID table based on the IPv6
DA, checks that the End type is used, continues to query the IPv6 FIB table, and finds
the outbound interface. In addition, node F reduces the SL value 0 and changes the IPv6
DA to Z::. The path information <Z::, F::, D::, B::> becomes meaningless, and therefore,
node F uses the PSP to remove SRH path information and forward the packet to node Z.
Figure 2-13 End SID-based data forwarding

IPv6 DA=D:: IPv6 DA=F::
SRH(SL=2) SRH(SL=1)
(Z::,F::,D::,B::) (Z::,F::,D::,B::)
Payload Payload
IPv6 DA=B:: End SID B:: End SID D:: End SID F::
SRH(SL=3) B D F
(Z::,F::,D::,B::) IPv6 DA=Z::
Payload Payload
A Z
End SID A:: End SID Z::
C E G
End SID C:: End SID E:: End SID G::
End.X SID-based data forwarding

Figure 2-14 demonstrates the process of forwarding data based on End.X SIDs:
1. Node A pushes an SRH into a data packet. The path information is <Z::, F::1, B::1>, and
the IPv6 DA is B::1.
2. After the packet arrives at node B, node B searches the local SID table based on the IPv6
DA, checks that the End.X type is used, forwards the packet through an outbound
interface to a next hop, reduces the SL value by one, and changes the IPv6 DA to F::1.
3. After the packet arrives at node D, node D searches the local SID table based on the IPv6
DA of F::1, finds no match, continues to use the IPv6 DA to query the IPv6 FIB table,
and finds a matching entry to forward the packet to node F.
interface to a next hop, reduces the SL value to 0, and changes the IPv6 DA to Z::. The
path information <Z::, F::1, B::1> becomes meaningless, and therefore, node F uses the
PSP to remove SRH path information and forward the packet to node Z.

Figure 2-14 End.X SID-based data forwarding

IPv6 DA=F::1 IPv6 DA=F::1
SRH(SL=1) SRH(SL=1)
(Z::,F::1,B::1) (Z::,F::1,B::1)
Payload Payload
IPv6 DA=B::1
End SID B:: End SID D:: End SID F:: IPv6 DA=Z::
SRH(SL=2) B End.X D F
(Z::,F::1,B::1) SID B::1 Payload
Payload
A Z
C E G
Data forwarding based on End SIDs and End.X SIDs

Figure 2-15 demonstrates the process of forwarding data based on End SIDs and End.X SIDs:
1. Node A pushes an SRH into a data packet. The path information is <Z::, F::, B::1>, and
the IPv6 DA is B::1.
2. After the packet arrives at node B, node B searches the local SID table based on the IPv6
interface to a next hop, reduces the SL value by one, and changes the IPv6 DA to F::.
3. After the packet arrives at node D, node D searches the local SID table based on the IPv6
DA of F::, finds no match, continues to use the IPv6 DA to query the IPv6 FIB table, and
finds a matching entry to forward the packet to node F.
DA, checks that the End type is used, continues to query the IPv6 FIB table, and then
forwards the packet through an outbound interface, reduces the SL value to 0, and
changes the IPv6 DA to Z::. The path information <Z::, F::, B::1> becomes meaningless,
and therefore, node F uses the PSP to remove SRH path information and forward the
packet to node Z.

Figure 2-15 Data forwarding based on End SIDs and End.X SIDs
IPv6 DA=F:: IPv6 DA=F::
SRH(SL=1) SRH(SL=1)
(Z::,F::,B::1) (Z::,F::,B::1)
Payload Payload
IPv6 DA=B::1
End SID B:: End SID D:: End SID F:: IPv6 DA=Z::
SRH(SL=2) B End.X D F
(Z::,F::,B::1) SID B::1 Payload
Payload
A Z
C E G
SRH Information Popping

SRv6 supports the penultimate segment POP of the SRH (PSP) function, which is similar to
Penultimate Hop Popping (PHP) in MPLS. PSP is enabled to allow the penultimate segment
node to remove the SRH that becomes meaningless before a packet is sent to the egress,
which reduces the burden on the egress. Without PSP enabled, the egress removes the SRH.
2.1.2.3.3 Importing Traffic to SRv6-TE Tunnel
An SRv6 tunnel is configured based on a TE explicit path. The ingress runs CSPF to compute
the path. There is a tunnel interface in use. Data traffic can be directly imported into the
tunnel interface.
Traffic can be directed to SRv6 tunnels using static routes, tunnel policies, or automatic
routes. Traffic import is used in various services, such as public network services and L3VPN.
Static Route
Static routes on an SRv6 tunnel work in the same way as common static routes. When
configuring a static route, set the outbound interface of a static route to an SRv6 tunnel
interface so that traffic transmitted over the route is directed to the SRv6 tunnel.
Auto Route
An IGP uses an auto route related to an SRv6 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:
l Forwarding shortcut: The node does not advertise an SRv6 tunnel to its neighbor nodes.
The SRv6 tunnel can be involved only in local route calculation, but cannot be used by
the other nodes.

l Forwarding adjacency: The node advertises an SRv6 tunnel to its neighbor nodes. The
SRv6 tunnel is involved in global route calculation and can be used by the other nodes.
NOTE
l Forwarding shortcut and forwarding adjacency are mutually exclusive, and cannot be used
simultaneously.
l 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. On an SRv6 network, packets
matching specified filter conditions can be forwarded along a specified SRv6 tunnel.
SRv6 PBR has the same definition as IPv6 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-TE tunnel. If packets do not match PBR rules, they are properly forwarded
using IPv6; if they match PBR rules, they are forwarded over specific tunnels.
2.1.2.4 IS-IS for SRv6
Segment routing (SR) uses an IGP to advertise topology, prefix, segment routing global block
(SRGB), and label information. To complete the preceding functions, the IGP extends some
TLVs of protocol packets. Table 2-4 describes TLVs of the IS-IS SRv6 extension.
Table 2-4 TLVs of the IS-IS SRv6 extension
Type Name Function Position
TLV SRv6 Locator TLV Advertises SRv6 locators IS-IS packet

and End SIDs associated
with each locator.
Sub-TLV SRv6 Capabilities Advertises SRv6 IS-IS TLV of type 242

sub-TLV capabilities.
SRv6 End SID sub- Advertises SRv6 SIDs. SRv6 Locator TLV
TLV
SRv6 End.X SID Advertises SRv6 SIDs on IS-IS TLVs of types 22,
sub-TLV a P2P network. 23, 141, 222, and 223
SRv6 LAN End.X Advertises SRv6 SIDs on IS-IS TLVs of types 22,
SID sub-TLV a LAN. 23, 141, 222, and 223
Node MSD sub- Advertises the maximum IS-IS router capability

TLV SID depth (MSD) TLV
supported by a device.

SRv6 Locator TLV

The SRv6 Locator TLV is used to advertise SRv6 locators and End SIDs associated with each
locator. Figure 2-16 shows the format of the SRv6 Locator TLV.
Figure 2-16 SRv6 Locator TLV
0 7 15 23 31
Type Length RR R R MTID
Metric
Flags Algorithm
Loc Size Locator (variable)...
sub-tlv-len Sub-TLVs (variable) . . .
Table 2-5 Fields in the SRv6 Locator TLV

Field Length Description
Type 8 bits Type.
Length 8 bits Length.
MTID 12 bits Multitopology identifier.
Metric 32 bits Metric.
Flags 8 bits Flags 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.
This is to prevent looping.
Figure 2-17 Flags field format
0 7
D Reserved
Algorithm 8 bits Associated algorithm:

l 0: shortest path first
l 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 Length of sub-TLVs.

Sub-TLVs Variable Contained sub-TLVs, for example, SRv6 End SID sub-TLV.
(variable) length
SRv6 locators must be advertised in the SRv6 Locator TLV. After receiving the TLV, other
SRv6-capable IS-IS devices deliver forwarding entries for corresponding locators. SRv6-
incapable devices do not deliver such entries.
Locators are routable and can also be advertised in Prefix Reachability TLVs (236 or 237).
Locators associated with algorithm 0 (for all supported topologies) must be advertised in a
Prefix Reachability TLV (236 or 237) so that legacy routers (for example, routers that do not
support SRv6) will install a forwarding entry for SRv6 traffic with algorithm 0. In cases
where a locator advertisement is received in both a Prefix Reachability TLV and an SRv6
Locator TLV, the Prefix Reachability advertisement must be preferred when installing entries
on the forwarding plane.
SRv6 End SID sub-TLV

The SRv6 End SID sub-TLV is used to advertise SRv6 End SIDs with Endpoint functions.
Figure 2-18 shows the format of the SRv6 End SID sub-TLV.
Figure 2-18 SRv6 End SID sub-TLV
0 7 15 23 31
Type Length
Flags SRv6 Endpoint Function
SID (128 bits) . . .
SID (cont...)
SID (cont...)
SID (cont...)
Sub-sub-
Sub-sub-TLVs (variable) . . .
tlv-len
Table 2-6 Fields in the SRv6 End SID sub-TLV
Type 8 bits Type.
Flags 8 bits Flags bit.

SRv6 16 bits SRv6 Endpoint function. For details about function values,
Endpoint see SRv6 Endpoint Function.
Function
SID 16 octets Advertised SRv6 SID.
Sub-sub-tlv- 8 bits Sub-sub-TLV length.

len
Sub-sub- Variable Contained sub-sub-TLVs.

TLVs length
(variable)
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 based on some restrictions. The SRv6
Capabilities sub-TLV is used to advertise the SRv6 capabilities supported by a local node.
Figure 2-19 shows the format of the SRv6 Capabilities sub-TLV.
Figure 2-19 SRv6 Capabilities sub-TLV
0 7 15 23 31
Type Length Flags
optional sub-sub-TLVs...
Table 2-7 Fields in the SRv6 Capabilities sub-TLV

Type 8 bits Type.
Flags 16 bits Flags bit.
optional sub- Variable Optional sub-sub-TLVs.

sub-TLVs length
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
point to point adjacency. Figure 2-20 shows the format of the SRv6 End.X SID sub-TLV.

Figure 2-20 SRv6 End.X SID sub-TLV
0 7 15 23 31
Type Length
Flags Algorithm Weight
SRv6 Endpoint Function
SID (128 bits) . . .
SID (cont...)
SID (cont...)
SID (cont...)
Sub-sub-
tlv-len
Table 2-8 Fields in the SRv6 End.X SID sub-TLV

Type 8 bits Type.
Flags 8 bits Flags bit. Figure 2-21 shows the format of this field.
Figure 2-21 Flags field format
0 7
B S P Reserved
l B-Flag: backup flag.

l S-Flag: set flag. When being set, the S-Flag indicates that
the End.X SID refers to a set of adjacencies.
l P-Flag: persistent flag. When being set, the P-Flag
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 function values,
Endpoint see SRv6 Endpoint Function.
Function
SID 16 octets Advertised SRv6 SID.

Sub-sub-tlv- 8 bits Sub-sub-TLV length.

len
Sub-sub- Variable Contained sub-sub-TLVs.

TLVs length
(variable)
SRv6 LAN End.X SID sub-TLV

The SRv6 LAN End.X SID sub-TLV is used to advertise an SRv6 End.X SID associated with
a LAN adjacency. Figure 2-22 shows the format of the SRv6 LAN End.X SID sub-TLV.
Figure 2-22 SRv6 LAN End.X SID sub-TLV
0 7 15 23 31
Type Length System-ID (6 octets)
Flags Algorithm Weight
SID (128 bits) . . .
SID (cont...)
SID (cont...)
SID (cont...)
Sub-sub-
tlv-len
Compared with the SRv6 End.X SID sub-TLV, the SRv6 LAN End.X SID sub-TLV merely
has an additional System ID field. Table 2-9 describes the fields in this sub-TLV.
Table 2-9 Fields in the SRv6 LAN End.X SID sub-TLV

System ID 48 bits IS-IS system ID

Node MSD sub-TLV

The Node MSD sub-TLV is used to advertise the MSD supported by a device. Figure 2-23
shows the format of the Node MSD sub-TLV.
Figure 2-23 Node MSD sub-TLV
0 7 15
Type Length
MSD-Type MSD Value
MSD-Type MSD Value
Table 2-10 describes the fields in the Node MSD sub-TLV.
Table 2-10 Fields in the Node MSD sub-TLV

Type 8 bits Type
Length 8 bits Length
MSD-Type 8 bits MSD type:

l Maximum Segments Left MSD Type: specifies the
maximum value of the SL field in the SRH of a received
packet before applying the SRv6 Endpoint function
associated with a SID.
l 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.
l Maximum T.Insert MSD Type: specifies the maximum
number of SIDs that can be added into SRH information
when a node performs a T.insert operation. Value 0
indicates that a local node cannot perform a T.insert
operation.
l Maximum T.Encaps MSD Type: specifies the maximum
number of SIDs that can be included as part of the
"T.Encaps" operation.
l Maximum End D MSD Type: specifies the maximum
number of SIDs in an SRH when performing
decapsulation associated with End.Dx (for example,
End.DX6 and End.DT6) functions.
MSD Value 8 bits MSD value


SRv6 uses Endpoint functions to define the action of each segment. Table 2-11 lists the SRv6
Endpoint functions that can be advertised by SID sub-TLVs through IS-IS.
Table 2-11 SRv6 Endpoint functions

SRv6 End SID End.X SID LAN End.X SID
Endpoint
Function
End(no PSP, no Y N N
USP)
End(with PSP) Y N N
End(with USP) Y N N
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.OTP Y N N
2.1.2.5 IPv6 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 requirements on topology
constraints and provides more reliable fast reroute (FRR).
IPv6 TI-LFA
In Figure 2-24. 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
Device B and Device E, Device B forwards data packets to Device C. Device C is not the Q
node and has no FRR entry directly to the destination IP address of Device F. 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 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 2-24 RLFA
1:: 2:: 3::

P
Cost: 10 space
3::1
3
Cost: 10 Cost: 1000
Cost: 10
Q
4::1 space
6:: 5:: 4::
Faulty Path before fault
point
Path after fault
TI-LFA FRR protects links and nodes on SRv6 tunnels. Figure 2-25 shows IPv6 TI-LFA FRR
implementation
If a fault occurs on the link between Device B and Device E, Device B directly enables TI-
LFA FRR backup entries and adds new path information (End.X SIDs of Device C and
Device D) to the packets to ensure that the data packets can be forwarded along the backup
path.
Figure 2-25 TI-LFA

IPv6 DA=3::1
SRH(SL=2) New path
IPv6 DA=6:: (6::, 4::1, 3::1) information
Payload Payload
1:: 2:: 3::
P
Cost: 10 space
3::1
Cost: 10 3 Cost: 1000
4
Cost: 10
Q
4::1 space
6:: 5:: 4::
Faulty Path before fault
point
Path after fault

Switchover Anti-Microloop
In Figure 2-26, if Device B fails and Device A converges earlier than Device F, Device A
forwards traffic to Device F that does not finish convergence. Upon receipt of the traffic,
Device F forwards traffic along the original path to Device A, causing a loop.
Figure 2-26 Switchover anti-microloop
1:: 2:: 3::

IPv6 DA=5::
SRH(SL=1)
(3::, 5::)
Payload

6:: 5:: 4::
Faulty point Backup path

The path before The path after
convergence convergence
To prevent the microloop, after Device B fails, Device A delays its convergence and switches
traffic to a TI-LFA backup path. After Device F finishes convergence, Device A starts
convergence and switches traffic from the TI-LFA backup path to the converged path.
Revertive Switchover Anti-Microloop

In Figure 2-27, data traffic travels along the backup path before the link between Device B
and Device C recovers. After the link between Device B and Device C recovers and Device A
converges earlier than Device B, Device A forwards traffic to Device B. As Device B does
not converge, it forwards data still along the backup path, causing a loop between Device A
and Device B.

Figure 2-27 Revertive Switchover anti-microloop

IPv6 DA=2::1
SRH(SL=1)
(3::, 2::1) IPv6 DA=3::
Payload Payload
1:: 2:: 3::
Device A 3 Device B Device C
1::1 1 2::1 2

6:: 5:: 4::
Faulty
Switchback path
point
Backup path
To prevent the micro loop, after Device A performs a traffic switchback, it adds E2E path
information (for example, End.X SID of Device B) to packets and forwards the packets to
Device B. Upon receipt of the packets, Device B forwards them to Device C based on SRH
path information.
After Device B convergence, Device A stops adding an SRH to packets and forwards packets
to Device C in IPv6 forwarding process.
2.1.2.6 SRv6 OAM
SRv6 Operation, Administration, and Maintenance (OAM) monitors SRv6 path connectivity
and rapidly detects faults. SRv6 OAM is implemented using IPv6 ping and tracert.
SRv6 Ping
In Figure 2-28, nodes A, D, G, and Z have SRv6 capabilities. An SRv6 tunnel is established
between nodes A and Z.

Figure 2-28 SRv6-TE ping/tracert

IPv6 DA=G
SRH(SL=1)
IPv6 DA=D (Z, G, D)
SRH(SL=2) B D Payload F
(Z, G, D)
Payload
A Z
IPv6 DA=Z
Payload
C E G
Node A pings the SRv6 tunnel. The process is as follows:

1. Node A constructs an IPv6 Echo Request packet that carries whole IPv6 link information
<Z, G, D>. The IPv6 DA is set to node D. A searches the IPv6 routing table and
forwards the packet to node B.
2. SRv6-incapable node B cannot process this packet and searches the IPv6 routing table to
transparently transmit the packet to node D.
3. Upon receipt of the packet, node D finds that itself is the IPv6 DA. Node D updates the
IPv6 DA and SL information and searches the IPv6 routing table to forward the packet to
node F.
4. SRv6-incapable node F processes the packet in the same way as node B.
5. Upon receipt of the packet, node G finds that itself is the IPv6 DA and the SL is reduced
to 0, indicating that node G is the penultimate node. Node G updates the IPv6 DA,
deletes IPv6 link information <Z, G, D>, and searches the IPv6 routing table to send the
packet to node Z.
6. Upon receipt of the packet, node Z processes the received IPv6 packet and sends it to the
host transceiver module for processing. Then, node Z returns an IPv6 Echo Reply packet
to node A.
7. Node A receives the IPv6 Echo Reply packet and generates SRv6 ping results. If node A
does not receive IPv6 Echo Reply packets, the tracert operation fails.
SRv6 Tracert
The tracert mechanism is similar to the ping mechanism. Tracert first sends a packet with the
TTL value of 1. Each time a tracert packet is sent, the TTL increases by one. Tracert checks
whether a network connection is reachable and where a fault occurs.
In Figure 2-28, node A initiates a tracert operation on an SRv6 tunnel. The process is as
follows:
1. Node A continuously constructs IPv6 Echo Request packets and forwards them to node
D.
2. Node D checks whether TTL-1 is 0:

– If TTL-1 is 0, the packets are sent to the host transceiver for processing after the
TTL times out.
– If TTL-1 is greater than 0, node D updates the IPv6 DA and SL information,
searches the IPv6 routing table, and forwards the packets to the next-hop node G.
3. Node G processes them in the same way as D. G checks whether TTL-1 is 0:
– If TTL-1 is 0, the packets are sent to the host transceiver for processing after the
TTL times out.
– If TTL-1 is greater than 0, node G updates the IPv6 DA and SL information,
searches the IPv6 routing table, and forwards the packets to the next-hop node Z.
4. After common IPv6 packets arrive at node Z, node Z sends the packet to the host
transceiver for processing and returns IPv6 Echo Reply packets to node A.
5. After node A receives IPv6 Echo Reply packets, it generates SRv6 tracert results. If node
A does not receive IPv6 Echo Reply packets, the tracert operation fails.
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.
SRv6-TE Segment Routing IPv6 Traffic Engineering (SRv6-TE) runs

the SRv6 protocol and uses TE constraints to create a tunnel.

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


Abbreviation
SRH Segment Routing Header
TE Traffic Engineering
TI-LFA FRR Topology-Independent Loop-free Alternate FRR
USP Ultimate Segment POP of the SRH
2.2 Segment Routing IPv6 Configuration

This chapter describes the basic principles, configuration procedures, and configuration
examples of Segment Routing IPv6 (SRv6).
2.2.1 Overview of Segment Routing IPv6

Segment Routing IPv6 (SRv6) is a protocol designed to forward IPv6 data packets on a
network based on source routes.
IPv6 forwarding plane-based SRv6 enables the ingress to add a segment routing header
(SRH) into IPv6 packets. An explicit IPv6 address stack is pushed into the SRH. Transit
nodes continue to update destination IPv6 addresses and the offset address stack to implement
per-hop forwarding.
SRv6 offers the following benefits to users:
l Streamlines network configurations to be more easier to implement VPNs.
SRv6 does not use MPLS techniques and is fully compatible with existing IPv6
networks. Nodes merely support IPv6 forwarding, not MPLS forwarding. Transit nodes
does not need to support SRv6 and are able to forward IPv6 packets carrying the SRH
over routes.
l Provides topology independent-loop-free alternate (TI-LFA), which improves FRR
protection.
SRv6, in combination with the Remote Loop-free Alternate FRR (RLFA) algorithm,
implements the efficient Topology-Independent Loop-free Alternate FRR (TI-LFA) to
support any topology in theory and overcomes drawbacks in conventional tunnel
protection.
l Facilitates traffic optimization on IPv6 forwarding paths.
Segment IDs (SIDs) with various service types are used to flexible plan explicit paths on
the ingress to adjust service traffic.

2.2.2 Licensing Requirements and Limitations for Segment

Routing IPv6
BOM License Control Description Minimum Version
Item Requirement
81401295 NetEngine40E Controllable V800R011C00

SRv6 Function feature:
License This license
controls SRv6.
One device
requires one
such license.

Segment Routing IPv6 next None Dynamic load balancing

hops do not support does not take effect on the
dynamic load balancing next hops of the outbound
adjustment. interfaces on the Segment
Routing ingress and transit
nodes.
Segment Routing IPv6 SRH Properly plan service IPv6 forwarding fails.
does not support configurations. Setting a
fragmentation within a small MTU on the inbound
tunnel. A maximum of 10 interface of a tunnel to
labels can be added to a prevent too big packets from
packet header at a time. traveling through the tunnel.
The SRH with the Next None This service packets cannot
Header set to an IPv6 header be identified and cannot be
is only supported. The SRH forwarded based on IPv6.
extension header is at the
first IPv6 extension header
field, not at the other
extension headers.
SRv6 supports packets None This service packets cannot

carrying multiple SRHs and be identified and cannot be
parses only the first SRH. forwarded based on IPv6.

The SRv6 ingress does not None Packet information cannot

support the sampling of be collected.
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.
When strict URPF is None Service traffic is interrupted.

configured, SRv6 packets
may be discarded due to a
check failure.
The SRv6 egress does not Properly plan services. The unexpected load
support deep load balancing. imbalance may occur.
When L3VPN traffic is None IPv6 forwarding fails.

iterated to an SRv6 tunnel
functioning as a public
network tunnel, packet
information is sampled, but
the forwarding information,
such as next-hop and
outbound interface
information cannot be
sampled.

network tunnel, the
outbound interface cannot
be set to a VLANIF
interface, BDIF interface,
PWIF interface, or MPLS
tunnel interface.
When L3VPN traffic is When L3VPN traffic is Incorrect BFD switching

iterated to an SRv6 tunnel iterated to an SRv6 tunnel may occur.
functioning as a public functioning as a public
network tunnel and BFD for network tunnel and BFD for
peer IP protection is peer IP protection is
supported, set the peer IP supported, set the peer IP
address to the network address to the network
segment address of a VPN segment address of a VPN
SID locator. SID locator.

When IPv6 packets enter None Load imbalance.

load-balancing SRv6
tunnels, shutting down a
physical outbound interface
of a tunnel may result in
load imbalance.
IPv6 packets enter a single Deploy load-balancing Services are interrupted.

SRv6 tunnel. When the tunnels to prevent services
physical interface of the from being affected if a
tunnel goes Down, services single link fails.
are interrupted.
After direct next hop is None SRv6 does not support TE

configured on a device, if FRR.
the explicit path label has
only one outbound interface,
SRv6 does not support TE
FRR.
IS-IS Segment Routing None None

IPv6: The END must be
globally unique.
When the Segment Routing Properly plan MTUs. Packets may fail to be sent
IPv6 feature is deployed on or received.
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.

network tunnel, the
outbound interface cannot
be set to a virtual access
interface.
2.2.3 Configuring an SRv6-TE Tunnel (over a Manually

Configured Explicit Path)
A TE explicit path is used to compute the path for an SRv6-TE tunnel, and the forwarding
plane forwards traffic directly using IPv6. SRv6 uses the IPv6 network extension to
implement simplified VPN and allows the flexible path planning.

Usage Scenario
An SRv6 tunnel is configured based on a TE explicit path. The whole TE explicit path can use
End SIDs only, End.X SIDs only, or the combination of these two types of SIDs.
Configuring an SRv6-TE tunnel, configure basic IS-IS functions (IPv6).
2.2.3.1 Setting an IPv6 Router ID

Before you configure SRv6, set a global TE IPv6 router ID.
Usage Scenario
A global TE IPv6 router ID uniquely identifies an SRv6 node on a network.
Procedure
Step 2 Run te ipv6-router-id ipv6-address
A global TE IPv6 router ID is set.
----End
2.2.3.2 Globally Enabling the SRv6 Capability

The SRv6 capability must be enabled on a forwarder before SRv6 functions are configured on
the forwarder.
Usage Scenario
An SRv6-capable node maintains a local SID table. This table contains all SRv6 segment
information generated by the local node. Based on the table, the local node generates an SRv6
forwarding table (FIB table). The local SID table provides the following functions:
l Defines a locally generated SID, for example, End.X SID.
l Specifies bindings between objects and SIDs.
l Stores parameters related to the preceding operations.
Procedure
Step 2 Run segment-routing ipv6
SRv6 is enabled on the forwarding plane, and the SRv6 view is displayed.
Step 3 Run traffic-eng enable

SRv6-TE is enabled.
Step 4 Run commit
----End
2.2.3.3 Configuring the SRv6 SID

An SRv6 tunnel is established using SRv6 SIDs. The SRv6 SID must be configured before an
SRv6 tunnel is configured.
Usage Scenario
An SRv6 tunnel is established using SRv6 SIDs. An SRv6 SID can be manually configured
using the opcode command or dynamically generated by IS-IS. Either mode can be specified.
SIDs dynamically generated by IS-IS can be flooded and advertised over the whole network
by IS-IS. Perform the following steps on the PE.
Procedure
l Statically configure an SRv6 SID.
a. Run system-view

b. Run segment-routing ipv6
Segment Routing IPv6 is enabled on the forwarding plane, and the segment routing
IPv6 view is displayed.
c. Run locator locator-name [ ipv6-prefix ipv6-address prefix-length [ static static-
length | args args-length ] * [ default ] ]
The SID node route locator is configured.

d. Run opcode func-opcode end-x interface interface-name nexthop nexthop-address
[ no-psp ]
The operation code is configured for the static SID.

e. Run commit

l Configure IS-IS to dynamically generate SRv6 SIDs.
a. Run system-view

b. Run segment-routing ipv6
Segment Routing IPv6 is enabled on the forwarding plane, and the segment routing
IPv6 view is displayed.
c. Run locator locator-name [ ipv6-prefix ipv6-address prefix-length [ static static-
length | args args-length ] * [ default ] ]

d. Run quit
Exist the segment routing IPv6 locator view.

e. Run quit
Exist the SRv6 view.

f. Run isis [ process-id ]

g. Run ipv6 enable
IPv6 is enabled for the IS-IS process.

h. Run cost-style { compatible [ relax-spf-limit ] | wide | wide-compatible }

i. Run segment-routing ipv6 locator locator-name
The device is enabled to send network routes that carry SIDs to IS-IS module.
j. Run commit
----End
2.2.3.4 Configuring an SRv6-TE Tunnel Interface

An SRv6-TE tunnel is established over an explicit path. The explicit path must be configured
before an SRv6-TE tunnel interface is configured.
Usage Scenario
An explicit path refers to a vector path on which a series of nodes are arranged in the
Procedure
Step 1 Configure an explicit path.
1. Run system-view

2. Run explicit-path path-name

3. Run next sid ipv6 ipv6-address [ type { adjacency | prefix } ]
An IPv6 SID is set.

4. Run add sid ipv6 ipv6-address2 [ type { adjacency | prefix } ] { before | after } sid
ipv6 ipv6-address1
The SID is added to an explicit path.

To modify the explicit path, run the modify sid ipv6 ipv6-address1 to ipv6-address2
[ type { adjacency | prefix ] command. To delete a SID from the explicit path, run the
delete sid ipv6 ipv6-address command.
5. Run commit
Step 2 Configure an SRv6-TE tunnel interface.
1. Run system-view
2. Run interface tunnel tunnel-number
3. Run tunnel-protocol srv6
SRv6 is configured as a tunneling protocol.
4. Run destination ipv6 ipv6-address
The destination IPv6 address is configured for a tunnel.
5. Run tunnel-id tunnel-id
A tunnel ID is set.
6. Run path explicit-path path-name
An explicit path is configured for the SRv6 tunnel.
The path-name parameter must be the same as that specified in the explicit-path path-
name command.
7. (Optional) Run match dscp ipv6 { default | { dscp-value1 | to dscp-value2 ] }
&<1-32> }
A DSCP value is set for IPv6 packets that enter an SRv6 tunnel.
The DSCP setting on an SRv6 tunnel interface is mutually exclusive with the service-
class command. If both of them are configured, an error message is displayed.
8. Run commit
----End
2.2.3.5 Verifying the IPv6 SR-TE Tunnel Configuration

After configuring an SRv6-TE tunnel, verify information about the SRv6-TE tunnel and its
status statistics.
Prerequisites
All SRv6-TE tunnel configurations are complete.
Procedure
l Run the display srv6 lsp [ lsp-id ingress-router-id session-id lsp-id ] [ verbose ]
command to check information about the label stack of SRv6.

l Run the display explicit-path [ name ] path-name [ verbose ] command to check SRv6
explicit path information.
l Run the following commands to check SRv6 tunnel information.
a. Run the display srv6 te tunnel path [ name ] [ lsp-id ingress-router-id session-id
local-lsp-id ] or display srv6 te tunnel path tunnel-name name [ lsp-id ingress-
router-id session-id local-lsp-id ] command to check tunnel path attributes on a
local node.
b. Run the display srv6 te tunnel-interface command on a local node to view SRv6
tunnel interface information.
----End
2.2.4 Configuring IPv4 VPN over SRv6-BE

This section describes how to configure IPv4 VPN over SRv6-BE.
Usage Scenario
IPv4 VPN over SRv6-BE allows SRv6-BE forwarding paths on public networks to carry IPv4
VPN data. The implementation of IPv4 VPN over SRv6-BE involves establishing SRv6-BE
paths, implementing VPN route interworking, and forwarding data.
Figure 2-29 shows the new IPv6 public network between PE1 and PE2 and the traditional
IPv4 private network. An SRv6-BE path is established over the public IPv6 network to carry
IPv4 VPN services of the private network.
Figure 2-29 IPv4 VPN over SRv6-BE networking
PE1 P PE2
IPv6 IPv6
IPv4 SRv6 IPv4
CE1 CE2
Before you configure IPv4 VPN over SRv6-BE, complete the following tasks:
l Configure a link layer protocol.

l Configure IP addresses for interfaces to ensure that neighboring devices are reachable at
the network layer.
Procedure
Step 1 Configure IPv6 IS-IS on each PE and P. For configuration details, see Configuring Basic IS-
IS Functions (IPv6).

Step 2 Configure VPN instances in the IPv4 address family on each PE.
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 IPv4 address family is enabled for the VPN instance, and the VPN instance IPv4
address family 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.
8. Run quit
Exit the VPN instance view.
The view of the interface to be bound to a VPN instance is displayed.
10. Run ip binding vpn-instance vpn-instance-name
The interface is bound to the VPN instance.
NOTE
Using the ip binding vpn-instance command will delete Layer 3 (including IPv4 and IPv6)
configurations, such as the IP address and routing protocol on the interface. Reconfigure them
after using the ip binding vpn-instance command if needed.
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 from the interface view.
Step 3 Configure PEs and CEs to exchange IPv4 route information. For configuration details, see
Configuring the PE and CE to Exchange Route Information.

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

The BGP view is displayed.
2. Run router-id ipv4-address
The 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 BGP VPNv4 address family view is displayed.
6. Run peer ipv6-address enable
The ability to exchange VPN-IPv4 routes with the BGP peer is enabled.
7. Run commit
8. Run quit
Exit the BGP-VPNv4 address family view.
9. Run quit
Exit the BGP view.
Step 5 Establish an SRv6-BE forwarding path between PEs.
1. Run segment-routing ipv6
SRv6 is enabled on the forwarding plane, and the SRv6 view is displayed.
2. Run encapsulation source-address ipv6-address [ ip-ttl ttl-value ]
The source address used in SRv6 VPN encapsulation is configured.
3. Run locator locator-name [ ipv6-prefix ipv6-address prefix-length [ static static-length |
args args-length ] * [ default ] ]
4. Run opcode func-opcode end-dt4 vpn-instance vpn-instance-name
The operation code is configured for the static SID.
5. Run quit
Exist the SRv6 locator view.
6. Run quit
Exist the SRv6 view.
The BGP VPNv4 address family view is displayed.

9. Run peer ipv6-address prefix-sid

The device is enabled to exchange IPv4 prefix SIDs with a specified IPv6 peer.
10. Run quit
Exit the BGP VPNv4 address family view.
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 ]
The device is enabled to add SIDs in private network routes.
If the auto-sid-disable parameter is not configured, SID attributes can be dynamically
assigned. If static SID attributes exist in locator-name, the static SIDs are used. If no
static SIDs exist, dynamically assigned SID attributes are used.
14. Run commit
----End

All configurations of IPv4 VPN over SRv6-BE are complete.
l Run the display segment-routing ipv6 locator [ locator-name ] verbose command to
view SRv6 locator information.
l Run the display segment-routing ipv6 local-sid { end | end-x | end-dt4 } [ sid ]
forwarding command to check SRv6 local SID table information.
l Run the ping command to check the connectivity between CEs.
2.2.5 Configuring IPv6 IS-IS TI-LFA FRR

IPv6 Topology-Independent Loop-free Alternate FRR (TI-LFA) uses an explicit path to
represent a backup path, which poses no requirements on topology constraints and provides
more reliable fast reroute (FRR).
Usage Scenario
IPv6 TI-LFA 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 IPv6 IS-IS TI-LFA FRR, you should enable IS-IS SRv6, refer to Enable
IS-IS SRv6.

Procedure
Step 2 Run isis [ process-id ]
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 LFA is enabled, and LFA links can be generated.
Step 5 Run ti-lfa [ level-1 | level-2 | level-1-2 ]
IPv6 IS-IS TI-LFA is enabled.
Step 6 (Optional) After the preceding configurations are complete, IPv6 IS-IS TI-LFA is enabled on
all IPv6 IS-IS interfaces. If you do not want to enable IPv6 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.


4. Run isis ipv6 ti-lfa disable [ level-1 | level-2 | level-1-2 ]
The IPv6 IS-IS TI-LFA is disabled on an specified interface.
Step 7 Run commit
----End

All IPv6 IS-IS TI-LFA FRR configurations are complete.
l Run the display isis [ process-id ] route ipv6 [ level-1 | level-2 ] [ verbose ] command to
check information about the primary and backup link information after IPv6 IS-IS TI-
LFA FRR is enabled.
Follow-up Procedure
When a main interface fails and recovers and a route next hop is switched to the previous
route next hop, inconsistent convergence speeds on devices result in microloops. To prevent
microloops, perform the following steps:

1. Run system-view
3. Run ipv6 avoid-microloop segment-routing
The switchback anti-microloop is enabled.
4. (Optional) Run ipv6 avoid-microloop segment-routing rib-update-delay rib-update-
delay
The delay in delivering IS-IS route in an SRv6 scenario is set.
5. Run commit
2.2.6 Segment Routing IPv6 Configuration Examples

This section provides several SRv6 configuration examples.
2.2.6.1 Example for Configuring an IS-IS SRv6-TE Tunnel (Dynamic SID Mode)
This section provides an example for configuring an IS-IS SRv6-TE tunnel.
Figure 2-30 shows the IS-IS SRv6-TE tunnel networking.
l routerDevice A, routerDevice B, and routerDevice C are in the same AS and run IS-IS to
implement IPv6 network connectivity.
l Device A, Device B, and Device C are Level-1 devices in area 1.
A bidirectional SRv6-TE tunnel is to be established between Device A and Device C to carry
IPv6 services.
Figure 2-30 IS-IS SRv6-TE tunnel networking

NOTE

2001::1/96 2001::2/96 2002::1/96 2002::2/96

SRv6 tunnel
tunnel1 tunnel1

1. Enable IPv6 forwarding capabilities on each router and assign an IPv6 address to each
interface.
2. Enable IS-IS on each router, set a level, and specify a network entity.
3. Configure the IS-IS SRv6 capability on each router.
4. Configure an explicit path on Device A and Device C and establish a bidirectional SRv6-
TE tunnel in between.
Data Preparation
l IPv6 addresses to interfaces on Device A, Device B, and Device C
l Area ID of Device A, Device B, and Device C
l Levels of Device A, Device B, and Device C
Procedure
Step 1 Enable the capability of IPv6 forwarding and configure an IPv6 address for each interface. In
the following example, the configuration on Device A is used as an example. The
configurations of Device B and Device C are similar to the configuration of Device A. For
[~HUAWEI] sysname DeviceA
[*HUAWEI] commit
[~DeviceA] interface gigabitethernet 1/0/0
[~DeviceA-GigabitEthernet1/0/0] ipv6 enable
[*DeviceA-GigabitEthernet1/0/0] ipv6 address 2001::1 96
[*DeviceA-GigabitEthernet1/0/0] commit
Step 2 Configure IS-IS.

# Configure Device A.
[~DeviceA] isis 1
[*DeviceA-isis-1] is-level level-1
[*DeviceA-isis-1] network-entity 10.0000.0000.0001.00
[*DeviceA-isis-1] ipv6 enable topology ipv6
[*DeviceA-isis-1] quit
[*DeviceA] interface gigabitethernet 1/0/0
[*DeviceA-GigabitEthernet1/0/0] isis ipv6 enable 1
[~DeviceA-GigabitEthernet1/0/0] quit
# Configure Device B.
[~DeviceB] isis 1
[*DeviceB-isis-1] is-level level-1
[*DeviceB-isis-1] network-entity 10.0000.0000.0002.00
[*DeviceB-isis-1] ipv6 enable topology ipv6
[*DeviceB-isis-1] quit
[*DeviceB] interface gigabitethernet 1/0/0
[*DeviceB-GigabitEthernet1/0/0] isis ipv6 enable 1
[*DeviceB-GigabitEthernet1/0/0] commit
[~DeviceB-GigabitEthernet1/0/0] quit
# Configure Device C.
[~DeviceC] isis 1

[*DeviceC-isis-1] network-entity 10.0000.0000.0003.00

[*DeviceC-isis-1] ipv6 enable topology ipv6
[*DeviceC-isis-1] quit
[*DeviceC] interface gigabitethernet 2/0/0
[*DeviceC-GigabitEthernet2/0/0] isis ipv6 enable 1
[*DeviceC-GigabitEthernet2/0/0] commit
[*DeviceC-GigabitEthernet2/0/0] quit
After completing the configuration, run the following commands to verify IS-IS
configuration.
# Display information about IS-IS neighbors. In the following example, the display on Device
A is used.
[~DeviceA] display isis peer

--------------------------------------------------------------------------------
0000.0000.0002 GE1/0/0 0000.0000.0003.01 Up 8s L1 64
Total Peer(s): 1
# Display IS-IS routes. In the following example, the display on Device A is used.
[~DeviceA] display isis route
Route information for ISIS(1)
-----------------------------
ISIS(1) Level-1 Forwarding Table

--------------------------------
IPV6 Dest. ExitInterface NextHop Cost Flags

--------------------------------------------------------------------------------
2001::/96 GE1/0/0 Direct 10 D/-/L/-
2002::/96 GE1/0/0 FE80::3AFE:67FF:FE31:17 20 A/-/-/-
Flags: D-Direct, A-Added to URT, L-Advertised in LSPs, S-IGP Shortcut,
U-Up/Down Bit Set, LP-Local Prefix-Sid
Step 3 Configure the SRv6 capability.

[~DeviceA] te ipv6-router-id 1::1
[*DeviceA] commit
[~DeviceA] segment-routing ipv6
[*DeviceA-segment-routing-ipv6] traffic-eng enable
[*DeviceA-segment-routing-ipv6] locator example1 ipv6-prefix 1:: 64 static 32
[*DeviceA-segment-routing-ipv6-locator] commit
[~DeviceA-segment-routing-ipv6-locator] quit
[~DeviceA-segment-routing-ipv6] quit
[~DeviceA] isis 1
[*DeviceA-isis-1] cost-style wide
[*DeviceA-isis-1] segment-routing ipv6 locator example1
[*DeviceA-isis-1] commit
[~DeviceA-isis-1] quit
[~DeviceB] te ipv6-router-id 2::2
[*DeviceB] commit
[~DeviceB] segment-routing ipv6
[*DeviceB-segment-routing-ipv6] traffic-eng enable
[*DeviceB-segment-routing-ipv6] locator example1 ipv6-prefix 2:: 64 static 32
[*DeviceB-segment-routing-ipv6-locator] commit
[~DeviceB-segment-routing-ipv6-locator] quit
[~DeviceB-segment-routing-ipv6] quit
[~DeviceB] isis 1
[*DeviceB-isis-1] cost-style wide
[*DeviceB-isis-1] segment-routing ipv6 locator example1

[*DeviceB-isis-1] commit
[~DeviceB-isis-1] quit
[~DeviceC] te ipv6-router-id 3::3
[*DeviceC] commit
[~DeviceC] segment-routing ipv6
[*DeviceC-segment-routing-ipv6] traffic-eng enable
[*DeviceC-segment-routing-ipv6] locator example1 ipv6-prefix 3:: 64 static 32
[*DeviceC-segment-routing-ipv6-locator] commit
[~DeviceC-segment-routing-ipv6-locator] quit
[~DeviceC-segment-routing-ipv6] quit
[~DeviceC] isis 1
[*DeviceC-isis-1] cost-style wide
[*DeviceC-isis-1] segment-routing ipv6 locator example1
[*DeviceC-isis-1] commit
[~DeviceC-isis-1] quit
# After completing the configuration, check the End.X SIDs dynamically generated by IS-IS,
which are used to configure an explicit path in the next step. In the following example, the
display on Device B is used.
[~DeviceB] display segment-routing ipv6 local-sid end-x forwarding
My Local-SID End.X Forwarding Table
-----------------------------------
SID : 2::1:0:3/128 FuncType : End.X

Flavor : --
LocatorName: example1 LocatorID: 1
NextHop : Interface : ExitIndex:
FE80::3AFE:67FF:FE11:17 Eth0/1/7 0x0000000e

Flavor : PSP
FE80::3AFE:67FF:FE11:17 Eth0/1/7 0x0000000e

Flavor : --
FE80::3AFE:67FF:FE51:13 Eth0/1/3 0x0000000a

Flavor : PSP
FE80::3AFE:67FF:FE51:13 Eth0/1/3 0x0000000a
Total SID(s): 4
Step 4 Configure an SRv6-TE tunnel.

# On Device A, configure a tunnel that originates from Device A and is terminated at Device
C.
[~DeviceA] explicit-path p1
[*DeviceA-explicit-path-p1] next sid ipv6 1::1:0:3 type adjacency
[*DeviceA-explicit-path-p1] next sid ipv6 2::1:0:3 type adjacency
[*DeviceA-explicit-path-p1] commit
[~DeviceA-explicit-path-p1] quit
[~DeviceA] interface Tunnel 1
[*DeviceA-Tunnel1] ipv6 enable
[*DeviceA-Tunnel1] ipv6 address auto link-local
[*DeviceA-Tunnel1] tunnel-protocol srv6
[*DeviceA-Tunnel1] destination ipv6 3::3
[*DeviceA-Tunnel1] tunnel-id 100

[*DeviceA-Tunnel1] path explicit-path p1

[*DeviceA-Tunnel1] commit
[~DeviceA-Tunnel1] quit
# On Device C, configure a tunnel that originates from Device C and is terminated at Device
A.
[~DeviceC] explicit-path p1
[*DeviceC-explicit-path-p1] next sid ipv6 3::1:0:18 type adjacency
[*DeviceC-explicit-path-p1] next sid ipv6 2::1:0:18 type adjacency
[*DeviceC-explicit-path-p1] commit
[~DeviceC-explicit-path-p1] quit
[~DeviceC] interface Tunnel 1
[*DeviceC-Tunnel1] ipv6 enable
[*DeviceC-Tunnel1] ipv6 address auto link-local
[*DeviceC-Tunnel1] tunnel-protocol srv6
[*DeviceC-Tunnel1] destination ipv6 1::1
[*DeviceC-Tunnel1] tunnel-id 100
[*DeviceC-Tunnel1] path explicit-path p1
[*DeviceC-Tunnel1] commit
[~DeviceC-Tunnel1] quit

After completing the configuration, run the following commands to verify IS-IS SRv6
configuration.
# Display label stack information on SRv6. In the following example, the display on Device
A is used.
[~DeviceA] display srv6 lsp
Total lsp number: 1
----------------------------------------------------------------------------------
-
LSP Information: SRv6 LSP
----------------------------------------------------------------------------------
-
FEC Out SID
3::3/128 2::1:0:18
# Display information about the SRv6-TE tunnel. In the following example, the display on
Device A is used.
[~DeviceA] display srv6 te tunnel-interface tunnel 1
Tunnel Attributes :
Session ID : 100
Ingress Router ID : [1::1]
Egress Router ID : [3::3]
Signaling Protocol : Segment-Routing-IPv6
FTid : 24577
Primary LSP ID : [1::1]:[24]

Explicit Path Name : p1
# Display path attributes of the SRv6-TE tunnel on a local node. In the following example, the
display on Device A is used.
[~DeviceA] display srv6 te tunnel path
Lsp ID : [1::1] :[100] :[24]
Hop Information
Hop 0 Adjacency SID IPv6 1::1:0:3
Hop 1 Adjacency SID IPv6 2::1:0:3

# To test the connectivity of an SRv6-TE tunnel, run the ping lsp command on the ingress to
initiate a ping test to the egress. In the following example, the display on Device A is used.
[~DeviceA] ping lsp segment-routing te ipv6 Tunnel 1 nil-fec
LSP PING FEC: SEGMENT ROUTING TE IPV6 SESSION QUERY Tunnel1 : 100 data bytes,
press CTRL_C to break
Reply from 3::3
bytes=100 Sequence=1 time=8 ms
Reply from 3::3
Reply from 3::3
Reply from 3::3
Reply from 3::3
--- FEC: SEGMENT ROUTING TE IPV6 SESSION QUERY Tunnel1 ping statistics ---
0.00% packet loss
----End
Configuration Files
l Device A configuration file
#
sysname DeviceA
#
te ipv6-router-id 1::1
#
explicit-path p1
next sid ipv6 1::1:0:3 type adjacency
#
segment-routing ipv6
traffic-eng enable
locator example1 ipv6-prefix 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 example1
#
undo shutdown
ipv6 enable
ipv6 address 2001::1/96
isis ipv6 enable 1
#
interface Tunnel1
ipv6 enable
ipv6 address auto link-local
tunnel-protocol srv6
destination ipv6 3::3
tunnel-id 100
path explicit-path p1
#
return
l Device B configuration file

#
sysname DeviceB

#
#
traffic-eng enable
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0002.00
#
#
undo shutdown
ipv6 enable
isis ipv6 enable 1
#
undo shutdown
ipv6 enable
isis ipv6 enable 1
#
return
l Device C configuration file

#
sysname DeviceC
#
#
explicit-path p1
#
traffic-eng enable
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0003.00
#
#
undo shutdown
ipv6 enable
isis ipv6 enable 1
#
interface Tunnel1
ipv6 enable
tunnel-id 100
#
return

2.2.6.2 Example for Configuring an IS-IS SRv6-TE Tunnel (Static SID Mode)
This section provides an example for configuring an IS-IS SRv6-TE tunnel.
Figure 2-31 shows the IS-IS SRv6-TE tunnel networking.
l routerDevice A, routerDevice B, and routerDevice C are in the same AS and run IS-IS to
implement IPv6 network connectivity.
l Device A, Device B, and Device C are Level-1 devices in area 1.
A bidirectional SRv6-TE tunnel is to be established between Device A and Device C to carry

IPv6 services.
Figure 2-31 IS-IS SRv6-TE tunnel networking

NOTE

2001::1/96 2001::2/96 2002::1/96 2002::2/96

SRv6 tunnel
tunnel1 tunnel1
interface.
4. Configure an explicit path on Device A and Device C and establish a bidirectional SRv6-
TE tunnel in between.
Data Preparation
l IPv6 addresses to interfaces on Device A, Device B, and Device C

l Area ID of Device A, Device B, and Device C
l Levels of Device A, Device B, and Device C

Procedure
the following example, the configuration on Device A is used as an example. The
configurations of Device B and Device C are similar to the configuration of Device A. For
[~HUAWEI] sysname DeviceA
[*HUAWEI] commit
[~DeviceA] interface gigabitethernet 1/0/0
[~DeviceA-GigabitEthernet1/0/0] ipv6 enable
[*DeviceA-GigabitEthernet1/0/0] ipv6 address 2001::1 96
[~DeviceA] isis 1
[*DeviceA-isis-1] is-level level-1
[*DeviceA-isis-1] network-entity 10.0000.0000.0001.00
[*DeviceA-isis-1] ipv6 enable topology ipv6
[*DeviceA-isis-1] quit
[*DeviceA] interface gigabitethernet 1/0/0
[*DeviceA-GigabitEthernet1/0/0] isis ipv6 enable 1
[~DeviceA-GigabitEthernet1/0/0] quit
[~DeviceB] isis 1
[*DeviceB-isis-1] is-level level-1
[*DeviceB-isis-1] network-entity 10.0000.0000.0002.00
[*DeviceB-isis-1] ipv6 enable topology ipv6
[*DeviceB-isis-1] quit
[~DeviceC] isis 1
[*DeviceC-isis-1] network-entity 10.0000.0000.0003.00
[*DeviceC-isis-1] ipv6 enable topology ipv6
[*DeviceC-isis-1] quit
[*DeviceC] interface gigabitethernet 2/0/0
[*DeviceC-GigabitEthernet2/0/0] isis ipv6 enable 1
[*DeviceC-GigabitEthernet2/0/0] commit
[*DeviceC-GigabitEthernet2/0/0] quit
After completing the configuration, run the following commands to verify IS-IS
configuration.
# Display information about IS-IS neighbors. In the following example, the display on Device
A is used.
[~DeviceA] display isis peer

--------------------------------------------------------------------------------
0000.0000.0002 GE1/0/0 0000.0000.0003.01 Up 8s L1 64

Total Peer(s): 1
# Display IS-IS routes. In the following example, the display on Device A is used.
[~DeviceA] display isis route
-----------------------------

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

--------------------------------------------------------------------------------
2001::/96 GE1/0/0 Direct 10 D/-/L/-
2002::/96 GE1/0/0 FE80::3AFE:67FF:FE31:17 20 A/-/-/-
Step 3 Configure the SRv6 capability.

[~DeviceA] te ipv6-router-id 1::1
[*DeviceA] commit
[~DeviceA] segment-routing ipv6
[*DeviceA-segment-routing-ipv6] traffic-eng enable
[*DeviceA-segment-routing-ipv6] locator example1 ipv6-prefix 1:: 64 static 32
[~DeviceA-segment-routing-ipv6-locator] opcode ::1 end-x interface
GigabitEthernet1/0/0 nexthop 2001::2
[*DeviceA-segment-routing-ipv6-locator] commit
[~DeviceA-segment-routing-ipv6-locator] quit
[~DeviceA-segment-routing-ipv6] quit
[~DeviceA] commit
[~DeviceB] te ipv6-router-id 2::2
[*DeviceB] commit
[~DeviceB] segment-routing ipv6
[*DeviceB-segment-routing-ipv6] traffic-eng enable
[*DeviceB-segment-routing-ipv6] locator example1 ipv6-prefix 2:: 64 static 32
[*DeviceB-segment-routing-ipv6-locator] opcode ::2 end-x interface
[*DeviceB-segment-routing-ipv6-locator] opcode ::1 end-x interface
[*DeviceB-segment-routing-ipv6-locator] commit
[~DeviceB-segment-routing-ipv6-locator] quit
[~DeviceB-segment-routing-ipv6] quit
[~DeviceB] commit
[~DeviceC] te ipv6-router-id 3::3
[*DeviceC] commit
[~DeviceC] segment-routing ipv6
[*DeviceC-segment-routing-ipv6] traffic-eng enable
[*DeviceC-segment-routing-ipv6] locator example1 ipv6-prefix 3:: 64 static 32
[~DeviceC-segment-routing-ipv6-locator] opcode ::1 end-x interface
[*DeviceC-segment-routing-ipv6-locator] commit
[~DeviceC-segment-routing-ipv6-locator] quit
[~DeviceC-segment-routing-ipv6] quit
[~DeviceC] commit
Step 4 Configure an SRv6-TE tunnel.

# On Device A, configure a tunnel that originates from Device A and is terminated at Device
C.

[~DeviceA] explicit-path p1
[*DeviceA-explicit-path-p1] next sid ipv6 1::1 type adjacency
[*DeviceA-explicit-path-p1] next sid ipv6 2::2 type adjacency
[*DeviceA-explicit-path-p1] commit
[~DeviceA-explicit-path-p1] quit
[~DeviceA] interface Tunnel 1
[*DeviceA-Tunnel1] ipv6 enable
[*DeviceA-Tunnel1] ipv6 address auto link-local
[*DeviceA-Tunnel1] tunnel-protocol srv6
[*DeviceA-Tunnel1] destination ipv6 3::3
[*DeviceA-Tunnel1] tunnel-id 100
[*DeviceA-Tunnel1] path explicit-path p1
[*DeviceA-Tunnel1] commit
[~DeviceA-Tunnel1] quit
# On Device C, configure a tunnel that originates from Device C and is terminated at Device
A.
[~DeviceC] explicit-path p1
[*DeviceC-explicit-path-p1] next sid ipv6 3::1 type adjacency
[*DeviceC-explicit-path-p1] next sid ipv6 2::1 type adjacency
[*DeviceC-explicit-path-p1] commit
[~DeviceC-explicit-path-p1] quit
[~DeviceC] interface Tunnel 1
[*DeviceC-Tunnel1] ipv6 enable
[*DeviceC-Tunnel1] ipv6 address auto link-local
[*DeviceC-Tunnel1] tunnel-protocol srv6
[*DeviceC-Tunnel1] destination ipv6 1::1
[*DeviceC-Tunnel1] tunnel-id 100
[*DeviceC-Tunnel1] path explicit-path p1
[*DeviceC-Tunnel1] commit
[~DeviceC-Tunnel1] quit

After completing the configuration, run the following commands to verify IS-IS SRv6
configuration.
# Display information about the SRv6-TE tunnel. In the following example, the display on
Device A is used.
[~DeviceA] display srv6 te tunnel-interface tunnel 1
Tunnel Attributes :
Session ID : 100
Ingress Router ID : [1::1]
Egress Router ID : [3::3]
FTid : 24577

Explicit Path Name : p1
# To test the connectivity of an SRv6-TE tunnel, run the ping lsp command on the ingress to
initiate a ping test to the egress. In the following example, the display on Device A is used.
[~DeviceA] ping lsp segment-routing te ipv6 Tunnel 1 nil-fec
LSP PING FEC: SEGMENT ROUTING TE IPV6 SESSION QUERY Tunnel1 : 100 data bytes,
press CTRL_C to break
Reply from 3::3
Reply from 3::3
Reply from 3::3

Reply from 3::3

Reply from 3::3
--- FEC: SEGMENT ROUTING TE IPV6 SESSION QUERY Tunnel1 ping statistics ---
0.00% packet loss
----End
Configuration Files
l Device A configuration file
#
sysname DeviceA
#
#
explicit-path p1
next sid ipv6 1::1 type adjacency
#
traffic-eng enable
opcode ::1 end-x interface GigabitEthernet1/0/0 nexthop 2001::2
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0001.00
#
#
undo shutdown
ipv6 enable
isis ipv6 enable 1
#
interface Tunnel1
ipv6 enable
tunnel-id 100
#
return
l Device B configuration file

#
sysname DeviceB
#
#
traffic-eng enable
#
isis 1
is-level level-1
cost-style wide

network-entity 10.0000.0000.0002.00
#
#
undo shutdown
ipv6 enable
isis ipv6 enable 1
#
undo shutdown
ipv6 enable
isis ipv6 enable 1
#
return
l Device C configuration file

#
sysname DeviceC
#
#
explicit-path p1
#
traffic-eng enable
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0003.00
#
#
undo shutdown
ipv6 enable
isis ipv6 enable 1
#
interface Tunnel1
ipv6 enable
tunnel-id 100
#
return
2.2.6.3 Example for Configuring IPv4 VPN over SRv6-BE

This section provides an example for configuring IPv4 VPN over SRv6-BE.
On the network shown in Figure 2-32:
l PE1, the P, and PE2 are in the same AS and run IS-IS to implement IPv6 network
connectivity.

l PE1, the P, and PE2 belong to area 1 and are level-1 devices.
A bidirectional SRv6-BE path between PE1 and PE2 is established to carry IPv4 VPN
services.
Figure 2-32 IPv4 VPN over SRv6-BE networking

NOTE
loopback1 loopback1 loopback1

1::1/64 2::2/64 3::3/64
interface2 2001::1/96 2002::2/96 interface2
10.1.1.1/24 10.2.1.1/24
interface1 2001::2/96 P 2002::1/96 PE2 interface1
PE1
10.1.1.2/24 10.2.1.2/24
SRv6
CE1 CE2
interface.
4. Configure a VPN instance on PE1 and PE2.
5. Establish an EBGP peer relationship between each pair of the PE and CE.
6. Establish an MP-IBGP peer relationship between PEs.
7. Configure an SRv6-BE path on PE1 and PE2.
Data Preparation
l IPv6 address of each interface on PE1, the P, and PE2

l Area number of PE1, the P, and PE2
l Level on PE1, the P, and PE2
l VPN instance name, RD, and RT on PE1 and PE2
Procedure
the following example, the configuration on PE1 is used as an example. The configurations of

the other routers are similar to the configuration of PE1. For configuration details, see
[*HUAWEI] commit
[~PE1-GigabitEthernet1/0/0] ipv6 enable
[*PE1-GigabitEthernet1/0/0] ipv6 address 2001::1 96

# 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
[*PE1-LoopBack1] commit
[~PE1-LoopBack1] quit
# Configure the P.
[~P] isis 1
[*P-isis-1] ipv6 enable topology ipv6
[*P-isis-1] quit
[*P-GigabitEthernet1/0/0] isis ipv6 enable 1
[*P-GigabitEthernet1/0/0] commit
[~P-GigabitEthernet1/0/0] quit
[*P-GigabitEthernet2/0/0] isis ipv6 enable 1
[*P-GigabitEthernet2/0/0] commit
[~P-GigabitEthernet2/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] ipv6 enable topology ipv6
[*PE2-isis-1] quit
[*PE2-GigabitEthernet1/0/0] isis ipv6 enable 1
[*PE2] interface loopback1
[*PE2-LoopBack1] isis ipv6 enable 1
[*PE2-LoopBack1] commit
[~PE2-LoopBack1] quit
After completing the configuration, verify that IS-IS is correctly configured.
# Display information about IS-IS neighbors. Use the display on PE1 as an example.


--------------------------------------------------------------------------------
0000.0000.0002 GE1/0/0 0000.0000.0002.01 Up 8s L1 64
Total Peer(s): 1
# Display IS-IS routing table information. Use the display on PE1 as an example.
[~PE1] display isis route
-----------------------------

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

--------------------------------------------------------------------------------
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
# Configure PE1.
[*PE1] commit
# Configure PE2.
[*PE2] commit
# Assign an IP address to each interface on CEs as shown in Figure 2-32. For configuration
After completing 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.

NOTE
Step 4 Establish EBGP peer relationships between PEs and CEs.

# 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-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-vpna] import-route direct
[~PE2-bgp] quit
PrefRcv
10.1.1.2 4 65410 11 9 0 00:06:37 Established 1

# Configure PE1.
[~PE1] bgp 100

[~PE1-bgp] peer 3::3 as-number 100

[*PE1-bgp] peer 3::3 connect-interface loopback 1
[*PE1-bgp-af-vpnv4] peer 3::3 enable
[~PE1-bgp] quit
# Configure PE2.
[~PE2] bgp 100
[~PE2-bgp] peer 1::1 as-number 100
[*PE2-bgp] peer 1::1 connect-interface loopback 1
[*PE2-bgp-af-vpnv4] peer 1::1 enable
[~PE2-bgp] quit
# After completing the configuration, run the display bgp vpnv4 all peer command on PEs.
The command output shows that a BGP peer relationship has been established between PEs
and the BGP peer relationship is in the Established state.
Step 6 Establish an SRv6-BE path between PEs.
# Configure PE1.
[~PE1] segment-routing ipv6
[~PE1-segment-routing-ipv6] encapsulation source-address 2001::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
[~PE1-isis-1] quit
# Configure PE2.
[~PE2] segment-routing ipv6
[~PE2-segment-routing-ipv6] encapsulation source-address 2002::2
[*PE2-segment-routing-ipv6] locator as1 ipv6-prefix 30::1 64 static 32
[*PE2-segment-routing-ipv6-locator] quit
[*PE2-segment-routing-ipv6] quit
[*PE2] bgp 100
[*PE2-bgp-af-vpnv4] peer 1::1 prefix-sid
[*PE2-bgp-vpna] segment-routing ipv6 best-effort
[*PE2-bgp-vpna] segment-routing ipv6 locator as1
[~PE2-bgp-vpna] quit
[~PE2-bgp] quit
[~PE2] isis 1
[*PE2-isis-1] segment-routing ipv6 locator as1
[~PE2-isis-1] quit


Run the display segment-routing ipv6 locator [ locator-name ] verbose command to view
SRv6 locator information. Take PE1 as an example:
[~PE1] display segment-routing ipv6 locator verbose
Locator Configuration Table
---------------------------
LocatorName : as1 LocatorID : 1

IPv6Prefix : 10::1 PrefixLength: 64
StaticLength : 32 Reference : 2
Default : N 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
SRv6 local SID table information. Take PE1 as an example:
[~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
CEs in the same VPN can successfully 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
#
encapsulation source-address 2001::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
#
segment-routing ipv6 locator as1
#
#
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
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
#
ipv4-family
#
encapsulation source-address 2002::2
locator as1 ipv6-prefix 30::1 64 static 32
#
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
peer 1::1 as-number 100
peer 1::1 connect-interface LoopBack1
#
ipv4-family unicast
#
ipv6-family unicast
#
ipv4-family vpnv4
policy vpn-target
peer 1::1 enable
peer 1::1 prefix-sid
#
import-route direct
#
return

#
sysname CE1
#
undo shutdown
ip address 10.1.1.2 255.255.255.0
#
interface LoopBack1
ip address 11.11.11.11 255.255.255.255
#
bgp 65410
#
ipv4-family unicast
network 11.11.11.11 255.255.255.255
#
return

#
sysname CE2
#
undo shutdown
ip address 10.2.1.2 255.255.255.0
#
interface LoopBack1
ip address 22.22.22.22 255.255.255.255
#
bgp 65420
#
ipv4-family unicast
network 22.22.22.22 255.255.255.255
#
return
2.3 Segment Routing IPv6 Configuration Commands
2.3.1 add sid

Function
The add sid command adds a specified node to an explicit path.
Format
add sid ipv6 ipv6-address2 [ type { adjacency | prefix } ] { before | after } sid ipv6 ipv6-
address1

Parameters

ipv6 ipv6- Specifies the interface IPv6 address of The value is a 32-digit
address2 a node to be added. hexadecimal number, in the
format of X:X:X:X:X:X:X:X.
type Indicates the SID type. The default -

value is none.
adjacency Sets the SID type to "link." -
prefix Sets the SID type to "prefix." -
before Adds the ipv6-address2 node before -

the ipv6-address1 node.
after Adds the ipv6-address2 node after the -

ipv6-address1 node.
sid Indicates the SID. -
ipv6 ipv6- Specifies the IPv6 address or node The value is a 32-digit
address1 router ID of an interface on a node of hexadecimal number, in the
an explicit path. format of X:X:X:X:X:X:X:X.
Views
Explicit path view
Default Level

mpls-base write
Usage Guidelines
To add a specified node to an explicit path, run the add sid command. In this command, ipv6-
address1 must be included by the explicit path. The IPv6 address must be unique and mapped
to a single type.

Example
# Adds a node with an IPv6 SID of 1::2 before a node with an IPv6 SID of 1::1 on an explicit
path named cc.
[~HUAWEI] te ipv6-router-id 2001:db8::1
[*HUAWEI] segment-routing ipv6
[*HUAWEI-segment-routing-ipv6] traffic-eng enable
[*HUAWEI-segment-routing-ipv6] quit
[*HUAWEI] explicit-path cc
[*HUAWEI-explicit-path-cc] next sid ipv6 1::1 type prefix
[*HUAWEI-explicit-path-cc] add sid ipv6 1::2 type adjacency before sid ipv6 1::1
2.3.2 autoroute announce

Function
The autoroute announce command enables the automatic route advertisement function.
The undo autoroute announce command disables the automatic route advertisement
function.
By default, the automatic route advertisement function is disabled.
Format
autoroute announce isis
undo autoroute announce isis
Parameters
isis Configures IS-IS. -
Views
Default Level
Usage Guidelines
To enable the automatic route advertisement function, run the autoroute announce
command. With this function enabled, when an IGP performs enhanced SPF computation, an
SRH tunnel in the Up state is used.
Example
# Enable the automatic route advertisement function.


[*HUAWEI] interface tunnel10
[*HUAWEI-Tunnel10] tunnel-protocol srv6
[*HUAWEI-Tunnel10] autoroute announce isis
2.3.3 autoroute metric

Function
The autoroute metric command sets automatic route costs.
The undo autoroute metric command deletes automatic route costs.
By default, no automatic route costs are set, and the automatic route costs of an SRv6 tunnel
are equal to those of IGP routes used by the SRH tunnel.
Format
autoroute metric absolute absolute-value
autoroute metric relative relative-value
undo autoroute metric[ absolute [ absolute-value ] | relative [ relative-value ] ]
Parameters
absolute absolute- Specifies an absolute cost The value is an integer ranging
value value. from 1 to 65535.
relative relative-value The value is an integer ranging

Specifies a relative cost value.
from -10 to +10.
Views
Default Level
Usage Guidelines
To set automatic route costs, run the autoroute metric command. IGP routes are
preferentially selected based on the configured costs. The weight values include absolute and
relative values.
Example
# Set the absolute cost of automatic routes to 100.


[*HUAWEI-Tunnel10] autoroute metric absolute 100
2.3.4 delete sid

Function
The delete sid command deletes a specified node to an explicit path.
Format
delete sid ipv6 ipv6-address
Parameters
ipv6 ipv6-address Specifies the interface IPv6 The value is a 32-digit hexadecimal
address of a node to be added. number, in the format of
X:X:X:X:X:X:X:X.
Views
Explicit path view
Default Level

mpls-base write
Usage Guidelines
To delete a specified node to an explicit path if the node's SID becomes useless, run the delete
sid command.
Example
# Delete a node with an IPv6 address of 1::2 from an explicit path.

[*HUAWEI-explicit-path-cc] next sid ipv6 1::2 type adjacency

[*HUAWEI-explicit-path-cc] delete sid ipv6 1::2
2.3.5 destination ipv6

Function
The destination ipv6 command sets an IPv6 destination address for a tunnel.
The undo destination ipv6 command deletes an IPv6 destination address for a tunnel.
By default, no destination IPv6 address is configured for a tunnel.
Format
destination ipv6 ipv6-address
undo destination ipv6
Parameters
ipv6-address Specifies an IPv6 The value is a 32-digit hexadecimal number, in the
address. format of X:X:X:X:X:X:X:X.
Views
Default Level

mpls-te write
Usage Guidelines
To set an IPv6 destination address for a tunnel, run the destination ipv6 command.
Example
# Set an IPv6 destination address for a tunnel.
[~HUAWEI] interface tunnel3
[~HUAWEI-Tunnel3] tunnel-protocol srv6

[*HUAWEI-Tunnel3] destination ipv6 1::1
2.3.6 display explicit-path (SRv6)
Function
The display explicit-path command displays SRv6 explicit path information.
Format
display explicit-path [ name ] path-name [ verbose ]
Parameters
name path-name Specifies the name of an explicit The value is an integer ranging
path. from 1 to 128.
verbose Displays detailed information. -
Views
All views
Default Level
1: Monitoring level

mpls-te write
Usage Guidelines
To view SRv6 explicit path information, run the display explicit-path command.
Example
# Display detailed information about an explicit path.
<HUAWEI> display explicit-path verbose
Path Name : aa Path Status : Enabled
1 1::3
2 1::4
3 1::5
4 1::6 Adjacency
5 1::7 Prefix
List of segment routing ipv6 tunnels using this path:
Tunnel1 Tunnel2
Number of segment routing ipv6 tunnels using this path: 2

Table 2-12 Description of the display explicit-path command output
Item Description
Path Name Explicit path name
Path Status Explicit path status
List of segment routing List of SRv6 tunnels that are established over the specified
ipv6 tunnels using this explicit path
path
Number of segment Number of SRv6 tunnels that are established over the specified
routing ipv6 tunnels explicit path
using this path
2.3.7 display isis srv6 ti-lfa-node
Function
The display isis srv6 ti-lfa-node command displays TI-LFA information on a specified node.
Format
display isis [ process-id ] srv6 ti-lfa-node [ ipv6 ] [ level-1 | level-2 ] [ systemid systemid ]
Parameters

process-id Displays TI-LFA information on nodes in a The value is an integer
specified process. ranging from 1 to
4294967295.
If this parameter is not configured, TI-LFA
information of all processes is displayed.
ipv6 Displays TI-LFA information on IPv6 nodes. -

Level-1 areas.

Level-2 areas.
NOTE
If no level is specified, TI-LFA information of nodes
in all areas is displayed.
systemid Specifies the system ID of a node. The value is a string of 1

systemid to 19 characters.

Views
All views
Default Level
3: Management level

isis debug
Usage Guidelines
After IS-IS TI-LFA FRR is configured on a device, run the display isis srv6 ti-lfa-node
command to view TI-LFA information of a specific node or all nodes. The command output
contains the P node's prefix, outbound interface name, next-hop IP address, P and Q nodes,
and P-to-Q label stack.
Example
# Display TI-LFA information on nodes in Level 1 areas in an IPv6 IS-IS process numbered
1.
<HUAWEI> display isis 1 srv6 ti-lfa-node level-1
-----------------------------------------------

DestNode : 1111.1111.1111 Protect : LINK
PNode : 3333.3333.3333 QNode : 3333.3333.3333
ExitInterface : Eth2/0/0 NexthopAddr : 2222.2222.2222
SidStack (P->Q) :(FD00::83:422:0:363, FD00::83:422:0:364)

PNode : 4444.4444.4444 QNode : 4444.4444.4444
SidStack (P->Q) : (FD00::83:422:0:363, FD00::83:422:0:364)

PNode : 3333.3333.3333 QNode : 3333.3333.3333
SidStack (P->Q) :(FD00::83:422:0:363, FD00::83:422:0:364)

PNode : 4444.4444.4444 QNode : 4444.4444.4444
SidStack (P->Q) : (FD00::83:422:0:363, FD00::83:422:0:364)

Table 2-13 Description of the display isis srv6 ti-lfa-node command output
Item Description
DestNode System ID of the destination node
Protect Protection type:

l LINK: Link protection
l LINKNODE: Node protection
PNode System ID of the P node
QNode System ID of the Q node
ExitInterface Backup outbound interface name
NexthopAddr Backup next-hop node
SidStack (P->Q) P-to-Q SID label stack
2.3.8 display segment-routing ipv6 local-sid

Function
The display segment-routing ipv6 local-sid command displays information about Local SID
tables of the SRv6.
Format
display segment-routing ipv6 local-sid { end | end-x | end-dt4 | end-otp } [ sid ]
forwarding
display segment-routing ipv6 local-sid end-x interface interface-type interface-number
[ nexthop nexthop-address ] forwarding
display segment-routing ipv6 local-sid end-dt4 vpn-instance vpn-instance-name
forwarding
Parameters
end Indicates the End SID. -
end-x Indicates the End.X SID. -
end-dt4 Indicates the END.DT4 -

type.
end-otp Indicates the END.OTP -

type.


sid The value is a 32-digit hexadecimal
Specifies an IPv6 SID
number, in the format of
value.
X:X:X:X:X:X:X:X.
forwarding Displays forwarding -
information.
interface interface- Specifies the interface type -

type interface- and interface number.
number
nexthop nexthop- Specifies a nexthop IP The value is a 32-digit hexadecimal
address address. number, in the format of
X:X:X:X:X:X:X:X.
vpn-instance vpn- Specifies the name of a The value is a string of 1 to 31 case-

instance-name VPN instance. sensitive characters, spaces not
supported. In addition, the VPN instance
name must not be _public_. When
double quotation marks are used around
the string, spaces are allowed in the
string.
Views
All views
Default Level
1: Monitoring level

Usage Guidelines
To view information about Local SID tables of SRv6 of a specific SID or all SIDs, run the
display segment-routing ipv6 local-sid command.
When End.X SID information is queried, the output contains the outbound interface name and
next hop information.
Example
# Display information about Local SRv6 End SID tables.
<HUAWEI> display segment-routing ipv6 local-sid end forwarding
My Local-SID End Forwarding Table
---------------------------------
SID : 10:1::1:0/128 FuncType : End

Flaver : PSP
LocatorName: a LocatorID: 1

Flaver : PSP
LocatorName: b LocatorID: 2

Flaver : PSP
LocatorName: c LocatorID: 3
# Display information about Local SRv6 End.X SID tables.

<HUAWEI> display segment-routing ipv6 local-sid end-x forwarding
My Local-SID End.X Forwarding Table
-----------------------------------
SID : 222::4:101:0:1/128 FuncType :End.x Flavor :--
NextHop : Interface : ExitIndex :
FE80::3A00:10FF:FE03:1 GE2/0/0 0x0000000a
SID : 123:ABC::4:101:0:2/128 FuncType :End.x Flavor :PSP

NextHop : Interface : ExitIndex :
FE80::3A00:10FF:FE03:0 GE1/0/0 0x00000009
Table 2-14 Description of the display segment-routing ipv6 local-sid command output
Item Description
SID SID value
FuncType Function type
Flavor Function feature, which is fixed at Penultimate

Segment POP of the SRH (PSP)
NextHop Next-hop IP address
Interface Outbound interface name
ExitIndex Outbound interface index
# Display information about the local SID table of the SRv6 END.DT4.
<HUAWEI> display segment-routing ipv6 local-sid end-dt4 forwarding
My Local-SID End.DT4 Forwarding Table
-------------------------------------
SID : 1234::40/128 FuncType : End.DT4

VPN Name : vpn1vpn2vpn3vpn4vpn5vpn6vpn7vp1 VPN ID : 67
LocatorName: locator_1_locator_1_locator_1_3 LocatorID: 7




Table 2-15 Description of the display segment-routing ipv6 local-sid end-dt4 forwarding
command output
Item Description
VPN Name VPN instance name mapped to an SID
VPN ID VPN ID mapped to the SID
LocatorName Locator name mapped to the SID
LocatorID Locator ID mapped to the SID
# Display information about the local SID table of the SRv6 END.OTP.
<HUAWEI> display segment-routing ipv6 local-sid end-otp forwarding
My Local-SID End.OTP Forwarding Table
-------------------------------------
SID : 30::65/128 FuncType : End.OTP

LocatorName: test LocatorID: 1
Total SID(s): 1
2.3.9 display segment-routing ipv6 locator
Function
The display segment-routing ipv6 locator command displays SRv6 locator information.
Format
display segment-routing ipv6 locator [ locator-name ] verbose
Parameters

locator-name Specifies the name of a SID node The value is a string of 1 to 31 case-
route locator. sensitive characters.
verbose Displays detailed information. -
Views
All views
Default Level
1: Monitoring level


Usage Guidelines
After a locator is configured in SRv6, a static SID can be assigned to the locator, and an IGP
or BGP can advertise the SID of the locator. After the static SID locator length is set for the
locator, dynamic SIDs out of the specified static SID range can be applied for, which prevents
SID conflicts.
To view SRv6 locator information, run the display segment-routing ipv6 locator command.
Example
# Display SRv6 locator information.
<HUAWEI> display segment-routing ipv6 locator verbose
Locator Configuration Table
--------------------------
LocatorName : locator_1_locator_1_locator_1_2 LocatorID : 6

IPv6Prefix : 1234:5678:9013:: PrefixLength: 48
Default : Y ArgsLength : 8
AutoSIDBegin : 1234:5678:9013::1:0
AutoSIDEnd : 1234:5678:9013::FFFF:FFFF:FFFF:FFFF

IPv6Prefix : 1234:: PrefixLength: 100
AutoSIDBegin : 1234::1:0
AutoSIDEnd : 1234::FFFF:FFFF:FFFF:FFFF

IPv6Prefix : 1234:1:: PrefixLength: 100
AutoSIDBegin : 1234:1::1:0
AutoSIDEnd : 1234:1::FFFF:FFFF:FFFF:FFFF
Table 2-16 Description of the display segment-routing ipv6 locator verbose command
output
Item Description
LocatorName Configured locator name
LocatorID Automatically assigned locator ID
IPv6Prefix Locator prefix
PrefixLength Locator prefix length
StaticLength Static segment length of the locator
Reference Whether the locator is referenced

Item Description
Default Whether the default locator is used
ArgsLength Length of arguments segment
AutoSIDBegin Begin value of the dynamic SID
AutoSIDEnd End value of the dynamic SID
2.3.10 display srv6 lsp
Function
The display srv6 lsp command displays SRv6 label stack information.
Format
display srv6 lsp [ lsp-id ingress-router-id session-id lsp-id ] [ verbose ]
Parameters

lsp-id Specifies an LSP ID. -
ingress-router-id Specifies the router ID of the The value is in dotted decimal

ingress. notation.
session-id Specifies a session ID. The value is an integer ranging

from 0 to 65535.
lsp-id Specifies the LSP ID. The value is an integer ranging

from 0 to 65535.
verbose Displays detailed SRv6 -

information.
Views
All views
Default Level
3: Management level


mpls-base debug
Usage Guidelines
To view label stack information on all SRv6 LSPs, run the display srv6 lsp command.
To view information about the label stack of a specific SRv6 LSP, run the display srv6 lsp
[ lsp-id ingress-router-id session-id lsp-id ] [ verbose ] command.
Example
# Display SRv6 label stack information.
<HUAWEI> display srv6 lsp
Total lsp number: 2
----------------------------------------------------------------------------------
-
LSP Information: SRv6 LSP
----------------------------------------------------------------------------------
-
FEC Out SID
2::2/128 1::2
3::3/128 1::7
Table 2-17 Description of the display srv6 lsp command output
Item Description
FEC Forwarding equivalence class
Out SID Outgoing SID
2.3.11 display srv6 te tunnel path
Function
The display srv6 te tunnel path command displays path attributes of a tunnel on a local
node.
Format
display srv6 te tunnel path [ name ] [ lsp-id ingress-router-id session-id local-lsp-id ]
display srv6 te tunnel path tunnel-name name [ lsp-id ingress-router-id session-id local-
lsp-id ]

Parameters

name Specifies a tunnel name. The tunnel name The name is a string of 1
format, including the upper and lower casing, to 255 case-sensitive
and blank spaces, must be consistent with characters, spaces not
that saved in the configuration file. For supported.
example, when a tunnel interface in a
configuration file is named "interface
Tunnel10", the tunnel name to be specified in
this command must also be Tunnel10.
"Tunnel10" or "Tunnel 10" is incorrect.
tunnel-name Specifies the tunnel name. -
lsp-id Specifies an LSP ID. -
ingress-router-id Specifies the LSR ID of the ingress from The value is in dotted
which a P2MP TE tunnel originates. decimal notation.
session-id Specifies a tunnel ID. The value is an integer

local-lsp-id Specifies the LSP ID of a P2MP TE tunnel. The value is an integer

Views
All views
Default Level
1: Monitoring level

mpls-base read
Usage Guidelines
To view path attributes of a tunnel on a local node, run the display srv6 te tunnel path
command. If no tunnel interface number is specified, path attributes of all tunnels are
displayed.
LSP label stack-based path information can be queried based on a specified tunnel path.

Example
# Display LSP label stack-based path information on all tunnels.
<HUAWEI> display srv6 te tunnel path
Lsp ID : [1::1] :[10] :[9]
Hop Information
Hop 0 Adjacency SID IPv6 1::3
Hop 4 Prefix SID IPv6 1::7

Lsp ID : [1::1] :[100] :[8]
Hop Information
# Display LSP label stack-based path information on a tunnel named Tunnel1.

<HUAWEI> display srv6 te tunnel path Tunnel1
Lsp ID : [1::1] :[10] :[9]
Hop Information
Table 2-18 Description of the display srv6 te tunnel path command output
Item Description
Tunnel Interface Name Tunnel interface name
Lsp ID LSP ID
Hop Information SID IPv6 hop information
2.3.12 display srv6 te tunnel-interface

Function
The display srv6 te tunnel-interface command displays SRv6 tunnel interface information
on a local node.
Format
display srv6 te tunnel-interface
Parameters
None

Views
All views
Default Level
1: Monitoring level

mpls-base read
Usage Guidelines
To view SRv6 tunnel interface information on a local node, run the display srv6 te tunnel-
interface command.
Example
# Display information about all SRv6 tunnel interfaces.
<HUAWEI> display srv6 te tunnel-interface
Tunnel Attributes :
Traffic Switch : -
Session ID : 100
Ingress LSR ID : [1::1]
Egress LSR ID : [1::2]
FTid : 1
Bfd Cap : None
Tunnel BFD Status : -
BackUp LSP Type : None

Explicit Path Name : aa
BFD Status : -

Tunnel Attributes :
Traffic Switch : -
Session ID : 10
Ingress LSR ID : [1::1]
Egress LSR ID : [1::4]
FTid : 2
Bfd Cap : None
Tunnel BFD Status : -
BackUp LSP Type : None



Explicit Path Name : aa
BFD Status : -
Table 2-19 Description of the display srv6 te tunnel-interface command output

Item Description
Tunnel Name Tunnel interface name.

Item Description
Tunnel State Desc Tunnel status:

l CR-LSP is up: The tunnel is being used.
l CR-LSP is down: The tunnel fails to be
set up.
l Modifying CR-LSP is waiting for
deleting: A tunnel is waiting for being
deleted.
l Modifying CR-LSP is waiting for
switching: Traffic is waiting for being
switched from a Modified CR-LSP to
another CR-LSP.
l Primary CR-LSP Up and HotBackup
CR-LSP Up: CR-LSP hot standby is
configured, and both the primary and
hot-standby CR-LSPs are successfully
established.
l Primary CR-LSP UP and HotBackup
CR-LSP setting Up: CR-LSP hot
standby is configured. The primary CR-
LSP is successfully established, and the
hot-standby CR-LSP fails..
l Primary CR-LSP Down and Backup CR-
LSP setting Up: CR-LSP hot standby
and a best-effort path are configured.
The primary and hot-standby CR-LSPs
fail, and a node attempts to establish a
hot-standby CR-LSP or best-effort path.
l Backup CR-LSP In use and Primary CR-
LSP setting Up: CR-LSP hot standby or
ordinary backup is configured. The
primary CR-LSP fails, and a backup CR-
LSP (hot-standby CR-LSP or best-effort
path) is successfully established. The
backup CR-LSP is transmitting data.
l CR-LSP is setting Up: The system is
trying to set up a CR-LSP.
l CR-LSP setup Failed: A CR-LSP fails to
be established.
If Down is displayed, the tunnel has been
Down.
Tunnel Attributes Tunnel attribute.

Item Description
Active LSP Type of LSP in use:

l Primary LSP
l LSP Hot-Standby LSP
l LSP Ordinary LSP
l LSP BestEffort LSP
Traffic Switch Traffic switched between different types of

LSPs. This field is only displayed when
traffic is being switched. For example, if
traffic is being switched from a best-effort
path to a primary LSP, this field value is
BestEffort LSP -> Primary LSP.
l If the Active LSP field value is
BestEffort LSP, traffic is in delayed
switching state and is passing through a
best-effort path.
l If the Active LSP field value is Primary
LSP, traffic is in delayed deletion state
and is passing through a primary LSP.
Session ID Tunnel ID.
Ingress LSR ID Ingress LSR ID, in the format of X.X.X.X.
Egress LSR ID Egress LSR ID.
Admin State Administrative status of the tunnel.
Oper State Running status of the tunnel.
Signaling Protocol Signaling protocol type.
FTid Forwarding entry index.
Bfd Cap BFD capability:

l Enable
l Disable
Tunnel BFD Status BFD for tunnel status.
BackUp LSP Type Type of backup CR-LSP:

l Hot-standby
l Ordinary
l BestEffort
Secondary Explicit Path Name Name of a backup explicit path.
Hot-Standby Revertive Mode Hot-standby revertive mode:

l Revertive
l Non-Revertive

Item Description
Hot-Standby Switch State Hot-standby switchover status:

l FORCE: Traffic is forcibly switched to a
hot-standby CR-LSP.
l CLEAR: Traffic can be switched back to
the primary CR-LSP.
Primary LSP ID Primary LSP ID
LSP State Status of a main LSP:

l Down: No main LSP is established.
l UP: A main LSP is successfully
established.
l FRR INUSE: The LSP of the specific
type is in the FRR In-use state.
Status of a modified LSP:
l DOWN: No modified LSP is
established.
l GRACEFUL SWITCH: Traffic is being
gracefully switched between the main
and modified LSPs.
l GRACEFUL DELETE: The modified
LSP is being gracefully deleted.
LSP Type LSP type:

l Primary LSP
l LSP Hot-Standby LSP
l Ordinary LSP
l BestEffort LSP
Explicit Path Name Name of an explicit path
BFD Status BFD status.
2.3.13 encapsulation source-address
Function
The encapsulation source-address command configures the source address used in SRv6
VPN encapsulation.
The undo encapsulation source-address command deletes the source address used in SRv6
VPN encapsulation.
By default, no source address is configured for SRv6 VPN encapsulation.

Format
encapsulation source-address ipv6-address [ ip-ttl ttl-value ]
undo encapsulation source-address [ ipv6-address [ ip-ttl ttl-value ] ]
Parameters

ipv6-address Specifies an IPv6 address. The value is a 32-digit
hexadecimal number, in the format
of X:X:X:X:X:X:X:X.
ip-ttl ttl-value Specifies a TTL in IPv6 packets. The value is an integer ranging
from 1 to 255. The default value is
If the ttl-mode comand is not run or 255.
the ttl-mode pipe is run in the VPN
instance view, the TTL carried in the
IPv6 header is the same as ip-ttl ttl-
value.
Views
Segment routing IPv6 view
Default Level

segr write
Usage Guidelines
When traffic enters the SRv6 VPN tunnel, to set the source address carried in the IPv6 header,
run the encapsulation source-address command.
Example
# Configure the source address used in SRv6 VPN encapsulation.
[~HUAWEI] segment-routing ipv6
[~HUAWEI-segment-routing-ipv6] encapsulation source-address 2001:db8:66::66 ip-
ttl 200

2.3.14 ipv6 avoid-microloop segment-routing

Function
The ipv6 avoid-microloop segment-routing command enables the switchback anti-
microloop function in SRv6.
The undo ipv6 avoid-microloop segment-routing command disables the switchback anti-
microloop function in SRv6.
Format
ipv6 avoid-microloop segment-routing
undo ipv6 avoid-microloop segment-routing
Parameters
None
Views
IS-IS view
Default Level

isis write
Usage Guidelines
Usage Scenario
microloops, run the ipv6 avoid-microloop segment-routing command to delay the route next
hop switching.
Follow-up Procedure
Run the ipv6 avoid-microloop segment-routing rib-update-delay command to set a delay
time for a route next hop switchback.
Example
# Enable the switchback anti-microloop function in SRv6.


[~HUAWEI-segment-routing-ipv6] locator test1 ipv6-prefix 100:: 64 static 32
default
[*HUAWEI-segment-routing-ipv6] commit
[~HUAWEI-segment-routing-ipv6] quit
[~HUAWEI] isis 1
[*HUAWEI-isis-1] ipv6 enable
[*HUAWEI-isis-1] segment-routing ipv6 locator test1 auto-sid-disable
[*HUAWEI-isis-1] ipv6 avoid-microloop segment-routing
2.3.15 ipv6 avoid-microloop segment-routing rib-update-delay

Function
The ipv6 avoid-microloop segment-routing rib-update-delay command sets a delay in
delivering IS-IS routes in SRv6.
The undo ipv6 avoid-microloop segment-routing rib-update-delay command restores the
default delay in delivering IS-IS routes in SRv6.
The default delay time is 5000 ms.
Format
ipv6 avoid-microloop segment-routing rib-update-delay rib-update-delay
undo ipv6 avoid-microloop segment-routing rib-update-delay
Parameters
rib-update-delay Sets a delay in delivering IS-IS The value is an integer ranging from
routes. 1000 to 10000 in milliseconds.
Views
IS-IS view
Default Level

isis write
Usage Guidelines

microloops, run the ipv6 avoid-microloop segment-routing command to delay the route next
hop switching. To set a delay in delivering IS-IS routes in SRv6, run the ipv6 avoid-
microloop segment-routing rib-update-delay command.
Example
# Set a delay in delivering IS-IS routes in SRv6.
default
[~HUAWEI] isis 1
[*HUAWEI-isis-1] ipv6 avoid-microloop segment-routing
[*HUAWEI-isis-1] ipv6 avoid-microloop segment-routing rib-update-delay 2000
2.3.16 isis ipv6 ti-lfa disable
Function
The isis ipv6 ti-lfa disable command disables TI-LFA on an IPv6 IS-IS interface.
The undo isis ipv6 ti-lfa disable command enables TI-LFA on an IPv6 IS-IS interface.
By default, IPv6 TI-LFA is enabled automatically on IS-IS interfaces if the ti-lfa (IPv6)
command is run.
Format
isis ipv6 ti-lfa disable [ level-1 | level-2 | level-1-2 ]
undo isis ipv6 ti-lfa disable [ level-1 | level-2 | level-1-2 ]
Parameters

level-1 Enables or disables TI-LFA on an IPv6 IS-IS Level-1 interface. -
level-2 Enables or disables TI-LFA on an IPv6 IS-IS Level-2 interface. -
level-1-2 Enables or disables TI-LFA on all IPv6 IS-IS interfaces. -
NOTE
If no level is specified, TI-LFA is disabled by default on all IS-IS interfaces.
Views
Interface view

Default Level

isis write
Usage Guidelines
Usage Scenario
After the ti-lfa (IPv6) command is run, TI-LFA is automatically enabled on all IPv6 IS-IS
interfaces. To disable TI-LFA on a specified interface, run the isis ipv6 ti-lfa disable
command in the interface view.
Precautions
If the ti-lfa (IPv6) command is not run, the isis ipv6 ti-lfa disable command can be run but
cannot take effect on an interface.
If the isis ipv6 ti-lfa disable and ti-lfa (IPv6) commands are run in sequence, the isis ipv6 ti-
lfa disable command still takes effect.
Example
# Disable TI-LFA on an IPv6 IS-IS Level-1 interface.
[~HUAWEI] isis 1
[*HUAWEI-isis-1] ipv6 frr
[*HUAWEI-isis-1-ipv6-frr] loop-free-alternate level-2
[*HUAWEI-isis-1-ipv6-frr] ti-lfa level-2
[*HUAWEI-isis-1-ipv6-frr] quit
[*HUAWEI-GigabitEthernet1/0/0] ipv6 enable
[*HUAWEI-GigabitEthernet1/0/0] isis ipv6 enable 1
[*HUAWEI-GigabitEthernet1/0/0] isis ipv6 ti-lfa disable level-1
Related Topics
2.3.31 ti-lfa (IPv6)
2.3.17 locator
Function
The locator command configures a SID node route locator.
The undo locator command deletes a SID node route locator.

By default, no SID node route locator is configured.
Format
locator locator-name [ ipv6-prefix ipv6-address prefix-length [ static static-length | args
args-length ] * [ default ] ]
undo locator locator-name [ ipv6-prefix ipv6-address prefix-length [ static static-length |

args args-length ] * [ default ] ]
Parameters

locator-name Specifies the name of a SID node The value is a string of 1 to 31 case-
route locator. sensitive characters.
ipv6-prefix Specifies the prefix of an IPv6 The address is a 32-digit hexadecimal

ipv6-address address. number, in the format of
X:X:X:X:X:X:X:X.
prefix-length Specifies the prefix length of an The value is an integer ranging from
IPv6 address. 32 to 120.
static static- Specifies a static segment length. The value is an integer ranging from 1
length to 96.
args args-length Specifies an arguments segment The value is an integer ranging from 1
length. to 64.
The arguments segment is at the The total length specified using prefix-
end of the SID. If the args args- length, static-length, and args-length
length parameter is configured, cannot exceed 128.
the arguments segment is
reserved. The static or generated
dynamic SID is not occupied by
the configuration.
default Indicates whether a default route

-
segment is used.
Views
Default Level


segr write
Usage Guidelines
An SRv6 SID is a 128-bit IPv6 address expressed in the Locator:Function:Args format.
l The Locator field corresponds to the ipv6-prefix ipv6-address parameter, and its length
is determined by the prefix-length parameter. A locator identifies an IPv6 network
segment on which all IPv6 addresses can be assigned as SRv6 SIDs. After the Locator
field is configured for a node, the system generates a Locator network segment route
through which other nodes can locate this node. In addition, all SIDs advertised by this
node can be reached through the Locator network segment route.
l The Function field is also called Opcode (operation code), which can be dynamically
assigned using an IGP or be configured using the opcode command. When configuring a
locator, you can use the static static-length parameter to specify the length of a static
operation code segment. The length determines the number of static operation codes that
can be configured in the locator. During dynamic operation code allocation, the IGP
applies for operation codes out of the static operation code segment so that no SRv6 SID
conflict occurs.
l The Args field is determined by the args args-length parameter. It is optional.
The relationships between the preceding fields are as follows:

+-----------------------------------------------------------------+
| Locator | Dynamic Opcode | Static Opcode | Args |
+-----------------------------------------------------------------+
Table 2-20 describes how SIDs are generated based on different combinations of parameters.
Table 2-20 SRv6 SID generation examples
No. Configuration Description SRv6 SID
1 locator srv6_locator1 The locator is Start value of the static

ipv6-prefix
2001:DB8:ABCD:: 64 2001:DB8:ABCD::, operation code segment:
static 32 occupying 64 bits. The 2001:DB8:ABCD::1
static operation code End value of the static
segment occupies 32 bits, operation code segment:
the Args field zero bits, 2001:DB8:ABCD::FFFF:
and the dynamic FFFF
operation code segment
32 bits (128 – 64 – 32 Start value of the
– 0 = 32). dynamic operation code
segment:
2001:DB8:ABCD::1:0:0
End value of the dynamic
operation code segment:
2001:DB8:ABCD::FFFF:
FFFF:FFFF:FFFF

No. Configuration Description SRv6 SID

ipv6-prefix
static 24 args 32 occupying 64 bits. The 2001:DB8:ABCD:0:0:1::
the Args field 32 bits, and 2001:DB8:ABCD:
the dynamic operation 0:FF:FFFF::
code segment 8 bits (128
– 64 – 24 – 32 = 8). Start value of the
dynamic operation code
segment:
2001:DB8:ABCD:0:100::
End value of the dynamic
operation code segment:
2001:DB8:ABCD:
0:FFFF:FFFF::

ipv6-prefix
static 32 args 32 occupying 64 bits. The 2001:DB8:ABCD:0:0:1::
the Args field 32 bits, and 2001:DB8:ABCD:
the dynamic operation 0:FFFF:FFFF::
code segment zero bits
(128 – 64 – 32 – 32 = No dynamic operation
0). code segment exists.
4 locator srv6_locator4 The locator is No static operation code

ipv6-prefix
2001:DB8:ABCD:: 64 2001:DB8:ABCD::, segment exists.
args 32 occupying 64 bits. The Start value of the
static operation code dynamic operation code
segment occupies zero segment:
bits, the Args field 32 2001:DB8:ABCD::1:0:0
bits, and the dynamic
operation code segment End value of the dynamic
32 bits (128 – 64 – 0 – operation code segment:
32 = 32). 2001:DB8:ABCD::FFFF:
FFFF:0:0
If a static operation code is configured, it is preferentially used for SID generation. If no static
operation code is configured, operation codes are dynamically assigned. The process of
generating SRv6 SIDs through IS-IS is as follows:
1. Configure a locator segment in the system view, and run the segment-routing ipv6
{ locator locator-name | locator-default } command in the IS-IS view to enable SRv6
and reference the locator. An IS-IS process can reference only one locator.
2. IS-IS generates End SIDs for all locators based on the dynamic operation code segment
specified in locator configurations. Both penultimate segment pop of the SRH (PSP) and
non-PSP SIDs are generated.

3. Configure an IPv6 address for the desired interface, enable IS-IS IPv6, and generate
End.X SIDs for the interface through IS-IS. SIDs are generated based on the dynamic
operation code segment specified in locator configurations. Both PSP and non-PSP SIDs
are generated.
Example
# Configure a SID node route locator.
HUAWEI> system-view
default
2.3.18 modify sid

Function
The modify sid command changes an IPv6 address of a node on an explicit path to another
node on the same path.
Format
modify sid ipv6 ipv6-address1 to ipv6-address2 [ type { adjacency | prefix} ]
Parameters
ipv6 ipv6-address1 to Changes ipv6-address1 to ipv6- ipv6-address1 and ipv6-
ipv6-address2 address2 on an explicit path. address2 are 32-digit
hexadecimal numbers.
type Indicates the SID type. -
Views
Explicit path view
Default Level


mpls-base write
Usage Guidelines
To change an IPv6 address of a node on an explicit path to another node on the same path, run
the modify sid command. The existing next-hop IPv6 address already on the explicit path
cannot be specified.
Example
# Change the IPv6 address of a node on an explicit path from 1::1 to 1::2, with the SID type
of link.
[*HUAWEI-explicit-path-cc] next sid ipv6 1::1 type adjacency
[*HUAWEI-explicit-path-cc] modify sid ipv6 1::1 to 1::2 type adjacency
2.3.19 next sid ipv6
Function
The next sid ipv6 command adds an IPv6 SID in an existing explicit path view.
The undo next sid ipv6 command deletes an IPv6 SID in an existing explicit path view.
By default, no an IPv6 SID is added in an existing explicit path view.
Format
next sid ipv6 ipv6-address [ type { adjacency | prefix } ]
undo next sid ipv6 ipv6-address [ type { adjacency | prefix } ]
Parameters

ipv6-address Specifies an IPv6 address. The value is a 32-digit hexadecimal number, in
the format of X:X:X:X:X:X:X:X.
type Indicates the SID type. -


Views
Explicit path view
Default Level

mpls-te write
Usage Guidelines
To add an IPv6 SID in an existing explicit path view, run the next sid ipv6 command. Explicit
paths of all types must be configured using the same explicit path template.
In the view of a specific explicit path, hops to be configured must be of the same type.
Example
# Create an explicit path named cc.
[*HUAWEI-explicit-path-cc] next sid ipv6 1::1 type prefix
2.3.20 opcode
Function
The opcode command configures a static SRv6 SID operation code (Opcode).
The undo opcode command deletes a static SRv6 SID operation code.
By default, no static SRv6 SID operation code is configured.
Format
opcode func-opcode end [ no-psp ]
undo opcode func-opcode end [ no-psp ]
opcode func-opcode end-x interface interface-name nexthop nexthop-address [ no-psp ]

undo opcode func-opcode [ end-x interface interface-type interface-number nexthop

nexthop-address [ no-psp ] ]
opcode func-opcode end-dt4 vpn-instance vpn-instance-name
undo opcode func-opcode end-dt4 [ vpn-instance vpn-instance-name ]
opcode func-opcode end-otp
undo opcode func-opcode end-otp
Parameters

func-opcode Specifies a static SRv6 SID The value is a 32-digit hexadecimal
operation code. number, in the format of
X:X:X:X:X:X:X:X.
end Indicates the End SID type. -

no-psp Disables penultimate -
segment pop of the SRH
(PSP).
end-x Indicates the End.X SID -
type.
interface interface- Specifies the interface type -
type interface- and interface number.
number
nexthop nexthop- Specifies a next-hop IP The value is a 32-digit hexadecimal
address address. number, in the format of
X:X:X:X:X:X:X:X.
end-dt4 Indicates the End.DT4 SID. -

vpn-instance vpn- Specifies the name of a The value is a string of 1 to 31 case-
instance-name VPN instance. sensitive characters, spaces not
supported. In addition, the VPN
instance name must not be _public_.
When double quotation marks are used
around the string, spaces are allowed in
the string.
end-otp Indicates the End.OTP SID. -
Views
Segment routing IPv6 locator view
Default Level


segr write
Usage Guidelines
Usage Scenario
An SRv6 SID is a 128-bit IPv6 address expressed in the Locator:Function:Args format. The
Function field is also called Opcode, and different operation codes define different functions.
Operation codes can be dynamically assigned using an IGP or be configured using the opcode
command.
Static operation codes must be configured within the static operation code segment to prevent
conflicts with dynamically assigned operation codes. The length of a static operation code
segment is configured through the static static-length parameter in the locator command to
determine the number of static operation codes that can be configured in a specified locator
range.
After you run the opcode command to configure various types of operation codes, the
Locator, Opcode, and Args fields form a unique SRv6 SID. The SRv6 SID is then added to
the local SID table on the device and also advertised externally through a routing protocol. In
forwarding, the Locator field in the SRv6 SID instructs other nodes to find the SRv6 SID
generation node through addressing and forward SRv6 packets to the node; the Opcode field
instructs the SRv6 SID generation node to implement corresponding functions.
Precautions
To ensure proper forwarding, configured static SIDs and IPv6 addresses configured on
interfaces cannot conflict with each other.
Example
# Configure the static SID operation code.
[~HUAWEI] ip vpn-instance vpn1
[*HUAWEI-vpn-instance-vpn1] commit
[~HUAWEI-vpn-instance-vpn1] quit
[*HUAWEI-segment-routing-ipv6] locator test1 ipv6-prefix 100:: 64 static 32
default
[*HUAWEI-segment-routing-ipv6-locator] opcode ::100 end
[*HUAWEI-segment-routing-ipv6-locator] opcode ::200 end-x interface
[*HUAWEI-segment-routing-ipv6-locator] opcode ::300 end-dt4 vpn-instance vpn1
[*HUAWEI-segment-routing-ipv6-locator] opcode ::400 end-otp
2.3.21 peer enable (BGP VPNv4 address family view)
Function
The peer enable command enables BGP to exchange IPv4 route information with the
specified IPv6 peer in the BGP VPNv4 address family view.

The undo peer enable command disables BGP from exchanging IPv4 route information with
the specified IPv6 peer in the BGP VPNv4 address family view.
By default, BGP is disabled from exchanging IPv4 route information with the specified IPv6
peer in the BGP VPNv4 address family view.
Format
peer ipv6-address enable
undo peer ipv6-address enable
Parameters
ipv6-address Specifies the IPv6 address of a The value is a 32-digit hexadecimal number,
BGP peer. in the format of X:X:X:X:X:X:X:X.
Views
BGP VPNv4 address family view
Default Level

bgp write
Usage Guidelines
Usage Scenarios
In an SRv6 VPN scenario, IPv6 runs on a public network and IPv4 runs on the private
network. PEs establish an IPv6 BGP peer relationship to exchange IPv4 private network route
information. To enable BGP to exchange IPv4 route information with the specified IPv6 peer
in the BGP VPNv4 address family view, run the peer enable command.
Example
# Enable a device to exchange BGP VPNv4 route information with the specified BGP peer.
[~HUAWEI] bgp 100
[*HUAWEI-bgp] peer 2001:db8::1 as-number 100
[*HUAWEI-bgp] ipv4-family vpnv4
[*HUAWEI-bgp-af-vpnv4] peer 2001:db8::1 enable
Related Topics
peer as-number

2.3.22 peer prefix-sid

Function
The peer prefix-sid command enables a device to exchange IPv4 prefix SIDs with a specified
IPv6 peer.
The undo peer prefix-sid command disables a device from exchanging IPv4 prefix SIDs with
a specified IPv6 peer.
Format
peer ipv6-address prefix-sid
undo peer ipv6-address prefix-sid
Parameters
ipv6-address Specifies the IPv6 address of a The value is a 32-digit hexadecimal number,
BGP peer. in the format of X:X:X:X:X:X:X:X.
Views
BGP VPNv4 address family view
Default Level

bgp write
Usage Guidelines
Usage Scenarios
In an SRv6 VPN scenario, IPv6 runs on a public network and IPv4 runs on the private
network. PEs establish an IPv6 BGP peer relationship to exchange IPv4 private network route
information. To enable BGP to exchange IPv4 route information with the specified IPv6 peer
in the BGP VPNv4 address family view, run the peer enable command.
To enable a device to exchange IPv4 prefix SIDs with a specified IPv6 peer, run the peer
prefix-sid command.
Example
# Enable a device to exchange IPv4 prefix SIDs with a specified IPv6 peer.

[~HUAWEI] bgp 100
[*HUAWEI-bgp] peer 2001:db8::1 as-number 100
[*HUAWEI-bgp-af-vpnv4] peer 2001:db8::1 enable
[*HUAWEI-bgp-af-vpnv4] peer 2001:db8::1 prefix-sid
Related Topics
peer as-number
2.3.23 path explicit-path (SRv6)
Function
The path explicit-path command configures an explicit path for an SRv6 tunnel.
The undo path command deletes the explicit path for an SRv6 tunnel.
By default, no explicit path is configured for an SRv6 tunnel.
Format
path explicit-path path-name
undo path
Parameters
path-name Specifies the name of an explicit The value is a string of 1 to 128 case-
path. sensitive characters.
Views
Default Level

mpls-base write
Usage Guidelines
To configure an explicit path for an SRv6 tunnel, run the path explicit-path command. The
explicit path specifies the nodes through which an SRv6 tunnel must pass.

Example
# Configure an explicit path named aa for an SRv6 tunnel.
[*HUAWEI] explicit-path aa
[*HUAWEI-explicit-path-aa] next sid ipv6 1::1 type prefix
[*HUAWEI-explicit-path-aa] quit
[*HUAWEI-Tunnel10] path explicit-path aa
2.3.24 segment-routing ipv6

Function
The segment-routing ipv6 command enables SRv6 function and displays the SRv6 view.
The undo segment-routing ipv6 command disables SRv6 function.
Format
undo segment-routing ipv6
Parameters
None
Views
System view
Default Level

segr write
Usage Guidelines
Usage Scenarios
Segment Routing IPv6 (SRv6) is a means used to forwarding IPv6 data packets based on the
source route concept. IPv6 forwarding plane-based SRv6 enables the ingress to add a segment
routing header (SRH) into IPv6 packets. An explicit IPv6 address stack is pushed into the

SRH. Transit nodes continue to update IPv6 destination IP addresses and the offset address
stack to implement per-hop forwarding.
To enable SRv6, run the segment-routing command. An IPv6 SID can then be set in the
SRv6 view and used to generate an IPv6 local SID forwarding entry.
Example
# Enable SRv6.
2.3.25 segment-routing ipv6 best-effort

Function
The segment-routing ipv6 best-effort command enables a device to perform private network
route iteration based on SIDs carried in routes.
The undo segment-routing ipv6 best-effort command disables a device from performing
private network route iteration based on SIDs carried in routes.
Format
undo segment-routing ipv6 best-effort
Parameters
None
Views
BGP VPN instance IPv4 address family view
Default Level

bgp write
Usage Guidelines
Usage Scenarios
In an SRv6 VPN scenario, the segment-routing ipv6 best-effort command enables a device
to perform private network route iteration based on SIDs carried in routes.

Example
# Enable the device to perform private network route iteration based on the SIDs carried in
routes.
[*HUAWEI-vpn-instance-vpn1] ipv4-family
[*HUAWEI-vpn-instance-vpn1-af-ipv4] route-distinguisher 100:1
[*HUAWEI-vpn-instance-vpn1-af-ipv4] vpn-target 100:1 both
[*HUAWEI-vpn-instance-vpn1-af-ipv4] quit
[*HUAWEI-vpn-instance-vpn1] quit
[*HUAWEI] bgp 100
[*HUAWEI-bgp] ipv4-family vpn-instance vpn1
[*HUAWEI-bgp-vpn1] segment-routing ipv6 best-effort
Related Topics
peer as-number
2.3.26 segment-routing ipv6 locator (BGP VPN instance IPv4

address family view)
Function
The segment-routing ipv6 locator command enables a device to add SIDs into private
network routes.
The undo segment-routing ipv6 locator command disables a device from adding SIDs into
private network routes.
By default, the private network routes do not have SIDs.
Format
segment-routing ipv6 locator locator-name [ auto-sid-disable ]
undo segment-routing ipv6 locator [ locator-name auto-sid-disable ]
Parameters
locator-name Specifies the name of a SID node route locator, The value is a string
which was configured through the locator of 1 to 31 case-
command. sensitive characters.
auto-sid- Specifies to disable the dynamic SID allocation -

disable function.
NOTE
If the auto-sid-disable parameter is not configured, SIDs
can be dynamically assigned. If static SIDs configured by
the opcode command exist in locator-name, the static SIDs
are used. If no static SIDs exist, dynamically assigned
SIDs are used.

Views
BGP VPN instance IPv4 address family view
Default Level

bgp write
Usage Guidelines
Usage Scenarios
In SRv6 VPN, private network route information of VPN instance is transferred using BGP.
By default, the private network routes do not have SIDs, the segment-routing ipv6 locator
command enables a device to add SIDs in private network routes.
After the BGP VPNv4 neighbor is set up and the peer ipv6-address prefix-sid command is
enabled, the BGP peers can exchange the private network routing information carrying the
SID attributes through the BGP VPNv4 neighbor.
Precautions
The configuration fails if the operation code-specific END.DT4 VPN of the locator does not
match the private network VPN instance or the specified locator does not exist.
Example
# Enable a device to send private network routes that carry SIDs, and enable the SID dynamic
allocation capability.
[*HUAWEI-vpn-instance-vpn1-af-ipv4] vpn-target 100:1 both
[*HUAWEI-vpn-instance-vpn1-af-ipv4] quit
[*HUAWEI-vpn-instance-vpn1] quit
[*HUAWEI] bgp 100
[*HUAWEI-bgp] ipv4-family vpn-instance vpn1
[*HUAWEI-bgp-vpn1] segment-routing ipv6 locator test
2.3.27 segment-routing ipv6 (IS-IS view)
Function
The segment-routing ipv6 command enables the IS-IS SRv6 function.
The undo segment-routing ipv6 command disables the IS-IS SRv6 function.
By default, the IS-IS SRv6 function is disabled.

Format
segment-routing ipv6 [ locator locator-name | locator-default ] [ auto-sid-disable ]
undo segment-routing ipv6 [ locator locator-name | locator-default ] [ auto-sid-disable ]
Parameters
locator Specifies the name of a SID node route locator, which was The value is a
locator-name configured through the locator command. string of 1 to
31 case-
After you configure the locator locator-name parameter,
sensitive
IS-IS allows static End and End.X SIDs to be imported
characters.
from the configured locator-name.
locator- Imports static End and End.X SIDs from the default node -
default route segment. The default parameter in the locator
command determines whether a node route segment is a
default one.
auto-sid- Disables the dynamic assignment of End and End.X SIDs. -

disable
If the auto-sid-disable parameter is configured to disable
the dynamic assignment of End and End.X SIDs, these
SIDs are imported only from a specified locator.
If the auto-sid-disable parameter is not configured, End
and End.X SIDs can be dynamically assigned. If static
End and End.X SIDs exist, the static SIDs are used. If no
static SIDs exist, dynamically assigned End and End.X
SIDs are used.
Views
IS-IS view
Default Level

isis write
Usage Guidelines
Usage Scenarios

In SRv6 scenarios, after the IS-IS SRv6 function is enabled, End and End.X SIDs are
generated preferentially based on the specified locator. Each SRv6 SID generated by IS-IS is
added to the local SID table on the device and also advertised externally through IS-IS LSP
packets.
The command function varies according to the parameters configured in the command.
Detailed command functions are as follows:
1. The segment-routing ipv6 command without any parameter enables the IS-IS SRv6
function and dynamic SID assignment.
2. The segment-routing ipv6 auto-sid-disable command enables the IS-IS SRv6 function
but disables dynamic SID assignment. Because neither the locator locator-name
parameter nor the locator-default parameter is configured, SIDs cannot be statically
generated.
3. The segment-routing ipv6 locator locator-name command enables the IS-IS SRv6
function and dynamic SID assignment. SIDs must be assigned within the locator range
specified using the locator locator-name parameter.
4. The segment-routing ipv6 locator locator-name auto-sid-disable command enables the
IS-IS SRv6 function but disables dynamic SID assignment. SIDs must be assigned
within the locator range specified using the locator locator-name parameter.
5. The segment-routing ipv6 locator-default command enables the IS-IS SRv6 function
and dynamic SID assignment. SIDs must be assigned in the default locator range.
6. The segment-routing ipv6 locator-default auto-sid-disable command enables the IS-IS
SRv6 function but disables dynamic SID assignment. SIDs must be statically assigned in
the default locator range.
7. The undo segment-routing ipv6 command disables the IS-IS SRv6 function and deletes
all the dynamic and static SIDs assigned by IS-IS.
8. The undo segment-routing ipv6 [ locator locator-name | locator-default ] [ auto-sid-
disable ] command deletes all the dynamic and static SIDs assigned by IS-IS within the
specified locator range. The auto-sid-disable parameter is optional. The configuration
effect is not affected no matter whether this parameter is configured.
If a static operation code is configured, it is preferentially used for SID generation. If no static
operation code is configured, operation codes are dynamically assigned. The process of
generating SRv6 SIDs through IS-IS is as follows:
1. Configure a locator segment in the system view, and run the segment-routing ipv6
{ locator locator-name | locator-default } command in the IS-IS view to enable SRv6
and reference the locator. An IS-IS process can reference only one locator.
2. IS-IS generates End SIDs for all locators based on the dynamic operation code segment
specified in locator configurations. Both penultimate segment pop of the SRH (PSP) and
non-PSP SIDs are generated.
3. Configure an IPv6 address for the desired interface, enable IS-IS IPv6, and generate
End.X SIDs for the interface through IS-IS. SIDs are generated based on the dynamic
operation code segment specified in locator configurations. Both PSP and non-PSP SIDs
are generated.
Prerequisites
Before you run the segment-routing ipv6 command, ensure that the following commands
have been run:
1. ipv6 enable: enables IPv6 for the IS-IS process.

2. cost-style wide: sets the IS-IS cost type to wide.

Precautions
After the undo segment-routing ipv6 command is configured, IS-IS does not support the
assignment and advertisement of SRv6 SIDs.
Example
# Enable IS-IS to import static End and End.X SIDs from a specified locator.
default
[~HUAWEI] isis 1
2.3.28 sr-te frr enable

Function
The sr-te frr enable command enables SR-TE FRR.
The undo sr-te frr enable command disables SR-TE FRR.
By default, SR-TE FRR is disabled.
Format
sr-te frr enable
undo sr-te frr enable
Parameters
None
Views
Segment Routing IPv6 view
Default Level
Usage Guidelines
To enable SR-TE FRR, run the sr-te frr enable command. After SR-TE FRR is enabled, if a
transit node fails during SRv6 forwarding, FRR rapidly switches traffic to a backup next hop.
Example
# Enable SR-TE FRR.

[*HUAWEI-segment-routing-ipv6] sr-te frr enable
2.3.29 statistic enable (SRv6)

Function
The statistic enable command enables traffic statistics collection on an SRv6 tunnel.
The undo statistic enable command disables traffic statistics collection on an SRv6 tunnel.
By default, the traffic statistics collection function is disabled on an SRv6 tunnel.
Format
statistic enable
undo statistic enable
Parameters
None
Views
SRv6 tunnel interface view
Default Level

interface-mgr write
Usage Guidelines
Usage Scenario
Before checking the statistics about received or sent packets on an SRv6 tunnel, you need to
run the statistic enable command in the SRv6 tunnel interface view to enable traffic statistics
collection.
After the statistic enable command is configured, you can run the display interface tunnel
command to view the traffic statistics on the SRv6 tunnel interface and troubleshoot the
interface according to the displayed statistics.
Example
# Enable traffic statistics collection function on SRv6 tunnel1.

[*HUAWEI-Tunnel1] statistic enable
2.3.30 te ipv6-router-id
Function
The te ipv6-router-id command sets a global TE IPv6 router ID.
The undo te ipv6-router-id command deletes a global TE IPv6 router ID.
By default, no global TE IPv6 router ID is set.
Format
te ipv6-router-id ipv6-address
undo te ipv6-router-id
Parameters
ipv6-address Specifies an IPv6 The value is a 32-digit hexadecimal number, in the
address. format of X:X:X:X:X:X:X:X.
Views
System view
Default Level

mpls-te write
Usage Guidelines
Usage Scenario
To set a global TE IPv6 router ID, run the te ipv6-router-id command. The setting does not
depend on global MPLS.
The TE IPv6 Router ID must be configured on the tunnel ingress node and can be any value,
but it is required to be globally unique.

Precautions
If an SRv6 tunnel exists, the global TE IPv6 router ID cannot be modified or deleted.
Example
# Set a global TE IPv6 router ID to 1::1.
[~HUAWEI] te ipv6-router-id 1::1
2.3.31 ti-lfa (IPv6)
Function
The ti-lfa command enables IPv6 IS-IS topology independent-loop free alternate (TI-LFA).
The undo ti-lfa command disables IPv6 IS-IS TI-LFA.
By default, IPv6 IS-IS TI-LFA is disabled.
Format
ti-lfa [ level-1 | level-2 | level-1-2 ]
undo ti-lfa [ level-1 | level-2 | level-1-2 ]
Parameters
level-1 Enables or disables IPv6 IS-IS Level-1 TI-LFA. -
level-2 Enables or disables IPv6 IS-IS Level-2 TI-LFA. -
level-1-2 Enables or disables IPv6 IS-IS Level-1-2 TI-LFA. -
NOTE
If no level is specified, IS-IS Level-1-2 TI-LFA is enabled by default.
Views
IPv6 IS-IS FRR view
Default Level

isis write

Usage Guidelines
Usage Scenario
Based on the P and Q node information (see IPv6 TI-LFA FRR), a label stack for a backup
tunnel is generated. Then, the forwarding table of segment routing labels is used to continue
to forward traffic.
Prerequisites
The segment routing IPv6 forwarding has been enabled using the segment-routing ipv6
command.
FRR has been enabled and the IPv6 FRR view has been displayed using the ipv6 frr
command, and IPv6 IS-IS LFA has been enabled using the loop-free-alternate command.
Precautions
The level specified in the ti-lfa command depends on the level configured in the loop-free-
alternate command. TI-LFA configured using the ti-lfa command can take effect in a level-
specific IS-IS area only after the level-specific LFA is enabled.
Example
# Enable IPv6 IS-IS Level-2 TI-LFA.
[~HUAWEI] isis 1
[*HUAWEI-isis-1] ipv6 frr
[*HUAWEI-isis-1-ipv6-frr] loop-free-alternate level-2
[*HUAWEI-isis-1-ipv6-frr] ti-lfa level-2
2.3.32 traffic-eng enable
Function
The traffic-eng enable command enables Segment Routing IPv6 TE (SRv6-TE).
The undo traffic-eng enable command disables SRv6-TE.
By default, SRv6-TE is disabled.
Format
traffic-eng enable
undo traffic-eng enable

Parameters
None
Views
Default Level

segr write
Usage Guidelines
An SRv6 tunnel is configured based on a TE explicit path. The ingress runs CSPF to compute
the path. To use TE in SRv6, run the traffic-eng enable command.
Example
# Enable SRv6-TE.
2.3.33 tunnel-id (SRv6)
Function
The tunnel-id command sets an SRv6 tunnel ID.
The undo tunnel-id command deletes an SRv6 tunnel ID.
By default, no SRv6 tunnel ID is set.
Format
tunnel-id tunnel-id
undo tunnel-id
Parameters
tunnel-id Specifies the tunnel ID of an SRv6 The value is an integer ranging from 1
tunnel. to 65535.

Views
Default Level

mpls-base write
Usage Guidelines
Usage Scenario
To set an SRv6 tunnel ID, run the tunnel-id command. A tunnel ID must be set for an SRv6
tunnel to be established. The tunnel ID uniquely identifies a tunnel on a device, which helps
plan and manage SRv6 tunnels.
Precautions
The tunnel ID must be configured before you commit SRv6 tunnel configurations for the first
time. Otherwise, no SRv6 tunnels can be established.
Example
# Set a tunnel ID to 100.
[~HUAWEI-Tunnel10] tunnel-protocol srv6
[*HUAWEI-Tunnel10] tunnel-id 100

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:
l Lack of support for load balancing: VPLS does not support traffic load balancing in
multi-homing networking scenarios.
l 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 no
need to learn the MAC addresses carried in them.
EVPN solves the preceding problems with the following characteristics:
l 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.
l 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.
l 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:
l Improved link usage and transmission efficiency: EVPN supports load balancing, fully
utilizing network resources and reducing network congestion.
l 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.

Figure 3-1 EVPN networking
EVPN1
Site 1
CE1
PE1 PE2
ESI1
ESI3 EVPN1
ESI2
ISP backbone Site 3
EVPN1
Site 2 CE3
PE4
ESI3
CE2
PE3
ESI4
CE4
EVPN1
Site 4
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:
l 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
Route Distinguisher (8 bytes)
Ethernet Segment Identifier (10 bytes)
Ethernet Tag ID (4 bytes)
MPLS Label (3 bytes)
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.
l 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.
Figure 3-3 EVPN NLRI specific to the MAC/IP advertisement route
MAC Address Length (1 byte)
MAC Address (6 bytes)
IP Address Length (1 byte)
IP Address (0, 4, or 16 bytes)
MPLS Label1 (3 bytes)
MPLS Label2 (0 or 3 bytes)
The description of each field is as follows:

– Route Distinguisher: an 8-byte field representing the RD value of an EVPN
instance.
– 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
– 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.
NOTE
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.
– 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.
NOTE
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.

l 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
Originating Router's IP Address (4 or 16 bytes)

instance.
– 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.
l 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. 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.
CEs.
– IP Address Length: a 1-byte field representing the length of the source IP address
– Originating Router's IP Address: a 4-byte or 16-byte field representing the source IP
address configured on the local PE.
l 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

IP Prefix Length (bytes)
IP Prefix (4 or 16 bytes)
GW IP Address (4 or 16 bytes)

instance.
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 construct EVPN instance forwarding entries based on the RTs carried in
received MAC/IP advertisement route.
Figure 3-7 Unicast MAC address advertisement networking
EVPN1 EVPN1
MACA MACB
Site 1 Site 2
CE1 PE1 PE2 CE2
ARP Request message or

gratuitous ARP message
ARP Reply message or
MAC advertisement route
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
PE1 MAC
PE2 MAC
LDP Label
EVPN Label
EVPN1 Data Data Data EVPN1
Site 1 CE1 PE1 PE2 CE2 Site 2
Data

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.
NOTE
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
P MAC PE2 MAC

PE1 MAC P MAC PE2 EVPN1
LDP Label LDP Label
BUM Label BUM Label CE2
Site2
Data Data Data
EVPN1 PE1
CE1
Site1 Data P
P MAC PE3 MAC Data EVPN1

PE1 MAC P MAC
LDP Label LDP Label CE3
BUM Label BUM Label Site3
PE3
Data Data
Inclusive Multicast Route
Data
3.1.3 EVPN-MPLS
3.1.3.1 EVPN Multi-Homing Technology

Related Concepts
l 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 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.
NOTE
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

PE1
ES1
EVPN1 EVPN1
CE1 ISP backbone CE2

Site 2
Site 1
PE3
ES1
PE2 Ethernet segment route

Data
l 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.
Figure 3-11 Split horizon networking

PE1
ES1
EVPN1 EVPN1

Site 2
Site 1
PE3
ES1
PE2 Data
l 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.
– If either PE1 or PE2 or both PE1 and PE2 are configured to work in Single-Active
mode, after PE1 and PE2 send Ethernet auto-discovery route carrying the
redundancy mode to PE3, PE3 uses the optimal received route as the primary route
and the second optimal received route as the backup route to implement FRR.
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.

Figure 3-12 Redundancy mode and aliasing networking
PE1
EVPN1 EVPN1
Site 1 Site 2
PE3

PE2
Ethernet auto-discovery route
Data
l 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
PE1
EVPN1 EVPN1
Site 1 Site 2
PE3
PE2 Ethernet auto-discovery route

Data
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:
l Allows access nodes to signal all services to an LSP.
l Uses the same transport layer convergence technology to switch all services to backup
paths in case of network-side faults, ensuring proper service transmission.

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:
l Intra-AS seamless MPLS: The access, aggregation, and core layers are deployed within a
single AS. This solution mainly applies to mobile bearer networks.
l 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.

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

routing follows:
protocols. l An IGP (IS-IS or OSPF) is enabled on devices at the access,
aggregation, and core layers to establish connectivity within
the AS.
l 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.
l The next hop addresses in BGP routes are set on the AGG
Control
and core ABR to the devices' own addresses to prevent
plane
advertising unnecessary IGP area-specific public routes.
Figure 3-14 Routing protocol deployment for intra-AS

seamless MPLS networking
Single AS
IBGP IBGP IBGP

OSPF/ OSPF/ OSPF/
IS-IS IS-IS IS-IS
CSG1 AGG1 Core ABR1 MASG1
NodeB/
eNodeB Aggregation
Access Core
MME/
SGW
NodeB/
eNodeB

Network Description
Deployment
Deploy In Figure 3-15, tunnels are deployed as follows:

tunnels. l A public network tunnel is established using LDP, TE, or
LDP over TE in each IGP area.
l 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
Single AS
IBGP label IBGP label IBGP label
NodeB/
eNodeB Aggregation
Access Core
MME/
SGW
NodeB/
eNodeB MPLS LDP/ MPLS LDP/ MPLS LDP/
MPLS TE MPLS TE MPLS TE

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 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.
Forwarding plane 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.
Figure 3-16 Forwarding plane for intra-AS seamless MPLS

networking
NodeB/
eNodeB Aggregation
Access Core
MME/
SGW
NodeB/
eNodeB
EVPN
MPLS tunnel label BGP label

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

routing follows:
protocols. l An IGP (IS-IS or OSPF) is enabled on devices at the access,
aggregation, and core layers to establish connectivity within
the AS.
l 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.
l The AGG is configured as an RR so that IBGP peers can
exchange BGP routes, and the CSG and MASG can obtain
Control BGP routes destined for each other's loopback addresses.
plane
l 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
AS x AS y
IBGP IBGP EBGP IBGP

OSPF/ OSPF/ OSPF/
IS-IS IS-IS IS-IS
CSG1 AGG1 AGG ASBR1 Core ASBR1 MASG1
NodeB/
eNodeB Access Aggregation Core
MME/
SGW
NodeB/
eNodeB

Network Description
Deployment
Deploy In Figure 3-18, tunnels are deployed as follows:

tunnels. l 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.
l 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.
l 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
AS x AS y
IBGP IBGP EBGP IBGP

label label label label
NodeB/
MME/
SGW
NodeB/
eNodeB MPLS LDP/ MPLS LDP/ MPLS LDP/
MPLS TE MPLS TE MPLS TE

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 packets without MPLS tunnel labels.
4. Upon receipt, the core ASBR swaps a BGP LSP label for a
new label and pushes a core-layer MPLS tunnel label into
each packet. It then forwards the packets to the MASG.
5. Upon receipt, the MASG removes MPLS tunnel labels, BGP
LSP labels, and VPN labels from the packets. If the PHP
function is enabled on the core ASBR, the core ASBR has
removed the MPLS tunnel labels from the packets, and
therefore, the MASG receives packets without MPLS tunnel
labels.
The EVPN packet transmission along the inter-AS seamless
MPLS LSP is complete.

Network Description
Deployment
Figure 3-19 Forwarding plane for the inter-AS seamless MPLS

networking with a BGP LSP established in the core area
NodeB/
MME/
SGW
NodeB/
eNodeB
EVPN
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
NodeB/
MME/
SGW
NodeB/
eNodeB
EVPN

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.
l 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
AGG1 AGG ASBR1 Core ASBR1 MASG1

CSG1
NodeB/
MME/
SGW
NodeB/
eNodeB Primary path
Backup path
l 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
AGG ASBR1 Core ASBR1

AGG1 MASG1
CSG1
NodeB/
MME/
SGW
CSG2 AGG2 Core ASBR2 MASG2
AGG ASBR2
NodeB/
eNodeB Primary path
Backup path
l 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

AGG1 MASG1
CSG1
NodeB/
MME/
SGW
NodeB/
eNodeB Primary path
Backup path
l 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

AGG1 MASG1
NodeB/ CSG1
MME/
SGW
CSG2 MASG2
NodeB/ AGG2 AGG ASBR2 Core ASBR2
eNodeB
Primary path
Backup path for downstream traffic
Backup path for upstream traffic
l 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.

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

MASG1
CSG1 AGG1
NodeB/
MME/
SGW
CSG2 MASG2
eNodeB
Primary path
l 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

MASG1
AGG1
NodeB/ CSG1
MME/
SGW
CSG2 MASG2
eNodeB
Primary path
l 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.

Figure 3-27 Traffic protection from a link fault in a core area on the inter-AS seamless
MPLS network
Core ASBR1
AGG1 AGG ASBR1 MASG1
CSG1
NodeB/
MME/
SGW
MASG2
CSG2 AGG2 AGG ASBR2 Core ASBR2
NodeB/
eNodeB
Primary path
Backup path
l 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

Core ASBR1
CSG1 AGG1 AGG ASBR1 MASG1
NodeB/
MME/
SGW
NodeB/
eNodeB
Primary path
Backup path
l 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.
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
AS x AS y
IBGP label EBGP
IBGP label
label
OSPF/I OSPF/I
S-IS S-IS
PE1 ASBR1 ASBR3
CE1 PE3
CE2
PE2 PE4
LDP/ ASBR2 ASBR4
LDP/
TE LDP/TE TE
Primary path
Backup path
l 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:
l Port-based
l VLAN-based
l VLAN bundle
l VLAN-aware bundle
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

Device 1 Device 2
User1 VLAN1 BD 1 EVI 1 BD 1 VLAN2 User1
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.
NOTE
In a VLAN bundle scenario, only termination EVC sub-interfaces support both Layer 2 and Layer 3
interfaces. Non-termination EVC sub-interfaces support only Layer 2 services.
Figure 3-31 VLAN-bundle mode

Device 1 Device 2
User1 User1
VLAN1 VLAN1
User2 VLAN2 BD 1 EVI1 BD 1 VLAN2 User2
VLAN3 VLAN3
User3 User3
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

Device 1 Device 2
User1 VLAN1 BD1 BD1 VLAN2 User1
User2 VLAN3 BD2 EVI 1 BD2 VLAN4 User2
User3 VLAN5 BD3 BD3 VLAN6 User3
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:
l 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.
l DF election:
– For interface-based DF election, the system chooses the first interface to go Up in a
BD for DF election.
– During DF election after an AC interface is enabled to influence DF election, a PE
cannot participate in DF election if the system does not receive the Ethernet auto-
discovery route advertised by the PE. If the VLAN-aware bundle mode is enabled
in this scenario, an Ethernet auto-discovery route is generated for each BD tag. The
PE can participate in DF election only if the system receives Ethernet auto-
discovery routes in all BDs bound to a specified EVI.
l 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.
l 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 the control plane, and VTEP discovery and MAC addresses
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.
EVPN uses extended BGP and defines new BGP EVPN routes to transmit VTEP addresses
and host information. As such, the application of EVPN on VXLANs moves VTEP discovery
and host information learning from the data plane to the control plane.
BGP EVPN Routes

EVPN NLRI defines the following BGP EVPN route types applicable to the VXLAN control
plane:
Type 2 route—MAC/IP route
Figure 3-33 shows the format of MAC/IP routes.
Figure 3-33 MAC/IP route

The Table 3-3 describes the fields.
Table 3-3 The fields of MAC/IP route
Field Description
Route Distinguisher RD value of an EVPN instance
Ethernet Segment Identifier Unique ID for defining the

connection between local and
remote devices
Ethernet Tag ID VLAN ID configured on the

device
MAC Address Length Length of the host MAC address

carried in the route

Field Description
MAC Address Host MAC address carried in the

route
IP Address Length Mask length of the host IP address

IP Address Host IP address carried in the

route
MPLS Label1 Layer 2 VNI carried in the route
MAC/IP routes function as follows on the VXLAN control plane:

l 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.
l 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.
l 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 Layer 3 VNI. This type of MAC/IP route
is called the integrated routing and bridging (IRB) route.
NOTE
An ARP route carries host MAC and IP addresses and 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.
l 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 as 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 a Layer 3 VNI. MAC/IP routes in this
case are also called IRBv6 routes.

NOTE
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. 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 inclusive multicast routes.
Figure 3-34 Format of an inclusive multicast route

Prefix
PMSI attribute
Flags (1 byte)
Tunnel Type (1 byte)
Tunnel Identifier (variable)
Table 3-4 The fields of an inclusive multicast route

Field Description
Route Distinguisher RD value of an EVI
Ethernet Tag ID VLAN ID

The value is all 0s in this type of
route.
IP Address Length Mask length of the local VTEP's

IP address carried in the route
Originating Router's IP Address Local VTEP's IP address carried

in the route

Field Description
Flags Flags indicating whether leaf node

information is required for the
tunnel
This field is inapplicable in
VXLAN scenarios.
Tunnel Type Tunnel type carried in the route

The value can only be 6,
representing Ingress Replication in
VXLAN scenarios. It is used for
BUM packet forwarding.
MPLS Label Layer 2 VNI carried in the route
Tunnel Identifier Tunnel identifier carried in the

route
This field is the local VTEP's IP
address in VXLAN scenarios.
This type of route is used on the VXLAN control plane for automatic VTEP discovery and
dynamic VXLAN tunnel establishment. VTEPs that function as BGP EVPN peers transmit
Layer 2 VNIs 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 a Layer 2 VNI. If the remote VTEP's IP address is reachable at Layer 3, a VXLAN
tunnel to the remote VTEP is established. If the remote VNI is the same as the local VNI, an
ingress replication list is created for subsequent BUM packet forwarding.
Type 5 route—IP prefix route
The Figure 3-35 shows the format of IP prefix routes.
Figure 3-35 IP prefix route


Table 3-5 The fields of IP prefix route
Field Description

remote devices

device
IP Prefix Length Length of the IP prefix carried in

the route
IP Prefix IP prefix carried in the route
GW IP Address Default gateway address

VXLAN scenarios.
The IP Prefix Length and IP Prefix fields in an IP prefix route can identify a host IP address
or network segment.
l If the IP Prefix Length and IP Prefix fields in an IP prefix route identify 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.
l If the IP Prefix Length and IP Prefix fields in an IP prefix route identify a network
segment, the route allows external network access.
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:
l 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.

l 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.
l 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.
l Tunnel: indicates a network-side MPLS tunnel or SR tunnel.
Compared with the traditional L2VPN VPWS (PWE3 and CCC/SVC) solution, the EVPN
VPWS solution simplifies the control and data models and uses BGP as the control plane
where 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
L3 Network
Tunnel
CE1 PE1 PE2 CE2
EVPN-VPWS Instance
AC
EVPL Instance
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:
l 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


n 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.
n Ethernet Segment Identifier: uniquely identifies a connection between a PE
and a CE.
n Ethernet Tag ID: indicates the local service ID of the EVPL instance on the
local PE.
n MPLS Label: indicates the EVPL label assigned for each EVI Ethernet Auto-
Discovery route.
In addition to NLRI, an EVI Ethernet Auto-Discovery route carries the Layer 2
extended community attribute that includes the following control fields:
n C: identifies a control word. If this control field is set to 1, packets sent by the
local PE must carry control information.
n 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.
n B: is used to identify whether the local PE is the backup PE in dual-homing
single-active scenarios.
l 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 configured on the
local PE.
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.
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.
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. 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 SR 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, 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. 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 SR tunnel and local
EVPL instance are generated.
6. Upon receipt of EVI Ethernet AD routes from PE1 and PE2, PE3 matches RTs of the
FRR entries indicating the association between the MPLS or SR tunnel and local EVPL
instance are generated. The entries destined for PE1 are the master entries, and the
entries destined for PE2 are the backup entries.

local EVPL instance, the bypass entries indicating the association between the MPLS or
SR tunnel and local EVPL instance are generated.
Figure 3-39 EVPN VPWS dual-homing single-active networking (with an E-Trunk deployed)
PE1(Primary)
E-Trunk
CE1 P PE3 CE3
PE2(Backup)
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)
PE1(Primary)
CE1 P PE3 CE3
PE2(Backup)
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 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.
NOTE
The DF election result determines the P control field in EVI Ethernet AD routes.
Figure 3-41 DF election in EVPN VPWS
CE1 source IP=1.1.1.1
PE1
ESx ES Route
ESy
PE2 service ID=100
CE1 source IP=2.2.2.2 service ID=101
ESx Peer List(N=2)
Index IP PE
DF Result 0 1.1.1.1 PE1
ID ES N ID mod N 1 2.2.2.2 PE2
100 ESx 2 0
101 ESy 2 1 ESy Peer List(N=2)
Index IP PE
0 1.1.1.1 PE1
1 2.2.2.2 PE2
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 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, and master/backup role.
5. Upon receipt of EVI Ethernet AD routes from PE3, PE1 and PE2 match RTs of the

forwarding entries indicating the association between the MPLS or SR tunnel and local
EVPL instance are generated.
6. Upon receipt of EVI Ethernet AD routes from PE1 and PE2, PE3 matches RTs of the
routes is the same as the remote service ID configured for the local EVPL instance, load
balancing entries of the MPLS or SR tunnel and local EVPL instance are generated.
local EVPL instance, the bypass entries indicating the association between the MPLS or
SR tunnel and local EVPL instance are generated.
Figure 3-42 EVPN VPWS networking in dual-homing all-active scenarios

PE1
CE1 P PE3 CE3
PE2
The data packets sent from AC-side interfaces are forwarded to the peer PE over the
corresponding MPLS tunnel based on the forwarding entries indicating the association
between tunnels and EVPL instances. Upon receipt of packets, the peer PE searches for the
association entries based on the label encapsulated in the packets and the forwards the packets
to the corresponding AC interface based on the association entries.
3.1.6 PBB-EVPN
3.1.6.1 PBB-EVPN Fundamentals
PBB-EVPN Networking
PBB-EVPN is an L2VPN technology implemented based on MPLS and Ethernet
technologies. PBB-EVPN uses BGP to exchange MAC address information between PEs on
the control plane and controls the exchange of data packets among different sites across the
MPLS network.
As shown in Figure 3-43, a PBB-EVPN has similar architecture as an EVPN. Compared with
EVPN, PBB-EVPN introduces the following concepts:
l 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.
l 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.
l B-EVPN: accesses the backbone network. A B-EVPN instance manages EVPN routes
received from other PEs.
l I-SID: uniquely identifies a broadcast domain. One I-EVPN instance corresponds to one
I-SID. If two PEs share the same I-SID, the two PEs belong to the same BUM group.
Figure 3-43 PBB-EVPN networking
I-EVPN1 B-EVPN1
ESI1
I-SID1 BGP
I-EVPN2 B-EVPN2
ESI2
I-SID2
site4
site1
CE1 CE4
ESI1 ESI4
ESI2 ESI5
site2 PE1 PE3 site5
MPLS/IP
CE2 Network CE5
ESI2 ESI5
ESI3 ESI6
PE2 PE4 site6
site3
CE3 CE6
Table 3-6 describes the key points in PBB-EVPN implementation.

Table 3-6 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 the l MAC advertisement route
B-MAC addresses learned from
these routes for later data l Inclusive multicast route
packet transmission. Unicast MAC address advertisement
BUM packet transmission
PBB-EVPN supports fast Fast convergence

convergence.
On a multi-homing network, Ethernet segment routeDF election

PBB-EVPN uses DF election to
prevent bandwidth waste.
PBB-EVPN uses split horizon Split horizon

to prevent routing loops.
On a multi-homing network, Redundancy mode

PBB-EVPN supports per-flow
load balancing, but does not
support per-ISID load
balancing.
Data plane PBB-EVPN supports the Unicast packet transmission

transmission of unicast and
BUM packets. BUM packet transmission
PBB-EVPN Routes
On a PBB-EVPN, PEs exchange the following types of routes:
l 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

– Route Distinguisher: a field representing the RD of an EVPN instance.
– Ethernet Segment Identifier: a field of all 0s or Fs. Currently, this field can only be
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
– 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.
l 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
l Ethernet segment route: carries the EVPN instance RD and ESI information and source
IP address on the local PE. PEs connecting to the same CE use Ethernet segment routes
to discover each other. Ethernet segment routes are used in DF election. Figure 3-46
shows the prefix format of an Ethernet segment route packet.
Figure 3-46 Prefix format of an Ethernet segment route packet

– Route Distinguisher: a field representing a combination of the source IP address on
the local PE and :0, such as X.X.X.X:0.
– Ethernet Segment Identifier: a field that uniquely identifies links between PEs and
CEs.
– IP Address Length: a field representing the length of the source IP address
– Originating Router's IP Address: a field representing the source IP address
Other Concepts
l 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

PE1
EVPN1 EVPN1
ISP
CE1 CE2
backbone
Site1 Site2
PE3

PE2
Data
l DF election
On the network shown in Figure 3-48, CE1 is dual-homed to PE1 and PE2, and CE2
sends BUM traffic to PE1 and PE2. In this scenario, CE1 receives the same copy of
traffic from both PE1 and PE2, wasting network resources. To solve this problem, EVPN
elects one PE as the DF to forward BUM traffic. If PE1 is elected, it becomes the
primary DF, with PE2 functioning as the backup DF. The primary DF forwards BUM
traffic from CE2 to CE1.
If a PE interface connecting to a CE goes Down, the PE functions as a backup DF. If a
PE interface connecting to a CE goes Up, the PE and other PEs with Up interfaces elect a
primary DF using the following procedure:
a. The PEs establish EVPN BGP peer relationships with each other and then exchange
Ethernet segment routes.
b. Upon receipt of the Ethernet segment routes, each PE generates a multi-homing
PE list based on the ESIs carried in Ethernet segment routes. Each multi-homing
PE list contains information about all PEs connecting to the same CE.
c. Each PE then sequences the PEs in each multi-homing PE list based on the source
IP addresses carried in Ethernet segment routes. The PEs are numbered from 0.
d. The primary DF is elected based on I-SIDs. Specifically, PBB-EVPN uses the
formula of "I-SID modulo Number of PEs in the PE list corresponding to the I-SID"
to calculate a number and then elects the PE with the same number as the calculated
one as the primary DF.

Figure 3-48 DF election networking

PE1
DF
I-SID1
ES1
EVPN1 EVPN1
ISP
CE1 CE2
backbone
Site2
Site1
PE3
ES1
I-SID1
PE2 Ethernet Segment Route
Data
l Split horizon
On the network shown in Figure 3-49, CE1 is dual-homed to PE1 and PE2. If PE1 and
PE2 have established an EVPN BGP peer relationship with each other, after PE1
receives BUM traffic from CE1, it forwards the BUM traffic to PE2. If PE2 forwards
BUM traffic to CE1, a loop will occur. To prevent this problem, EVPN uses split
horizon. After PE1 forwards the BUM traffic to PE2, PE2 checks the B-SMAC address
carried in the traffic. If the B-SMAC address equals the B-MAC address configured on
PE2, PE2 drops the traffic, preventing a routing loop.
Figure 3-49 Split horizon networking

PE1
ES1
EVPN1 EVPN1
ISP
CE1 CE2
backbone
Site2
Site1
PE3
ES1
PE2 Data
l 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 Ethernet segment
routes carrying the redundancy mode information to PE3, PE3 sends unicast traffic
destined for CE1 to both PE1 and PE2 in load balancing mode.

Figure 3-50 Redundancy mode networking

PE1
All-Active
EVPN1 EVPN1
ISP
CE1 CE2
backbone
Site1 Site2
PE3
All-Active MAC advertisement route

PE2
Data
Unicast MAC Address Advertisement

On the network shown in Figure 3-51, unicast MAC addresses are advertised as follows:
1. Site1 sends an ARP request or gratuitous packet that carries Site1's C-MAC address C-
MAC A and the corresponding IP address to Site2.
2. Upon receipt of the packet, Site2 returns an ARP reply or gratuitous packet that carries
Site2's C-MAC address C-MAC B and the corresponding IP address to Site1.
3. PE1 and PE2 exchange MAC advertisement routes that carry B-MAC addresses, next
hops, and EVPN instance extended community attributes (such as RTs).
4. PE1 and PE2 construct B-EVPN instance forwarding entries based on the RTs carried in
received MAC advertisement routes.
Figure 3-51 Unicast MAC address advertisement networking
EVPN1 B-MACA B-MACB EVPN1

C-MACA C-MACB
Site1 Site2
CE1 PE1 PE2 CE2
ARP Request message or

ARP Reply message or
BUM Packet Transmission

After two PEs establish an EVPN BGP peer relationship, they exchange inclusive multicast
routes. PEs then form redundancy groups based on I-SIDs carried in received inclusive
multicast routes, with PEs having the same I-SID belonging to the same redundancy group.
On the network shown in Figure 3-52, BUM packets are transmitted as follows:

1. CE1 sends BUM packets to PE1.

2. Upon receipt of the packets, PE1 searches its C-MAC address table for the C-DMAC
address carried in packets. If the C-DMAC address cannot be found, PE1 sends the BUM
packets to all other PEs in the same redundancy group. Specifically, PE1 replicates a
copy of received BUM packets, encapsulates the PBB header, public tunnel label, and
VPN label into each copy, and sends the two copies of traffic to PE2 and PE3,
respectively. The B-DMAC address carried in the PBB header is a broadcast MAC
address.
3. Upon receipt of the BUM packets, PE2 and PE3 decapsulate the BUM packets and send
the BUM packets to the sites identified by the EVPN label carried in the packets.
NOTE
Use the network shown in Figure 3-50 as an example. If PE1 and PE2 both work in Single-Active
mode, the bidirectional BUM traffic between CE2 and CE1 will be dropped by the backup DF. If PE1
and PE2 both work in All-Active mode, only the BUM traffic from CE2 to CE1 will be dropped by the
backup DF.
Figure 3-52 BUM packet transmission networking

MPLS Label
EVPN Label C-DMAC
Broadcast C-SMAC
B-DMAC Data
B-SMAC PE2 EVPN1
I-SID
C-DMAC CE2
C-SMAC Site2
EVPN1 PE1 Data
CE1
C-DMAC
Site1 P
C-SMAC
C-DMAC MPLS Label Data
C-SMAC EVPN Label EVPN1
Data Broadcast CE3
B-DMAC Site3
B-SMAC PE3
I-SID
C-DMAC Inclusive Multicast Route
C-SMAC Data
Data
Unicast packet transmission

On the network shown in Figure 3-53, unicast packets are transmitted as follows:
1. CE1 forwards unicast packets that carry the source C-MAC (C-SMAC) and destination
C-MAC (C-DMAC) addresses to PE1 at Layer 2.
2. Upon receipt of the packets, the I-EVPN instance on PE1 searches its C-MAC address
table for a matching forwarding entry. After finding such an entry, PE1 encapsulates a

PBB header, a tunnel label, and a VPN label into these packets and forwards these
packets to PE2. The PBB header carries the I-SID and B-SMAC address configured in
the I-EVPN instance and the B-DMAC address obtained from the C-DMAC address
table.
3. Upon receipt of these packets, PE2 removes the tunnel label and PBB header, searches
the local C-MAC address table for a matching forwarding entry, and forwards these
packets to an outbound interface.
Figure 3-53 Unicast packet transmission networking

MPLS Label
EVPN Label
B-DMAC
B-SMAC
I-SID
C-DMAC C-DMAC C-DMAC
C-SMAC C-SMAC C-SMAC
EVPN1 Data PE1 Data PE2 Data EVPN1
CE1 CE2
Site1 Site2
Data
PE1
I-EVPN B-EVPN MPLS
MPLS Label
EVPN Label EVPN Label
B-DMAC B-DMAC B-DMAC
PBB
B-SMAC B-SMAC B-SMAC
Header
I-SID I-SID I-SID
C-DMAC C-DMAC C-DMAC C-DMAC
C-SMAC C-SMAC C-SMAC C-SMAC
Data Data Data Data
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.

l 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.
l 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-54 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.
Figure 3-54 Packet format of the extended community attribute used by EVPN E-Tree
0 7 15 23 31
Type=0x06 Sub-Type=0x05 Flags Reserved=0
Reserved=0 Leaf Label
Flags: 0 0 0 0 0 0 0 L
Take the network shown in Figure 3-55 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.
Figure 3-55 Network with EVPN E-Tree deployed
CE1 CE3
R CE4
t
PE1 PE2
oo
oo
R
t
Leaf
af
Le
Le
af
CE2 CE5
NOTE
EVPN E-Tree supports the following types of AC interfaces: main interfaces bound to common EVPN
instances, EVC Layer 2 sub-interfaces associated with BDs, and VLAN sub-interfaces.
In a CE dual-homing scenario, ensure that the same root or leaf attribute is set for the same VLAN sub-
interface in the same broadcast domain on two PEs. If the leaf attribute is set on both PEs, the Leaf label
can replace the ESI label to implement split horizon.
Different root or leaf attributes can be set for a PE's interfaces or sub-interfaces that connect to different
CEs.
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.

Figure 3-56 BUM traffic loop over an EVPN
CE1 PE1 PE2 CE2

1 1
CE1 PE1 PE2 CE2

3 2
CE1 PE1 PE2 CE2

4 5
Access-side Interface
Network-side Interface
BUM Data
On the network shown in Figure 3-56, 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-56).
2. PE2 forwards the BUM traffic received from PE1 through the network-side link to the
access-side link (traffic 2 in Figure 3-56). Equally, PE2 forwards the BUM traffic
received from the access side to the network side (traffic 3 in Figure 3-56).
3. PE1 forwards the BUM traffic received from PE2 through the network-side link to the
access-side link (traffic 4 in Figure 3-56). Equally, PE1 forwards the BUM traffic
received from the access side to the network side (traffic 5 in Figure 3-56).
4. As steps 2 and 3 are repeated, BUM traffic is continuously transmitted between PE1 and
PE2.

Figure 3-57 Route flapping over the EVPN

CE1 PE1 PE2 CE2
M1/Seq0
M1/Seq0+1
Withdraw
M1/Seq0+2
Withdraw Time
M1/Seq0+3
…...
Withdraw
M1/Seq0+N
On the network shown in Figure 3-57, 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. 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:
l 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.
l 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-58 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, and are also clients
of the RR. An EVPN instance with a specific RT is configured on each PE.

Figure 3-58 Basic usage scenario of EVPN ORF
EVPN1 EVPN2
IRT: 1:1 IRT: 2:2
ERT: 1:1 ERT: 2:2
EVPN4
IRT: 2:2
ERT: 2:2 PE1 RR PE3
EVPN5
IRT: 3:3
ERT: 3:3
EVPN3
IRT: 1:1
ERT: 1:1
PE2
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.
But the BGP-VT address family can resolve this problem.
On the network shown in Figure 3-58, 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.
NOTE
In addition to configuring an L3VPN instance, you can also configure the RR to advertise default ORF
routes to PE1 and PE3 and delete the BGP-VT peer relationship between the RR and PE3. After the
configuration is complete, PE1, PE2, and PE3 advertise all routes to the RR. The RR then advertises
routes with ERTs of 1:1 and 2:2 to PE1, routes with an ERT of 1:1 to PE2, and all routes to PE3.

If both EVPN and L3VPN services are deployed on the network in Figure 3-58, 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-59, 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-59 An EVPN ORF network carrying both EVPN and L3VPN services
EVPN1 EVPN2
IRT: 1:1 IRT: 2:2
ERT: 1:1 ERT: 2:2
VPN1 VPN2
IRT: 1:1 IRT: 2:2
EVPN4 ERT: 1:1 ERT: 2:2
IRT: 2:2
ERT: 2:2
VPN4
IRT: 2:2 PE1 RR PE3
ERT: 2:2 EVPN5
IRT: 3:3 EVPN3
ERT: 3:3 IRT: 1:1
VPN5 ERT: 1:1
IRT: 3:3 EVPN3
ERT: 3:3 IRT: 1:1
PE2 ERT: 1:1
Benefits
l Bandwidth consumption is lowered (because the number of routes being advertised is
smaller).
l 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 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, and IGMP Leave Synch routes.
l 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-60, 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.

Figure 3-60 SMET route format
Route Distinguisher (8 octets)
Ethernet Tag ID (4 octets)
Multicast Source Length (1 octet)
Multicast Source Address (variable)
Multicast Group Length (1 octet)
Multicast Group Address (variable)
Originator Router Length (1 octet)
Originator Router Address (variable)
Flags (1 octet) (optional)
Flags:
reserved IE V3 V2 V1
0 1 2 3 4 5 6 7
l 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-61, the fields in the routing information
are described as follows:
– Ethernet Segment Identifier: unique identifier defined for a device to connect to the
access network.
– 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.

Figure 3-61 IGMP Join Synch route format

Ethernet Segment Identifier (10 octets)
Flags (1 octet)
Flags:
0 1 2 3 4 5 6 7
l IGMP Leave Synch route

IGMP Leave Synch routes are used to synchronize multicast group leave information
between dual-homed devices on the access side. A device that receives an IGMP Leave
Synch route can delete member entries from 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:
– Ethernet Segment Identifier: unique identifier defined for a device to connect to the
access network.
– Originator Router Length: address length of the device that generated the IGMP
Leave Synch route.
– Originator Router Address: address of the device that generated the IGMP Leave
Synch route.

– Leave Group Synchronization: sequence number of the process in which a multicast

member leaves a specified multicast group. The sequence number increases each
time the device starts the process.
– Maximum Response Time: longest time for a querier to wait for responses from
downstream hosts. A host must respond to the querier before the specified longest
time expires if it wants to receive traffic of a multicast group.
Figure 3-62 IGMP Leave Synch route format

Ethernet Segment Identifier (10 octets)
Leave Group Synchronization (4 octets)
Maximum Response Time (1 octet)
Flags (1 octet)
Flags:
0 1 2 3 4 5 6 7
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.
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
CE2 Receiver A
BD1
PE2
Multicast
source
BD1
EVPN
CE1 PE1
BD1
PE3 Receiver B
CE3
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 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.

Figure 3-64 Dual-homing access for IGMP snooping over EVPN MPLS on the multicast
source side
CE2 Receiver A
BD1
PE1
PE3
Multicast BD1
source
EVPN
CE1
BD1 BD1
PE4 Receiver B
PE2
CE3
Dual-homing access for IGMP snooping over EVPN MPLS on the access side
Figure 3-65 shows dual-homing access for IGMP snooping over EVPN MPLS on the access
side. Configure an EVPN instance on PE1, PE2, and PE3, and bind a BD to the EVPN
instance. Establish BGP EVPN peer relationships between the PEs, and deploy EVPN IGMP
proxy on each PE. Deploy PE1 as a sender PE, and deploy PE2 and PE3 as receiver PEs.
Configure IGMP snooping and IGMP proxy on BD1 bound to the EVPN instance on PE1,
PE2, and PE3. Connect BD1 on PE1, PE2, and PE3 to CE1, CE2, and CE3 through VLAN
dot1q sub-interfaces, respectively. Configure PIM-SM and IGMP on CE1's interface
connected to PE1, and connect CE2 to PE2 and PE3 through Eth-Trunk interfaces. Bind the
Eth-Trunk interfaces of CE2 to an E-Trunk and configure the same ESI on PE2 and PE3.
Configure the E-Trunk on PE2 and PE3 to work in single-active mode, select PE2 as the
master device, and ensure that the Eth-Trunk interface of PE2 is Up.
NOTE
IGMPv3 is not supported in access-side dual-homing access scenarios.
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-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 Leave Synch routes 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
PE2
BD1
Multicast
source
BD1
EVPN
CE2 Receiver
BD1
CE1 PE1
PE3
3.1.11 Application Scenarios for EVPN
3.1.11.1 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:
l Ethernet auto-discovery routes
l MAC and IP routes
l Inclusive multicast routes
l Ethernet segment routes
l 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.
l PEs in different ASs establish multi-hop EBGP connections with each other and
exchange EVPN routes.
l ASBRs do not store EVPN routes or advertise EVPN routes to each other.
Figure 3-66 Inter-AS EVPN Option C networking where PEs advertise labeled EVPN routes
BGP/MPLS backbone BGP/MPLS backbone
EVPN1 AS100 AS200 EVPN1
CE1 Multi-hop MP-EBGP CE3
PE1 PE3
EBGP
MP-IBGP MP-IBGP
PE4
PE2 ASBR1 ASBR2
EVPN2
CE2 Multi-hop MP-EBGP
CE4
EVPN2 EVPN LSP
To improve expansibility, you can specify a route reflector (RR) in each AS. An RR stores all
EVPN routes and exchanges EVPN routes with PEs in the AS. RRs in two ASs establish MP-
EBGP connections with each other and advertise EVPN routes.

Figure 3-67 Inter-AS EVPN Option C networking with RRs
EVPN1
CE1 EVPN1
CE3
AS100 AS200
PE1
PE3
MP-IBGP MP-IBGP
EBGP
RR-1 RR-2
ASBR1 ASBR2
PE4
PE2
Multi-hop MP-EBGP EVPN2
CE4
EVPN LSP
CE2
EVPN2 LSP
Inter-AS EVPN Option C can be implemented using the following solutions:

l 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.
l 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
l 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.
l 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.2 DCI Scenarios

Data Center Interconnect (DCI) is a solution for communication between virtual machines
(VMs) in different data centers (DCs). DCI runs on carriers' networks. It uses technologies
such as Virtual eXtensible Local Area Network (VXLAN), Ethernet virtual private network
(EVPN), and BGP/MPLS IP VPN to ensure secure and reliable transmission of packets from
DCs, implementing communication between VMs in different DCs.

Table 3-7 Basic DCI concepts

Concept Description
Overlay network l 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.
l The overlay network has an independent
control plane and forwarding plane.
l 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 devices.

and DCI-PEs
Integrated deployment of DCI-PEs and A DC-GW and a DCI-PE are a single device,
DC-GWs which applies to scenarios where carriers build
their own DCs.
On the network shown in Figure 3-68, 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-8.

Figure 3-68 Basic DCI scenario
DCI backbone network

DCI-PE1 DCI-PE2
VXLAN/VLAN
VXLAN/VLAN
DC-GW1 DC-GW2
Device1 Device2 Device3 Device4
VSwitch VSwitch VSwitch VSwitch
VMa1 VMa2 VMa3 VMa4 VMb1 VMb2 VMb3 VMb4
Data center A Data center B
Data packets

Table 3-8 Route information

Route Function Fields Carried in a Route
l RD1: route distinguisher 1,

indicating the route ID of
an EVPN instance.
l VM-MAC: MAC address
of a VM.
l VM-IP: IP address of a
VM.
l Label 1: L2VNI of a
VXLAN tunnel or Layer 2
MPLS label.
Used to transmit a tenant's l Label 2: L3VNI of a
EVPN IRB route host IP address and MAC VXLAN tunnel or Layer 3
address on an EVPN. MPLS label.
l NHP: next hop of a route,
usually a local IP address
used to establish a BGP
EVPN peer relationship.
l ExtCommunity: extended
community attributes of a
route, including the
VXLAN encapsulation
mode, Router-MAC, and
export route target (ERT)
of a route.

an EVPN instance.
l IP: VM's IP address or
address of the network
segment to which a VM's
IP address belongs.
l Label: L3VNI of a
Used to transmit a tenant's
VXLAN tunnel or Layer 3
host IP address or the address
MPLS label.
EVPN IP prefix route of the network segment to
which the host IP address l NHP: next hop of a route,
belongs on an EVPN. usually a local IP address
VXLAN encapsulation
mode, Router-MAC, and
ERT of a route.

Route Function Fields Carried in a Route

indicating the ID of a
VPNv4 route.
VM.
Used to transmit a tenant's l Label: VPN label carried in
host IP address or the address VPNv4 routes.
VPNv4 route of the network segment to l NHP: next hop of a route,
which the host IP address usually a local IP address
belongs on an L3VPN. used to establish a BGP
VPNv4 peer relationship.
community attribute of a
route, only the ERT
attribute.

an EVPN instance.
l VM-MAC: MAC address
of a VM.
VM. This field is carried
only in ARP routes.
Used to transmit a tenant's l Label: L2VNI of a
EVPN MAC route or VXLAN tunnel or Layer 2
host MAC address or ARP
ARP route MPLS label.
information on an EVPN.
l NHP: next hop of a route,
usually a local IP address
VXLAN encapsulation
mode and ERT of a route.
DCI Control Plane

The DCI control plane advertises both Layer 3 and Layer 2 routes:
l 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.

l 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-9 describes Layer 3 route advertisement and Layer 2 route advertisement.

Table 3-9 Route advertisement

Advertisement Process
Deployme
Services DC-GW1 to DCI-PE1 to DCI-PE2 to DC-
nt Mode
DCI-PE1 DCI-PE2 GW2
Upon receipt,
DCI-PE2 imports
the BGP VPNv4
DCI-PE1 reroute into the
encapsulates the local IP VPN
EVPN route instance based on
received from DC- the route RT and
GW1 into a BGP delivers
DC-GW1 sends a VPNv4 route, information about
tenant's host IP applying the MPLS tunnel
address to DCI- following recursion to the
PE1 through an changes: VPN forwarding
IRB route or IP
l Changes the table. DCI-PE2
prefix route. DCI-
next hop to the re-encapsulates
PE1 parses the
local device's the received BGP
tenant's host IP
IP address VPNv4 route into
route from the
used to an IP prefix route,
received EVPN
establish a applying the
route. Then the
BGP VPNv4 following
system imports
L3VPN peer changes:
Layer 3 the tenant's route
(VXLAN relationship. l Changes the
services into the IP VPN
access) next hop to the
instance based on l Replaces the
RT matching RD and RT VTEP address
between the values of the of DCI-PE2.
EVPN route and EVPN route l Replaces the
the IP VPN with those of RD and RT
instance and an L3VPN values of the
delivers instance. BGP VPNv4
information about l Applies for route with
VXLAN tunnel and those of the
recursion to the encapsulates a L3VPN
VPN forwarding VPN label. instance and
table. pads the route
After re-
with an
encapsulation,
L3VNI.
DCI-PE1 sends
the route to DCI- After re-
PE2. encapsulation,
DCI-PE2 sends
the IP prefix route
to DC-GW2.

Deployme
nt Mode
DCI-PE1 DCI-PE2 GW2
DCI-PE1 re-
encapsulates the
VPN route into an
IP prefix route,
applying the
following
changes:
l Changes the After receiving
next hop to the the EVPN route,
DC-GW1 sends local device's DCI-PE2 imports
routes destined for IP address the route into the
the network used to local IP VPN
segment on which establish a instance based on
a tenant's host IP BGP EVPN the RT of the
EVPN-
address resides to peer EVPN route,
MPLS Layer 3
DCI-PE1 through relationship. generates a VPN
(VLAN services
an IGP or BGP route forwarding
access) l Adds the RD
route. Upon entry, and
and RT
receipt, DCI-PE1 advertises the
attributes to
delivers these EVPN route to
the EVPN
routes to the VPN DC-GW2 through
route.
forwarding table. a VPN IGP or
l Applies for BGP peer
and relationship.
encapsulates a
VPN label.
After re-
encapsulation,
DCI-PE1 sends
the route to DCI-
PE2.

Deployme
nt Mode
DCI-PE1 DCI-PE2 GW2
DCI-PE1
generates an
EVPN MAC
route, applying the
following
changes:
l Changes the
next hop to the
local device's
IP address Upon receipt,
DCI-PE1 learns
used to DCI-PE2 imports
the source MAC
establish a the MAC/IP
address of service
BGP EVPN advertisement
traffic received
peer route into the
from DC-GW1.
Layer 2 relationship. local EVPN
Then DCI-PE1
services instance based on
generates a local l Adds the RD
the route RT and
MAC forwarding and RT
generates a local
entry and an attributes to
Layer 2
EVPN MAC the EVPN
forwarding entry
route. route.
accordingly.
l Applies for
and
encapsulates a
VPN label.
After re-
encapsulation,
DCI-PE1 sends
the route to DCI-
PE2.

Deployme
nt Mode
DCI-PE1 DCI-PE2 GW2
DCI-PE1 re-
encapsulates the
route into an IRB
DC-GW1 sends a or IP prefix route.
tenant's host IP The encapsulation
mode changes Upon receipt,
address to DCI-
from VXLAN to DCI-PE2 imports
PE1 through an
MPLS: the IRB or IP
IRB route or IP
prefix route into
prefix route. DCI- l Changes the the IP VPN
PE1 parses the next hop to the instance and
tenant's host IP local device's delivers
route from the IP address information about
received EVPN used to MPLS tunnel
route. Then the establish a recursion to the
EVPN- system imports BGP EVPN VPN forwarding
MPLS Layer 3 the tenant's route peer table. DCI-PE2
(VXLAN services into the IP VPN relationship. changes the L2
access) instance based on
l Adds the RD and L3 VPN
RT matching
and RT labels in the route
between the local
attributes to to L2 and L3
EVPN instance
the EVPN VNIs, re-
and the IP VPN
route. encapsulates the
instance and
l Applies for route into an IRB
delivers
and or IP prefix route,
information about
encapsulates a and then sends the
VXLAN tunnel
VPN label. route to DC-
recursion to the
GW2.
VPN forwarding After re-
table. encapsulation,
DCI-PE1 sends
the route to DCI-
PE2.

Deployme
nt Mode
DCI-PE1 DCI-PE2 GW2
Upon receipt,
DCI-PE1 re- DCI-PE2 imports
encapsulates the the MAC/IP
EVPN routes and advertisement
change the next- route into the
hop IP address to local EVPN
the IP address of instance based on
DC-GW1 sends a
the locally RT matching.
tenant's host MAC
established EVPN DCI-PE2 re-
address to DCI-
peer. The RD and encapsulates the
PE1 through a
RT attributes in EVPN route by
MAC/IP
the EVPN routes changing the next
advertisement
that carry the hop to its own
route. DCI-PE1
VXLAN VTEP address,
Layer 2 imports the
encapsulation replacing the RD
services MAC/IP
attribute are and RT values of
advertisement
replaced with the the EVPN route
route into the
RD and RT of the with those of the
local EVPN
local EVPN local EVPN
instance based on
instance. The instance and
RT matching and
MPLS label is padding the route
generates a MAC
requested. The re- with an L2VNI.
forwarding entry.
encapsulated Then DCI-PE2
MAC/IP sends the re-
Advertisement encapsulated
routes are then MAC address
advertised to DCI- advertisement
PE2. route to DC-
GW2.
DCI Data Plane

Table 3-10 describes Layer 2 traffic forwarding and Layer 3 traffic forwarding.

Table 3-10 Service traffic forwarding

Forwarding Process
Deployme
nt Mode
DCI-PE2 DCI-PE1 GW1
DCI-PE2 parses
the VXLAN data
packet to obtain Upon receipt,
the VNI and data DCI-PE1 removes
packet. Based on the public MPLS
the VNI, DCI-PE2 tunnel label, and,
finds the based on the VPN
corresponding label, finds the
VPN instance and, corresponding
based on the VPN instance.
tenant's host IP Then, based on
address for the the tenant's host
DC-GW2 sends a
MPLS tunnel to IP address for the
L3VPN data packet to
Layer 3 DCI-PE1, VXLAN tunnel to
(VXLAN DCI-PE2 through
services searches the DC-GW1, DCI-
access) the VXLAN
corresponding PE1 searches the
tunnel.
VPN instance corresponding
forwarding table. VPN instance
After forwarding table.
encapsulating a DCI-PE1
VPN label and a encapsulates the
public MPLS data packet with a
tunnel label into VXLAN header
the data packet, and then sends the
DCI-PE2 sends VXLAN packet to
the packet to DCI- DC-GW1.
PE1 through the
MPLS tunnel.

Forwarding Process
Deployme
nt Mode
DCI-PE2 DCI-PE1 GW1
Upon receipt,
DCI-PE2 searches DCI-PE1 removes
the forwarding the public MPLS
table of the VPN tunnel label, and,
instance bound to based on the VPN
the interface that label, finds the
receives the data corresponding
packet and, based VPN instance.
on the destination Based on the
address of the data tenant's host IP
DC-GW2 sends a
packet, finds the address, DC-PE1
Layer 3 data packet to
MPLS tunnel to searches the
services DCI-PE2 through
DCI-PE1. After corresponding
VPN forwarding.
encapsulating a VPN instance
VPN label and a forwarding table
public MPLS for the outbound
tunnel label into interface to DC-
the data packet, GW1. Then, DC-
DCI-PE2 sends PE1 sends the
the packet to DCI- data packet to
PE1 through the DC-GW1 through
EVPN- MPLS tunnel. the outbound
MPLS interface.
(VLAN Upon receipt,
access) DCI-PE2 searches DCI-PE1 removes
the forwarding the public MPLS
table of the EVPN tunnel label, and,
instance bound to based on the VPN
the interface that label, finds the
receives the data corresponding
packet and, based EVPN instance.
on the destination Based on the
DC-GW2 sends a
address of the data MAC forwarding
data packet to
packet, finds the entry for the
Layer 2 DCI-PE2 through
MPLS tunnel to broadcast domain
services Layer 2
DCI-PE1. After bound to the
forwarding on the
encapsulating a EVPN instance,
data plane.
VPN label and a DC-PE1 finds the
public MPLS corresponding
tunnel label into outbound
the data packet, interface and
DCI-PE2 sends sends the data
the packet to DCI- packet to DC-
PE1 through the GW1 through the
MPLS tunnel. outbound
interface.

Forwarding Process
Deployme
nt Mode
DCI-PE2 DCI-PE1 GW1
DCI-PE2 parses
the VXLAN data
packet to obtain Upon receipt,
the VNI and data DCI-PE1 removes
packet. Based on the public MPLS
the VNI, DCI-PE2 tunnel label, and,
finds the based on the VPN
corresponding label, finds the
VPN instance and, corresponding
based on the VPN instance.
tenant's host IP Then, based on
address for the the tenant's host
DC-GW2 sends a
EVPN- MPLS tunnel to IP address for the
data packet to
MPLS Layer 3 DCI-PE1, VXLAN tunnel to
DCI-PE2 through
(VXLAN services searches the DC-GW1, DCI-
the VXLAN
access) corresponding PE1 searches the
tunnel.
VPN instance corresponding
forwarding table. VPN instance
After forwarding table.
encapsulating a DCI-PE1
VPN label and a encapsulates the
public MPLS data packet with a
tunnel label into VXLAN header
the data packet, and then sends the
DCI-PE2 sends VXLAN packet to
the packet to DCI- DC-GW1.
PE1 through the
MPLS tunnel.

Forwarding Process
Deployme
nt Mode
DCI-PE2 DCI-PE1 GW1
DCI-PE2 parses
the VXLAN data
packet to obtain
the VNI and data
packet. Based on
the VNI, DCI-PE2
Upon receipt,
finds the
DCI-PE1 removes
corresponding
the public MPLS
broadcast domain.
tunnel label and,
Based on the
based on the VPN
broadcast domain,
label and BD ID,
DCI-PE2 finds the
finds the
forwarding table
corresponding
of the
broadcast domain,
corresponding
and then, based on
DC-GW2 sends a EVPN instance.
the tenant's host
data packet to DCI-PE2 searches
Layer 2 destination MAC
DCI-PE2 through for the forwarding
services address, searches
the VXLAN information
the broadcast
tunnel. corresponding to
domain for the
the destination
VXLAN tunnel to
address of the data
DC-GW1. DCI-
packet, that is,
PE1 encapsulates
information about
the data packet
the MPLS tunnel
with a VXLAN
to DCI-PE1. After
header and then
encapsulating a
sends the VXLAN
VPN label and a
packet to DC-
public MPLS
GW1.
tunnel label into
the data packet,
DCI-PE2 sends
the packet to DCI-
PE1 through the
MPLS tunnel.
3.1.11.3 Migration from an HVPLS Network to a PBB-EVPN

On the network shown in Figure 3-69, VPLS is deployed to allow services of the same
private network to access VSIs over different PEs. To avoid establishment of full-mesh PWs,
SPEs are deployed on the network to form an HVPLS.
After devices have PBB-EVPN enabled, the HVPLS network can migrate to a PBB-EVPN.
Because this network has large numbers of devices, migration needs to be performed step by
step and HVPLS and PBB-EVPN will temporarily coexist. The implementation process is as
follows:

1. Configure a B-EVPN instance on the SPE and specify a unique B-MAC address for the
B-EVPN instance.
2. Change the existing VSI on the SPE to be an MP2MP I-VSI and bind the I-VSI to the B-
EVPN instance previously configured. The I-tag for the I-VSI must be the same as the I-
tag for the B-EVPN instance. Otherwise, services cannot be forwarded.
3. Specify each UPE as an EVPN BGP peer for the SPE.
4. Configure a B-EVPN instance on each UPE and specify the SPE as an EVPN BGP peer
for each UPE. Then, UPEs will learn B-MAC addresses from their EVPN BGP peers
and the SPE will learn the B-MAC addresses of the entire network.
5. Change the existing VSI on each UPE to be an I-EVPN instance, bind the I-EVPN
instance to the previously configured B-EVPN instance, and bind the AC interface on
each UPE to the I-EVPN instance on that UPE. After all configurations are complete, the
network becomes a PBB-EVPN.
Figure 3-69 Typical networking
UPE1 UPE3
Site2
CE1
SPE CE3
Site1
MPLS/IP
CE2 Network Site3
CE4
UPE2 UPE4
3.1.11.4 Using EVPN to Interconnect Other Networks

On the network shown in Figure 3-70, to interconnect different sites through a public
network, deploy EVPN by performing the following configurations:
l 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.
l Create EVPN instances on PEs. Configure the same RT values for the PEs to allow
EVPN route cross.
l 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-70 EVPN application networking
RR1
PE1 PE3
Backbone
CE1
PE5
EVPN1 Site 1
EVPN Site 2
CE2 CE4
EVPN1
PE2 PE4
RR2
3.1.11.5 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.

Figure 3-71 L3VPN accessing EVPN
L3VPN EVPN
UPE NPE1 NPE2
CE1 CE2
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:
l 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.

Figure 3-72 Single-homing scenario 1 for VLL accessing EVPN (per NID per PW)
CE1-1
C-Vlan=1
S-Vlan=100
CE1-3
CE2-1 VLL EVPN
C-Vlan=2
NID1 PW1 for NID1
Switch S-Vlan=100 C-Vlan=1,2 EVPN1 for CE1
EVPN2 for CE2

NID2 PW1 for NID2
UPE S-Vlan=200 C-Vlan=1,2 NPE1 NPE2
CE1-2
C-Vlan=1
CE2-3
S-Vlan=200
CE2-2
C-Vlan=2
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-73 Single-homing scenario 2 for VLL accessing EVPN (multiple NIDs per
PW)
CE1-1
C-Vlan=1
S-Vlan=100
CE1-3
CE2-1 VLL EVPN
C-Vlan=2
NID1
Switch EVPN1 for CE1
PW1 for NID1,NID2
S-Vlan=100 ,200
C-Vlan=1,2
EVPN2 for CE2
NID2
UPE NPE1 NPE2
CE1-2
C-Vlan=1
CE2-3
S-Vlan=200
CE2-2
C-Vlan=2
l 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.

Figure 3-74 Dual-homing scenario for VLL accessing EVPN
CE1-1 VLL EVPN

C-Vlan=1
NPE1
S-Vlan=100 nnel CE1-3

S Tu
MPL
MPLS EVPN
MPL
S Tu
nnel NPE3
NID UPE
NPE2
CE1-2
C-Vlan=2
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-75, 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-75 Splicing VXLAN and VPLS
PE1 Data Center
Server
PE3 TOR
MPLS VXLAN
VPLS
Enterprise
campus
PE2
Splicing Primary and Secondary PWs with an Anycast VXLAN Tunnel in an

EVPN Active-Active Scenario
On the network shown in Figure 3-76, PE1 and PE2 are egress devices of the data center
network. PE1 and PE2 work in active-active mode with a bypass VXLAN tunnel deployed
between them. They use an anycast VTEP address to establish a VXLAN tunnel with the
TOR. In this manner, PE1, PE2, and the TOR can communicate with each other. PE1 and PE2
communicate with the external network (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 TOR, 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. 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-76 Splicing primary and secondary PWs with an anycast VXLAN tunnel in an
EVPN active-active scenario
VPLS PE1 Data Center
PW
e
tiv
Ac
Bypass VXLAN
Anycast
PE-AGG
VTEP
Network Anycast VXLAN
St TOR
an Server
db
y
PW
PE2
Traffic forwarding path
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-77, 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 Ethenet 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 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.
NOTE
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-77 Networking of VPLS splicing with MPLS EVPN

ASG1
PW
e
tiv
Ac
CSG
VPLS EVPN Site2

Site1
St RSG
an
db
y
PW
ASG2
3.1.11.6 Seamless Migration of VPLS to EVPN

To convert each VPLS PE on a network into an EVPN device, you can configure the seamless
migration of VPLS to EVPN function, which does not interrupt services during network
running.
On the network shown in Figure 3-78, seamless migration of VPLS to EVPN involves the
following process:
1. After EVPN is enabled on PE1, PE1 starts to advertise inclusive multicast routes to the
other PEs. Because PE1 does not receive any inclusive multicast routes from the other
PEs, traffic between PE1 and the other PEs continues to be forwarded through VPLS
connections.
2. When EVPN continues to be enabled on another PE, for example PE2, PE2 starts to send
inclusive multicast routes to the remaining EVPN-disabled PEs.
3. After PE1 and PE2 receive inclusive multicast routes from each other, they discover each
other and disable the VPLS connection between them. The service between PE1 and PE2
is carried through an EVPN. Simultaneously, services between PE1/PE2 and the other
PEs remain carried through the VPLS connections.
4. The preceding process continues on the EVPN-incapable PEs one after another,
implementing seamless migration of VPLS to EVPN.

Figure 3-78 Seamless migration of VPLS to EVPN

CE1 PE1 PE2 CE2
CE3 PE3 PE4 CE4

PW EVPN Peer
PW
3.1.11.7 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-79 shows the basic architecture of an EVPN L3VPN HVPN consisting of mainly
UPEs, SPE, and NPE:
l 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.
l 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.
l NPE: An NPE is a network provider-end PE that is connected to SPEs and located at the
network side.
Figure 3-79 Basic EVPN L3VPN HVPN architecture

CE1 UPE1
Site 1 SPE NPE CE3
Site 3
Access Aggregation
Site 2
CE2 UPE2
EVPN L3VPN HVPN is classified into EVPN L3VPN HoVPN or EVPN L3VPN H-VPN:
l 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.
l 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:
l 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.
l Splicing between L3VPN HoVPN and BD EVPN L3VPN: L3VPN HoVPN is deployed
between the UPEs and SPE, and BD EVPN L3VPN is deployed between the SPE and
receiving specific routes (L3VPN routes) from the UPEs, the SPE encapsulates these
routes into EVPN routes and advertises them to the NPE.
Route Advertisement from CE1 to Device 1 on an EVPN L3VPN HoVPN or

EVPN L3VPN H-VPN
Figure 3-80 shows route advertisement from CE1 to Device 1 on an EVPN L3VPN HoVPN
or EVPN L3VPN H-VPN.
1. CE1 advertises an IPv4 route to the UPE using the IP protocol.
2. The UPE converts the IPv4 route into an IP prefix route with the next hop being the UPE
and then sends the IP prefix route to the SPE through a BGP-EVPN peer relationship.
3. Upon receipt, the SPE advertises this route to the NPE in either of the following ways:
– Using RR: Configure the SPE as an RR so that the RR directly reflects the received
IP prefix route to the NPE, and change the next hop of the route to the SPE. An
EVPN L3VPN H-VPN supports only this mode.
– Using re-encapsulation: The SPE re-encapsulates the IP prefix route into a new IP
prefix route with the next hop being the SPE. Then the SPE advertises the new
route to the NPE through a BGP-EVPN peer relationship.
4. After receiving the IP prefix route, the NPE imports the route into its VRF table under
the condition that the route's next hop is reachable.
5. The NPE advertises the IPv4 route to Device 1 using the IP protocol.

Figure 3-80 Route advertisement from CE1 to Device 1 on an EVPN L3VPN HoVPN or
EVPN L3VPN H-VPN
UPE SPE NPE

IP Prefix route IP Prefix route
IP route IP route
Device1
CE1
Site 1 Site 2
Route Advertisement from Device 1 to CE1 on an EVPN L3VPN HoVPN

Figure 3-81 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 imports it into
6. The UPE advertises the IPv4 route to CE1 using the IP protocol.
Figure 3-81 Route advertisement from Device 1 to CE1 on an EVPN L3VPN HoVPN
IP Prefix route
(default or
UPE aggregate route) SPE IP Prefix route NPE
IP route IP route
Device1
CE1
Site 1 Site 2

Route Advertisement from Device 1 to CE1 on an EVPN L3VPN H-VPN

Figure 3-82 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 imports it into
5. The UPE advertises the IPv4 route to CE1 using the IP protocol.
Figure 3-82 Route advertisement from Device 1 to CE1 on an EVPN L3VPN H-VPN
UPE SPE NPE

IP Prefix route IP Prefix route
IP route IP route
Device1
CE1
Site 1 Site 2
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 searches for a
VPN instance corresponding to the packet based on the inner VPN label. Then, the NPE
the packet based on the destination address of the packet. The NPE sends the packet
from the corresponding outbound interface to Device 1. The packet sent by the NPE is a
pure IP packet with no label.
Packet Forwarding from CE1 to Device 1 on an EVPN L3VPN H-VPN

Packet forwarding from CE1 to Device 1 on an EVPN L3VPN H-VPN is as follows:
1. CE1 sends a VPN packet to the NPE.
2. After receiving the packet, the UPE searches its VPN forwarding table for a tunnel to
forward the packet based on the destination address of the packet (the UPE does so by
matching the destination address of the packet against the forwarding entry for the
specific route received from the SPE). Then, the UPE adds a VPN label (inner) and a
tunnel label (outer) to the packet and sends the packet to the SPE over the found tunnel.
3. Upon receipt, the SPE removes the outer tunnel label, replaces the inner VPN label with
a new one, and then adds the outer tunnel label to the packet. Then, the SPE forwards the
packet to the NPE through the tunnel.
4. After receiving the packet, the NPE removes the outer tunnel label and searches for a
VPN instance corresponding to the packet based on the inner VPN label. Then, the NPE
the packet based on the destination 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:
l 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.
l 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.2 EVPN Configuration

This chapter provides an overview of Ethernet virtual private network (EVPN) and describes
its basic configurations.
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:
l Lack of support for load balancing: VPLS does not support traffic load balancing in
multi-homing networking scenarios.
l 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 no
need to learn the MAC addresses carried in them.
EVPN solves the preceding problems with the following characteristics:

l 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.
l 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.
l 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:
l Improved link usage and transmission efficiency: EVPN supports load balancing, fully
utilizing network resources and reducing network congestion.
l 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 Licensing Requirements and Limitations for EVPN

Item Requirement
82400924 NetEngine40E Controllable V800R009

100G EVPN Port feature:
License(per This license
100G) controls EVPN
for a 100G
interface on the
CM board.

10G EVPN Port feature:
License(per 10G) This license
controls EVPN
for a 10G
interface on the
CM board.

The EVPN public network Configure MF classification MF classification configured

interface does not support for the traffic inbound for the EVPN public
MF classification. interface before the EVPN network interface does not
public network interface. take effect.

If an EVPN instance is Manually set the VPLS PW If an EVPN instance is

bound to a BD that has been to Down. In master/backup bound to a BD that has been
bound to a VSI for an E-Trunk scenarios, bind an bound to a VSI for an
existing VPLS service, EVPN instance to a BD on existing VPLS service,
services may be interrupted. the backup E-Trunk first and services may be interrupted.
After the EVPN instance is then perform the binding on The MAC addresses learned
bound to the BD, services the master E-Trunk. by a BD are cleared, and
are restored. then the BD relearns the
MAC addresses. The unicast
mode is changed to
broadcast mode.
For a BD bound to both an None If a VPLS PW is set to be in

EVPN instance and a VPLS Spoken mode, loops may
VSI, the VPLS PWs cannot occur.
be set to be in Spoken mode.
When a VSI is bound to When a VSI is bound to If the BDs to be bound to

multiple BDs, if an EVPN multiple BDs, unbind the EVPN instances are not
instance is bound to one of BDs to be bound to EVPN removed from the VSI,
the BDs, the VSI's PW is set instances from the VSI. services in the other BDs are
to Down. As a result, interrupted.
services in the other BDs
that are not bound to EVPN
instances are interrupted.
An EVPN instance and a None Deleting the MAC address

VSI are bound to the same learned from the AC
BD. If the BD receives a interface triggers MAC
MAC Withdraw packet for a address deletion on the
PW from the remote VSI, EVPN. After the BD
the BD deletes the MAC relearns a MAC address
address learned from the AC from the AC interface, the
interface but does not clear BD broadcasts the MAC
the MAC address learned address on the EVPN.
from the EVPN instance.
If the PE at one end of a Re-plan the network Some services are

VPLS has only one VSI and deployment. interrupted during the
the PE at the other end has network reconstruction.
multiple VSIs, the VPLS
network cannot be
reconstructed into an EVPN.

The EVPN switch to which When the VPLS network is If the VPLS network is
a user device is connected is reconstructed into the reconstructed into the EVPN
replaced with a VPLS EVPN, manually shut down before the MAC entry for
network switch. Before the the network device interface the user device is aged, user
MAC entry aging time connecting to the switch and services are interrupted until
expires, the user device is then re-enable the interface the VPLS network ages the
reconnected to the EVPN after the network MAC entry for the user
switch. As a result, services reconstruction. device.
are interrupted until the
VPLS network ages the
MAC entry for the user
device.
In the scenario of splicing N/A EVPN traffic fails to be

between VLL and EVPN, forwarded or is interrupted.
when a VE 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.
In the scenario of splicing None None

between VLL and EVPN, a
VLL supports only the
following tunnel types: LDP,
TE, and LDP over TE.
In full-mesh networking, a Configure a VPLS PW to be An incorrect configuration

loop occurs in either of the in Hub or Spoken mode as results in a loop.
following scenarios: required.
l 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.)
l The E-Trunks through
which a CE is dual-
homed to PEs work in
active-active mode.

In an EVPN active-active On the access side, if one In the EVPN active-active

scenario, an access-side Eth- member interface or scenario, if a board fails,
Trunk interface has multiple multiple member interfaces duplicate traffic may exist
member interfaces, and the are configured on an Eth- for a short time.
member interfaces are Trunk, ensure that the
deployed on different member interfaces resided
interface boards. if an ESI is on the same interface board.
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.
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.
Regarding EVPN E-Line: If an EVPN works in single- Traffic for other services
The EVPN single-active active mode, the EVPN may not be forwarded
mode blocks traffic on an single-active services and properly.
AC interface. If the master/ active-active or Layer 3
backup E-Trunk status is services cannot be
determined, the backup E- transmitted through the
Trunk interface is set Down. same link.
Therefore, EVPN single-
active services and active-
active or Layer 3 services
cannot be transmitted
through the same link for
dual-homing access.
When a VLL accesses an None None

EVPN, only non-BD EVPN
(MPLS EVPN) is supported.

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. DCI and VXLAN anycast
active-active are mutually
exclusive.
3. Non-anycast VXLAN
active-active is not
supported.
4. ESIs on different dual-
homed interfaces cannot be
the same.
5. In active-active scenarios,
a CE must be directly
accessed to a PE, without
any intermediate device.
The same E-Tree attribute None No impact.

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.
In an EVPN dual-homing Configure different RDs for The remote device fails to
over RR scenario, the same EVI instances on the dual- implement load balancing or
RD is configured for the homing PE. FRR.
EVI instances corresponding
to the dual-homing devices
PE1 and PE2. RRs cannot
reflect the routes sent by
both PE1 and PE2. As a
result, the remote device
fails to implement load
balancing or FRR.

In an EVPN VPWS dual- Configure different RDs for The remote device fails to
homing over RR scenario, EVI instances on the dual- implement load balancing,
the same RD is configured homing PE. FRR, or bypass EVPL paths.
for the EVI instances
corresponding to the dual-
homing devices PE1 and
PEs. RRs cannot reflect the
routes sent by both PE1 and
PE2. As a result, the peer
device fails to implement
load balancing, FRR, or
bypass EVPL paths.
In a BGP EVPN L3VPN You need to switch to the In an EVPN L3VPN over
over SR-BE scenario, both VPN view to configure the SR-BE scenario where fast
the primary and secondary following tunnel policy. tunnel fault detection (such
SR-BE tunnels exist on the When the SR-BE primary as BFD detection) is not
EVPN L3VPN edge PE and tunnel fails, you can quickly enabled, the restart of edge
peer edge PE. If fast tunnel switch to the standby SR-BE PEs relies on hard
fault detection is not enabled tunnel. Other types of convergence and the
and the peer edge PE tunnels (such as LDP) are secondary SR-BE tunnel is
becomes faulty, a primary/ no longer selected. The used. The tunnel switching
secondary switchover is recommended configuration speed is low.
triggered by hard is as follows:
convergence. When multiple tunnel-policy AAA
types of tunnels exist, such
as LDP LSPs, to quicken tunnel select-seq sr-lsp ldp
convergence, a tunnel policy load-balance-number 1 //
must be configured. In this Configure the tunnel policy
case, focus on only the and select only the SR-BE
status of the primary and tunnel.
secondary SR-BE tunnels. #
ip vpn-instance vpn-801
ipv4-family
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

If a PE is configured with Configure different ERTs for BUM traffic forwarding

two EVPN instances whose different EVPN instances on fails.
ERTs are the same and the same PE.
EVPN routes are 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.
LPUF-50/LPUF-50-L/ Plan services properly. l 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-B/
LPUI-101-B/LPUS-101 LPUI-101/LPUI-101-B/
boards do not support SRv6 LPUS-101 board is
EVPN VPWS, EVPN installed after services
P2MP, or E-Tree per AC. are configured, the board
cannot be registered.
l 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 loop protection Do not disable MAC EVPN loop protection fails.
depends on MAC address address learning.
learning. If MAC address
learning is disabled, the
function becomes invalid.

In an active-active scenario Do not configure the After the ignore-standby-

where primary and ignore-standby-state state parameter and dual-
secondary PWs of a VPLS parameter for the PW on the receive are configured on
are connected to a VXLAN, device where the VPLS is the device where the VPLS
the ignore-standby-state connected to the VXLAN. is connected to the VXLAN,
parameter cannot be duplicate multicast traffic is
configured for the PW on generated in the direction
the device where the VPLS from the VXLAN to the
is connected to the VXLAN. VPLS.
If both the parameter and
dual-receive are configured,
duplicate multicast traffic is
generated in the direction
from the VXLAN to the
VPLS.
When a VLL is connected to Run the evpn access vll When a VLL is connected to
an EVPN, the loopback convergence separate an EVPN, the loopback
scheme is used in the disable command. scheme is used in the
downstream direction. In downstream direction. In
this case, CAR rate limit is this case, CAR rate limit is
inaccurate on a PWVE sub- inaccurate on a PWVE sub-
interface in the downstream interface in the downstream
direction. direction.
When a VLL is connected to None Packets are discarded in the

an EVPN, the loopback direction from the EVPN to
scheme is used in the the VLL during an ISSU.
downstream direction. In
this case, packets are
discarded in the direction
from the EVPN to the VLL
during an ISSU.
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.
l The license file for the master main control board has been activated using the license
active file-name command.
l 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.
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 takes effect only for boards in CM mode.
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-83, to allow Layer 2 networks at different sites to
communicate, configure EVPN. Specifically:
l 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.
l Configure EVPN source IP addresses to identify PEs in the EVPN networking.
l Configure ESIs for PE interfaces connecting to CEs. PE interfaces connecting to the
same CE have the same ESI.
l Configure BGP EVPN peer relationships between PEs on the backbone network to allow
MAC addresses to be advertised over routes.
l Configure RRs to decrease the number of BGP EVPN peer relationships required.

EVPN1
site1
CE1
PE1 PE2
ESI1 RR ESI3
ESI2 EVPN1
site3
EVPN1
site2 CE3
CE2 ESI3
PE4 PE3
EVPN1 CE4
site4
Before configuring common EVPN, complete the following tasks:
l Configure an IGP on the backbone network to ensure IP connectivity.

l Configure MPLS LDP or TE tunnels on the backbone network.
l 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.
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 RD is configured for the EVPN instance.
An EVPN instance takes effect only after the RD is configured. The RDs of different EVPN
instances on a PE must be different.
NOTE
After being configured, an RD cannot be modified, but can be deleted. After you delete the RD of an
EVPN instance, the VPN targets of the EVPN instance will also be deleted.
Step 5 Run vpn-target vpn-target &<1-8> [ both | export-extcommunity | import-extcommunity ]
VPN targets are configured for the EVPN instance.
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.
NOTE
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.
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 Run commit
----End
3.2.4.2 Configuring an EVPN Source Address

An EVPN source address uniquely identifies a PE in EVPN networking.
Context
The EVPN source address, which can be used to identify a PE on an EVPN, is part of EVPN
route information. Configuring EVPN source addresses is a mandatory task for EVPN
configuration.
Procedure
Step 2 Run evpn source-address ip-address
An EVPN source address is configured.
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.
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:

l The interface has been bound to an EVPN instance using the evpn binding vpn-
instance command.
l 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. 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 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.
NOTE
Functions, such as rapid convergence, split horizon, and DF election that are required in the EVPN dual-
homing scenario fail to take effect in a single homing scenario. In such a scenario, configuring the ESI is
optional on a dual-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 pdded with 0.

Procedure
l (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.
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
l Statically configure an ESI on an interface.
a. Run system-view
b. Run interface interface-type interface-number


c. Run esi esi
An ESI is configured.
d. Run commit

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

NOTE
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 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 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 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 router 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 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) 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
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:

l To set the local discriminator, run the discriminator local discr-value command.

l 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.9 (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.
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.10 Verifying the EVPN Configuration

After configuring EVPN, check the operating status and information about EVPN functions.
Prerequisites
EVPN has been configured.
Procedure
l Run the display default-parameter evpn command to check default EVPN
configurations during EVPN initialization.
l Run the display evpn vpn-instance [ name vpn-instance-name ] command to check
EVPN instance information.
l 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.
l Run the display evpn vpn-instance name vpn-instance-name df-timer state command
to check the DF timer status of an EVPN instance.
l 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.
l Run the display bgp evpn { all | route-distinguisher route-distinguisher | vpn-instance
vpn-instance-name } routing-table [ { ad-route | es-route | inclusive-route | mac-route
| prefix-route } prefix ] command to check information about EVPN routes.
l Run the display bgp evpn all routing-table statistics command to check statistics about
EVPN routes.
l Run the display evpn mac routing-table command to check MAC route information
about EVPN instances.
l Run the display evpn mac routing-table limit command to check MAC address limits
of EVPN instances.
l Run the display evpn mac routing-table statistics command displays MAC route
statistics of EVPN instances.
l Run the display arp broadcast-suppress user bridge-domain bd-id command to check
the ARP broadcast suppression table of a specified BD.
l 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:
l Configure an IGP on the backbone network to ensure IP connectivity.
l Configure MPLS LDP LSPs or TE tunnels on the backbone network.
l (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.
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.
An EVPN instance takes effect only after an RD is configured for it. The RDs of different
EVPN instances on the same PE must be different.
NOTE
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.

A VPN target is a BGP extended community attribute used to control the receiving and

vpn-target command. To configure more VPN targets in the EVPN instance address family,
NOTE
An RT of an Ethernet segment route is generated using the middle six bytes of an ESI. For example, if
the ESI is 0011.1001.1001.1001.1002, the Ethernet segment route uses 11.1001.1001.10 as its RT.
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 ]
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 tunnel.
Step 10 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.

Procedure
Step 2 Run evpn source-address ip-address
An EVPN source address is configured.
Step 3 Run commit
----End
3.2.5.3 Configuring an ESI

Ethernet segment identifiers (ESIs) must be configured for PE interfaces connecting to CEs or
BDs configured on PEs, and the same ESI must be configured for different PE interfaces
connecting to the same CE or BDs on different PEs connecting to the same CE.
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:
l Statically configured
l 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.
NOTE
The features required in an EVPN dual-homing scenario, such as fast convergence, split horizon, and DF
election, all become invalid in a single-homing scenario. Therefore, configuring an ESI on a single-homed PE
is optional.
Procedure
l (Optional) Configure an E-Trunk.
a. Run system-view
b. Run e-trunk e-trunk-id
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
The view of an Eth-Trunk interface is displayed.
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
l Configure an interface to dynamically generate an ESI.
a. Run system-view
c. Run mode lacp-static
The working mode of the Eth-Trunk interface is set to static LACP.
d. Run commit
l 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
l 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.
l 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.
l In MPLS mode, an EVPN instance is bound to a BD directly in the BD view.
Procedure
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
A Layer 2 sub-interface is created, and the sub-interface view is displayed.
NOTE
Before running this command, ensure that the Layer 2 interface on which 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
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.
A VPN instance is created, and the VPN instance view is displayed.
2. Run ipv4-family
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.
6. (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.
7. (Optional) Run import route-policy policy-name evpn
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.
8. (Optional) Run export route-policy policy-name evpn
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 attributes for eligible routes.
9. Run quit
Exit from the VPN instance IPv4 address family view.
10. Run quit
Exit from the VPN instance view.
Step 3 Run interface vbdif bd-id
A VBDIF interface is created, and the VBDIF interface view is displayed.
By default, no VBDIF interface is created.

Step 4 Run ip binding vpn-instance vpn-instance-name
The L3VPN instance is bound to the VBDIF interface.
Step 5 Run ip address ip-address { mask | mask-length } [ sub ]
An IP address is configured for the VBDIF interface to implement Layer 3 interworking.
Step 6 (Optional) Run mac-address mac-address
A MAC address is configured for the VBDIF interface.
Step 7 Run arp distribute-gateway enable
Distributed gateway is enabled.
After distributed gateway is enabled, the discards the ARP messages received from the
network side and learns only ARP messages from the user side and generates host routes.
Step 8 Run arp collect host enable
The function to advertise hots ARP routes and IRB routes is enabled.
Step 9 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.
The interface on which a TCP connection to the specified peer is to be established is

specified.

NOTE
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 }
IRB or ARP 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
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 [ percentage ] [ alert-
only | idle-forever | idle-timeout times ]
The maximum number of MAC advertisement routes that can be received from each peer is
configured.
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 Run commit
----End
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
Step 2 Run evpn redundancy-mode single-active
The Single-Active redundancy mode is configured.
Step 3 Run commit
----End
3.2.5.8 (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 router 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
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
If a cluster has multiple RRs, you can use this command to set the same cluster ID for these
The reflector cluster-id command can only be run on an RR.
Step 7 Run commit
----End
3.2.5.9 (Optional) Configuring Proxy ARP

When users access each other for the first time, they send ARP request packets. These packets
are broadcast on Layer 2 networks. Proxy ARP can be configured to reduce the number of
ARP broadcast packets.
Context
On an EVPN MPLS network, after a device receives an ARP request packet, it broadcasts the
packet within a BD. If the device receives a large number of ARP request packets within a
specified period and broadcasts these packets, excessive ARP request packets are forwarded
on the EVPN MPLS network, consuming excessive network resources and causing network
congestion. As a result, the network performance deteriorates, and user services are affected.
To address this problem, configure proxy ARP on the device. Proxy ARP allows a device to
listen to a received ARP packet and generate an ARP snooping entry to record the source user
information, including the packet's source IP address, source MAC address, and inbound
interface. If proxy ARP is enabled on a device and an ARP request packet is received, the
device preferentially responds to the request if an ARP snooping entry matches the user
information in the ARP request.
Procedure
Step 1 Run: system-view
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
Step 7 Run: bridge-domain bd-id
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.
Step 10 Perform the following operations as required:
l 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.
l 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, check the operating status and information about EVPN functions.
Prerequisites
EVPN has been configured.

Procedure
l Run the display default-parameter evpn command to check default EVPN
configurations during EVPN initialization.
l 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.
l Run the display evpn vpn-instance name vpn-instance-name df-timer state command
to check the DF timer status of an EVPN instance.
l 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.
| prefix-route } prefix ] command to check information about EVPN routes.
l Run the display bgp evpn all routing-table statistics command to check statistics about
EVPN routes.
l Run the display evpn mac routing-table command to check MAC route information
about EVPN instances.
l Run the display evpn mac routing-table limit command to check MAC address limits
of EVPN instances.
l Run the display evpn mac routing-table statistics command displays MAC route
statistics of EVPN instances.
l Run the display arp broadcast-suppress user bridge-domain bd-id command to check
the ARP broadcast suppression table of a specified BD.
l 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

To allow traffic communication between an AC interface on the user side and a P2P MPLS
LDP tunnel interface on the network side, you can configure EVPN VPWS over MPLS so
that the two interfaces can be bound to each other.
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:
l 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.
l 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.
l 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.
l Tunnel: tunnel on the network side.
Figure 3-84 Configuring EVPN VPWS over MPLS functions

CE1
PE1
PE2 CE3
MPLS Network
PE2
CE2
MPLS LDP Tunnel Interface

AC Interface
EVPL Instance
MPLS LDP Tunnel
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.
NOTE
After being configured, an RD cannot be modified, but can be deleted. After you delete the RD of an
EVPN instance, the VPN targets of the EVPN instance will also be deleted.
A VPN target is a BGP extended community attribute. It is used to control the receiving and
vpn-target command. To configure more VPN targets in the EVPN instance address family,
Step 5 Run quit
Step 6 Run evpl instance evpl-id mpls-mode
An EVPL instance is created, and its view is displayed.
Step 7 Run evpn binding vpn-instance vpn-instance-name
The EVPL instance is bound to an EVPN instance for a specified VPWS.
Step 8 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

NOTE
Before running this command, ensure that the Layer 2 main interface does not have the port link-type
dot1q-tunnel command configuration. If the configuration has existed, run the undo port link-type
command to delete it.
Step 3 Run evpl instance evpl-id

An EVPL instance is bound to the Layer 2 sub-interface.
Step 4 Run commit

----End
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:
l Configuring an LSR ID is the prerequisite of all MPLS configurations.
l An LSR ID must be manually configured because no default LSR ID is available.
l Use the IP address of a loopback interface on an LSR as an LSR ID.
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
MPLS is enabled on an interface.
Step 8 Run mpls ldp
MPLS LDP is enabled on an interface.
NOTE
Disabling MPLS LDP from an interface leads to interruptions of all LDP sessions on the interface and
deletions of all LSPs established over these LDP sessions.
Step 9 Run commit
----End
3.2.6.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-85 Configuring DF election
PE1
CE1 PE3 CE2

MPLS Network
PE2

AC Interface
EVPL Instance
MPLS LDP Tunnel
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.
NOTE
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
----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-86 Configuring FRR

Procedure
l Configure local and remote FRR functions on PE1 and PE2.
a. Run system-view
b. Run evpn vpn-instance vpn-instance-name vpws
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.
NOTE
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
l Configure remote FRR on PE3.
a. Run system-view
b. Run evpn vpn-instance vpn-instance-name vpws
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.
NOTE
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, check the configurations.
Prerequisites
EVPN VPWS over MPLS has been configured.
Procedure
l Run the display bgp evpn evpl brief command to check brief information about all
EVPL instances.

l Run the display bgp evpn evpl instance-id instance-id command to check information
about a specified EVPL instance.
----End
3.2.7 Configuring an EVPN to Carry Layer 3 Services

On DCI and IP RAN networks, you can configure EVPN functions to carry Layer 3 services.
Usage Scenario
On a traditional network, the BGP/MPLS IP VPN function is used to carry Layer 3 services.
To additionally carry Layer 2 services, users have to deploy an L2VPN over the existing
network, which increases deployment and O&M costs. To address this problem, users can
deploy an EVPN to carry Layer 3 services. To additionally carry Layer 2 services, users only
add some EVPN configurations, implementing the bearer of both Layer 2 and Layer 3
services.
EVPN can replace BGP/MPLS IP VPN in the following scenarios to carry Layer 3 services:
l Intra-AS mutual VPN communication
On the network shown in Figure 3-87, 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-87 Intra-AS mutual VPN communication
PE1 PE2
CE1 CE2
MPLS Network
Site1 Site2
l Inter-AS mutual VPN communication

On the network shown in Figure 3-88, 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.
and CE at the access side to mutually transmit VPN routes.

Figure 3-88 Inter-AS mutual VPN communication
PE1 ASBR1 ASBR2 PE2

MPLS Network MPLS Network
AS100 AS200
CE1 CE2
Site1 Site2
l DCI network
The EVPN function applies to traditional DCs that interconnect through a DCI network.
On the network shown in Figure 3-89, 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.
and DC-GW to mutually transmit VM IP routes.
Figure 3-89 DCI network
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
9. Run quit
10. Run quit
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 Run ip address ip-address { mask | mask-length }
An IP address is configured for the Ethernet sub-interface.
Step 7 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
l Configure BGP EVPN peers.
NOTE
If a BGP RR needs to be configured on the network, establish BGP EVPN peer relationships
between all the PEs and the RR.

b. Run peer ipv4-address as-number { as-number-plain | as-number-dot }
The remote PE is specified as the BGP peer.

c. (Optional) Run peer ipv4-address connect-interface interface-type interface-
number [ ipv4-source-address ]
A source interface and a source IP address are specified to set up a TCP connection
between the BGP peers.
NOTE
When loopback interfaces are used to establish a BGP connection, it is recommended that
the peer connect-interface command be run on both ends to ensure correct connection. If
this command is run on only one end, the BGP connection may fail to be established.
d. (Optional) Run peer ipv4-address ebgp-max-hop [ hop-count ]
The maximum number of hops allowable is set for an EBGP EVPN connection.
Generally, EBGP EVPN peers are directly connected. If they are not directly
connected, run the peer ebgp-max-hop command to allow the EBGP EVPN peers
to establish a multi-hop TCP connection.

NOTE
If loopback interfaces are used for an EBGP EVPN connection, the peer ebgp-max-hop
command must be run, with the hop-count value greater than or equal to 2. If this
configuration is absent, the EBGP EVPN connection fails to be established.
e. Run ipv4-family vpn-instance vpn-instance-name
The BGP-VPN instance IPv4 address family view is displayed.

f. Run import-route { direct | isis process-id | ospf process-id | rip process-id |
static } [ med med | route-policy route-policy-name ] *
The device is enabled to import non-BGP routing protocol routes into the BGP-
VPN instance IPv4 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 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

l (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 for these
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

To implement route exchange between a PE and an access-side device, deploy BGP or an IGP
between them or configure static routes (including default routes) destined for each other on
them. You can choose a dynamic routing protocol or static routes 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.
----End
3.2.7.4 (Optional) Re-Encapsulating IRB Routes into IP Prefix Routes and ARP
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, you must enable the
device to re-encapsulate IRB 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.

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
| prefix-route } prefix ] command to check information about BGP EVPN routes.
l Run the display ip 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-90, an L3VPN is already deployed. If a user wants to
deploy an EVPN L3VPN over the network, co-existence of the EVPN L3VPN and L3VPN
occurs during reconstruction. To ensure communication between the two VPNs, the user must
configure splicing between L3VPN and EVPN L3VPN on NPE1.
Figure 3-90 Splicing between L3VPN and EVPN L3VPN
UPE NPE1 NPE2

L3VPN EVPN
Site1 Site2

Before configuring splicing between L3VPN and EVPN L3VPN, complete the following
tasks:
l Configure basic MPLS functions on the UPE, NPE1, and NPE2.

l Configure an IGP on the UPE, NPE1, and NPE2 to implement route reachability.
l Configure EVPN instances in BD mode on NPE1 and NPE2. For configuration details,
see 3.2.4.5 Configuring a BGP EVPN Peer Relationship.
l Configure an L3VPN between NPE1 and the UPE. For configuration details, see
Configuring a Basic BGP/MPLS IP VPN.
Procedure
l Configure NPE1 and NPE2 to generate and advertise IP prefix routes.
a. Run ip vpn-instance vpn-instance-name
b. Run ipv4-family
The IPv4 address family is enabled for the VPN instance, and the VPN instance
IPv4 address family view is displayed.
c. Run vpn-target vpn-target &<1-8> [ both | export-extcommunity | import-
extcommunity ] evpn
VPN targets are configured for the VPN instance IPv4 address family to mutually
import routes with the local EVPN instance.
d. Run evpn mpls routing-enable
e. (Optional) Run tnl-policy policy-name evpn
f. Run quit
g. Run quit
h. Run commit
l Configure NPE1 to advertise routes regenerated by the EVPN address family to the BGP
VPNv4 peer (UPE).


c. Run peer { ipv4-address | group-name } import reoriginate
The BGP device is enabled to add the regeneration flag to the routes received from
the BGP EVPN peer.

d. Run quit
Return to the BGP view.
e. Run ipv4-family vpnv4
The BGP-VPNv4 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 routes into which EVPN routes are re-encapsulated.
g. Run peer { ipv4-address | group-name } advertise route-reoriginated evpn
{ mac-ip | ip }
NPE1 is configured to advertise routes regenerated by the EVPN address family to
the BGP VPNv4 peer (UPE).
After the peer { ipv4-address | group-name } advertise route-reoriginated evpn
{ mac-ip | ip } command is run, NPE1 uses MPLS to re-encapsulate the EVPN
routes received from NPE2 into BGP VPNv4 routes and then sends them to the
UPE.
h. Run quit
i. Run quit
j. Run commit
l Configure NPE1 to advertise routes regenerated by the VPNv4 address family to the
BGP EVPN peer (NPE2).
b. Run ipv4-family vpnv4
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 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 routes are re-encapsulated.
g. Run peer { ipv4-address | group-name } advertise route-reoriginated vpnv4
NPE1 is configured to advertise routes regenerated by the VPNv4 address family to
the BGP EVPN peer (NPE2).

After the peer { ipv4-address | group-name } advertise route-reoriginated vpnv4

command is run, NPE1 re-encapsulates the MPLS-encapsulated VPNv4 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

j. Run advertise l2vpn evpn
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

l Run the display bgp evpn all routing-table command on NPE2 to check information
about EVPN routes received from the UPE.
l 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
communicate with the external network through the VPLS network, on which PW
redundancy is configured. Specifically, the PE-AGG connects to PE1 and PE2 through
primary and secondary PWs, respectively.

Figure 3-91 Splicing a VPLS in PW Redundancy Mode with an Anycast VXLAN in an

EVPN Active-Active Scenario
VPLS PE1 Data Center
PW
e
ctiv
Bypass VXLAN
A Anycast
PE-AGG
VTEP
Network Anycast VXLAN
St TOR
an Server
db
y
PW
PE2
To implement the splicing, perform the following configurations:

l Configure VPLS PW redundancy on the PE-AGG, PE1, and PE2.
l Configure the dynamic VXLAN active-active scenario on PE1 and PE2.
l 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
----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-92, 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-92 Carrying multicast services over an EVPN
CE2 Receiver A
BD1
PE2
Multicast EVPN
source
BD1
CE1 PE1 P
BD1
PE3 Receiver B
CE3
Before configuring EVPN E-LAN over mLDP P2MP tunnels, complete the following tasks:
l Configure BD-based EVPN functions over the EVPN.

Procedure
l Perform the following steps on the root node:
a. Run system-view
b. Run evpn vpn-instance vpn-instance-name bd-mode
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
l 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.
NOTE
In a dual-homing scenario, if the dual-homing PEs are configured as root nodes using the
root command, the two PEs can no longer be configured as leaf nodes using the leaf
command.
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 tunnel for
service transmission.
3.2.11 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.
Procedure
l In the user view, run:
refresh bgp evpn { all | peer-address | group group-name } { export | import }
BGP EVPN soft reset is configured.
----End

3.2.12 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.
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.13 Configuring EVPN Reliability

This section describes how to configure Ethernet VPN (EVPN) reliability functions.

Usage Scenario
Reliability Function Scenario
Configuring EVPN On an EVPN where a CE is dual-homed to PEs, after a PE

BGP Peer Status restarts due to a fault or other reasons, traffic may be lost. As
Tracking shown in Figure 3-93, CE1 is dual-homed to PE1 and PE2, and
PE1 is elected as the primary designated forwarder (DF). If PE1
fails, PE2 becomes the primary DF and takes over the broadcast,
unknown unicast, and multicast (BUM) traffic. After PE1
recovers, if PE1 sets up a BGP peer relationship with PE2
before with PE3, PE1 exchanges Ethernet segment (ES) routes
with PE2 and restores to be 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 sets
up a BGP peer relationship with PE3 before with PE2, PE1 and
PE2 both become the primary DFs, in which 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 connecting to
CE1 to track the EVPN BGP peer status.
This configuration allows PE1 to trigger a delay timer for ES
route advertisement after PE1 recovers and PE1's interface
connecting to CE1 goes Up. After the delay timer is triggered,
PE1 tracks the status of its BGP peers PE2 and PE3. If the BGP
peer relationships both go Up within the timer-specified delay,
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 generates and sends
ES routes, PE1 performs DF election based on all the received
ES routes.
NOTE
The delay after which ES routes are sent must be set according to the
BGP peer relationship status. If a BGP peer relationship is not set up
after the delay elapses, two primary or backup DFs exist. In the case of
two primary DFs, duplicate copies of traffic are sent. In the case of two
backup DFs, the traffic is discarded.
Figure 3-93 CE dual-homing networking

PE1
EVPN site
EVPN site
CE2 PE3
CE1
PE2

Setting a Delay After If the PE functioning as the primary DF recovers from a fault,
Which ES Routes Are the traffic on the network side may be lost due to the slow
Advertised connection recovery on the access side. As shown in Figure
3-94, at least one of PE1 and PE2 is configured to work in the
Single-Active redundancy 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. The traffic forwarding path is changed
from CE2->PE3->PE1->CE1 to CE2->PE3->PE2->CE1. After
PE1 recovers, PE1's ESI becomes valid again, and PE1
generates ES routes immediately for DF election. PE1 becomes
the primary DF rapidly, but the connection between CE1 and
PE1 still fails to be set up. As a result, CE1 still sends traffic to
PE2, causing traffic loss.
To resolve this issue, set on PE1's interface connecting to CE1 a
delay after which ES routes are advertised. This configuration
allows PE1 to generate ES routes only after the access-side
network recovers.
Figure 3-94 CE dual-homing networking
CE2 CE2
PE3 PE3
PE1 PE2 PE1 PE2

Primary Backup
DF Backup Primary DF
DF DF
CE1 CE1

Configuring the In CE dual-homing networking, AC sub-interfaces are bound to

Function That the AC EVPN instances. If an ESI is configured on the interface and
Status Influences DF one of the sub-interfaces goes Down due to a fault or some other
Election on a PE reason, the ESI remains valid because the other sub-interface
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 system has received the Auto Discovery (AD)
routes from all the PEs during DF election to determine whether
they are qualified for DF election. If the system has not received
the AD routes from a PE, this PE cannot participate in DF
election.
Configuring a Delay In a scenario where a VLL accesses an EVPN in active-active

for a Public-Network mode, when the backup PE restarts, BUM traffic can still be
Outbound Interface to forwarded due to the unstable status. As a result, extra packets
Go Up occur. 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
expires. Setting a 5-minute delay for an interface to go Up is
recommended.
Before configuring EVPN reliability functions, 3.2.4 Configuring Common EVPN
Functions.
Perform the following steps on a PE:
Procedure
l Configure the function of tracking the BGP EVPN peer status on a PE.
a. Run system-view
The Eth-Trunk interface view is created and displayed.
c. Run es track evpn-peersource-address
The function of tracking the EVPN BGP peer status is configured. To track the
status of multiple EVPN BGP peers, repeat this step.
d. Run commit
l Set a delay after which ES routes are advertised on a PE.
a. Run system-view


The Eth-Trunk interface view is created and displayed.
c. Run timer es-recovery interval
A delay after which ES routes are advertised is set. The recommended value is 30s.
d. Run commit
l Configure the function that the AC status influences DF election on the PE.
a. Run system-view
b. Run evpn
c. Run df-election ac-influence enable
The function that the AC interface status influences DF election is enabled on the
PE.
d. Run commit
l Configure a delay for a public-network outbound interface to go Up.
a. Run system-view
The view of a specified interface is displayed.
c. Run carrier up-hold-time interval
A delay for the interface to go Up is set.
d. Run commit
----End

Run the display current-configuration command to check whether the reliability functions
are configured successfully.
3.2.14 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-95, 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.
Figure 3-95 MAC duplication suppression for EVPN
CE1 PE1 EVPN PE2 CE2
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
l Configure MAC duplication suppression for all EVPN instances.
a. Run system-view

b. Run evpn
The global EVPN configuration view is displayed.

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

l Configure MAC duplication suppression for a specified EVPN instance.

a. Run system-view

b. Run either of the following commands:
n evpn vpn-instance vpn-instance-name
The view of an EVPN instance is displayed.
n evpn vpn-instance vpn-instance-name bd-mode
c. Run mac-duplication
The EVPN instance MAC-duplication view is displayed.

d. Run detect loop-times loop-times detect-cycle detect-cycle-time
Loop detection parameters for MAC duplication suppression are configured,

including the detection period and the threshold for the number of MAC entry flaps
within a detection period.
e. Run retry-cycle retry-times
A hold-off time to unsuppress MAC routes is configured.

f. Run black-hole-dup-mac [ block-source-interface ]
The flapping MAC routes are set to black-hole MAC routes. If the source or
destination MAC address of the forwarded traffic is the same as the MAC address
of the black-hole MAC route, the traffic is discarded.
The block-source-interface parameter enables AC interface blocking. This means

that, if the traffic comes from a local AC interface and the source MAC address of
the traffic is the same as the MAC address of a black-hole MAC route, the AC
interface is blocked. In this way, a loop can be removed quickly.
NOTE
Only BD-EVPN instances support AC interface blocking.

To enable AC interface blocking, first enable MAC flapping-based loop detection in the BD.
g. 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.
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.15 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 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. 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.
l 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.
l 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
l Configure EVPN E-Tree for a BD-EVPN.
a. Run system-view
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
l Configure EVPN E-Tree for a basic EVPN.
a. Run system-view
b. Run evpn vpn-instance vpn-instance-name
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.
3.2.16 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 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 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.
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.17 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-96, 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-96 Splicing a VLL with a Common EVPN E-LAN
l 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.

l 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:
l Configure interfaces and their IP addresses on the UPE, NPE1, NPE2, and NPE3.
l Configure an IGP on the UPE, NPE1, NPE2, and NPE3 to implement route connectivity.
l Configure primary/secondary mode of PW redundancy on the UPE.
l Configure EVPN functions on NPE3.
l Configure basic MPLS functions on NPE1, NPE2, and NPE3.
Procedure
Step 1 Configure basic EVPN functions on NPE1 and NPE2.
1. Configure an EVPN instance.
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 pw-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 encapsulation qinq-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.
8. Run evpn binding vpn-instance vpn-instance-name
The PW VE sub-interface is bound to an EVPN instance.
9. Run commit
----End
Configuration Examples
l Run the display evpn vpn-instance [ verbose ] command to view information about the
EVPN instance-bound PW VE sub-interfaces.
l 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.18 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 communication between different 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-97, 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-97 Splicing a VLL with an MPLS EVPN E-Line
CE1-1 VLL EVPN

C-Vlan=1
NPE1
CE1-3
S-Vlan=100 nnel
S Tu
MPL
MPLS EVPN
MPL
S Tu
NID UPE nnel
NPE3
CE1-2 NPE2
C-Vlan=2

l 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.
l 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:
l Configure interfaces and their IP addresses on NPE1, NPE2, NPE3, and the UPE.
l Configure an IGP on NPE1, NPE2, NPE3, and the UPE to implement Layer 3
reachability.
l Configure PW redundancy in master/slave mode on the UPE.
l Configuring EVPN VPWS over MPLS Functions on NPE1, NPE2, and NPE3.
l Configure basic MPLS LDP functions on NPE1, NPE2, NPE3, and the UPE.
l 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 pw-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.

NOTE
Before running this command, ensure that the Layer 2 interface on which the PW-VE sub-interface is to
be created does not have the port link-type dot1q-tunnel command configuration. If this configuration
exists, run the undo port link-type command to delete the configuration.
In addition to a Layer 2 sub-interface, an Ethernet main interface, Layer 3 sub-interface, or Eth-Trunk
interface can also function as an AC interface.
Step 8 Configure an encapsulation type for the PW-VE sub-interface.

l 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.
n Specify local-switch so that the sub-interface for QinQ VLAN tag termination
supports local switching.
n Specify rt-protocol so that the sub-interface for QinQ VLAN tag termination
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 sub-interface for QinQ
VLAN tag termination.
After you specify rt-protocol, the sub-interface terminates double-tagged packets,
and both inner and outer tags must be specific VLAN IDs.
l 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 sub-interface for dot1q VLAN tag termination
supports routing protocols.
b. Run either of the following commands:
n To configure a sub-interface for dot1q VLAN tag termination, run the dot1q
termination vid low-pe-vid [ to high-pe-vid ] [ vlan-group group-id ]
command.
n To configure a sub-interface for dot1q VLAN tag termination 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.
NOTE
n If you do not configure a matching policy, the sub-interface for dot1q VLAN tag
termination terminates the VLAN tags of packets carrying the specified VLAN ID. If
you configure a matching policy, the sub-interface for dot1q VLAN tag termination
terminates the VLAN tags of packets carrying the specified VLAN ID+802.1p value/
DSCP value/EthType.
n 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.19 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-98, 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-98 Splicing a VXLAN EVPN with a VPLS
PE1 Data Center
Server
PE3 TOR
MPLS VXLAN
VPLS
Enterprise
campus
PE2
Before splicing a VXLAN EVPN with a VPLS, complete the following tasks:
l 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.
l Configure an IGP on PE3, PE1, PE2, and the TOR to implement IP connectivity on the
backbone network.
l Enable MPLS on PE3, PE1, and PE2. Configure MPLS LDP LSPs between PE3 and
PE1 and between PE3 and PE2.

3.2.19.1 Creating VSIs and Configuring PW Connections

Before enabling interconnection between PE1, PE2, and PE3 on an MPLS VPLS network,
you must create VSIs and configure PWs on them.
Procedure
l 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 [ negotiation-vc-id vc-id ] pw pw-name
PE3 is specified as the VSI peer.
f. Run commit
l 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
e. Run peer [ 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 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.19.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
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).

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

Step 11 Run commit

----End
3.2.19.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
l Configure PE1 and PE2.
a. Run bridge-domain bd-id
The BD view is displayed.
b. Run vxlan vni vni-id split-horizon-mode
A VNI is created and associated with the BD, and forwarding in split horizon mode
is enabled.
c. Run evpn binding vpn-instance vpn-instance-name [ bd-tag bd-tag ]
A specified EVPN instance is bound to the BD. By specifying different bd-tag
values, you can bind multiple BDs with different VLANs to the same EVPN
instance and isolate services in the BDs.
d. Run l2 binding vsi vsi-name
A specified VSI is bound to the BD.
NOTE
On a node that splices VXLAN and VPLS, the BD-bound VSI does not support pw-tag, and the
PW configured in the VSI must be in Raw mode rather than in Tag mode.
e. Run quit
f. Run commit
NOTE
l The BD bound to an EVPN instance and a VSI do not support AC interface access.
l 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.
l Bind the AC interface to the BD on PE3.
a. Run system-view
c. Run l2 binding vsi vsi-name [ pw-tag pw-tag-value ]
A specified VSI is bound to the BD.

d. Run quit
Exit from the BD view.
e. Run interface interface-type interface-number.subnum mode l2
f. Run bridge-domain bd-id
The Layer 2 sub-interface is bound to the BD.
The Layer 2 sub-interface and the vsi are bound to the same BD.
g. Run quit
Exit from the sub-interface view.
h. Run commit
----End
3.2.19.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-99, 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-99 Splicing VXLAN and VPLS
PE1
CE1 TOR CE2

MPLS
VXLAN VPLS
PE3
PE2
Fault Point Path before the fault occurs

Path after the fault occurs
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:
l Run the discriminator local discr-value command to set the local discriminator.
l Run the discriminator remote discr-value command to set the remote discriminator.
NOTE
The local discriminator on one end must be the remote discriminator on the other end.
Step 6 Run commit

If the status of a PW is Down, the BFD session can be established but cannot go Up.
NOTE
l You must simultaneously configure or cancel BFD for PW on both PEs. Otherwise, the PW status on
both ends may be inconsistent.
l 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.19.6 Verifying the Configuration of Splicing a VXLAN EVPN with a VPLS

After configuring splicing a VXLAN EVPN with a VPLS, check the configurations.
Prerequisites
All configurations of splicing a VXLAN EVPN with a VPLS have been completed.
Procedure
l Check the VPLS configurations.
– Run the display vsi [ name vsi-name ] [ verbose ] command to check VSI
information of the VPLS.
– 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.
l 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 check
– 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.20 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.
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-100 MPLS EVPN E-LAN Option B networking

AS100 AS200
CE1 CE2
IBGP EVPN EBGP EVPN IBGP EVPN
MPLS MPLS
PE1 ASBR1 ASBR2 PE2
Before configuring MPLS EVPN E-LAN Option B, complete the following tasks:
l Configure an IGP for the MPLS backbone network of each AS to ensure IP connectivity
of the backbone network in each AS.
l 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.
l Configure Configuring an EVPN Instance on the PE connected to the CE.
l Configure Configuring an EVPN Source Address on the PE connected to the CE.

l Configure Binding an Interface to an EVPN Instance on the PE connected to the CE.

l Configure Configuring an ESI on the PE connected to the CE.
3.2.20.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.
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.20.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
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.20.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 information about 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
----End
3.2.20.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.
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.20.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.
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.


AS100 AS200
PE1 ASBR1 ASBR3 PE3
CE1
CE2
MPLS MPLS
PE2 ASBR2 ASBR4 PE4

Faulty Switchback path
Point
Backup path
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.20.6 (Optional) Configuring BGP-EVPN Route Reflection on an ASBR

In a scenario in which the backbone network spans two ASs, ASBRs need to advertise EVPN
routes through MP-EBGP. 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 PEs.
Configuring an ASBR as an RR will burden the ASBR. Therefore, it is required 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.

CE1 PE1
AS100 AS200
PE3 CE3
ASBR2
CE2 PE2
ASBR1
(RR)
Procedure
The ASBR1 system view is displayed.
Step 4 Run peer peer-ipv4-address reflect-client
The ASBR is configured as an RR, and the PE is configured as a client. If you need to
configure multiple PEs as clients, repeatedly run this command.
Step 5 Run peer peer-ipv4-address next-hop-local
The ASBR is configured to change the next hop address of a route to the device's own IP
address before the device advertises the route to an IBGP peer.
Step 6 (Optional)Run rr-filter extended-list-number
A reflection policy is configured for the RR. Only IBGP routes whose VPN targets meet the
matching rules can be reflected. This allows load balancing among RRs.
Step 7 (Optional) Run rr-filter extended-list-number
A reflection policy is configured for the RR.
Step 8 (Optional) Run reflect change-path-attribute
You can enable the RR to modify BGP route attributes using an export policy.
NOTE
After the reflect change-path-attribute command is run on the RR

l Under BGP-EVPN address family view, peer route-policy export command takes precedence over
the peer next-hop-invariable command.
l Under BGP-EVPN address family view, peer next-hop-local command takes precedence over the
peer route-policy export command.
Step 9 Run commit

----End

3.2.20.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
l Run the display bgp evpn all peer command on the PE or ASBR to check the status of
all BGP peer relationships.
l Run the display bgp evpn all routing-table command on the PE or ASBR to check
information about EVPN routes.
----End
3.2.21 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
L3VPN HVPN.
Figure 3-101 shows the basic architecture of an HVPN that consists of the following device
roles:
l 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.
l 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.
l NPE: An NPE is a network provider-end PE that is connected to SPEs and located at the
network side.
Figure 3-101 Basic EVPN L3VPN HVPN architecture

CE1 UPE1
Site 1 SPE NPE CE3
Site 3
Access Aggregation
Site 2
CE2 UPE2

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:
l 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.
l 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:
l 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
receiving specific routes (EVPN routes) from the UPEs, the SPE encapsulates these
routes into VPNv4 routes and advertises them to the NPE.
l 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.
3.2.21.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 on the UPEs and NPEs.

NOTE
According to relevant standards, the VPN instance status obtained from an NMS is Up only if at
least one interface bound to the VPN instance is Up. On an HoVPN, VPN instances on SPEs are
not bound to interfaces. As a result, the VPN instance status obtained from an NMS is always
Down. To solve this problem, run the transit-vpn command in the VPN instance view or VPN
instance IPv4 address family view of an SPE. Then, the VPN instance status obtained from the
NMS is always Up, regardless of whether the VPN instance is bound to interfaces.
2. Configure BGP-EVPN peer relationships between UPEs and SPEs and between SPEs
and NPEs. For details, see 3.2.4.5 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.
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.
l 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 ] }
A default IPv4 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
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 VPN instance routing table.
f. Run advertise l2vpn evpn
The SPE is enabled to advertise IP prefix routes.
g. Run quit
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

l Configure the SPE to advertise summarized routes to the UPE.

a. Run system-view
c. Run ipv4-family vpn-instance vpn-instance-name
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 ] *
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.
i. Run quit
j. Run quit
k. Run commit
Step 2 Configure route regeneration or route next hop modification on the SPE.
l Configure route regeneration.
a. Run system-view
c. Run l2vpn-family evpn
d. Run peer { ipv4-address | group-name } import reoriginate
The SPE is enabled to add the regeneration flag to the routes received from the
UPE.
e. Run peer { ipv4-address | group-name } advertise route-reoriginated evpn ip
The SPE is enabled to advertise routes regenerated by the EVPN address family to
the BGP VPNv4 peer (NPE).
f. Run commit

l Configure route next hop modification.

a. Run system-view
c. Run l2vpn-family evpn
d. Run peer { ipv4-address | group-name } reflect-client
The UPE is specified as the BGP-EVPN RR to reflect BGP EVPN routes.
e. 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.
f. Run commit
----End
3.2.21.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
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. This
4. Configure SPEs as RRs, and specify UPEs and NPEs are RR clients. For details, see
Procedure.
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.
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.21.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:
l Create VPN instances on UPEs and SPEs and bind the VPN instances to AC interfaces
on the UPEs.
NOTE
l Configure VPN instances and bind the VPN instances to AC interfaces on NPEs.
l Configure the default static VPN routes on the SPEs. For details, see Creating IPv4
Static Routes.
l 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 VPN. For more information, see Establishing MP-IBGP Peer Relationships
Between PEs.
l Configure BGP-EVPN peer relationships between UPEs and SPEs. For details, see
3.2.4.5 Configuring a BGP EVPN Peer Relationship.
l Configure SPEs to advertise only default or summarized routes to UPEs. For details, see
3.2.21.1 Configuring an EVPN L3VPN HoVPN.
l Configure routing protocols for NPEs and UPEs to exchange routes with CEs. This
l 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
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
Step 7 Run peer { ipv4-address | group-name } advertise route-reoriginated evpn ip
The SPE is configured to re-encapsulate the EVPN routes received from the UPE into BGP
VPNv4 routes and then send them to the NPE.
Step 8 Run commit
----End
3.2.21.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:
l Configure VPN instances on SPEs and NPEs and bind the VPN instances to the NPE
interfaces that connect to CEs. For details, see
NOTE
l Configure VPN instances and bind the VPN instances to AC interfaces on UPEs.
l Configure BGP-EVPN peer relationships between SPEs and NPEs. For details, see
3.2.4.5 Configuring a BGP EVPN Peer Relationship.
l 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.
l Configure routing protocols for NPEs and UPEs to exchange routes with CEs. This
l Configure SPEs to advertise only default or summarized routes to UPEs.
l Configure SPEs to advertise re-encapsulated EVPN routes to NPEs. For details, see
Procedure.
Perform the following steps on each SPE.
Procedure
Step 3 Run ipv4-family vpnv4
Step 4 Run peer { ipv4-address | group-name } import reoriginate
The SPE is enabled to add the regeneration flag to the routes received from the UPE.
Step 5 Run quit

Step 7 Run peer { ipv4-address | group-name } advertise route-reoriginated vpnv4

The SPE is configured to re-encapsulate the BGP VPNv4 routes received from the UPE into
EVPN routes and then send them to the NPE.
Step 8 Run commit
----End
3.2.21.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
l Run the display ip routing-table vpn-instance command on a UPE or an NPE to check
the VPN routing table for default or specific routes sent by the remote end.
l 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.22 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-102 IGMP snooping over EVPN MPLS networking
CE2 Receiver A
BD1
PE2
Multicast
source
BD1 EVPN
Network
CE1 PE1
BD1
PE3 Receiver B
CE3
Before configuring IGMP snooping over EVPN MPLS, complete the following task:
l Configure BD-based EVPN functions.

l Configure EVPN E-LAN over mLDP P2MP tunnels.
3.2.22.1 Configuring IGMP Snooping and Proxy

To implement IGMP snooping over EVPN MPLS, you must configure basic IGMP snooping
and proxy functions.
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.

l If number is set to 1, only IGMPv1 messages can be processed.

l If number is set to 2, both IGMPv1 and IGMPv2 messages can be processed.
l 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.22.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:
l 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/
Leave Synch routes in a BD.
l 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/Leave Synch routes in a BD.
l 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/Leave
Synch routes in a BD, associate the EVI-RT extended community attributes of IGMP
Join/Leave Synch routes with the BD, and enable the DF status ignoring function on
non-DF nodes.
l 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/Leave Synch routes in a BD, associate the EVI-RT
extended community attributes of IGMP Join/Leave Synch routes with the BD, and
enable the DF status ignoring function on non-DF nodes.
Procedure
l 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/Leave Synch
routes is enabled in the BD.

d. (Optional) Run evi vpn-target

The EVI-RT extended community attributes of IGMP Join/Leave Synch routes are
associated with the BD.
e. Run commit
l 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
f. Run commit
l 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
m. Run commit
----End
3.2.22.3 Verifying the Configuration

After configuring IGMP snooping over EVPN MPLS, verify the configuration.
Prerequisites
IGMP snooping over EVPN MPLS has been configured.
Procedure
l Run the display bgp evpn { vpn-instance evpn-name | route-distinguisher route-
distinguisher } routing-table { smet-route | join-route | leave-route } [ prefix ] or
display bgp evpn all routing-table [ peer peer-address advertised-routes ] { smet-
route | join-route | leave-route } [ prefix ] command to check information about BGP
EVPN SMET or IGMP Join/Leave routes.
----End
3.2.23 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:
l For enterprises, leased fibers or leased lines are costly.
l 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

Interconnection (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 communicate with each other.
Figure 3-103 Configuring DCI functions

DCI-PE1 DCI-PE2
Data center A GW1 GW2 Data center B
Device 1 Device 2 Device 3 Device 4
Before configuring DCI functions, configure MPLS tunnels over the DCI backbone network.
3.2.23.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-104, 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.

Figure 3-104 Configuring a DCI Scenario with an E2E VXLAN EVPN Deployed on a
Gateway

DCI-PE1 DCI-PE2
Data center A VXLAN Tunnel Data center B

GW1 GW2
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.23.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-105, VXLAN tunnels are established within data centers to

allow intra-DC VM communication. To allow inter-data center VM communication, BGP/

MPLS IP VPN functions are deployed on the DCI backbone network, and a Layer 3 Ethernet
sub-interface is configured on each DCI-PE, added to the same VLAN, and bound to the VPN
instance of each DCI-PE.
Figure 3-105 Configuring a DCI Scenario with a VLAN Layer 3 Sub-interface Accessing a
Common L3VPN
Procedure
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
----End

3.2.23.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. VPNv4 is used 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-106, data center gateway devices GW1 and GW2 are connected to the DCI
backbone network. To allow inter-data center VM communication, BGP/MPLS IP 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-106 Configuring a DCI scenario with a VXLAN EVPN L3VPN accessing a
common L3VPN

DCI-PE1 DCI-PE2
P
VXLAN Tunnel
VXLAN Tunnel
Procedure
Step 1 Configure a VXLAN tunnel between each DCI PE and the corresponding GW. For
configuration details, see Configuring VXLAN.

Step 3 Configure the DCI-PE to send the routes that are regenerated in the EVPN address family to a
VPNv4 peer.
1. Run bgp as-number
2. Run l2vpn-family evpn
3. Run peer { ipv4-address | group-name } import reoriginate
The DCI-PE is configured to add the regeneration flag to the routes to be received from a
BGP EVPN peer.
4. Run quit
6. Run peer { ipv4-address | group-name } advertise route-reoriginated evpn { mac-ip |
ip }
The DCI-PE is configured to send the routes that are regenerated in the EVPN address
family to a VPNv4 peer.
After the peer { ipv4-address | group-name } advertise route-reoriginated evpn { mac-
ip | ip } 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 routes that carry the MPLS encapsulation attribute to the VPNv4 peer
on the DCI backbone network.
Step 4 Configure the DCI-PE to send the routes that are regenerated in the VPNv4 address family to
a BGP EVPN peer.
The DCI-PE is configured to add the regeneration flag to the routes received from a
VPNv4 peer.
4. Run quit
6. Run peer { ipv4-address | group-name } advertise route-reoriginated vpnv4
The DCI-PE is configured to send the routes that are regenerated in the VPNv4 address
family to a BGP EVPN peer.

After the peer { ipv4-address | group-name } advertise route-reoriginated vpnv4

command is run and VPNv4 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.23.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:
l Centralized deployment mode: As shown in Figure 3-107, the DC gateway and the PE
on the DCI backbone network are the same device (DCI-PE-GW). Specifically, the PE
also functions as the DC gateway to access the DC network.
Figure 3-107 Configuring a DCI scenario with a VLAN base accessing an MPLS EVPN
IRB (The PE functions as a gateway)
DCI-PE1-GW1 DCI-PE2-GW2
Device1 Device2
VSwitch VSwitch
VMa1 VMa2 VMb1 VMb2
Data Center A Data Center B

l Distributed deployment mode: As shown in Figure 3-108, 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-108 Configuring a DCI scenario with a VLAN base accessing an MPLS EVPN
IRB (PE and gateway are separately deployed)
Before configuring a DCI scenario with a VLAN base accessing an MPLS EVPN IRB, ensure
that routes on the IPv4 network are reachable.
Procedure
Step 1 Configure BGP EVPN peers.
NOTE
If a BGP RR needs to be configured on the network, establish BGP EVPN peer relationships between all
the PEs and the RR.

The remote PE is specified as the BGP peer.

3. (Optional) Run peer ipv4-address connect-interface interface-type interface-number
[ ipv4-source-address ]
NOTE
When loopback interfaces are used to establish a BGP connection, it is recommended that the peer
connect-interface command be run on both ends to ensure correct connection. If this command is
run on only one end, the BGP connection may fail to be established.

4. Run ipv4-family vpn-instance vpn-instance-name

5. Run import-route { direct | isis process-id | ospf process-id | rip process-id | static }
[ med med | route-policy route-policy-name ] *
The device is enabled to import non-BGP routing protocol routes into the BGP-VPN
instance IPv4 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.
6. Run advertise l2vpn evpn
configuration allows the BGP device to advertise both host IP routes and routes of the
network segment where the host resides.
7. Run quit


9. Run peer { ipv4-address | group-name } enable
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
The BGP device is enabled to advertise IRB 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
10. Run quit
Step 3 Configure access-side interfaces.

l If you want the network to carry both Layer 2 and Layer 3 services, perform the
following configurations:
a. Run the bridge-domain bd-id command to enter the BD view.
b. Run the evpn binding vpn-instance vpn-instance-name [ bd-tag bd-tag ]
command to bind a specified EVPN instance to the BD. By specifying different bd-
tag values, you can bind multiple BDs with different VLANs to the same EVPN
instance and isolate services in the BDs..
c. Run the quit command to exit from the BD view.
d. Run the interface interface-type interface-number.subnum mode l2 command to
create a Layer 2 sub-interface and enter the Layer 2 sub-interface view.
e. Run the encapsulation { dot1q [ vid low-pe-vid [ to high-pe-vid ] ] | untag | qinq
[ vid pe-vid ce-vid { low-ce-vid [ to high-ce-vid ] | default } ] } command to
configure a traffic encapsulation type so that different interfaces can access different
data packets.
f. Run the rewrite pop { single | double } command to remove VLAN tags of
received packets.
g. Run the bridge-domain bd-id command to add the Layer 2 sub-interface to the BD
so that the sub-interface can transmit data packets through this BD.
h. Run the quit command to exit from the sub-interface view and return to the system
view.
i. Run the interface vbdif bd-id command to create a VBDIF interface enter the
VBDIF interface view.
j. Run the ip binding vpn-instance vpn-instance-name command to bind the VBDIF
interface to the VPN instance.
k. Run ip address ip-address { mask | mask-length } [ sub ]
An IP address is configured for the VBDIF interface to implement Layer 3
interworking.

l. (Optional) Run the mac-address mac-address command to specify a MAC address

for the VBDIF interface.
m. Run the arp distribute-gateway enable command to enable the distributed
gateway function.
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.
n. Run the arp collect host enable command to collect host information.
o. Run the quit command to exit from the interface view and return to the system
view.
l If you want the network to carry only Layer 2 services, perform the following
configurations:
a. Run the bridge-domain bd-id command to enter the BD view.
b. Run the evpn binding vpn-instance vpn-instance-name [ bd-tag bd-tag ]
command to bind a specified EVPN instance to the BD. By specifying different bd-
tag values, you can bind multiple BDs with different VLANs to the same EVPN
instance and isolate services in the BDs..
c. Run the quit command to exit from the BD view.
d. Run the interface interface-type interface-number.subnum mode l2 command to
create a Layer 2 sub-interface and enter the Layer 2 sub-interface view.
e. Run the encapsulation { dot1q [ vid low-pe-vid [ to high-pe-vid ] ] | untag | qinq
[ vid pe-vid ce-vid { low-ce-vid [ to high-ce-vid ] | default } ] } command to
configure a traffic encapsulation type so that different interfaces can access different
data packets.
f. Run the rewrite pop { single | double } command to remove VLAN tags of
received packets.
g. Run the bridge-domain bd-id command to add the Layer 2 sub-interface to the BD
so that the sub-interface can transmit data packets through this BD.
h. Run the quit command to exit from the interface view and return to the system
view.
l If you want the network to carry only Layer 3 services, see Binding Interfaces to a VPN
Instance.
Step 4 Configure an EVPN instance in BD mode.
1. Run evpn vpn-instance vpn-instance-name bd-mode
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.
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
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
through the RR to reduce the link cost. The undo reflect 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
3.2.23.5 Configuring a DCI Scenario with a VXLAN EVPN Accessing an MPLS

EVPN IRB
The underlay VXLAN Layer 3 access to DCI uses different cloud management platforms, and
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-109, 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-109 Configuring a DCI Scenario with a VXLAN EVPN Accessing an MPLS EVPN
IRB

DCI-PE1 DCI-PE2
VXLAN Tunnel
VXLAN Tunnel
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 ]

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.
1. Run system-view


3. (Optional) Run router-id ipv4-address
A BGP router ID is configured.

The remote DCI-PE is specified as the BGP peer.


NOTE
When loopback interfaces are used to establish a BGP connection, it is recommended that the peer
connect-interface command be run on both ends to ensure correct connection. If this command is
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 following
configurations:
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 following
configurations:
evpn { mac-ip | ip } 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 command to
configure the device to advertise IRB routes.
– If you want the network to carry both Layer 2 and Layer 3 services, perform the
following configurations:
evpn { mac | mac-ip | ip } 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 command to
configure the device to advertise IRB routes.
Step 5 Run commit
----End
3.2.23.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
l Run the display ip vpn-instance vpn-instance-name command to check brief
information about a specified VPN instance.
l 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.
l Run the display ip vpn-instance [ vpn-instance-name ] interface command to view
information about the interfaces bound to a specified VPN instance.
l Run the display evpn vpn-instance [ vpn-instance-name ] command to check EVPN
instance information.
l Run the display vxlan tunnel [ tunnel-id ] [ verbose ] command to check VXLAN
tunnel information.
l 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.
l Run the display bgp evpn peer [ [ ipv4-address ] verbose ] command to check
information about BGP EVPN peers.
vpn-instance-name } routing-table mac-route command to check MAC route
information.
l Run the display bgp vpnv4 { all | route-distinguisher route-distinguisher | vpn-
instance vpn-instance-name } routing-table command to check BGP VPNv4 route
information.
----End
3.2.24 Configuration Examples for EVPN

This section provides EVPN configuration examples.
3.2.24.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-110, 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.

NOTE
Interfaces 1 through 3 in this example are 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.

Loopback 1
1.1.1.1/32
PE1
interface2
interface1
10.1.1.1/24
Loopback 1 Loopback 1
3.3.3.3/32 4.4.4.4/32
interface1 10.1.1.2/24 10.3.1.2/24 interface1 CE2
10.2.1.2/24 10.3.1.1/24
CE1 RR PE3
Site1 Backbone Site2
interface2 Network
interface1 10.2.1.1/24
PE2
Loopback 1
2.2.2.2/32
Precautions
When configuring a VPN to access a common EVPN E-LAN, note the following:
l 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.
l 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
l EVPN instance name (evpna)
l 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-110. For
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
# 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 routes to Loopback1 of each other.
[~PE1] display ospf peer


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
3.3.3.3/32 OSPF 10 1 D 10.1.1.2
4.4.4.4/32 OSPF 10 2 D 10.1.1.2
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 OSPF 10 2 D 10.1.1.2
10.3.1.0/24 OSPF 10 2 D 10.1.1.2
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 that Status is
Operational. Run the display mpls ldp lsp command. The command output shows LDP LSP
configurations.
[~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
--------------------------------------------------------------------------
3.3.3.3:0 Operational DU Passive 0000:00:00 5/4
--------------------------------------------------------------------------
TOTAL: 1 Session(s) Found.
[~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

# 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] 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
[~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 0
[*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
After the configuration is complete, run the display bgp evpn peer command on the RR. The
command output shows that BGP peer relationships have been established between the PEs
and RR and are in the Established state.
[~RR] display bgp evpn peer


PrefRcv
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

[*CE1-GigabitEthernet2/0/0] commit
[~CE1-GigabitEthernet2/0/0] quit
NOTE
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.
[*CE2-GigabitEthernet1/0/0] commit
[~CE2-GigabitEthernet1/0/0] quit
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
[*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
0.0.0.0/0, ESI:0138.ba56.b790.0201.2100

From: 3.3.3.3 (3.3.3.3)
0.0.0.0/0, ESI:0138.ba56.b790.0201.2100
Remote-Cross route
From: 3.3.3.3 (3.3.3.3)


0.0.0.0/0, ESI:0138.ba56.b790.0201.2100

Remote-Cross route
From: 3.3.3.3 (3.3.3.3)
select, pre 255, not preferred for router ID
0.0.0.0/0, ESI: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
#
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 LoopBack0
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
#
lacp e-trunk system-id 00e0-fc00-0000
lacp e-trunk priority 1
#
#
bfd
#
mpls lsr-id 2.2.2.2
#
mpls
#
mpls ldp
#
ipv4-family
#
e-trunk 1
priority 20
#
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 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
#
#
mpls lsr-id 4.4.4.4
#
mpls
#
mpls ldp
#
ipv4-family
#
undo shutdown
ip address 10.3.1.2 255.255.255.0
mpls
mpls ldp
#
undo shutdown
#
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
l 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 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 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.24.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.
On the network shown in Figure 3-111, 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:
l Function that the AC status influences DF election
l EVPN BGP peer status tracking
l Delay after which ES routes are advertised
l Per-ES AD route division based on RTs


NOTE
Interface1, interface2, and interface3 stand for Ethernet1/0/0, Ethernet2/0/0, and Ethernet3/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.
Loopback 1
1.1.1.1/32
PE1
interface2
interface1
10.1.1.1/24
3.3.3.3/32 4.4.4.4/32
10.2.1.2/24 10.3.1.1/24
CE1 RR PE3
interface2 Network
PE2
Loopback 1
2.2.2.2/32
Precautions
When configuring Eth-Trunk sub-interfaces to access a common EVPN E-LAN in active-
active mode, note the following:
l 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.
l Using the local loopback interface address of a PE as the source address is
recommended.
backbone network.
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 configure the
PEs as RR clients.


10. Configure VLAN-based DF election and the function that the AC status influences DF
election.
11. Configure EVPN BGP peer status tracking and set a delay after which ES routes are
advertised.
12. Associate BFD sessions with the AC interfaces on PE1 and PE2 to accelerate DF
switching during an AC link fault.
Data Preparation
l EVPN instance name (evpna and evpnb)
l 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
is used as the IGP 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 completing the configurations, PE1, PE2, and PE3 can establish OSPF neighbor
that the RR and PEs have learned the routes to Loopback1 of each other.

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

2.2.2.2/32 OSPF 10 2 D 10.1.1.2
3.3.3.3/32 OSPF 10 1 D 10.1.1.2
4.4.4.4/32 OSPF 10 2 D 10.1.1.2
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 OSPF 10 2 D 10.1.1.2
10.3.1.0/24 OSPF 10 2 D 10.1.1.2
backbone network.
# 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.
configurations.

An asterisk (*) before a session means the session is being deleted.
--------------------------------------------------------------------------
--------------------------------------------------------------------------

--------------------------------------------------------------------------
LDP LSP Information

-------------------------------------------------------------------------------
Flag after Out IF: (I) - RLFA Iterated LSP, (I*) - Normal and RLFA Iterated LSP
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
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.
[*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.
[*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 the PEs as
RR clients.
# Configure PE1.
[~PE1] bgp 100
[*PE1-bgp] quit
[*PE1] commit
# Configure PE2.
[~PE2] bgp 100

[*PE2-bgp] quit
[*PE2] commit
# Configure PE3.
[~PE3] bgp 100
[*PE3-bgp] quit
[*PE3] commit
# Configure the RR.

[~RR] bgp 100
[*RR-bgp] quit
[*RR] commit
After completing the configurations, run the display bgp evpn peer command on the RR.
The command output shows that BGP peer relationships have been established between the
PEs and RR and are in the Established state.


PrefRcv
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
[*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
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 Configure EVPN BGP peer status tracking and set a delay after which ES routes are
advertised on PE1 and PE2.
# Configure PE1.
[*PE1-Eth-Trunk10] es track evpn-peer 3.3.3.3
[*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] commit
# Configure PE2.
[~PE2] bfd
[*PE2-bfd] quit
[*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
*>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
df-election ac-influence enable
#
#
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 bfd1
es track evpn-peer 3.3.3.3
timer es-recovery 30
port ignore-lacp-state enable
#
interface Eth-Trunk10.1
vlan-type dot1q 1
#
vlan-type dot1q 2
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
#
#
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
#
#
#
bfd
#
mpls lsr-id 2.2.2.2
#
mpls
#
mpls ldp
#
e-trunk 1
#
e-trunk 1
esi 0000.1111.2222.1111.1111
es track bfd bfd1
timer es-recovery 30
port ignore-lacp-state enable

#
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
#
#
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
#
#
#
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
#
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
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.24.3 Example for Configuring Eth-Trunk Sub-interfaces to Access a BD EVPN

IRB in Active-Active Mode (Carrying Both Layer 2 and Layer 3 Services)
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-112, 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-112 Configuring eth-trunk sub-interfaces to access a BD EVPN IRB in active-active

mode (carrying both layer 2 and layer 3 services)
NOTE
In this example, interface1, interface2, and interface3 stand for GigabitEthernet 1/0/0, GigabitEthernet 2/0/0,
and GigabitEthernet 3/0/0, respectively.
Loopback 1
1.1.1.1/32
PE1
interface2
interface1
10.1.1.1/24
1 Loopback 1 Loopback 1
ce 3.3.3.3/32 4.4.4.4/32
r fa
e
int interface1
interface1
10.1.1.2/24
10.3.1.2/24 interface1
CE1 interface2 CE2
10.2.1.2/24
int 10.3.1.1/24 PE3
er RR
fa
ce
Site1 2 Backbone Site2
interface2 Network
10.2.1.1/24
interface1
PE2
Loopback 1
2.2.2.2/32

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:
l 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 target list of a site shares
VPN targets with the export VPN target lists of the other sites.
l Using the local loopback interface address of a PE as the source address is
recommended.
backbone network.
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 configure the
PEs as RR clients.
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
l EVPN instance named evpna and VPN instance named vpnb
l 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
configuration details, see "Configuration Files" in this section.
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 neighbor
that the RR and PEs have learned the routes to Loopback 1 of each other.

Neighbors

DR: 10.1.1.1 BDR: 10.1.1.2 MTU: 0
------------------------------------------------------------------------------

2.2.2.2/32 OSPF 10 2 D 10.1.1.2

3.3.3.3/32 OSPF 10 1 D 10.1.1.2
4.4.4.4/32 OSPF 10 2 D 10.1.1.2
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 OSPF 10 2 D 10.1.1.2
10.3.1.0/24 OSPF 10 2 D 10.1.1.2
backbone network.
# Configure PE1.
[*PE1] mpls
[*PE1-mpls] quit
[*PE1] mpls ldp
# Configure PE2.
[*PE2] mpls
[*PE2-mpls] quit
[*PE2] mpls ldp
# Configure the RR.

[*RR] mpls
[*RR-mpls] quit
[*RR] mpls ldp
[*RR-mpls-ldp] quit

# Configure PE3.
[*PE3] mpls
[*PE3-mpls] quit
[*PE3] mpls ldp
After the configurations are complete, LDP sessions are established between the PEs and RR.
configurations.

--------------------------------------------------------------------------
--------------------------------------------------------------------------
--------------------------------------------------------------------------
LDP LSP Information

-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
1.1.1.1/32 3/NULL 3.3.3.3 127.0.0.1 Loop1
*1.1.1.1/32 Liberal/32828 DS/3.3.3.3
2.2.2.2/32 NULL/32829 - 10.1.1.2 GE2/0/0
2.2.2.2/32 32829/32829 3.3.3.3 10.1.1.2 GE2/0/0
3.3.3.3/32 NULL/3 - 10.1.1.2 GE2/0/0
3.3.3.3/32 32828/3 3.3.3.3 10.1.1.2 GE2/0/0
4.4.4.4/32 NULL/32830 - 10.1.1.2 GE2/0/0
4.4.4.4/32 32830/32830 3.3.3.3 10.1.1.2 GE2/0/0
-------------------------------------------------------------------------------

# 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.
[*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.
[*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] arp collect host 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 the PEs as
RR clients.
# Configure PE1.
[~PE1] bgp 100
[*PE1-bgp-af-evpn] peer 3.3.3.3 advertise irb
[*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.


PrefRcv
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

that EVPN routes are sent from the remote PEs (PE1 and PE2).


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

*> 0:192.166.1.0:24 0.0.0.0
*>i 0:192.167.1.0:24 2.2.2.2
*>i 0:192.168.1.0:24 1.1.1.1
*> 0:192.166.1.0:24 0.0.0.0
*>i 0:192.167.1.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
vlan-extend private enable
vlan-extend redirect enable
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
arp collect host 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
#
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
peer 3.3.3.3 advertise irb
#
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
#
e-trunk 1
#
interface Vbdif10
ip address 192.167.1.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
#
mpls lsr-id 4.4.4.4
#
mpls
#
bridge-domain 10
#

mpls ldp
#
interface Vbdif10
ip address 192.166.1.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
#
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
#
#
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.24.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-113, 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-113 Networking of EVPN VPWS over MPLS

NOTE
In this example, interface 1, interface 2, and interface 3 stand for GE 1/0/0, GE 2/0/0, and GE 3/0/0,
respectively.
Loopback 1
1.1.1.1/32
PE1
interface2
interface1
10.1.1.1/24
1 Loopback 1 Loopback 1
ce 3.3.3.3/32 4.4.4.4/32
erfa
int interface1
interface1
10.1.1.2/24
Site1 interface2 Site2
10.2.1.2/24
int 10.3.1.1/24 PE3
er RR
fa
ce
2 Backbone
interface2 Network
10.2.1.1/24
interface1
PE2
Loopback 1
2.2.2.2/32

backbone network.
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 configure the
PEs as RR clients.
5. Configure the FRR function on PEs.
Data Preparation
l EVPN instance name: evrf1
l RDs (100:1, 100:2, and 100:3) and RT (1:1) of the EVPN instance
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
backbone network.
# Configure PE1.
[*PE1] mpls
[*PE1-mpls] quit
[*PE1] mpls ldp
# Configure PE2.
[*PE2] mpls
[*PE2-mpls] quit
[*PE2] mpls ldp
# Configure the RR.

[*RR] mpls
[*RR-mpls] quit
[*RR] mpls ldp
[*RR-mpls-ldp] quit
# 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] 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 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] interface gigabitethernet 1/0/0.1 mode l2
[*PE1-GigabitEthernet 1/0/0] encapsulation dot1q vid 1
[*PE1-GigabitEthernet 1/0/0] evpl instance 1
[*PE1-GigabitEthernet 1/0/0] quit
[*PE1] commit
# Configure PE2.
[*PE2] commit
# Configure PE3.
[*PE2] commit
Step 5 Configure EVPN BGP peer relationships between PEs and the RR, and configure the PEs as
RR clients.
# Configure PE1.
[~PE1] bgp 100
[*PE1-bgp] quit
[*PE1] commit
# Configure PE2.
[~PE2] bgp 100


[*PE2-bgp] quit
[*PE2] commit
# Configure PE3.
[~PE3] bgp 100
[*PE3-bgp] quit
[*PE3] commit
# Configure the RR.

[~RR] bgp 100
[*RR-bgp] quit
[*RR] commit


PrefRcv
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

After completing the configurations, run the display bgp evpn all routing-table 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 0000.0000.0000.0000.0000:100 1.1.1.1
*>i 0000.0000.0000.0000.0000:100 2.2.2.2
*> 0000.0000.0000.0000.0000:200 127.0.0.1
*>i 0000.0000.0000.0000.0000:100 1.1.1.1
* i 2.2.2.2
*> 0000.0000.0000.0000.0000:200 127.0.0.1
After completing the configurations, run the display bgp evpn all routing-table ad-route
0000.0000.0000.0000.0000: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.
[~PE1] display bgp evpn all routing-table ad-route 0000.0000.0000.0000.0000:100
BGP routing table entry information of 0000.0000.0000.0000.0000:100:
From: 3.3.3.3 (3.3.3.3)
Relay IP Out-Interface:Ethernet3/0/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

Route Type: 1 (Ethernet Auto-Discovery (A-D) route)

ESI: 0000.0000.0000.0000.0000, Ethernet Tag ID: 100

From: 3.3.3.3 (3.3.3.3)
Relay IP Out-Interface:Ethernet3/0/3
Label<0 : 0 : 48124>
Originator: 2.2.2.2
Remote-Cross route
From: 3.3.3.3 (3.3.3.3)
Label<0 : 0 : 48124>
Originator: 1.1.1.1

Remote-Cross route
From: 3.3.3.3 (3.3.3.3)
Label<0 : 0 : 48124>
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
#
evpn vpn-instance evrf1 vpws
#
evpl instance 1 mpls-mode
local-service-id 100 remote-service-id 200
#
mpls lsr-id 1.1.1.1
#
mpls
#
mpls ldp
#
evpl instance 1
#
undo shutdown
ip address 10.1.1.1 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 1.1.1.1 255.255.255.255
#
bgp 100
#
ipv4-family unicast
peer 3.3.3.3 enable
#
l2vpn-family evpn
peer 3.3.3.3 enable
#
ospf 1
area 0.0.0.0
network 1.1.1.1 0.0.0.0
network 10.1.1.0 0.0.0.255
#
return

#
sysname PE2
#
#
#
mpls lsr-id 2.2.2.2

#
mpls
#
mpls ldp
#
evpl instance 1
#
undo shutdown
ip address 10.2.1.1 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 2.2.2.2 255.255.255.255
#
bgp 100
#
ipv4-family unicast
peer 3.3.3.3 enable
#
l2vpn-family evpn
peer 3.3.3.3 enable
#
ospf 1
area 0.0.0.0
network 2.2.2.2 0.0.0.0
network 10.2.1.0 0.0.0.255
#
return
#
sysname PE3
#
remote frr enable
#
#
mpls lsr-id 4.4.4.4
#
mpls
#
mpls ldp
#
undo shutdown
ip address 10.3.1.2 255.255.255.0
mpls
mpls ldp
#
evpl instance 1
#
interface LoopBack1
ip address 4.4.4.4 255.255.255.255
#

bgp 100
#
ipv4-family unicast
peer 3.3.3.3 enable
#
l2vpn-family evpn
peer 3.3.3.3 enable
#
ospf 1
area 0.0.0.0
network 4.4.4.4 0.0.0.0
network 10.3.1.0 0.0.0.255
#
return
#
sysname RR
#
mpls lsr-id 3.3.3.3
#
mpls
#
mpls ldp
#
undo shutdown
ip address 10.2.1.2 255.255.255.0
mpls
mpls ldp
#
undo shutdown
ip address 10.1.1.2 255.255.255.0
mpls
mpls ldp
#
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.24.5 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-114 to transmit services.
Specifically, an EVPN instance (BD-EVPN instance in this example) is configured on each
PE, and a BGP EVPN peer relationship is established between every two PEs. To improve
network security, PE2 and PE3 can only interact with PE1, and PE2 and PE3 cannot send
traffic to each other. To implement this function, the user can deploy EVPN E-Tree over the
network.
Figure 3-114 Configuring EVPN E-Tree

NOTE
Loopback 1
1.1.1.1/32
PE1
interface1 inte
interface1 10. rface
1.1 3
CE1 .1/2 Loopback 1
4
10.2.1.2/24
interface2
3.3.3.3/32
Site1 inte
10. rface1
1.1 interface1 CE3
.2/2
10.2.1.1/24
4
interface2
interface3
e3 e2 PE3
rfac r fa c
inte .1.1/2
4 inte .2/24 Site3
.1
10.
3 1 0 .3
interface1
interface1
CE2 PE2
Site2 Loopback 1
2.2.2.2/32
Precautions
When you configure EVPN E-Tree, note the following:

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

l EVPN instance evrf1's RD (10:1) and RT (11:1) on each PE
Procedure
Step 1 Assign an IP address to each PE interface, including the loopback interfaces.
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] commit

Repeat this step for PE2 and PE3. For configuration details, see Configuration Files in this
section.
Step 5 Configure each PE interface that connects to a CE.
# Configure PE1.
[~PE1] interface gigabitethernet 1/0/0.1 mode l2
[*PE1-GigabitEthernet1/0/0.1] encapsulation dot1q vid 10
[*PE1-GigabitEthernet1/0/0.1] rewrite pop single
[*PE1-GigabitEthernet1/0/0.1] bridge-domain 10
[*PE1] commit
section.
# Configure PE1.
[*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
section.
Step 8 Configure the AC interfaces on PE2 and PE3 as leaf AC interfaces.
# Configure PE2.
[*PE2-evpn-instance-evrf1] etree enable
[*PE2] interface gigabitethernet1/0/0.1 mode l2
[*PE2-GigabitEthernet1/0/0.1] evpn e-tree-leaf
[*PE2] commit
# Configure PE3.

[*PE3-evpn-instance-evrf1] etree enable

[*PE3-GigabitEthernet3/0/0.1] evpn e-tree-leaf
[*PE3] commit

Run the display bgp evpn all routing-table command on PE1 to view the leaf attribute in
Ethernet auto-discovery and MAC routes.


*>i 0000.0000.0000.0000.0000:4294967295 2.2.2.2
*>i 0000.0000.0000.0000.0000:4294967295 3.3.3.3
*>i 0000.0000.0000.0000.0000:4294967295 2.2.2.2
* 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
[~PE1] display bgp evpn all routing-table ad-route
0000.0000.0000.0000.0000:4294967295

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>

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)
0.0.0.0/0, ESI:0000.0000.0000.0000.0000
Remote-Cross route
From: 2.2.2.2 (2.2.2.2)
0.0.0.0/0, ESI:0000.0000.0000.0000.0000
----End
Configuration Files
#
sysname PE1
#
#
mpls lsr-id 1.1.1.1
#
mpls
#
bridge-domain 10
#

mpls ldp
#
rewrite pop single
bridge-domain 10
#
undo shutdown
ip address 10.2.1.2 255.255.255.0
mpls
mpls ldp
#
undo shutdown
ip address 10.1.1.1 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 1.1.1.1 255.255.255.255
#
bgp 100
#
ipv4-family unicast
peer 2.2.2.2 enable
peer 3.3.3.3 enable
#
l2vpn-family evpn
peer 2.2.2.2 enable
peer 3.3.3.3 enable
#
ospf 1
area 0.0.0.0
network 1.1.1.1 0.0.0.0
network 10.1.1.0 0.0.0.255
network 10.2.1.0 0.0.0.255
#
#
return
#
sysname PE2
#
etree enable
#
mpls lsr-id 2.2.2.2
#
mpls
#
bridge-domain 10
#
mpls ldp
#
rewrite pop single

bridge-domain 10
evpn e-tree-leaf
#
undo shutdown
ip address 10.2.1.1 255.255.255.0
mpls
mpls ldp
#
undo shutdown
ip address 10.3.1.1 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 2.2.2.2 255.255.255.255
#
bgp 100
#
ipv4-family unicast
peer 1.1.1.1 enable
peer 3.3.3.3 enable
#
l2vpn-family evpn
peer 1.1.1.1 enable
peer 3.3.3.3 enable
#
ospf 1
area 0.0.0.0
network 2.2.2.2 0.0.0.0
network 10.2.1.0 0.0.0.255
network 10.3.1.0 0.0.0.255
#
#
return
#
sysname PE3
#
etree enable
#
mpls lsr-id 3.3.3.3
#
mpls
#
bridge-domain 10
#
mpls ldp
#
undo shutdown
ip address 10.1.1.2 255.255.255.0
mpls
mpls ldp
#

undo shutdown
ip address 10.3.1.2 255.255.255.0
mpls
mpls ldp
#
rewrite pop single
bridge-domain 10
evpn e-tree-leaf
#
interface LoopBack1
ip address 3.3.3.3 255.255.255.255
#
bgp 100
#
ipv4-family unicast
peer 1.1.1.1 enable
peer 2.2.2.2 enable
#
l2vpn-family evpn
peer 1.1.1.1 enable
peer 2.2.2.2 enable
#
ospf 1
area 0.0.0.0
network 3.3.3.3 0.0.0.0
network 10.1.1.0 0.0.0.255
network 10.3.1.0 0.0.0.255
#
#
return
3.2.24.6 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-115, 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-115 Configuring EVPN ORF

NOTE

Loopback 1
1.1.1.1/32
PE1
CE1 interface1 interface2
Site1 3.3.3.3/32 4.4.4.4/32
interface1
interface1
10.1.1.2/24
interface2 CE3
10.2.1.2/24
10.3.1.1/24
RR PE3
Backbone Site3
interface2 Network
CE2
interface1
PE2
Site2
Loopback 1
2.2.2.2/32
Precautions
When you configure EVPN ORF, note the following:
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
3. Configure MPLS LDP on each PE.
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 configure the
PEs as RR clients.
10. Configure EVPN ORF on each device.
Data Preparation

l PE1's EVPN instance names: evrf1 and evrf2; PE2's EVPN instance name: evrf1; PE3's
EVPN instance name: evrf2
l evrf1's RD (100:1) and RT (1:1); evrf2's RD (100:2) and RT (2:2)
Procedure
Step 1 Assign an IP address to each PE interface, including the loopback interfaces.
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 Configure EVPN instances on the PEs and bind each EVPN instance to a BD.
# Configure PE1.
[~PE1] evpn vpn-instance evpn1 bd-mode
[*PE1-bd10] quit
[*PE1-bd20] quit
[*PE1] commit
# Configure PE2.
[*PE2-bd10] quit
[*PE2] commit
# Configure PE3.
[*PE3-bd20] quit
[*PE3] commit

# Configure PE1.

[*PE1] commit
# Configure PE2.
[*PE2] commit
# Configure PE3.
[*PE3] commit
Step 6 Configure each PE's sub-interface that connects to a CE.
# Configure PE1.
[~PE1] interface gigabitethernet1/0/0.1 mode l2
[*PE1] commit
# Configure PE2.
[*PE2] commit
# Configure PE3.
[*PE3] commit
# Configure PE1.
[~PE1] interface gigabitethernet1/0/0
[*PE1-GigabitEthernet1/0/0] esi 0000.1111.1111.1111.1111
[*PE1] commit
# Configure PE2.
[*PE2] commit
# Configure PE3.
[*PE3] commit

Step 8 Configure the CEs and PEs to communicate.

# Configure CE1.
[~CE1] interface gigabitethernet1/0/0.1 mode l2
[*CE1-GigabitEthernet1/0/0.1] bridge-domain 10
[*CE1] interface gigabitethernet1/0/0.2 mode l2
[*CE1] commit
# Configure CE2.
[*CE2] commit
# Configure CE3.
[*CE3] commit
Step 9 Configure BGP-EVPN peer relationships between the PEs and RR, and configure the PEs as
RR clients.
# Configure PE1.
[~PE1] bgp 100
[*PE1-bgp] quit
[*PE1] commit
# Configure PE2.
[~PE2] bgp 100
[*PE2-bgp] quit
[*PE2] commit
# Configure PE3.
[~PE3] bgp 100
[*PE3-bgp] quit
[*PE3] commit

# Configure the RR.

[~RR] bgp 100
[*RR-bgp] quit
[*RR] commit
# 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.


PrefRcv
1.1.1.1 4 100 10 33 0 00:00:19
Established 6
2.2.2.2 4 100 8 33 0 00:00:20
Established 4
4.4.4.4 4 100 8 33 0 00:00:21
Established 4
# Run the display bgp evpn all routing-table peer 2.2.2.2 advertised-routes and display
bgp evpn all routing-table peer 4.4.4.4 advertised-routes commands on the RR to view
routes advertised to PE2 and PE3.
[~RR] display bgp evpn all routing-table peer 2.2.2.2 advertised-routes


*>i 0000.1111.1111.1111.1111:0 1.1.1.1
*>i 0000.1111.2222.2222.2222:0 2.2.2.2
*>i 0000.1111.1111.1111.1111:0 1.1.1.1
*>i 0000.1111.3333.3333.3333:0 4.4.4.4
*>i 0000.1111.1111.1111.1111:4294967295 1.1.1.1
*>i 0000.1111.2222.2222.2222:4294967295 2.2.2.2


*>i 0000.1111.3333.3333.3333:4294967295 4.4.4.4

*>i 0:32:1.1.1.1 1.1.1.1
*>i 0:32:2.2.2.2 2.2.2.2
*>i 0:32:1.1.1.1 1.1.1.1
*>i 0:32:4.4.4.4 4.4.4.4

*>i 0000.1111.1111.1111.1111 1.1.1.1
*>i 0000.1111.2222.2222.2222 2.2.2.2
*>i 0000.1111.3333.3333.3333 4.4.4.4


*>i 0000.1111.1111.1111.1111:0 1.1.1.1
*>i 0000.1111.2222.2222.2222:0 2.2.2.2
*>i 0000.1111.1111.1111.1111:0 1.1.1.1
*>i 0000.1111.3333.3333.3333:0 4.4.4.4
*>i 0000.1111.1111.1111.1111:4294967295 1.1.1.1
*>i 0000.1111.2222.2222.2222:4294967295 2.2.2.2
*>i 0000.1111.3333.3333.3333:4294967295 4.4.4.4

*>i 0:32:1.1.1.1 1.1.1.1
*>i 0:32:2.2.2.2 2.2.2.2
*>i 0:32:1.1.1.1 1.1.1.1
*>i 0:32:4.4.4.4 4.4.4.4

*>i 0000.1111.1111.1111.1111 1.1.1.1
*>i 0000.1111.2222.2222.2222 2.2.2.2
*>i 0000.1111.3333.3333.3333 4.4.4.4
The command output shows that the RR reflects all routes to PE2 and PE3. However, PE2 and
PE3 do not have to receive all the routes. To resolve this problem, configure EVPN ORF on
each device.
Step 10 Configure EVPN ORF on each device.
# Configure PE1.
[~PE1] bgp 100
[*PE1-bgp] ipv4-family vpn-target
[*PE1-bgp-af-vpn-target] peer 3.3.3.3 enable
[*PE1-bgp-af-vpn-target] quit
[*PE1-bgp-af-evpn] vpn-orf enable
[*PE1-bgp] quit
[*PE1] commit
# Configure PE2.
[~PE2] bgp 100
[*PE2-bgp] quit
[*PE2] commit
# Configure PE3.
[~PE3] bgp 100
[*PE3-bgp] quit
[*PE3] commit
# 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
Total Number of Routes: 7

Network NextHop MED LocPrf PrefVal Path/Ogn
*>i RT <1 : 1> 1.1.1.1 0 100 0 ?
* i 2.2.2.2 0 100 0 ?
*>i RT <2 : 2> 1.1.1.1 0 100 0 ?
* i 4.4.4.4 0 100 0 ?
*>i RT <00e0-fc00-0001> 1.1.1.1 0 100 0 ?
*>i RT <00e0-fc00-0002> 2.2.2.2 0 100 0 ?
*>i RT <00e0-fc00-0003> 4.4.4.4 0 100 0 ?
Run the display bgp evpn all routing-table peer 2.2.2.2 advertised-routes and display bgp
evpn all routing-table peer 4.4.4.4 advertised-routes commands on the RR again. The
command output shows that the RR has advertised only requested routes to PE2 and PE3.


*>i 0000.1111.1111.1111.1111:0 1.1.1.1
*>i 0000.1111.1111.1111.1111:4294967295 1.1.1.1

*>i 0:32:1.1.1.1 1.1.1.1



*>i 0000.1111.1111.1111.1111:0 1.1.1.1

*>i 0000.1111.1111.1111.1111:4294967295 1.1.1.1

*>i 0:32:1.1.1.1 1.1.1.1
----End
Configuration Files
#
sysname PE1
#
#
#
mpls lsr-id 1.1.1.1
#
mpls
#
bridge-domain 10
#
bridge-domain 20
#
mpls ldp
#
undo shutdown
esi 0000.1111.1111.1111.1111
#
rewrite pop single
bridge-domain 10
#
rewrite pop single
bridge-domain 20
#
undo shutdown
ip address 10.1.1.1 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 1.1.1.1 255.255.255.255
#
bgp 100
#

ipv4-family unicast
peer 3.3.3.3 enable
#
l2vpn-family evpn
vpn-orf enable
peer 3.3.3.3 enable
#
ipv4-family vpn-target
peer 3.3.3.3 enable
#
ospf 1
area 0.0.0.0
network 1.1.1.1 0.0.0.0
network 10.1.1.0 0.0.0.255
#
#
return
#
sysname PE2
#
#
mpls lsr-id 2.2.2.2
#
mpls
#
bridge-domain 10
#
mpls ldp
#
undo shutdown
esi 0000.1111.2222.2222.2222
#
rewrite pop single
bridge-domain 10
#
undo shutdown
ip address 10.2.1.1 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 2.2.2.2 255.255.255.255
#
bgp 100
#
ipv4-family unicast
peer 3.3.3.3 enable
#
l2vpn-family evpn
vpn-orf enable
peer 3.3.3.3 enable
#

peer 3.3.3.3 enable
#
ospf 1
area 0.0.0.0
network 2.2.2.2 0.0.0.0
network 10.2.1.0 0.0.0.255
#
#
return
#
sysname PE3
#
#
mpls lsr-id 4.4.4.4
#
mpls
#
bridge-domain 20
#
mpls ldp
#
undo shutdown
ip address 10.3.1.2 255.255.255.0
mpls
mpls ldp
#
undo shutdown
esi 0000.1111.3333.3333.3333
#
rewrite pop single
bridge-domain 20
#
interface LoopBack1
ip address 4.4.4.4 255.255.255.255
#
bgp 100
#
ipv4-family unicast
peer 3.3.3.3 enable
#
l2vpn-family evpn
vpn-orf enable
peer 3.3.3.3 enable
#
peer 3.3.3.3 enable
#
ospf 1
area 0.0.0.0
network 4.4.4.4 0.0.0.0
network 10.3.1.0 0.0.0.255
#

#
return
#
sysname RR
#
mpls lsr-id 3.3.3.3
#
mpls
#
mpls ldp
#
undo shutdown
ip address 10.1.1.2 255.255.255.0
mpls
mpls ldp
#
undo shutdown
ip address 10.2.1.2 255.255.255.0
mpls
mpls ldp
#
undo shutdown
ip address 10.3.1.1 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 3.3.3.3 255.255.255.255
#
bgp 100
#
ipv4-family unicast
peer 1.1.1.1 enable
peer 2.2.2.2 enable
peer 4.4.4.4 enable
#
l2vpn-family evpn
vpn-orf enable
peer 1.1.1.1 enable
peer 2.2.2.2 enable
peer 4.4.4.4 enable
#
peer 1.1.1.1 enable
peer 2.2.2.2 enable
peer 4.4.4.4 enable
#
ospf 1
area 0.0.0.0
network 3.3.3.3 0.0.0.0
network 10.1.1.0 0.0.0.255

network 10.2.1.0 0.0.0.255

network 10.3.1.0 0.0.0.255
#
return

#
sysname CE1
#
bridge-domain 10
#
bridge-domain 20
#
undo shutdown
#
rewrite pop single
bridge-domain 10
#
rewrite pop single
bridge-domain 20
#
return

#
sysname CE2
#
bridge-domain 10
#
undo shutdown
#
rewrite pop single
bridge-domain 10
#
return

#
sysname CE3
#
bridge-domain 20
#
undo shutdown
#
rewrite pop single
bridge-domain 20
#
return
3.2.24.7 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.

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-116 Configuring an e2e VXLAN EVPN deployed on a gateway

NOTE
In this example, Interface 1 and Interface 2 stand for GE 1/0/0 and GE 2/0/0, respectively.
This example focuses on routing configuration of the DCI backbone network. VXLAN configuration is
mainly performed on devices in a DC. For details about VXLAN configuration, see the documents
related to DC devices.

DCI-PE1 DCI-PE2
Interface 2 Interface 2
Interface 1 P Interface 1
Data center A VXLAN Tunnel Data center B

GW1 GW2
Device Interface Name IP Address
DCI-PE1 GigabitEthernet 2/0/0 192.168.1.1/24

P

1. Enable OSPF on the DCI backbone network for DCI-PEs to communicate with each
other.
2. Configure an MPLS TE tunnel on the DCI backbone network.
3. Configure a VPN instance on each DCI-PE and bind the interface connected to a GW to
the VPN instance.
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
l MPLS LSR IDs of the DCI-PEs and P
l Route distinguisher (RD) of a VPN instance
l VPN target
Procedure
Step 1 Assign an IP address to each interface on each node, and configure loopback interface
addresses.
Step 2 Configure an IGP on the DCI backbone network. OSPF is used as an IGP in this example.
Step 3 Configure an MPLS TE tunnel on the DCI backbone network.
Step 4 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
[*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 5 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 6 Set up an MP-IBGP peer relationship between DCI-PEs.

[~DCI-PE1] bgp 100
[*DCI-PE1-bgp] peer 3.3.3.3 as-number 100
[*DCI-PE1-bgp] peer 3.3.3.3 connect-interface loopback 1
[*DCI-PE1-bgp] ipv4-family vpnv4
[*DCI-PE1-bgp-af-vpnv4] peer 3.3.3.3 enable
[*DCI-PE1-bgp-af-vpnv4] quit
[*DCI-PE1-bgp] quit
[*DCI-PE1] commit
[~DCI-PE2] bgp 100

[*DCI-PE2-bgp] quit
[*DCI-PE2] commit

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
192.168.20.0/24 Direct 0 0 D 192.168.20.1
192.168.20.1/32 Direct 0 0 D 127.0.0.1
192.168.20.255/32 Direct 0 0 D 127.0.0.1
4.4.4.4/32 EBGP 255 0 RD 10.1.1.1
7.7.7.7/32 IBGP 255 0 RD 3.3.3.3
----End
Configuration Files
l 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
#
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
#
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
l GW1 configuration file

See the data center device configuration file.
l Device 1 configuration file


3.2.24.8 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-117, 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-117 Configuring a DCI scenario with a VLAN Layer 3 sub-interface accessing a
common L3VPN
NOTE
In this example, Interface 1, Interface 2, and Sub-interface 1.1 stand for GE 1/0/0, GE 2/0/0, and GE
1/0/0.1, respectively.


DCI-PE1 DCI-PE2
Sub-interface 1.1 P Sub-interface 1.1

GigabitEthernet 1/0/0.1 192.168.20.1/24
GigabitEthernet 1/0/0.1 192.168.30.1/24
other.


the VPN instance.
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
l RD of a VPN instance
l VPN target
Procedure
addresses.
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


[*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
192.168.20.0/24 Direct 0 0 D 192.168.20.1
192.168.20.1/32 Direct 0 0 D 127.0.0.1

192.168.20.255/32 Direct 0 0 D 127.0.0.1
4.4.4.4/32 EBGP 255 0 RD 10.1.1.1
7.7.7.7/32 IBGP 255 0 RD 3.3.3.3
----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
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

#
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



3.2.24.9 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.
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-118 Configuring a DCI scenario with a VXLAN EVPN L3VPN accessing a
common L3VPN
NOTE
In this example, Interface 1 and Interface 2 stand for GE 1/0/0 and GE 2/0/0, respectively.

DCI-PE1 DCI-PE2
Interface 1 RR Interface 1
VXLAN VXLAN


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
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.
the VPN instance.
8. Configure an MP-IBGP peer relationship between each DCI-PE and RR to exchange
VPNv4 routes and configure RR in the figure as a route reflector.
9. Configure the route regeneration function on each DCI-PE-GW.
Data Preparation
l MPLS LSR IDs of the DCI-PEs and RR

l VPN targets

Procedure
addresses.
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 11.11.11.11
[*DCI-PE1] commit
[*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.


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

[~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 import reoriginate
[*DCI-PE1-bgp-af-vpnv4] peer 43.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-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

------------------------------------------------------------------------------
Routing Table : vpn1
10.1.1.0/24 EBGP 255 0 RD 4.4.4.4 VXLAN

10.1.1.1/32 EBGP 255 0 RD 4.4.4.4 VXLAN
10.2.1.0/24 IBGP 255 0 RD 3.3.3.3 Tunnel10
10.2.1.1/32 IBGP 255 0 RD 3.3.3.3 Tunnel10

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
#
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 encap-type vxlan
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
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
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
#

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.24.10 Example for Configuring MPLS EVPN E-LAN Option B

An EBGP peer relationship can be established between the ASBRs to exchange EVPN routes.
On the network shown in Figure 3-119, 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-119 Configuring MPLS EVPN E-LAN Option B networking

NOTE
Interfaces 1 through 2 in this example are GE 1/0/0, GE 2/0/0, respectively.

AS100 AS200
2.2.2.9/32 3.3.3.9/32
ASBR1 interface2 ASBR2
192.168.1.1/24 interface2
192.168.1.2/24
Loopback 1 interface1 interface1 Loopback 1
1.1.1.9/32 172.21.1.1/24 172.22.1.1/24 4.4.4.9/32
172.21.1.2/24 172.22.1.2/24
PE1 PE2
CE1 CE2
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
l Interfaces and their IP addresses
l MPLS LSR IDs of the PEs and ASBRs
l 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.
This example uses OSPF as the IGP. For configuration details, see Configuration Files in this
section.

NOTE
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.
NOTE
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 configuration

----End
Configuration Files
#
sysname PE1
#
evpn vpn-instance evrf_1
#
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
#
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
#
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.24.11 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-120, 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.
Figure 3-120 Configuring an MPLS EVPN L3VPN in E-LAN Option B mode

NOTE
Interface 1 and interface 2 in this example refer to GE 1/0/0 and GE 2/0/0, respectively.

AS100 AS200
2.2.2.9/32 3.3.3.9/32
ASBR1 ASBR2
10.2.1.1/24 10.2.1.2/24
Loopback 1 interface1 interface1 Loopback 1
1.1.1.9/32 10.1.1.1/24 10.3.1.2/24 4.4.4.9/32
10.1.1.2/24 10.3.1.1/24
PE1 PE2
192.168.1.1 192.168.2.1
192.168.1.2 192.168.2.2
CE1 CE2
10.10.10.10/32 10.20.20.20/32
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.
Data Preparation
l MPLS LSR IDs of the PEs and ASBRs

l 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 configuration
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] ip vpn-instance vpn1
[*PE1-vpn-instance-vpn1-af-ipv4] evpn mpls routing-enable
[*PE1] commit
Repeat this step for PE2. For configuration details, see Configuration Files in this 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 Configuration
Step 5 Establish a VPN BGP peer relationship between each PE and CE.
# Configure PE1.
[~PE1-bgp] ipv4-family vpn-instance vpn1
[*PE1-bgp-vpn1] peer 192.168.1.2 as-number 65410
[*PE1-bgp] quit
[*PE1] commit
# Configure CE1.
[~CE1] bgp 65410
[*CE1-bgp] import-route direct
[*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-GigabitEthernet2/0/0] ip address 10.2.1.1 24
[*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
Route Flags: R - relay, D - download to fib, T - to vpn-instance, B - black hole
route
------------------------------------------------------------------------------

10.20.20.20/32 EBGP 255 0 RD 192.168.1.1
192.168.1.0/24 Direct 0 0 D 192.168.1.2
192.168.1.2/32 Direct 0 0 D 127.0.0.1
192.168.1.255/32 Direct 0 0 D 127.0.0.1
192.168.2.0/24 EBGP 255 0 RD 192.168.1.1
----End
Configuration Files
#
sysname PE1
#
ipv4-family
#
mpls lsr-id 1.1.1.9

#
mpls
#
mpls ldp
#
undo shutdown
ip address 192.168.1.1 255.255.255.0
#
undo shutdown
ip address 10.1.1.2 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 1.1.1.9 255.255.255.255
#
bgp 100
#
ipv4-family unicast
peer 2.2.2.9 enable
#
import-route direct
peer 192.168.1.2 as-number 65410
#
l2vpn-family evpn
peer 2.2.2.9 enable
#
ospf 1
area 0.0.0.0
network 1.1.1.9 0.0.0.0
network 10.1.1.0 0.0.0.255
#
#
return
#
sysname ASBR1
#
mpls lsr-id 2.2.2.9
#
mpls
#
mpls ldp
#
undo shutdown
ip address 10.1.1.1 255.255.255.0
mpls
mpls ldp
#
undo shutdown
ip address 10.2.1.1 255.255.255.0
mpls
#
interface LoopBack1
ip address 2.2.2.9 255.255.255.255
#
bgp 100


#
ipv4-family unicast
peer 1.1.1.9 enable
#
l2vpn-family evpn
peer 1.1.1.9 enable
#
ospf 1
area 0.0.0.0
network 2.2.2.9 0.0.0.0
network 10.1.1.0 0.0.0.255
#
return
#
sysname ASBR2
#
mpls lsr-id 3.3.3.9
#
mpls
#
mpls ldp
#
isis 1
network-entity 00.1111.1111.1111.00
#
undo shutdown
ip address 10.3.1.2 255.255.255.0
isis enable 1
mpls
mpls ldp
#
undo shutdown
ip address 10.2.1.2 255.255.255.0
mpls
#
interface LoopBack1
ip address 3.3.3.9 255.255.255.255
isis enable 1
#
bgp 200
#
ipv4-family unicast
peer 4.4.4.9 enable
#
l2vpn-family evpn
peer 4.4.4.9 enable
#
return
#
sysname PE2

#
ipv4-family
#
mpls lsr-id 4.4.4.9
#
mpls
#
mpls ldp
#
isis 1
network-entity 00.1111.1111.2222.00
#
undo shutdown
ip address 10.3.1.1 255.255.255.0
isis enable 1
mpls
mpls ldp
#
undo shutdown
ip address 192.168.2.1 255.255.255.0
#
interface LoopBack1
ip address 4.4.4.9 255.255.255.255
isis enable 1
#
bgp 200
#
ipv4-family unicast
peer 3.3.3.9 enable
#
import-route direct
peer 192.168.2.2 as-number 65420
#
l2vpn-family evpn
peer 3.3.3.9 enable
#
#
return
#
sysname CE1
#
undo shutdown
ip address 192.168.1.2 255.255.255.0
#
interface LoopBack1
ip address 10.10.10.10 255.255.255.255
#
bgp 65410
#
ipv4-family unicast

import-route direct
#
return

#
sysname CE2
#
undo shutdown
ip address 192.168.2.2 255.255.255.0
#
interface LoopBack1
ip address 10.20.20.20 255.255.255.255
#
bgp 65420
#
ipv4-family unicast
import-route direct
#
return
3.2.24.12 Example for Configuring Inter-AS EVPN Option C

This section provides an example for configuring inter-AS EVPN Option C when multi-hop
EBGP EVPN peer relationships are established between PEs in different ASs.
On the network shown in Figure 3-121, 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-121 Inter-AS EVPN Option C networking

NOTE

AS 100 AS 200
Loopback1 Loopback1
2.2.2.2/32 3.3.3.3/32
GE1/0/0
GE2/0/0 GE2/0/0 GE1/0/0
10.1.1.1/24
10.2.1.1/24 10.2.1.2/24 10.3.1.1/24
Loopback1
ASBR1 ASBR2 Loopback1
1.1.1.1/32
4.4.4.4/32
PE1 GE1/0/0 GE1/0/0 PE2

10.1.1.2/24 10.3.1.2/24
GE2/0/0 GE2/0/0
Site1 Site2
AS 65001 AS 65002
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 communicate with each other.
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
l 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
l Name (vpn1), RD (100:1), and export and import VPN targets (1:1) of the VPN instance
on each PE
l Name (evrf1), RD (200:1), and export and import VPN targets (2:2) of the EVPN
instance on each PE

l Name of the routing policy configured on ASBR1: policy1; name of the routing policy
configured on ASBR2: policy2
Procedure
Step 1 Configure IP addresses for all interfaces on the PEs and ASBRs as well as the loopback
interface address.
Step 2 Configure an IGP on the MPLS backbone networks in AS100 and AS200 so that the PE and
ASBR on the same MPLS backbone network can communicate with each other.
NOTE
Configure OSPF to advertise the 32-bit loopback interface addresses used as LSR IDs.
Step 3 Configure basic MPLS functions and MPLS LDP on the MPLS backbone networks in AS100
and AS200 to establish MPLS LDP LSPs.
Step 4 Configure an IBGP peer relationship between PE1 and ASBR1 and between PE2 and ASBR2.
Configure an EBGP peer relationship between ASBRs. Enable these devices to exchange
labeled routes.
Step 5 Configure and apply a Route-Policy on each ASBR.
# Configure ASBR1: Enable MPLS on GE 2/0/0 connecting ASBR1 to ASBR2.
[~ASBR1] interface gigabitethernet 2/0/0
[*ASBR1] commit
# Configure ASBR1: Create a routing policy.

[~ASBR1] route-policy policy1 permit node 1
[*ASBR1-route-policy] apply mpls-label
[*ASBR1-route-policy] quit
[*ASBR1] route-policy policy2 permit node 1
[*ASBR1-route-policy] if-match mpls-label
[*ASBR1-route-policy] apply mpls-label
[*ASBR1-route-policy] quit
[*ASBR1] commit
# Configure ASBR1: Apply the routing policy to the routes advertised to PE1 and enable
ASBR1 to exchange labeled IPv4 routes with PE1.
[~ASBR1] bgp 100
[*ASBR1-bgp] peer 1.1.1.1 route-policy policy2 export
# Configure ASBR1: Apply the routing policy to the routes advertised to ASBR2 and enable
ASBR1 to exchange labeled IPv4 routes with ASBR2.
[*ASBR1-bgp] peer 10.2.1.2 route-policy policy1 export
# Configure ASBR1: Advertise the loopback routes from PE1 to ASBR2 and then to PE2.
[*ASBR1-bgp] network 1.1.1.9 32
[*ASBR1-bgp] network 10.1.1.0 24

[*ASBR1-bgp] quit
[*ASBR1] commit
Repeat this step for PE2 and ASBR2. For configuration details, see Configuration Files in
this section.
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
# 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
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
[*PE1] interface Vbdif10
[*PE1-Vbdif10] ip address 192.168.1.1 24
[*PE1-Vbdif10] quit
[*PE1] commit


After completing the configurations, run the display bgp evpn all routing-table 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
*> 0:192.168.1.0:24 0.0.0.0
*> 0:192.168.2.0:24 4.4.4.4
[~PE1] display ip routing-table vpn-instance vpn1
------------------------------------------------------------------------------

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
192.168.2.0/24 EBGP 255 0 RD 4.4.4.4
[~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
ip address 1.1.1.1 255.255.255.255
#
bgp 100


#
ipv4-family unicast
peer 2.2.2.2 enable
peer 2.2.2.2 label-route-capability
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
#
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
#
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
network 10.3.1.0 0.0.0.255
#
#
return

3.2.24.13 Example for Splicing a VXLAN EVPN with a VPLS

To implement interconnection between a DC and an enterprise network, splicing VXLAN
EVPN with VPLS must be configured.
On the network shown in Figure 3-122, 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-122 Splicing a VXLAN EVPN with a VPLS

NOTE
Interfaces 0 through 2 in this example refer to GigabitEthernet 1/0/0, GigabitEthernet 1/0/1, and
GigabitEthernet 1/0/2, respectively.
Lo
0 op
ba
10
ck
ck
0
ba
op
In te
Lo
Loopback100 r fa c Loopback0
e1
1 e2
ce ac PE1
t e rfa nterf In te
r fa c
In I e1
Interface0 MPLS Interface0
Inte VXLAN VPLS
rfac face2
e2 PE2 Inter
CE1 Inte PE3 CE2
TOR r fa c f ac e1
e2 I nt er
Lo
op
ba
0
ck
ck
ba
10
op
0
Lo
Table 3-14 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
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
l MPLS LSR IDs of PEs
l Names, RDs, and VPN targets of the EVPN instances of PE1, PE2, and the TOR
l Names and IDs of the VSIs on the PEs
l IP addresses of peers and tunnel policies used for setting up peer relationships
Procedure
Step 1 Configure IP addresses for interfaces on the PEs and TOR and configure an IGP. OSPF is
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 Files in
this section.
Step 4 Configure a BGP-EVPN peer relationship between the TOR and each of PE1 and PE2.
# Configure PE1.
[~PE1] bgp 100
[*PE1-bgp] peer 4.4.4.100 ebgp-max-hop 255
[*PE1-bgp-af-evpn] policy vpn-target
[*PE1-bgp-af-evpn] peer 4.4.4.100 advertise encap-type vxlan
[*PE1-bgp] quit
[*PE1] commit
Repeat this step for the TOR and PE2. For configuration details, see Configuration Files in
this section.
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
[*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
Run the display vsi name cpe verbose command on each PE to view the PW and VSI status.
[~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
*Peer Router ID : 3.3.3.3
Negotiation-vc-id : 10
ignore-standby-state : no
VC Label : 48123
Peer Type : dynamic
Session : up
Tunnel ID : 0x0000000001004c4b44
CKey : 1
NKey : 16777348
Stp Enable : 0
PwIndex : 1
Control Word : disable
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
Remote Control Word : disable
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
#
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
vni 10 head-end peer-list protocol bgp
#
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
#
#
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
#
#
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
l TOR configuration file
#
sysname TOR
#
#
bridge-domain 10
esi 0000.1111.1111.1111.1111
#
undo shutdown
#
#
undo shutdown
ip address 192.168.14.4 255.255.255.0
#
undo shutdown
ip address 192.168.24.4 255.255.255.0
#
interface LoopBack0
ip address 4.4.4.4 255.255.255.255
#

ip address 4.4.4.100 255.255.255.255
#
interface Nve1
source 4.4.4.100
#
interface NULL0
#
bgp 65001
#
ipv4-family unicast
#
l2vpn-family evpn
policy vpn-target
#
ospf 100
area 0.0.0.1
network 4.4.4.100 0.0.0.0
network 192.168.14.0 0.0.0.255
network 192.168.24.0 0.0.0.255
#
#
return
3.2.24.14 Example for Configuring EVPN E-LAN over mLDP P2MP Tunnels
On a network where an EVPN carries multicast services, to reduce redundant traffic and
conserve bandwidth resources, configure an EVPN E-LAN over mLDP P2MP tunnel for
service transmission.
On the network shown in Figure 3-123, 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-123 Configuring EVPN E-LAN over mLDP P2MP tunnels

NOTE
Multicast
Source
Loopback 0
1.1.1.1/32
PE1
interface2
interface1
10.1.1.1/24
interface1
CE1 Loopback 0 Loopback 0
3.3.3.3/32 4.4.4.4/32
interface1 interface1 CE3
10.1.1.2/24 10.3.1.2/24 interface1
interface2 interface3 interface2
10.2.1.2/24 10.3.1.1/24
RR PE3
PE2 Backbone
interface2 Network
Loopback 0 10.2.1.1/24
2.2.2.2/32
interface1 Receiver
interface1
CE2
Receiver
Precautions
When you configure EVPN to use an mLDP P2MP tunnel for service transmission, note the
following:
the import VPN target lists of the other sites. Conversely, the import VPN target list of a
site shares VPN targets with the export VPN target lists of the other sites.
recommended.
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 configure the
PEs as RR clients.
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
[~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
# 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
# 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
Step 8 Configure BGP EVPN peer relationships between the PEs and RR, and configure the PEs as
RR clients.
# Configure PE1.
[~PE1] bgp 100
[*PE1-bgp] quit
[*PE1] commit
# Configure PE2.
[~PE2] bgp 100
[*PE2-bgp] quit
[*PE2] commit
# Configure PE3.
[~PE3] bgp 100


[*PE3-bgp] quit
[*PE3] commit
# Configure the RR.

[~RR] bgp 100
[*RR-bgp] quit
[*RR] commit
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.


PrefRcv
1.1.1.1 4 100 231 253 0 03:07:26
Established 6
2.2.2.2 4 100 231 256 0 03:07:44
Established 6
4.4.4.4 4 100 232 254 0 03:07:54
Established 6
Step 9 Configure EVPN to use an mLDP P2MP tunnel for service transmission on each PE.
# Configure PE1.
[~PE1-evpn-instance-evrf1] inclusive-provider-tunnel
[*PE1-evpn-instance-evrf1-inclusive] root
[*PE1-evpn-instance-evrf1-inclusive-root] mldp p2mp
[*PE1-evpn-instance-evrf1-inclusive-root-mldpp2mp] root-ip 1.1.1.1
[*PE1-evpn-instance-evrf1-inclusive-root-mldpp2mp] quit
[*PE1-evpn-instance-evrf1-inclusive-root] quit
[*PE1-evpn-instance-evrf1-inclusive] quit
[*PE1] commit
# Configure PE2.
[*PE2-evpn-instance-evrf1-inclusive] leaf
[*PE2-evpn-instance-evrf1-inclusive-leaf] quit

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

Run the display evpn vpn-instance name evrf1 inclusive-provider-tunnel verbose
command on PE1. The command output shows information related to the root node.
[~PE1] display evpn vpn-instance name evrf1 inclusive-provider-tunnel verbose
VPN-Instance Name and ID : evrf1, 3
Address family bd-evpn
Route Distinguisher : 100:1
Label Policy : label per bridge-domain
Export VPN Targets : 1:1
Import VPN Targets : 1:1
Bridge-domain : 10
Ingress provider tunnel
PMSI type : P2MP mLDP
Root ip : 1.1.1.1
Opaque value : 01000400008001
State : up
Egress provider tunnel
Egress PMSI count: 0

command on PE2 or PE3. The command output shows information related to the leaf node.
The following example uses the command output on PE2:
Bridge-domain : 10
*PMSI type : P2MP mLDP
Root ip : 1.1.1.1
Opaque value : 01000400008001
State : up
----End
Configuration Files
#
sysname PE1
#
inclusive-provider-tunnel
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
#
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
#
#
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
#
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
#
#
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.24.15 Example for Splicing a VLL with a Common EVPN E-LAN

Traditional VLL is still used at the aggregation layer of a network, whereas the core network
has evolved into EVPN. To allow communication between different 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.
Figure 3-124 Splicing a VLL with a common EVPN E-LAN

NOTE
Interfaces 0 through 2 in this example refer to GigabitEthernet 1/0/0, GigabitEthernet 1/0/1 , and
VLL EVPN
e0
Int
ac
erf
erf
UPE NPE2
a
NPE1
ce
I nt
CE1 CE2

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.
5. On NPE1, bind the VSI to the PW-VE interface and the EVPN instance to PE-VE sub-
interface.
Data Preparation
l Interface names and IP addresses of the interfaces on NPE1, NPE2, and the UPE
l MPLS LSR IDs on the UPE, NPE1, and NPE2
l 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
[*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
BFD for PW : unavailable
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 : --
AdminPw link state : --
Forward state : send inactive, receive inactive
Service Class : --
Color : --
DomainId : --
Domain Name : --
----End
Configuration Files
l 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
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
l 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
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.24.16 Example for Splicing a VLL with an MPLS EVPN E-Line

The traditional VLL is still used at the aggregation layer of a network, whereas the core
network has evolved into EVPN. To allow services at different layers to run properly network
wide, a VLL must be spliced with an MPLS EVPN E-Line.
On the network shown in Figure 3-125, 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-125 Splicing a VLL with an MPLS EVPN E-Line

NOTE
Interfaces 0 through 2 in this example refer to GigabitEthernet 1/0/0, GigabitEthernet 1/0/1, and
VLL EVPN
e0
Int
ac
erf
erf
UPE NPE2
a
NPE1
ce
I nt
CE1 CE2

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 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
l Interface names and IP addresses of the interfaces on NPE1, NPE2, and the UPE
l MPLS LSR IDs on the UPE, NPE1, and NPE2
l 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.
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

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
#
#
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
#
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
ip address 192.168.14.4 255.255.255.0
mpls
mpls ldp
#
undo shutdown
esi 0011.1111.0000.0000.1111
#
interface GigabitEthernet1/0/2 mode l2
encapsulation qinq vid 100 ce-vid 100
evpl instance 1
#
ip address 2.2.2.100 255.255.255.255
#
bgp 100
#
ipv4-family unicast
#
l2vpn-family evpn
#
ospf 100
area 0.0.0.1
network 2.2.2.100 0.0.0.0
network 192.168.14.0 0.0.0.255
#
#
return
3.2.24.17 Example for Accessing a BD EVPN E-LAN over an MPLS Tunnel in

VLAN-Aware Mode
The VLAN-aware bundle access mode allows different VLANs configured on a physical
interface to access the same EVPN instance (EVI) and isolates the BDs to which the VLAN-
configured sub-interfaces belong.

On the network shown in Figure 3-126, 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-126 Accessing a BD EVPN E-LAN over MPLS tunnel in VLAN-Aware mode
NOTE
Loopback 0
1.1.1.1/32
PE1
interface2
interface1
10.1.1.1/24
3.3.3.3/32 4.4.4.4/32
10.2.1.2/24 10.3.1.1/24
CE1 RR PE3
interface2 Network
PE2
Loopback 0
2.2.2.2/32
Precautions
When you configure the VLAN-aware bundle access mode, note the following:
recommended.

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.
PEs as RR clients.
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.

[~RR] ospf 1

[*RR-ospf-1] area 0
[~RR-ospf-1] quit
that the RR and PEs have learned the routes destined for each other's loopback interfaces.


Neighbors

DR: 10.1.1.1 BDR: 10.1.1.2 MTU: 0
------------------------------------------------------------------------------

2.2.2.2/32 OSPF 10 2 D 10.1.1.2
3.3.3.3/32 OSPF 10 1 D 10.1.1.2
4.4.4.4/32 OSPF 10 2 D 10.1.1.2
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 OSPF 10 2 D 10.1.1.2
10.3.1.0/24 OSPF 10 2 D 10.1.1.2
backbone network.
# Configure PE1.


[*PE1] mpls
[*PE1-mpls] quit
[*PE1] mpls ldp
# Configure PE2.
[*PE2] mpls
[*PE2-mpls] quit
[*PE2] mpls ldp
# Configure the RR.

[*RR] mpls
[*RR-mpls] quit
[*RR] mpls ldp
[*RR-mpls-ldp] quit
# Configure PE3.
[*PE3] mpls
[*PE3-mpls] quit
[*PE3] mpls ldp
After the configurations are complete, LDP sessions are established between the PEs and RR.
configurations.



--------------------------------------------------------------------------
--------------------------------------------------------------------------
--------------------------------------------------------------------------
LDP LSP Information

-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
1.1.1.1/32 3/NULL 3.3.3.3 127.0.0.1 Loop1
*1.1.1.1/32 Liberal/32828 DS/3.3.3.3
2.2.2.2/32 NULL/32829 - 10.1.1.2 GE2/0/0
2.2.2.2/32 32829/32829 3.3.3.3 10.1.1.2 GE2/0/0
3.3.3.3/32 NULL/3 - 10.1.1.2 GE2/0/0
3.3.3.3/32 32828/3 3.3.3.3 10.1.1.2 GE2/0/0
4.4.4.4/32 NULL/32830 - 10.1.1.2 GE2/0/0
4.4.4.4/32 32830/32830 3.3.3.3 10.1.1.2 GE2/0/0
-------------------------------------------------------------------------------

# 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

# 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
[*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
RR clients.
# Configure PE1.
[~PE1] bgp 100
[*PE1-bgp] quit
[*PE1] commit
# Configure PE2.
[~PE2] bgp 100


[*PE2-bgp] quit
[*PE2] commit
# Configure PE3.
[~PE3] bgp 100
[*PE3-bgp] quit
[*PE3] commit
# Configure the RR.

[~RR] bgp 100
[*RR-bgp] quit
[*RR] commit
The command output shows that BGP peer relationships are established between the PEs and
RR and are in the Established state.


PrefRcv
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

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
*> 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
*> 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
#
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
#
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
#
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
#
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.24.18 Example for Accessing an EVPN E-LAN over a VXLAN Tunnel in

VLAN-Aware Mode
The AC side can access an EVPN E-LAN over a VXLAN tunnel in VLAN-aware bundle
mode. This 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-127, 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-127 Accessing an EVPN E-LAN over a VXLAN tunnel in VLAN-aware mode
NOTE

Loopback 0
1.1.1.1/32
PE1
interface2
interface1
10.1.1.1/24
3.3.3.3/32 4.4.4.4/32
10.2.1.2/24 10.3.1.1/24
CE1 RR PE3
interface2 Network
PE2
Loopback 0
2.2.2.2/32
Precautions
When you configure the VLAN-aware bundle mode, note the following:
l 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.
recommended.
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.
PEs as RR clients.
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.

[~RR] ospf 1
[*RR-ospf-1] area 0
[~RR-ospf-1] quit
that the RR and PEs have learned the routes destined for each other's loopback interfaces.

Neighbors


DR: 10.1.1.1 BDR: 10.1.1.2 MTU: 0
------------------------------------------------------------------------------

2.2.2.2/32 OSPF 10 2 D 10.1.1.2
3.3.3.3/32 OSPF 10 1 D 10.1.1.2
4.4.4.4/32 OSPF 10 2 D 10.1.1.2
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 OSPF 10 2 D 10.1.1.2
10.3.1.0/24 OSPF 10 2 D 10.1.1.2
Step 3 Configure an EVI on each PE.

# Configure PE1.
[*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
Step 4 Configure an Eth-Trunk sub-interface on each PE that connects to a CE.

# 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
[*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
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-af-evpn] peer 1.1.1.1 advertise encap-type vxlan
[*RR-bgp] quit
[*RR] commit
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.


PrefRcv
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
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.
[*PE3-Nve1] quit
[*PE3] commit

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
*> 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
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
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
#
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
#
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
#
bridge-domain 20
#
undo shutdown
eth-trunk 10
#
return

3.2.24.19 Example for Configuring Co-Existence of a VPLS and an EVPN

When a VPLS network is being evolved 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-128, a VPLS service is deployed. A user wants to deploy
EVPN on PE1 and PE3, that is, 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-128 Configuring co-existence of a VPLS and an EVPN

NOTE
Loopback 0
1.1.1.1/32
PE1
interface1 inte
interface1 10. rface
1.1 2
CE1 .1/2 Loopback 0
4
10.2.1.2/24
interface3
3.3.3.3/32
Site1 inte
10. rface1
1.1 interface1 CE3
.2/2
10.2.1.1/24
4
interface2
interface3
e3 e2 PE3
rfac r fa c
inte .1.1/2
4 inte .2/24 Site3
.1
10.
3 1 0 .3
interface1
interface1
CE2 PE2
Site2 Loopback 0
2.2.2.2/32
Precautions
When you configure co-existence of VPLS and EVPN, note the following:
recommended.

1. Create an EVPN instance in BD mode and a BD on each of PE1 and PE3, and bind the
BD to the EVPN instance on each PE.
2. Configure a source address on each of PE1 and PE3.
3. Establish a BGP EVPN peer relationship between PE1 and PE3.
Data Preparation
Procedure
Step 1 Ensure that an EVC has been configured to carry a VPLS service. For configuration details,
see Configuration Files in this section.
Run the display vsi name e1 verbose command on PE1. The command output shows that
VSI e1 has PWs to PE2 and PE3 established separately, and the VSI status and the PW status
are both Up.
[~PE1] display vsi name e1 verbose
***VSI Name : e1
Work Mode : bd-mode
VSI Index : 2
PW Signaling : bgp
MTU : 1500
Service Class : --
Color : --
DomainId : 255
Domain Name :
P2P VSI : disable
VSI State : up
BGP RD : 100:1
SiteID/Range/Offset : 1/10/0
Import vpn target : 1:1
Export vpn target : 1:1
Remote Label Block : 294928/8/0 294928/8/0
Local Label Block : 0/294928/8/0

Vac State : up
Last Up Time : 2018/03/23 11:01:50
**PW Information:

PW State : up


PW Type : label
Tunnel ID : 0x0000000001004c4bc1
Ckey : 129
Nkey : 16777346
Main PW Token : 0x0
Tnl Type : ldp
OutInterface : --
Stp Enable : 0
Mac Flapping : 0
PW Last Up Time : 2018/03/23 11:38:42
PW State : up
PW Type : label
Tunnel ID : 0x0000000001004c4b42
Ckey : 130
Nkey : 16777347
Main PW Token : 0x0
Tnl Type : ldp
OutInterface : --
Stp Enable : 0
Mac Flapping : 0
PW Last Up Time : 2018/03/23 11:39:10

# Configure PE1.
[*PE1-bd10] quit
[*PE1] commit
# Configure PE3.
[*PE3-bd10] quit
[*PE3] commit

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

[*PE3] commit
Step 4 Establish a BGP EVPN peer relationship between PE1 and PE3.
# Configure PE1.
[~PE1] bgp 100
[~PE1-bgp] l2vpn-family evpn
[*PE1-bgp] quit
[*PE1] commit
# Configure PE3.
[~PE3] bgp 100
[~PE3-bgp] l2vpn-family evpn
[*PE3-bgp] quit
[*PE3] commit

After the configurations are complete, run the display bgp evpn peer command on PE1. The
command output shows that the BGP EVPN peer relationship is established between the PEs
and is in Established state.


PrefRcv
3.3.3.3 4 100 7 9 0 00:00:07
Established 1
the inclusive multicast route received from PE3.


*> 0:32:1.1.1.1 127.0.0.1
*>i 0:32:3.3.3.3 3.3.3.3
m
*> 0:32:1.1.1.1 127.0.0.1
*>i 0:32:3.3.3.3 3.3.3.3
Run the display alarm active root verbose command on PE1. The command output shows
information about the alarm triggered when the VPLS VC on PE1 goes Down. The value of

HWL2VpnStateChangeReason (alarm cause parameter) is 98, indicating that the

establishment of an EVPN connection causes the VPLS VC to go Down.
[~PE1] display alarm active root verbose
Sequence : 46
AlarmId : 0xD4D0001 AlarmName :
hwVplsVcDown
AlarmType : communication Severity : Major State : active
RootKindFlag: Independent
StartTime : 2018-03-26 02:42:23
Description : The status of the VPLS VC turned DOWN. (VsiName=e1, PwId=3,
RemoteIp=3.3.3.3, PwType=1, HWL2VpnStateChangeReason=98, SysUpTime=23691243,
TunnelPolicyName=-)
Run the display vsi name e1 verbose command on PE1. The command output shows that
only the PW to PE2 is available and the PW status is Up.
[~PE1] display vsi name e1 verbose
***VSI Name : e1
Work Mode : bd-mode
VSI Index : 2
PW Signaling : bgp
MTU : 1500
Service Class : --
Color : --
DomainId : 255
Domain Name :
P2P VSI : disable
VSI State : up
BGP RD : 100:1
SiteID/Range/Offset : 1/10/0
Import vpn target : 1:1
Export vpn target : 1:1
Remote Label Block : 294928/8/0 294928/8/0
Local Label Block : 0/294928/8/0

Vac State : up
Last Up Time : 2018/03/23 11:01:50
**PW Information:

PW State : up
PW Type : label
Tunnel ID : 0x0000000001004c4bc1
Ckey : 129
Nkey : 16777346
Main PW Token : 0x0
Tnl Type : ldp
OutInterface : --

Stp Enable : 0
Mac Flapping : 0
PW Last Up Time : 2018/03/23 11:38:42
----End
Configuration Files
#
sysname PE1
#
#
mpls lsr-id 1.1.1.1
#
mpls
#
mpls l2vpn
#
vsi e1 bd-mode
pwsignal bgp
site 1 range 10 default-offset 0
#
bridge-domain 10
l2 binding vsi e1
#
mpls ldp
#
undo shutdown
#
bridge-domain 10
#
undo shutdown
ip address 10.1.1.1 255.255.255.0
mpls
mpls ldp
#
undo shutdown
ip address 10.2.1.2 255.255.255.0
mpls
mpls ldp
#
interface LoopBack0
ip address 1.1.1.1 255.255.255.255
#
bgp 100
#
ipv4-family unicast

peer 2.2.2.2 enable

peer 3.3.3.3 enable
#
l2vpn-ad-family
policy vpn-target
signaling vpls
peer 2.2.2.2 enable
peer 3.3.3.3 enable
#
l2vpn-family evpn
peer 3.3.3.3 enable
#
ospf 1
area 0.0.0.0
network 1.1.1.1 0.0.0.0
network 10.1.1.0 0.0.0.255
network 10.2.1.0 0.0.0.255
#
#
return
#
sysname PE2
#
mpls lsr-id 2.2.2.2
#
mpls
#
mpls l2vpn
#
vsi e1 bd-mode
pwsignal bgp
#
bridge-domain 10
l2 binding vsi e1
#
mpls ldp
#
undo shutdown
#
rewrite pop single
bridge-domain 10
#
undo shutdown
ip address 10.2.1.1 255.255.255.0
mpls
mpls ldp
#
undo shutdown
ip address 10.3.1.1 255.255.255.0
mpls
mpls ldp
#
interface LoopBack0
ip address 2.2.2.2 255.255.255.255
#
bgp 100


#
ipv4-family unicast
peer 1.1.1.1 enable
peer 3.3.3.3 enable
#
l2vpn-ad-family
policy vpn-target
signaling vpls
peer 1.1.1.1 enable
peer 3.3.3.3 enable
#
ospf 1
area 0.0.0.0
network 2.2.2.2 0.0.0.0
network 10.2.1.0 0.0.0.255
network 10.3.1.0 0.0.0.255
#
return
#
sysname PE3
#
#
mpls lsr-id 3.3.3.3
#
mpls
#
mpls l2vpn
#
vsi e1 bd-mode
pwsignal bgp
#
bridge-domain 10
l2 binding vsi e1
#
mpls ldp
#
undo shutdown
ip address 10.1.1.2 255.255.255.0
mpls
mpls ldp
#
undo shutdown
ip address 10.3.1.2 255.255.255.0
mpls
mpls ldp
#
undo shutdown
#
rewrite pop single
bridge-domain 10

#
interface LoopBack0
ip address 3.3.3.3 255.255.255.255
#
bgp 100
#
ipv4-family unicast
peer 1.1.1.1 enable
peer 2.2.2.2 enable
#
l2vpn-ad-family
policy vpn-target
signaling vpls
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
port trunk allow-pass vlan 10
#
return
#
sysname CE2
#
portswitch
undo shutdown
#
return
#
sysname CE3
#
portswitch
undo shutdown
#
return

3.2.24.20 Example for Configuring a DCI Scenario with a VXLAN EVPN

Accessing an MPLS EVPN IRB
This section provides an example for configuring a DCI scenario with a VXLAN EVPN
accessing an MPLS EVPN IRB. In this example, a data center gateway is connected to the
DCI backbone network through a VXLAN tunnel, and BGP EVPN is deployed on the DCI
backbone network to implement data center interconnection.
On the network shown in Figure 3-129, 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-129 Configuring a DCI scenario with a VXLAN EVPN accessing an MPLS EVPN
IRB
NOTE
In this example, Interface 1 and Interface 2 refer to GigabitEthernet 1/0/0 and GigabitEthernet 2/0/0,
respectively.

DCI-PE1 DCI-PE2
Interface 1 P Interface 1
VXLAN VXLAN


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

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
l RDs of the VPN and EVPN instances
l Import and export VPN targets of the VPN and EVPN instances

Procedure
Step 1 Assign an IP address to each node interface, including the loopback interfaces.
Step 2 Configure an IGP on the DCI backbone network. OSPF is used in this example.
Step 4 On each DCI-PE, configure a static route destined for the loopback interface of the connected
DC-GW.
Step 5 Configure an EVPN instance and a BD on each DCI-PE.
[*DCI-PE1-bd10] esi 0000.1111.1111.4444.5555
[*DCI-PE1] commit
[*DCI-PE2-bd10] esi 0000.1111.3333.4444.5555
[*DCI-PE2] commit
Step 6 Configure a source address on each DCI-PE.
[*DCI-PE1] commit
[*DCI-PE2] commit

Step 7 Configure the DCI-PEs to establish a BGP EVPN peer relationship with each other and BGP
EVPN peer relationships with the DC-GWs.
[~DCI-PE1] bgp 100
[*DCI-PE1-bgp] quit
[*DCI-PE1] commit
[~DCI-PE2] bgp 100
[*DCI-PE2-bgp] quit
[*DCI-PE2] commit
Step 8 Configure a VPN instance.

[*DCI-PE1-vpn-instance-vpn1-af-ipv4] evpn mpls routing-enable
[*DCI-PE1] commit
[*DCI-PE2-vpn-instance-vpn1-af-ipv4] evpn mpls routing-enable


[*DCI-PE2] commit
Step 9 Configure VXLAN tunnels between the DCI-PEs and DC-GWs.

[*DCI-PE1] commit
[*DCI-PE2] commit
Step 10 Apply a tunnel policy.

[*DCI-PE1-vpn-instance-vpn1-af-ipv4] tnl-policy te-lsp1 evpn
[*DCI-PE1] evpn vpn-instance evrf1 bd-mode
[*DCI-PE1-evpn-instance-evrf1] tnl-policy te-lsp1
[*DCI-PE1] commit
[*DCI-PE2-vpn-instance-vpn1-af-ipv4] tnl-policy te-lsp1 evpn
[*DCI-PE2] evpn vpn-instance evrf1 bd-mode
[*DCI-PE2-evpn-instance-evrf1] tnl-policy te-lsp1
[*DCI-PE2] commit
Step 11 Enable each DCI-PE to advertise regenerated routes to each BGP EVPN peer.
[~DCI-PE1] bgp 100
[*DCI-PE1-bgp-vpn1] import-route direct
[*DCI-PE1-bgp-af-evpn] peer 3.3.3.3 advertise route-reoriginated evpn mac-ip
[*DCI-PE1-bgp-af-evpn] peer 3.3.3.3 advertise route-reoriginated evpn mac
[*DCI-PE1-bgp-af-evpn] peer 3.3.3.3 advertise route-reoriginated evpn ip
[*DCI-PE1-bgp-af-evpn] peer 3.3.3.3 advertise irb


[*DCI-PE1-bgp] quit
[*DCI-PE1] commit
[~DCI-PE2] bgp 100
[*DCI-PE2-bgp-vpn1] import-route direct
[*DCI-PE2-bgp-af-evpn] peer 1.1.1.1 advertise route-reoriginated evpn mac
[*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.
route
------------------------------------------------------------------------------
10.1.1.0/24 EBGP 255 0 RD 4.4.4.4 VXLAN

10.2.1.0/24 IBGP 255 0 RD 3.3.3.3 Tunnel1
----End
Configuration Files
#
sysname DCI-PE1
#
tnl-policy te-lsp1
#
ipv4-family


tnl-policy te-lsp1 evpn
vxlan vni 555
#
mpls lsr-id 1.1.1.1
#
mpls
mpls te
mpls rsvp-te
mpls te cspf
#
bridge-domain 10
#
interface Vbdif10
ip address 10.10.10.1 255.255.255.0
#
undo shutdown
ip address 192.168.20.1 255.255.255.0
#
encapsulation qinq
bridge-domain 10
#
undo shutdown
ip address 192.168.1.1 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 1.1.1.1 255.255.255.255
#
interface LoopBack2
ip address 11.11.11.11 255.255.255.255
#
interface Nve1
source 11.11.11.11
#
interface Tunnel1
destination 3.3.3.3
#
bgp 100
#
ipv4-family unicast
peer 3.3.3.3 enable
peer 4.4.4.4 enable
#
import-route direct
#
l2vpn-family evpn

peer 3.3.3.3 enable

peer 3.3.3.3 advertise route-reoriginated evpn mac
peer 4.4.4.4 enable
#
ospf 1
area 0.0.0.0
network 1.1.1.1 0.0.0.0
network 192.168.1.0 0.0.0.255
mpls-te enable
#
ip route-static 4.4.4.4 255.255.255.255 192.168.20.2
#
#
#
return
#
sysname P
#
mpls lsr-id 2.2.2.2
#
mpls
mpls te
mpls rsvp-te
mpls te cspf
#
undo shutdown
ip address 192.168.1.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
undo shutdown
ip address 192.168.10.1 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 2.2.2.2 255.255.255.255
#
ospf 1
area 0.0.0.0
network 2.2.2.2 0.0.0.0
network 192.168.1.0 0.0.0.255
network 192.168.10.0 0.0.0.255
mpls-te enable
#
return
#
sysname DCI-PE2

#
tnl-policy te-lsp1
#
ipv4-family
vxlan vni 555
#
mpls lsr-id 3.3.3.3
#
mpls
mpls te
mpls rsvp-te
mpls te cspf
#
bridge-domain 10
#
interface Vbdif10
ip address 10.20.10.1 255.255.255.0
#
undo shutdown
ip address 192.168.30.1 255.255.255.0
#
encapsulation qinq
bridge-domain 10
#
undo shutdown
ip address 192.168.10.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 3.3.3.3 255.255.255.255
#
interface LoopBack2
ip address 33.33.33.33 255.255.255.255
#
interface Nve1
source 33.33.33.33
#
interface Tunnel1
destination 1.1.1.1
#
bgp 100


#
ipv4-family unicast
peer 1.1.1.1 enable
peer 5.5.5.5 enable
#
import-route direct
#
l2vpn-family evpn
peer 1.1.1.1 enable
peer 5.5.5.5 enable
#
ospf 1
area 0.0.0.0
network 3.3.3.3 0.0.0.0
network 192.168.10.0 0.0.0.255
mpls-te enable
#
ip route-static 5.5.5.5 255.255.255.255 192.168.30.2
#
#
#
return

See the configuration file of a DC device.
3.2.24.21 Example for Configuring a DCI Scenario with a VLAN Base Accessing
an MPLS EVPN IRB (Using EVPN-MPLS as the Bearer and PE as a GW)
The underlay VLAN access to DCI uses different cloud management platforms, and an
Ethernet sub-interface is associated with a VLAN to access the DCI backbone network, with

integrated deployment of DCI-PEs and DC-GWs (DCI-PE1-GW1 and DCI-PE2-GW2). A

BGP EVPN peer relationship is established between the DCI-PE-GWs.
A DC-GW and a DCI-PE are the same device, which is directly connected to a DC device. On
the network shown in Figure 3-130, 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-130 Configuring underlay VLAN access to DCI(Using EVPN-MPLS as the bearer
and PE as a GW)
NOTE
In this example, Interface 1, Interface 2, and sub-interface1.1 refer to GE 1/0/0, GE 2/0/0, and GE
1/0/0.1, respectively.

DCI-PE1-GW1 DCI-PE2-GW2
Device1 Device2
VSwitch VSwitch
VMa1 VMa2 VMb1 VMb2
Data center A Data center B

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
P GE 1/0/0 192.168.1.2/24


Name
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
l MPLS LSR IDs of the DCI-PE-GWs and P

l Import and export VPN targets of the VPN instance
Procedure
Step 1 Assign an IP address to each node interface, including the loopback interfaces.
Step 2 Configure an IGP on the DCI backbone network. OSPF is used in this example.

Step 4 Configure a VPN instance on each DCI-PE-GW and apply a tunnel policy to the VPN
instance.
# Configure DCI-PE1-GW1.
[~DCI-PE1-GW1] tunnel-policy te-lsp1
[*DCI-PE1-GW1-tunnel-policy-te-lsp1] tunnel select-seq cr-lsp load-balance-number
1
[*DCI-PE1-GW1-tunnel-policy-te-lsp1] quit
[*DCI-PE1-GW1] ip vpn-instance vpn1
[*DCI-PE1-GW1-vpn-instance-vpn1] ipv4-family
[*DCI-PE1-GW1-vpn-instance-vpn1-af-ipv4] route-distinguisher 11:11
[*DCI-PE1-GW1-vpn-instance-vpn1-af-ipv4] tnl-policy te-lsp1 evpn
[*DCI-PE1-GW1-vpn-instance-vpn1-af-ipv4] vpn-target 11:1 both evpn
[*DCI-PE1-GW1-vpn-instance-vpn1-af-ipv4] evpn mpls routing-enable
[*DCI-PE1-GW1-vpn-instance-vpn1-af-ipv4] quit
[*DCI-PE1-GW1-vpn-instance-vpn1] quit
[*DCI-PE1-GW1] commit
[~DCI-PE2-GW2] tunnel-policy te-lsp1
[*DCI-PE2-GW2-tunnel-policy-te-lsp1] tunnel select-seq cr-lsp load-balance-number
1
[*DCI-PE2-GW2-tunnel-policy-te-lsp1] quit
[*DCI-PE2-GW2] ip vpn-instance vpn1
[*DCI-PE2-GW2-vpn-instance-vpn1] ipv4-family
[*DCI-PE2-GW2-vpn-instance-vpn1-af-ipv4] route-distinguisher 11:11
[*DCI-PE2-GW2-vpn-instance-vpn1-af-ipv4] tnl-policy te-lsp1 evpn
[*DCI-PE2-GW2-vpn-instance-vpn1-af-ipv4] vpn-target 11:1 both evpn
[*DCI-PE2-GW2-vpn-instance-vpn1-af-ipv4] evpn mpls routing-enable
[*DCI-PE2-GW2-vpn-instance-vpn1-af-ipv4] quit
[*DCI-PE2-GW2-vpn-instance-vpn1] quit
Step 5 Configure each DCI-PE-GW to advertise IP prefix routes.

[~DCI-PE1-GW1] bgp 100
[*DCI-PE1-GW1-bgp] ipv4-family vpn-instance vpn1
[*DCI-PE1-GW1-bgp-vpn1] import-route direct
[*DCI-PE1-GW1-bgp-vpn1] advertise l2vpn evpn
[*DCI-PE1-GW1-bgp-vpn1] quit
[~DCI-PE2-GW2] bgp 100
[*DCI-PE2-GW2-bgp] ipv4-family vpn-instance vpn1
[*DCI-PE2-GW2-bgp-vpn1] import-route direct
[*DCI-PE2-GW2-bgp-vpn1] advertise l2vpn evpn
[*DCI-PE2-GW2-bgp-vpn1] quit
Step 6 Configure an EVPN instance on each DCI-PE-GW and establish a BGP EVPN peer
relationship between the DCI-PE-GWs, and configure each DCI-PE-GW to advertise IRB
routes.
[~DCI-PE1-GW1] evpn vpn-instance evrf1 bd-mode
[*DCI-PE1-GW1-evpn-instance-evrf1] route-distinguisher 10:1
[*DCI-PE1-GW1-evpn-instance-evrf1] vpn-target 11:1
[*DCI-PE1-GW1-evpn-instance-evrf1] tnl-policy te-lsp1
[*DCI-PE1-GW1-evpn-instance-evrf1] quit
[*DCI-PE1-GW1] bridge-domain 10
[*DCI-PE1-GW1-bd10] evpn binding vpn-instance evrf1
[*DCI-PE1-GW1-bd10] quit

[*DCI-PE1-GW1] bgp 100

[*DCI-PE1-GW1-bgp] peer 3.3.3.3 as-number 100
[*DCI-PE1-GW1-bgp] peer 3.3.3.3 connect-interface loopback 1
[*DCI-PE1-GW1-bgp] l2vpn-family evpn
[*DCI-PE1-GW1-bgp-af-evpn] peer 3.3.3.3 enable
[*DCI-PE1-GW1-bgp-af-evpn] peer 3.3.3.3 advertise irb
[*DCI-PE1-GW1-bgp-af-evpn] quit
[*DCI-PE1-GW1-bgp] quit
[~DCI-PE2-GW2] evpn vpn-instance evrf1 bd-mode
[*DCI-PE2-GW2-evpn-instance-evrf1] route-distinguisher 10:1
[*DCI-PE2-GW2-evpn-instance-evrf1] vpn-target 11:1
[*DCI-PE2-GW1-evpn-instance-evrf1] tnl-policy te-lsp1
[*DCI-PE2-GW2-evpn-instance-evrf1] quit
[*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 20.1.1.1 255.255.255.0
[*DCI-PE2-GW2-Vbdif10] arp collect host enable
[*DCI-PE2-GW2-Vbdif10] quit
Step 8 Configure a source address on each DCI-PE-GW.

# Configure DCI-PE-GW1.
[~DCI-PE-GW1] evpn source-address 1.1.1.1
[*DCI-PE-GW1] commit
# Configure DCI-PE-GW2.
[~DCI-PE-GW2] evpn source-address 3.3.3.3

[*DCI-PE-GW2] commit
Run the display bgp evpn all routing-table command on a DCI-PE-GW. The command
output shows EVPN IRB routes received from the connected DCI-PE-GW and the remote
DCI-PE-GW. The following uses the command output on DCI-PE1-GW1 as an example.
[~DCI-PE1-GW1] display bgp evpn all routing-table


*>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:32:20.1.1.1 3.3.3.3
*>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:20.1.1.0:24 3.3.3.3

*> 0:10.1.1.0:24 0.0.0.0

*>i 0:20.1.1.0:24 3.3.3.3
Run the display ip routing-table vpn-instance command on a DC-PE-GW. The command

output shows the VPN routes received from the remote DC-PE-GW. The following uses the
command output on DCI-PE1-GW1 as an example.
[~DCI-PE1-GW1] display ip routing-table vpn-instance vpn1
------------------------------------------------------------------------------
10.1.1.0/24 Direct 0 0 D 10.1.1.1 Vbdif10

10.1.1.1/32 Direct 0 0 D 127.0.0.1 Vbdif10
10.1.1.255/32 Direct 0 0 D 127.0.0.1 Vbdif10
20.1.1.0/24 IBGP 255 0 RD 3.3.3.3 Tunnel1
20.1.1.1/32 IBGP 255 0 RD 3.3.3.3 Tunnel1
----End
Configuration Files
l 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
#
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
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
l 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 20.1.1.1 255.255.255.0
#
undo shutdown
#
rewrite pop single
bridge-domain 10
#
undo shutdown
ip address 192.168.10.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
interface Pos3/1/3
link-protocol ppp
undo shutdown
#
interface LoopBack1
ip address 3.3.3.3 255.255.255.255

#
interface Tunnel1
destination 1.1.1.1
#
bgp 100
#
ipv4-family unicast
peer 1.1.1.1 enable
#
import-route direct
#
l2vpn-family evpn
peer 1.1.1.1 enable
#
ospf 1
area 0.0.0.0
network 3.3.3.3 0.0.0.0
network 192.168.10.0 0.0.0.255
mpls-te enable
#
#
#
return

3.2.24.22 Example for Splicing a Common L3VPN with an EVPN L3VPN

This section provides an example for splicing a common L3VPN with an EVPN L3VPN to
implement communication between the two networks.
An L3VPN is deployed over the MAN and is being replaced with an EVPN. If a lot of
devices are deployed on the MAN, end-to-end replacement may not be implemented at a time.
Therefore, co-existence of the L3VPN and EVPN occurs during the network reconstruction.
On the network shown in Figure 3-131, 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-131 Splicing a Common L3VPN with an EVPN L3VPN

NOTE
In this example, Interface 1 and Interface 2 refer to GigabitEthernet 1/0/0 and GigabitEthernet 2/0/0,
respectively.

UPE NPE1 NPE2

Site1 Site2

Name
UPE GigabitEthernet 2/0/0 192.168.20.1/24
Loopback 1 1.1.1.1/32
Loopback 1 2.2.2.2/32
Loopback 1 3.3.3.3/32
1. Deploy IGPs on the UPE, NPE1, and NPE2. In this example, OSPF runs between the
UPE and NPE1, and IS-IS runs between NPE1 and NPE2.
2. Configure MPLS LDP on the UPE, NPE1, and NPE2.
3. Configure L3VPN instances on the UPE and NPE1, and establish a BGP VPNv4
connection between them.
4. Establish a BGP EVPN connection between NPE1 and NPE2.
5. Configure an L3VPN instance and binding it to an interface on NPE2 to access Layer 3
services.

6. Enable NPE1 to regenerate routes.
Data Preparation
l MPLS LSR IDs of the UPE and NPEs
l RDs of the L3VPN instances
l 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

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

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

192.168.20.0/24 IBGP 255 0 RD 2.2.2.2

192.168.30.0/24 Direct 0 0 D 192.168.30.1 Vbdif10
192.168.30.1/32 Direct 0 0 D 127.0.0.1 Vbdif10
192.168.30.255/32 Direct 0 0 D 127.0.0.1 Vbdif10
----End
Configuration Files
#
sysname UPE
#
ipv4-family
#
mpls lsr-id 1.1.1.1
#
mpls
#
mpls ldp
#
undo shutdown
ip address 10.1.1.1 255.255.255.0
mpls
mpls ldp
#
undo shutdown
ip address 192.168.20.1 255.255.255.0
#
interface LoopBack1
ip address 1.1.1.1 255.255.255.255
#
bgp 100
#
ipv4-family unicast
peer 2.2.2.2 enable
#
ipv4-family vpnv4
policy vpn-target
peer 2.2.2.2 enable
#
import-route direct
peer 192.168.20.2 as-number 65410
#
ospf 1
area 0.0.0.0
network 1.1.1.1 0.0.0.0
network 10.1.1.0 0.0.0.255
#
return

#
sysname NPE1
#

ipv4-family
#
mpls lsr-id 2.2.2.2
#
mpls
#
mpls ldp
#
isis 1
network-entity 10.0000.0000.0002.00
#
undo shutdown
ip address 10.1.1.2 255.255.255.0
mpls
mpls ldp
#
undo shutdown
ip address 10.2.1.1 255.255.255.0
isis enable 1
mpls
mpls ldp
#
interface LoopBack1
ip address 2.2.2.2 255.255.255.255
isis enable 1
#
bgp 100
#
ipv4-family unicast
peer 1.1.1.1 enable
peer 3.3.3.3 enable
#
ipv4-family vpnv4
policy vpn-target
peer 1.1.1.1 enable
#
#
l2vpn-family evpn
peer 3.3.3.3 enable
#
ospf 1
area 0.0.0.0
network 2.2.2.2 0.0.0.0
network 10.1.1.0 0.0.0.255

#
return

#
sysname NPE2
#
ipv4-family
#
mpls lsr-id 3.3.3.3
#
mpls
#
mpls ldp
#
isis 1
network-entity 10.0000.0000.0003.00
#
undo shutdown
ip address 10.2.1.2 255.255.255.0
isis enable 1
mpls
mpls ldp
#
undo shutdown
ip address 192.168.30.1 255.255.255.0
#
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.24.23 Example for Splicing a VPLS in PW Redundancy Mode with an Anycast

VXLAN in an EVPN Active-Active Scenario
This section provides an example for splicing a VPLS in PW redundancy mode with an
anycast VXLAN in an EVPN active-active Scenario.

communicate with the external network through the VPLS network, on which PW
redundancy is configured. Specifically, the PE-AGG connects to PE1 and PE2 through
primary and secondary PWs, respectively.
Figure 3-132 Splicing a VPLS in PW redundancy mode with an anycast VXLAN in an

EVPN active-active scenario
NOTE
In this example, interface1, interface2, and interface3 refer to GigabitEhernet 1/0/1, GigabitEhernet
1/0/2, and GigabitEhernet 1/0/3, respectively.
Server
TOR
Anycast VXLAN
1
in
ce
te
r fa
rfa
te
ce
in
PE1 Anycast VTEP PE2

1
Bypass VXLAN
int 2
er f ce
ac t e rfa
e 2 VPLS in
i nt
erf e2
a ac
ce erf
1 int
PE-AGG
Network


Device Interface IP Address and Mask
Name
GigabitEhernet 1/0/1 10.1.14.1/24

PE1
Loopback 1 1.1.1.1/32
Loopback 2 1.1.1.100/32
Loopback 3 1.1.1.20/32
PE2 GigabitEhernet 1/0/1 10.2.14.1/24
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

l EVPN instance name

l RD and RT of the EVPN instance
Procedure
Step 1 Configure interface IP addresses, an IGP, and MPLS functions on each device.
Step 2 Configure BGP EVPN on PE1 and PE2.
# Configure PE1.
[~PE1] evpn
[*PE1-evpn] bypass-vxlan enable
[*PE1-evpn] quit
[*PE1] bgp 100
[*PE1-bgp] peer 2.2.2.100 connect-interface LoopBack 2
[*PE1-bgp] quit
[*PE1] commit
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-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
section.

Step 4 Configure primary and secondary PWs on the PE-AGG.
# Configure the PE-AGG.

[~PE-AGG] mpls l2vpn
[*PE-AGG-l2vpn] quit
[*PE-AGG] vsi vsi1 bd-mode
[*PE-AGG-vsi1] pwsignal ldp
[*PE-AGG-vsi1-ldp] vsi-id 1
[*PE-AGG-vsi1-ldp] peer 1.1.1.1
[*PE-AGG-vsi1-ldp] peer 2.2.2.2
[*PE-AGG-vsi1-ldp] protect-group 10
[*PE-AGG-vsi1-ldp-protect-group-10] protect-mode pw-redundancy master
[*PE-AGG-vsi1-ldp-protect-group-10] peer 1.1.1.1 preference 1
[*PE-AGG-vsi1-ldp-protect-group-10] peer 2.2.2.2 preference 2
[*PE-AGG-vsi1-ldp-protect-group-10] quit
[*PE-AGG-vsi1-ldp] quit
[*PE-AGG-vsi1] quit
[*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
Run the display vxlan tunnel command on PE1 and check information about the VXLAN
tunnels.
----------------------------------------------------------------------------------
-
4026531842 1.1.1.100 2.2.2.100 up dynamic 01:31:05
4026531843 1.1.1.20 4.4.4.100 up dynamic 00:32:51
Run the display vsi command on PE1 and check the VSI status.
[~PE1] display vsi
Total VSI number is 1, 1 is up, 0 is down, 1 is LDP mode, 0 is BGP mode, 0 is
BGPAD mode, 0 is mixed mode, 0 is unspecified mode
--------------------------------------------------------------------------
Vsi Mem PW Mac Encap Mtu Vsi
Name Disc Type Learn Type Value State
--------------------------------------------------------------------------
vsi1 -- ldp qualify vlan 1500 up
Run the display vsi name vsi1 protect-group 10 command on the PE-AGG and check
information about the PW protection group in the VSI.

[~PE-AGG] display vsi name vsi1 protect-group 10
Protect-group: 10
-------------------------------------------------------------------------------
PeerIp:VcId Pref Active
-------------------------------------------------------------------------------
1.1.1.1:1 1 Active
2.2.2.2:1 2 Inactive
----End
Configuration Files
#
sysname PE1
#
evpn
bypass-vxlan enable
#
evpn vpn-instance evpn1 bd-mode
#
mpls lsr-id 1.1.1.1
#
mpls
#
mpls l2vpn
#
vsi vsi1 bd-mode
pwsignal ldp
vsi-id 1
peer 3.3.3.3 ac-mode
#
bridge-domain 10
evpn binding vpn-instance evpn1
l2 binding vsi vsi1
#
mpls ldp
#
isis 1
network-entity 10.0000.0000.0001.00
#
undo shutdown
ip address 10.1.14.1 255.255.255.0
isis enable 1
#
undo shutdown
ip address 10.1.13.1 255.255.255.0
mpls
mpls ldp
#
undo shutdown
ip address 10.1.1.1 255.255.255.0
isis enable 1
#
interface LoopBack1
ip address 1.1.1.1 255.255.255.255
#
interface LoopBack2
ip address 1.1.1.100 255.255.255.255
isis enable 1

#
interface LoopBack3
ip address 1.1.1.20 255.255.255.255
isis enable 1
#
interface Nve1
source 1.1.1.20
bypass source 1.1.1.100
mac-address 00e0-fc12-3456
#
bgp 100
#
ipv4-family unicast
#
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
#
#
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
l2 binding vsi vsi1
#
mpls ldp
#
isis 1
network-entity 10.0000.0000.0002.00
#

undo shutdown
ip address 10.2.14.1 255.255.255.0
isis enable 1
#
undo shutdown
ip address 10.2.13.1 255.255.255.0
mpls
mpls ldp
#
undo shutdown
ip address 10.1.1.2 255.255.255.0
isis enable 1
#
interface LoopBack1
ip address 2.2.2.2 255.255.255.255
#
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
#
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
l 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
protect-mode pw-redundancy master
#
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
l TOR configuration file

3.2.24.24 Example for Configuring an EVPN L3VPN HoVPN

This section provides an example for configuring an EVPN L3VPN HoVPN to implement
network interworking.
L3VPN HVPN. On the network shown in Figure 3-133, 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 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.

Figure 3-133 EVPN L3VPN HoVPN

NOTE

1.1.1.1/32 2.2.2.2/32 3.3.3.3/32
UPE Interface1 SPE Interface1 NPE
10.1.1.1/24 10.2.1.2/24
10.1.1.2/24 10.2.1.1/24
192.168.20.1/24 192.168.30.1/24
Site1 Site2
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.
8. Configure route regeneration on the SPE.
Data Preparation
l MPLS LSR IDs of the UPE (1.1.1.1), SPE (2.2.2.2), and NPE (3.3.3.3)
l VPN instance name (vpn1) and RD (100:1)
l 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.
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
[*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] 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
Step 9 Configure route regeneration on the SPE.

[~SPE] bgp 100


[*SPE-bgp-af-evpn] peer 1.1.1.1 import reoriginate
[*SPE-bgp-af-evpn] peer 3.3.3.3 advertise route-reoriginated evpn ip
[*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.
[~NPE] display bgp evpn all routing-table


*>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
*>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.20.0/24 IBGP 255 0 RD 2.2.2.2

192.168.30.0/24 Direct 0 0 RD 192.168.30.1
192.168.30.1/32 Direct 0 0 D 127.0.0.1
192.168.30.255/32 Direct 0 0 D 127.0.0.1
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
*>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
------------------------------------------------------------------------------
0.0.0.0/0 IBGP 255 0 RD 2.2.2.2

192.168.20.0/24 Direct 0 0 RD 192.168.20.1
192.168.20.1/32 Direct 0 0 D 127.0.0.1
192.168.20.255/32 Direct 0 0 D 127.0.0.1
----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
#
import-route direct
#
l2vpn-family evpn
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
l SPE configuration file
#
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
#
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
l NPE configuration file
#
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
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.24.25 Example for Configuring an EVPN L3VPN H-VPN

This section provides an example for configuring an EVPN L3VPN H-VPN to implement
network interworking.
L3VPN HVPN. On the network shown in Figure 3-134, 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
layers. On an EVPN 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-134 EVPN L3VPN H-VPN

NOTE


1.1.1.1/32 2.2.2.2/32 3.3.3.3/32
10.1.1.1/24 10.2.1.2/24
10.1.1.2/24 10.2.1.1/24
192.168.20.1/24 192.168.30.1/24
Site1 Site2
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
l VPN targets 2:2 for EVPN
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
[*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.


*>i 0:192.168.20.0:24 2.2.2.2
*> 0:192.168.30.0:24 0.0.0.0
*>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.


------------------------------------------------------------------------------
192.168.20.0/24 IBGP 255 0 RD 2.2.2.2

192.168.30.0/24 Direct 0 0 RD 192.168.30.1
192.168.30.1/32 Direct 0 0 D 127.0.0.1
192.168.30.255/32 Direct 0 0 D 127.0.0.1
----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
#
import-route direct
#
l2vpn-family evpn

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
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
peer 2.2.2.2 enable
#
return
3.2.24.26 Example for Splicing an EVPN L3VPN HoVPN with a Common L3VPN
This section provides an example for splicing an EVPN L3VPN HoVPN with a common
L3VPN to implement network interworking.
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-135, the UPE and SPE are connected at the
access layer, and the SPE and NPE are connected at the aggregation layer. Separate IGPs are

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-135 Splicing between an EVPN L3VPN HoVPN and a common L3VPN
NOTE

1.1.1.1/32 2.2.2.2/32 3.3.3.3/32
10.1.1.1/24 10.2.1.2/24
10.1.1.2/24 10.2.1.1/24
192.168.20.1/24 192.168.30.1/24
Site1 Site2
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.
Data Preparation

l 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
[*NPE] commit
[*UPE] commit



[*NPE] commit

[*SPE] commit
[*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
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

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

output shows the VPN routes.
------------------------------------------------------------------------------
192.168.20.0/24 IBGP 255 0 RD 2.2.2.2

192.168.30.0/24 Direct 0 0 RD 192.168.30.1
192.168.30.1/32 Direct 0 0 D 127.0.0.1
192.168.30.255/32 Direct 0 0 D 127.0.0.1
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
*>i 0:0.0.0.0:0 2.2.2.2
*> 0:192.168.20.0:24 0.0.0.0
output shows the default VPN routes received from the SPE.
------------------------------------------------------------------------------
0.0.0.0/0 IBGP 255 0 RD 2.2.2.2

192.168.20.0/24 Direct 0 0 RD 192.168.20.1
192.168.20.1/32 Direct 0 0 D 127.0.0.1
192.168.20.255/32 Direct 0 0 D 127.0.0.1
----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
#
import-route direct
#
l2vpn-family evpn
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
#
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
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.24.27 Example for Splicing an L3VPN HoVPN with an EVPN L3VPN

This section provides an example for splicing an L3VPN HoVPN with an EVPN L3VPN to
implement network interworking.
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-136, 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-136 Splicing between an L3VPN HoVPN and an EVPN L3VPN

NOTE


1.1.1.1/32 2.2.2.2/32 3.3.3.3/32
10.1.1.1/24 10.2.1.2/24
10.1.1.2/24 10.2.1.1/24
192.168.20.1/24 192.168.30.1/24
Site1 Site2
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.
Data Preparation
l 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
[*NPE] commit
[*UPE] commit

[*NPE] commit

[*SPE] commit

[*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
[*SPE-bgp] quit

[*SPE] commit

[~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
*>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
output shows the VPN routes received from the UPE.
------------------------------------------------------------------------------
192.168.20.0/24 IBGP 255 0 RD 2.2.2.2

192.168.30.0/24 Direct 0 0 RD 192.168.30.1
192.168.30.1/32 Direct 0 0 D 127.0.0.1
192.168.30.255/32 Direct 0 0 D 127.0.0.1

output shows the default VPN routes.
------------------------------------------------------------------------------
0.0.0.0/0 IBGP 255 0 RD 2.2.2.2

192.168.20.0/24 Direct 0 0 RD 192.168.20.1
192.168.20.1/32 Direct 0 0 D 127.0.0.1
192.168.20.255/32 Direct 0 0 D 127.0.0.1
----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
#
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
#
#
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
peer 2.2.2.2 enable
#


#
#
#
return
3.2.24.28 Example for Configuring IGMP Snooping over EVPN MPLS

conserve bandwidth resources, configure EVPN to use an mLDP P2MP tunnel for service
transmission.
On the network shown in Figure 3-137, 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-137 Configuring IGMP snooping over EVPN MPLS

NOTE
In this example, interface1, interface2, and interface3 stand for GE 1/0/0, GE 2/0/0, and GE 3/0/0,
respectively.

Receiver
Loopback 0
2.2.2.2/32
PE2
interface1
interface2
10.2.1.1/24
3
ce
CE2
rfa
3.3.3.3/32 1.1.1.1/32
te
in
CE4 interface2 interface2 PE1 CE1
10.2.1.2/24 10.1.1.1/24
10.3.1.2/24 10.1.1.2/24
Receiver in RR
te
rfa
CE3 ce
3
interface1
PE3 Multicast
Loopback 0 Source
4.4.4.4/32
Receiver
Precautions
When you configure IGMP snooping over EVPN MPLS, note the following:
l The local loopback interface address is recommended as the source address on each PE.
2. Configure MPLS and mLDP P2MP both globally and per interface on each node of the
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
l EVPN instance evrf1's RD on each PE: 100:1; RT: 1:1
Procedure
is used as an IGP 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
Step 3 Configure MPLS and mLDP P2MP both globally and per interface on each node of the
# 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] 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.
[*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
[*PE3] commit
Step 7 Configure an ESI for each PE's interface connected to a CE.

# 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-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
[*PE3-bgp] quit
[*PE3] commit
# Configure the RR.

[~RR] bgp 100
[*RR-bgp] quit
[*RR] commit



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

command on PE1. The command output shows information related to the root node.
Bridge-domain : 10
Root ip : 1.1.1.1
Opaque value : 01000400008001
State : up

command on PE2 or PE3. The command output shows information related to the leaf node.
Bridge-domain : 10
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 uses the command output
on PE1.
[~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
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
igmp-snooping signal-synch enable
evi vpn-target 100:1 export-extcommunity
evi vpn-target 100:1 import-extcommunity
#
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
#
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
#
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
#
#
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
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
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.24.29 Example for Configuring BD EVPN IRB over SR-TE

This section provides an example for configuring BD EVPN IRB over SR-TE.
On the network shown in Figure 3-138, 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-TE tunnels.
Figure 3-138 Networking of BD EVPN IRB over SR-TE

NOTE

SR-TE
PE1 PE2
sub-interface1.1 sub-interface1.1
CE1 CE2


PE1
Vbdif10 192.168.1.1/24

PE2
Vbdif10 192.168.2.1/24
Configuration Notes
When configuring BD EVPN IRB over SR-TE, note the following:
l On the same EVPN instance, the export VPN target list of a site shares VPN targets with
l 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-TE tunnel on the backbone network.
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-TE tunnels.
8. Establish BGP EVPN peer relationships between PEs.
9. Configure CEs to communicate with PEs.
Data Preparation
l EVPN instance name (evrf1) and VPN instance name (vpn1)
l 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-138.
For configuration details, see the configuration files in this section.
Step 2 Configure an IGP to allow communication between PE1, PE2, and P. IS-IS is used as an IGP
protocol in this example.
# Configure PE1.
[~PE1] isis 1
[*PE1-isis-1] quit
[*PE1] commit
# Configure the P.
[~P] isis 1
[*P-isis-1] quit
[*P-LoopBack1] quit


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

--------------------------------------------------------------------------------
1111.1111.2222 Eth0/1/7 1111.1111.2222.01 Up 8s L2 64
------------------------------------------------------------------------------

2.2.2.2/32 ISIS-L2 15 10 D 10.1.1.2
3.3.3.3/32 ISIS-L2 15 20 D 10.1.1.2
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 ISIS-L2 15 20 D 10.1.1.2
Step 3 Configure an SR-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-Tunnel1] quit
[*PE1] commit
NOTE
The next sid label command uses the adjacency label from PE1 to P which is dynamically generated using
IS-IS. This adjacency label can be obtained using the display segment-routing adjacency mpls forwarding
command.

-----------------------------------------------------------------------------
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
[*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 Attributes :
Traffic Switch : -
Session ID : 1
FTid : 1
Bfd Cap : None
Readjust Value : -
Backup Tunnel : -


Ip-Prefix Name : -
Path Verification : No
Binding Sid : - Reverse Binding Sid : -

IncludeAll : 0x0
IncludeAny : 0x0
ExcludeAny : 0x0
Explicit Path Name : pe1tope2 Hop Limit: -
FRR Flag : Disabled
IdleTime Remain : -
BFD Status : -
Pce Flag : Normal
# Configure PE1.
[*PE1-bd10] quit
[*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.


[*PE2-Vbdif10] quit
[*PE2] commit
Step 8 Configure and apply a tunnel policy so that EVPN can recurse to SR-TE tunnels.
# Configure PE1.
[*PE1] commit
# Configure PE2.
[*PE2] commit
Step 9 Establish BGP EVPN peer relationships between PEs.

# Configure PE1.
[~PE1] bgp 100
[*PE1-bgp] quit
[*PE1] commit
# Configure PE2.
[~PE2] bgp 100
[*PE2-bgp] quit
[*PE2] commit
After completing the configuration, run the display bgp evpn peer command to check that
BGP peer relationships have been established between PEs and are in the Established state.



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

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.


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


*> 0:48:00e0-fc12-7890:0:0.0.0.0 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:0:0.0.0.0 3.3.3.3
*> 0:48:00e0-fc12-7890:0:0.0.0.0 0.0.0.0

*> 0:32:1.1.1.1 127.0.0.1
*>i 0:32:3.3.3.3 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
*> 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:0:0.0.0.0 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)
0.0.0.0/0, ESI:0000.0000.0000.0000.0000
Remote-Cross route
From: 3.3.3.3 (10.2.1.2)
0.0.0.0/0, ESI:0000.0000.0000.0000.0000
[~PE1] display bgp evpn all routing-table prefix-route 0:192.168.2.0:24

From: 3.3.3.3 (10.2.1.2)
internal, best, select, pre 255, IGP cost 20
0000.0000.0000.0000.0000, GW IP Address: 0.0.0.0
Remote-Cross route

From: 3.3.3.3 (10.2.1.2)

internal, best, select, pre 255
0000.0000.0000.0000.0000, GW IP Address: 0.0.0.0
----End
Configuration Files
#
sysname PE1
#
tnl-policy srte
#
ipv4-family
#
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
mpls
mpls te
#
interface LoopBack1
ip address 1.1.1.1 255.255.255.255
isis enable 1
#
interface Tunnel1
destination 3.3.3.3
mpls te reserved-for-binding
mpls te tunnel-id 1
#
interface NULL0
#
bgp 100
#
ipv4-family unicast
peer 3.3.3.3 enable
#
import-route direct
#
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
mpls
mpls te
#
undo shutdown
ip address 10.2.1.1 255.255.255.0
isis enable 1
mpls
mpls te
#
interface LoopBack1
ip address 2.2.2.2 255.255.255.255
isis enable 1
#
return
#
sysname PE2
#
tnl-policy srte
#
ipv4-family
#
mpls lsr-id 3.3.3.3
#
mpls
mpls te
#
bridge-domain 10
#
#
segment-routing
#
isis 1
is-level level-2
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
mpls
mpls te
#
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
#
tunnel-policy srte
#
#
return

#
sysname CE1
#
undo shutdown
#
rewrite pop single
#
return

#
sysname CE2
#
undo shutdown
#
rewrite pop single
#
return

3.3 EVPN Configuration Commands
3.3.1 active port-evpn

Function
The active port-evpn command activates EVPN interface licenses for a board in batches.
The undo active port-evpn command deactivates EVPN interface licenses for a board in
batches.
By default, EVPN interface licenses are not activated for a board.
Format
active port-evpn slot slot-id card card-id port port-list
undo active port-evpn slot slot-id card card-id [ port port-list ]
Parameters
slot slot-id Specifies the slot ID of a board. -
card card-id Specifies a subcard ID. -
port port-list Specifies the interface list of a board, with the interfaces separated by -
commas (,) or hyphens (-).
Views
License view
Default Level

license write
Usage Guidelines
Usage Scenario
The EVPN service can be configured on a board only after EVPN interface licenses are
activated for the board.
Prerequisites

l The license file for the master main control board has been activated using the license
active file-name command.
l 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.
Precautions
This command applies only to the Admin-VS.
Example
# Activate EVPN interface licenses in batches.
<HUAWEI>system-view
[~HUAWEI] license
[*HUAWEI-license] active port-evpn slot 2 card 0 port 0-8
# Deactivate EVPN interface licenses in batches.

<HUAWEI>system-view
[~HUAWEI] license
[*HUAWEI-license] undo active port-evpn slot 2 card 0 port 0-8
3.3.2 display license resource usage port-evpn
Function
The display license resource usage port-evpn command displays authorization information
about EVPN interface licenses on a board.
Format
display license resource usage port-evpn { all | slot slot-id } [ active | deactive ]
Parameters

all Displays authorization information about EVPN interface licenses on -
all boards.
slot slot-id Specifies the slot ID for a board on which authorization information -
about EVPN interface licenses is to be displayed.
active Displays authorization information about EVPN licenses for interfaces -

with the active port-evpn command configured on a board.
deactive Displays authorization information about EVPN licenses for interfaces -

with the active port-evpn command not configured on a board.

Views
All views
Default Level
1: Monitoring level

license read
Usage Guidelines
Usage Scenario
To view authorization information about EVPN interface licenses on aboard, run the display
license resource usage port-evpn command.
Precautions
In VS mode, this command is supported only by the admin VS.
Example
# Display authorization information about EVPN interface licenses on all boards.
<HUAWEI>system-view
[~HUAWEI] display license resource usage port-evpn all
FeatureName Descriptions:
==================================================================================
==
FeatureName
Description
----------------------------------------------------------------------------------
--
LCR9S9KNEVN0P NetEngineXX 100G EVPN Port License(per 100G)
LCR9S9KXEVN0P NetEngineXX 10G EVPN Port License(per 10G)
LCR9S9KNEVN0L NetEngineXX 100G EVPN Port License for Line Process Unit
L(per 100G)
LCR9S9KXEVN0L NetEngineXX 10G EVPN Port License for Line Process Unit
L(per 10G)
Global license information:

==================================================================================
==
FeatureName Offline Allocated Activated Available Total
----------------------------------------------------------------------------------
--
LCR9S9KNEVN0P 0 0 0 0 0
LCR9S9KXEVN0L 0 2 3 0 3
LCR9S9KXEVN0P 0 0 0 0 0
LCR9S9KNEVN0L 0 0 0 0 0
License detailed information:

==================================================================================
==
Physical Position FeatureName Needed Count Used Count Active

Status
----------------------------------------------------------------------------------
--
2/0/0 LCR9S9KXEVN0L 0 0 No allocated
2/0/4 LCR9S9KXEVN0L 1 1 Activated
2/0/7 LCR9S9KXEVN0L 1 0 Allocated
# Display authorization information about EVPN licenses for interfaces with the active port-
evpn command configured on the board in slot 1.
<HUAWEI>system-view
[~HUAWEI] display license resource usage port-evpn slot 1 active
==================================================================================
==
FeatureName
Description
----------------------------------------------------------------------------------
--
L(per 100G)
L(per 10G)
==================================================================================
==
----------------------------------------------------------------------------------
--

==================================================================================
==
Physical Position FeatureName Needed Count Used Count Active Status
----------------------------------------------------------------------------------
--
# Display authorization information about EVPN licenses for interfaces with the active port-
evpn command not configured on the CM board or the LSR board in slot 1.
<HUAWEI>system-view
[~HUAWEI] display license resource usage port-evpn slot 1 deactive
==================================================================================
==
FeatureName
Description

----------------------------------------------------------------------------------
--
L(per 100G)
L(per 10G)

==================================================================================
==
----------------------------------------------------------------------------------
--

==================================================================================
==
Physical Position FeatureName Needed Count Used Count Active
Status
----------------------------------------------------------------------------------
--
Table 3-22 Description of the display license resource usage port-evpn all command output
Item Description
FeatureName Descriptions Description of a feature
FeatureName Feature name
Description Description
Global license information Global information about EVPN interface

licenses
Offline Number of offline interfaces
Allocated Number of interfaces whose EVPN

interface licenses are in Allocated state
Activated Number of interfaces whose EVPN

interface licenses are in Activated state
Available Number of EVPN interface licenses that can

be activated
Total Total number of EVPN interface license

resources

3.3.3 black-hole-dup-mac
Function
The black-hole-dup-mac command configures flapping MAC routes as black-hole routes and
blocks the AC interface that generates flapping MAC routes.
The undo black-hole-dup-mac command restores the default configuration.
By default, flapping MAC routes are not set to black-hole routes, and the AC interface that
generates flapping MAC routes is not blocked.
Format
black-hole-dup-mac [ block-source-interface ]
undo black-hole-dup-mac
Parameters
block-source-interface Blocks the AC interface that generates flapping MAC -
routes.
Views
EVPN-MAC-duplication view
Default Level

bgp write
Usage Guidelines
preventing devices from working properly. In this case, MAC duplication suppression on the
devices works. By default, the system checks the number of times a MAC entry flaps within a
detection period (180s by default). If the number of MAC flaps exceeds the upper threshold (5
by default), 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. To set flapping MAC routes as
black-hole routes, run the black-hole-dup-mac command. After this configuration is
performed, if the source or destination MAC address of the forwarded traffic is the same as
the MAC address of a 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.
Example
# Set flapping MAC routes to black-hole routes, and block the AC interface that generates
flapping MAC routes.
[~HUAWEI] evpn vpn-instance evpna bd-mode
[~HUAWEI-evpn-instance-evpna] mac-duplication
[~HUAWEI-evpn-instance-evpna-mac-dup] black-hole-dup-mac block-source-interface
3.3.4 bypass-vxlan enable
Function
The bypass-vxlan enable command enables the inter-chassis VLXN function.
The undo bypass-vxlan enable command disables the function.
Format
bypass-vxlan enable
undo bypass-vxlan enable
Parameters
None
Views
EVPN global configuration view
Default Level

bgp write
Usage Guidelines
Usage Scenario
In the anycast VXLAN scenario, the dual-homed PEs must have the same VTEP address. As
a result, the dual-homed PEs cannot use the VTEP address to establish a VXLAN tunnel,

causing a traffic forwarding failure. To resolve the problem, run the bypass-vxlan enable
command to enable inter-chassis VXLAN on the PEs and configure different bypass
addresses for the PEs. In this way, the PEs can use the bypass addresses to establish VXLAN
tunnels for traffic forwarding.
Example
# Enable the inter-chassis VXLAN function.
[~HUAWEI] evpn
[~HUAWEI-evpn] bypass-vxlan enable
3.3.5 data-delay-time
Function
The data-delay-time command sets a hold-off time for an mLDP P2MP tunnel to go Up.
The undo data-delay-time command deletes the hold-off time set for an mLDP P2MP tunnel
to go Up.
By default, no hold-off time is set for an mLDP P2MP tunnel to go Up.
Format
data-delay-time delay-time
undo data-delay-time delay-time
Parameters
delay-time Specifies a hold-off time for an mLDP The value is an integer ranging
P2MP tunnel to go Up. from 1 to 300, in seconds.
Views
EVI I-PMSI root view
Default Level

bgp write
Usage Guidelines
Usage Scenario

On a multicast EVPN, if you want an mLDP P2MP tunnel to go Up after all leaf nodes are
configured, run the data-delay-time delay-time command to set a hold-off time for the mLDP
P2MP tunnel to go Up.
Example
# Set the hold-off time to 200s for an mLDP P2MP tunnel to go Up.
[~HUAWEI] evpn vpn-instance evpn1 bd-mode
[~HUAWEI-evpn-instance-evpn1] inclusive-provider-tunnel
[*HUAWEI-evpn-instance-evpn1-inclusive] root
[*HUAWEI-evpn-instance-evpn1-inclusive-root] data-delay-time 200
3.3.6 data-switch disable

Function
The data-switch disable command disables multicast traffic over an EVPN from being
forwarded through a P2P tunnel when an mLDP P2MP tunnel goes Down.
The undo data-switch disable command restores the default configuration.
By default, multicast traffic over an EVPN can be forwarded through a P2P tunnel when an
mLDP P2MP tunnel goes Down.
Format
data-switch disable
undo data-switch disable
Parameters
None
Views
Default Level

bgp write
Usage Guidelines
Usage Scenario
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 the data-switch disable command. This configuration disables
multicast services from being switched to a P2P tunnel once an mLDP P2MP tunnel goes
Down. This ensures that a leaf node receives and processes only multicast traffic from the
backup mLDP P2MP tunnel.
Example
# Disable a BD-EVPN instance from iterating multicast traffic over an EVPN to a P2P tunnel
when an mLDP P2MP tunnel goes Down.
[*HUAWEI-evpn-instance-evpn1-inclusive-root] data-switch disable
3.3.7 description (EVPN)
Function
The description command configures a description for an EVPN instance.
The undo description command deletes the description configured for an EVPN instance.
By default, no description is configured for an EVPN instance.
Format
description description-information
undo description
Parameters

description- Specifies a description for an The value is a string of 1 to 63 case-
information EVPN instance. sensitive characters, spaces supported.
Views
EVPN instance view, B-EVPN instance view, I-EVPN instance view
Default Level


bgp write
Usage Guidelines
Usage Scenario
To configure a description for an EVPN instance for easy memorization, run the description
command.
If the description command is run more than once, the latest configuration overrides the
previous one.
Example
# Configure a description for EVPN instance evpn1.
[~HUAWEI] evpn vpn-instance evpn1
[*HUAWEI-evpn-instance-evpn1] description OnlyForevpn
3.3.8 detect loop-times
Function
The detect loop-times command sets loop detection parameters for MAC duplication
suppression.
The undo detect loop-times command restores the default configuration.
By default, the loop detection period for MAC duplication suppression is 180s, and the
threshold for MAC entry flaps is 5 within a detection period.
Format
detect loop-times loop-times detect-cycle detect-cycle-time
undo detect loop-times [ loop-times ] detect-cycle [ detect-cycle-time ]
Parameters
loop-times Specifies the maximum number The value is an integer ranging from
of times MAC entry flapping is 3 to 10.
allowed in a detection period.
detect-cycle detect- Specifies a detection period. The value is an integer ranging from
cycle-time 60 to 900, in seconds. The value
must be a multiple of 10.

Views
EVPN-MAC-duplication view, EVPN instance MAC-duplication view
Default Level

bgp write
Usage Guidelines
Usage Scenario
detection period (180s by default). If the number of MAC flaps exceeds the upper threshold (5
by default), 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. To modify the detection period or
the threshold for MAC entry flaps, run the detect loop-times command.
If the detect loop-times command is run in both EVPN instance view and global EVPN
configuration view, the configuration in the EVPN instance view takes precedence.
Example
# Set loop detection parameters for MAC duplication suppression.
[~HUAWEI] evpn
[*HUAWEI-evpn] mac-duplication
[*HUAWEI-evpn-mac-dup] detect loop-times 4 detect-cycle 100
3.3.9 display bgp evpn evpl
Function
The display bgp evpn evpl command displays EVPL instance information.
Format
display bgp evpn evpl [ brief | instance-id instance-id | local-service-id service-id ]

Parameters
instance-id Specifies an EVPL instance The value is a decimal integer ranging from 1
ID. to 4294967295.
service-id Specifies a local service ID. The value is a decimal integer ranging from 1
to 16777215.
Views
All view
Default Level
1: Monitoring level

bgp debug
Usage Guidelines
To view EVPL instance information, run the display bgp evpn evpl command. You can
specify different parameters in the command to view specific information. You can run the
command with the following parameters:
l The display bgp evpn evpl command displays information about all EVPL instances.
l The display bgp evpn evpl brief command displays brief information about all EVPL
instances.
l The display bgp evpn evpl instance-id instance-id command displays information
about a specified EVPL instance.
NOTE
The command output displays only information about optimal paths rather than other paths such as
backup paths.
l The display bgp evpn evpl local-service-id service-id command displays information
about an EVPL instance with a specified local service ID.
Example
# Display brief information about all EVPL instances.
<HUAWEI> display bgp evpn evpl brief
Total EVPLs: 2 1 Up 1 Down
EVPL ID : 1
State : Up
Tunnel Type : VXLAN
Interface : Eth-trunk1.1

EVPL ID : 100
State : Down
Tunnel Type : LSP
Interface : GigabitEthernet 3/0/0.1
# Display detailed information about an EVPL instance with a specified instance ID.
<HUAWEI> display bgp evpn evpl instance-id 1211
Total EVPLs: 1 1 Up 0 Down
EVPL ID : 1211
State : up
Tunnel Type : LSP
Interface : Eth-Trunk255.2211
Local MTU : 1500
Local Control Word : false
Local Redundancy Mode : all-active
Local DF State : primary
Local ESI : 0000.1111.2222.1111.1111
Remote Redundancy Mode : single-active
Remote Primary DF Number : 3
Remote Backup DF Number : 0
Remote None DF Number : 0
Peer IP : 100.0.0.3
Origin Nexthop IP : 100.0.0.3
DF State : primary
Eline Role : primary
Remote MTU : 1500
Remote Control Word : false
Remote ESI : 0020.1812.1100.0000.0000
Tunnel ID : 0x0000000001004c4cc4
Out Interface : GigabitEthernet1/0/0.1
Peer IP : 100.0.0.1
DF State : primary
Eline Role : bypass
Remote MTU : 1500
Remote ESI : 0000.1111.2222.1111.1111
Tunnel ID : 0x0000000001004c4cc3
Peer IP : 100.0.0.3
DF State : primary
Eline Role : bypass
Remote MTU : 1500
Remote ESI : 0000.1111.2222.1111.1111
Tunnel ID : 0x0000000001004c4cc3
Last Interface UP Timestamp : 2018-12-11 6:36:7:885
Last Designated Primary Timestamp : 2018-12-11 5:54:47:784
Last Designated Backup Timestamp : --
Table 3-23 Description of the display bgp evpn evpl command output
Item Description
Total EVPLs Total number of EVPL instances
EVPL ID EVPL instance ID
State EVPL instance status
Tunnel Type Tunnel type
Interface Bound interface

Item Description
Tunnel ID Tunnel ID
Out Interface Outbound interface
Local MTU Local MTU
Local Control Word Local control word
Local Redundancy Mode Local redundancy mode
Local DF State Local DF election status
Local ESI Local Ethernet segment identifier (ESI)
Remote Redundancy Mode Remote redundancy mode
Remote Primary DF Number Number of primary DFs at the remote end
Remote Backup DF Number Number of backup DFs at the remote end
Remote None DF Number Number of non-DFs at the remote end
Peer IP Peer IP address
Origin Nexthop IP Original next-hop IP address
DF State DF status
Remote MTU Remote MTU
Remote Control Word Remote control word
Remote ESI Remote ESI
Eline Role Eline role:

l primary
l bypass
l backup
Last Interface UP Timestamp Date and time when the interface was Up
last time
Last Designated Primary Timestamp Date and time when the last primary DF
was elected
Last Designated Backup Timestamp Date and time when the last backup DF was
elected
3.3.10 display bgp evpn esi
Function
The display bgp evpn esi command displays ESI information about EVPN instances.

Format
display bgp evpn { all | vpn-instance vpn-instance-name } esi [ esi ]
Parameters
all Displays summary -
information about
ESIs of all EVPN
instances.
vpn-instance Displays ESI The value is a string of 1 to 31 case-sensitive
vpn-instance- information about a characters, spaces not supported. When double
name specified EVPN quotation marks are used around the string, spaces
instance. are allowed in the string.
esi Specifies an ESI. The value is in the format of
xxxx.xxxx.xxxx.xxxx.xxxx, where x is a
hexadecimal integer ranging from 0 to F. The value
must start with 00 or 01 and cannot be all 0s.
Views
All views
Default Level
1: Monitoring level

bgp read
Usage Guidelines
To check ESI information about all EVPN instances, run the display bgp evpn all esi
command.
To check ESI information about a specified EVPN instance, run the display bgp evpn vpn-
instance vpn-instance-name esi esi command.
ESI information about specified EVPN instances can be displayed by specifying different
parameters.
Example
# Display ESI information about all EVPN instances.
<HUAWEI> display bgp evpn all esi
Number of ESI for EVPN address family: 1

ESI IFName
0010.1010.1010.1010.1010 GigabitEthernet1/0/0
Number of ESI for evpn-instance c1: 1
ESI IFName
0010.1010.1010.1010.1010 GigabitEthernet1/0/0
Table 3-24 Description of the display bgp evpn esi command output
Item Description
Number of ESI for EVPN address family Number of ESIs for the EVPN instances
ESI Ethernet segment identifier
IFName Name of the interface that has an ESI

configured
Number of ESI for evpn-instance Number of ESIs configured for a specified

EVPN instance
3.3.11 display bgp evpn vpn-instance esi advance
Function
The display bgp evpn vpn-instance esi advance command displays the ESI and topology
structure information.
Format
display bgp evpn vpn-instance vpn-instance-name esi advance
Parameters

vpn-instance- Specifies the name of an The value is a string of 1 to 31 case-sensitive
name EVPN instance. characters, spaces not supported. When double
quotation marks are used around the string,
spaces are allowed in the string.
Views
All views
Default Level
1: Monitoring level


evpnbgp read
Usage Guidelines
To view information about an EVPN instance, such as the topology and redundancy mode, to
help troubleshooting, run the display bgp evpn vpn-instance esi advance command.
The display bgp evpn vpn-instance esi advance command does not support query of
information about PBB-EVPN scenarios.
You are advised to use this command when the network topology is stable. Otherwise, the
query result may be incorrect.
Example
# Display the ESI and topology structure information of an EVPN instance.
<HUAWEI> display bgp evpn vpn-instance evpna esi advance
SH: singel-homed
MH: multi-homed
SA: singel-active
AA: all-active
Number of ESI for evpn-instance evpna: 2
ESI IFName/Bridge-domain Remote-Peer Topology

0001.0001.0001.0001.0001 -- 1.1.1.1 MH/AA
Eth-Trunk10 -- MH/AA
0001.0001.0001.0001.0002 -- 2.2.2.2 IMCOMPLETE
Table 3-25 Description of the display bgp evpn vpn-instance esi advance command output
Item Description
Number of ESI for evpn-instance Number of ESIs for the EVPN instance
evpna
ESI ESI value
IFName/Bridge-domain Access-side interface or BD domain. If hyphens (--)

are displayed, this message is sent from the peer
device.
Remote-Peer EVPN peer address. If hyphens (--) are displayed,

this message is locally generated.

Item Description
Topology Topology information.

l SH: single-homing networking
l MH: multi-homing networking
l SA: single-active mode
l AA: active-active mode
l IMCOMPLETE: abnormal status. If the value is
IMCOMPLETE, the routing information in the
received message is incomplete and cannot be
used to determine the topology status.
3.3.12 display bgp evpn peer
Function
The display bgp evpn peer command displays information about BGP EVPN peers.
Format
display bgp evpn peer [ [ ipv4-address ] verbose ]
Parameters

ipv4-address Displays the information about BGP EVPN peers The value is in dotted
of a specified IPv4 address. decimal notation.
verbose Displays the detailed information about BGP -
EVPN peers.
Views
All views
Default Level
1: Monitoring level

bgp read

Usage Guidelines
To check the following information about BGP EVPN peers, run the display bgp evpn peer
command:
l Status of connections between BGP EVPN peers
l Configuration information about BGP EVPN peers
l Whether BGP EVPN peers are successfully configured using the peer enable command
l Whether BGP EVPN peers are successfully deleted using the undo peer enable
command
Example
# Display information about BGP EVPN peers.
<HUAWEI> display bgp evpn peer


PrefRcv
1.1.1.1 4 100 4456 3196 0 0045h29m
Established 5
2.2.2.2 4 100 4447 3202 0 0045h29m
Established 5
4.4.4.4 4 100 4452 3206 0 0045h29m
Established 4
Table 3-26 Description of the display bgp evpn peer command output
Item Description
BGP local router ID Local BGP EVPN router ID
Local AS number Local AS number
Total number of peers Number of peers
Peers in established state Number of peers in the Established state
Peer IP address of a peer
V BGP version of a peer
AS Autonomous system number
MsgRcvd Number of messages received
MsgSent Number of messages sent
OutQ Number of messages to be sent to a peer
Up/Down Duration in which the BGP EVPN session

remains in the current state

Item Description
State Current BGP EVPN status:

l Idle: BGP EVPN denies any connection
request. This is the initial state of BGP
EVPN.
After BGP EVPN receives a start event,
BGP EVPN initiates a TCP connection
to a peer, starts the ConnectRetry timer,
and listens to the TCP messages from
the peer. BGP EVPN then enters the
Connect state.
l Connect: BGP EVPN is waiting for the
TCP connection establishment to
complete before performing further
actions.
If the TCP connection is successfully
established, BGP EVPN stops the
ConnectRetry timer and sends an Open
message to the peer. BGP EVPN then
enters the Opensent state.
If the TCP connection fails to be
established, BGP EVPN resets the
ConnectRetry timer and listens to the
TCP connection initiated by the peer.
BGP EVPN then enters the Active state.
If the ConnectRetry timer expires, BGP
EVPN restarts the ConnectRetry timer
and attempts to establish a TCP
connection with the peer again. At this
time, BGP EVPN remains in the
Connect state.
l Active: BGP EVPN attempts to establish
a TCP connection. This is the
intermediate state of BGP EVPN.
If the TCP connection is successfully
ConnectRetry timer and sends an Open
message to the peer. BGP EVPN then
enters the Opensent state.
If the ConnectRetry timer expires, BGP
EVPN restarts the ConnectRetry timer
and enters the Connect state.
If BGP EVPN attempts to establish a
TCP connection with an unknown IP
address but fails, BGP EVPN resets the
ConnectRetry timer and remains in the
Active state.

Item Description
l OpenSent: BGP EVPN has sent an Open

message to the peer and is now waiting
for an Open message from the peer.
If BGP EVPN receives a correct Open
message, BGP EVPN enters the
OpenConfirm state.
If BGP EVPN receives an incorrect
Open message, BGP EVPN sends a
Notification message to the peer and
enters the Idle state.
If BGP EVPN receives a TCP
connection teardown message, BGP
EVPN resets the ConnectRetry timer and
listens to the TCP connection initiated
by the peer. BGP EVPN then enters the
Active state.
l OpenConfirm: BGP EVPN is waiting for
a Notification or Keepalive message.
If BGP EVPN receives a Notification or
TCP connection teardown message,
BGP EVPN enters the Idle state.
If BGP EVPN receives a Keepalive
Established state.
l Established: Peers can exchange Update,
Notification, and Keepalive messages.
If BGP EVPN receives an Update or
Keepalive message, BGP EVPN remains
in the Established state.
If BGP EVPN receives a Notification
message, BGP EVPN enters the Idle
state.
l No neg: The address family is not
enabled for the BGP peer. In this state,
Update messages can be exchanged in
other address families whose capabilities
have been successfully negotiated. If the
address family is enabled for the BGP
peer, the local BGP peer receives a
Notification message, and the peer
relationship is disconnected. Then, the
BGP peer changes to the Idle state and
re-establishes the peer relationship.
PrefRcv Number of route prefixes received from a

peer

# Display detailed information about the BGP EVPN peer at 3.3.3.3.

<HUAWEI> display bgp evpn peer 3.3.3.3 verbose
BGP Peer is 3.3.3.3, remote AS 100

Type: IBGP link
BGP version 4, Remote router ID 3.3.3.3
Update-group ID: 2
BGP current state: Established, Up for 1d08h11m09s
BGP current event: RecvKeepalive
BGP last state: OpenConfirm
BGP Peer Up count: 1
Received total routes: 7
Received active routes total: 7
Advertised total routes: 5
Port: Local - 179 Remote - 62019
Configured: Connect-retry Time: 32 sec
Configured: Min Hold Time: 0 sec
Configured: Active Hold Time: 180 sec Keepalive Time:60 sec
Received : Active Hold Time: 180 sec
Negotiated: Active Hold Time: 180 sec Keepalive Time:60 sec
Peer optional capabilities:
Peer supports bgp multi-protocol extension
Peer supports bgp route refresh capability
Peer supports bgp add-path capability
EVPN address-family: both
Negotiated bgp add-path capability
EVPN address-family: both
Peer supports bgp 4-byte-as capability
Address family IPv4 Unicast: advertised and received
Address family L2VPN EVPN: advertised and received
Received: Total 1608 messages
Update messages 25
Open messages 1
KeepAlive messages 1582
Notification messages 0
Refresh messages 0
Sent: Total 2218 messages
Update messages 7
Open messages 1
KeepAlive messages 2210
Notification messages 0
Refresh messages 0
Authentication type configured: None
Last keepalive received: 2035-04-09 23:33:18+00:00
Last keepalive sent : 2035-04-09 23:33:00+00:00
Last update received: 2035-04-09 17:54:06+00:00
Last update sent : 2035-04-09 17:49:37+00:00
No refresh received since peer has been configured
No refresh sent since peer has been configured
Minimum route advertisement interval is 15 seconds
Optional capabilities:
Route refresh capability has been enabled
4-byte-as capability has been enabled
Connect-interface has been configured
Peer Preferred Value: 0
Split group configured:
Routing policy configured:
No routing policy is configured
Table 3-27 Description of the display bgp evpn peer 3.3.3.3 verbose command output
Item Description
BGP Peer is 3.3.3.3 Peer address (3.3.3.3 in this example)
remote AS AS number of the peer

Item Description
Type BGP link type, which can only be IBGP

link currently
BGP version BGP version
Remote router ID Router ID of the peer
Update-group ID Update group ID of the peer

Item Description
BGP current state Current BGP EVPN status:

l Idle: BGP EVPN denies any connection
request. This is the initial state of BGP
EVPN.
After BGP EVPN receives a start event,
BGP EVPN initiates a TCP connection
to a peer, starts the ConnectRetry timer,
and listens to the TCP messages from
the peer. BGP EVPN then enters the
Connect state.
l Connect: BGP EVPN is waiting for the
TCP connection establishment to
complete before performing further
actions.
– If the TCP connection is successfully
established, BGP EVPN stops the
ConnectRetry timer and sends an
Open message to the peer. BGP
EVPN then enters the Opensent state.
– If the TCP connection fails to be
ConnectRetry timer and listens to the
TCP connection initiated by the peer.
BGP EVPN then enters the Active
state.
– If the ConnectRetry timer expires,
BGP EVPN restarts the
ConnectRetry timer and attempts to
establish a TCP connection with the
peer again. At this time, BGP EVPN
remains in the Connect state.
l Active: BGP EVPN attempts to establish
a TCP connection. This is the
intermediate state of BGP EVPN.
– If the TCP connection is successfully
ConnectRetry timer and sends an
Open message to the peer. BGP
EVPN then enters the Opensent state.
– If the ConnectRetry timer expires,
BGP EVPN restarts the
ConnectRetry timer and enters the
Connect state.
– If BGP EVPN attempts to establish a
TCP connection with an unknown IP
address but fails, BGP EVPN resets

Item Description
the ConnectRetry timer and remains

in the Active state.
l OpenSent: BGP EVPN has sent an Open
message to the peer and is now waiting
for an Open message from the peer.
– If BGP EVPN receives a correct
Open message, BGP EVPN enters
the OpenConfirm state.
– If BGP EVPN receives an incorrect
Open message, BGP EVPN sends a
Notification message to the peer and
enters the Idle state.
– If BGP EVPN receives a TCP
connection teardown message, BGP
EVPN resets the ConnectRetry timer
and listens to the TCP connection
initiated by the peer. BGP EVPN
then enters the Active state.
l OpenConfirm: BGP EVPN is waiting for
a Notification or Keepalive message.
– If BGP EVPN receives a Notification
or TCP connection teardown
state.
– If BGP EVPN receives a Keepalive
Established state.
l Established: Peers can exchange Update,
Notification, and Keepalive messages.
– If BGP EVPN receives an Update or
Keepalive message, BGP EVPN
remains in the Established state.
– If BGP EVPN receives a Notification
state.
l No neg: The address family is not
enabled for the BGP peer. In this state,
Update messages can be exchanged in
other address families whose capabilities
have been successfully negotiated. If the
address family is enabled for the BGP
peer, the local BGP peer receives a
Notification message, and the peer
relationship is disconnected. Then, the
BGP peer changes to the Idle state and
re-establishes the peer relationship.

Item Description
BGP current event Current BGP event
BGP last state Status of the last BGP stage, which can be
Idle, Connect, Active, OpenSent,
OpenConfirm, Established or No neg
BGP Peer Up count Number of times the peer alternates

between Up and Down
Received total routes Number of route prefixes received
Received active routes total Number of active route prefixes received
Advertised total routes Number of route prefixes sent
Port Port number:

l Local: local port number, which is fixed
at 179 because BGP uses TCP as the
transport layer protocol.
l Remote: peer port number.

Item Description
Configured Timers that are locally configured:

l Active Hold Time: indicates the hold
time. If BGP EVPN does not receive any
Keepalive message from the peer in the
hold time, BGP EVPN considers that the
peer is Down. BGP EVPN then instructs
the other peers to withdraw the routes
received from this peer.
l Keep Alive Time: indicates the interval
at which Keepalive messages are sent to
the peer. Peers exchange Keepalive
messages at intervals to show that they
are working normally.
l Min Hold Time: specifies the minimum
hold time. If the hold time configured on
a remote device is less than the min-
hold-value configured on the local
device, no BGP peer relationship can be
established between the two devices.
However, if the hold time configured on
the remote device is 0s, a BGP peer
relationship can be established between
the two devices.
l Connect-retry Time: specifies the
ConnectRetry interval for a peer or peer
group. When BGP initiates a TCP
connection, the ConnectRetry timer is
stopped if the TCP connection is
established successfully. If the attempt to
establish a TCP connection fails, BGP
tries again to establish the TCP
connection after the ConnectRetry timer
expires.
Received : Active Hold Time Hold time of the peer
Negotiated : Active Hold Time Hold time negotiated by peers
Peer optional capabilities Optional capabilities of the peer

Item Description
Received Number of messages received from the

peer:
l Total: indicates the total number of
messages received from the peer.
l Update messages: indicates the number
of Update messages received from the
peer.
l Open messages: indicates the number of
Open messages received from the peer.
l KeepAlive messages: indicates the
number of Keepalive messages received
from the peer.
l Notification messages: indicates the
number of Notification messages
received from the peer.
l Refresh messages: indicates the number
of route-refresh messages received from
the peer.
Sent Number of messages sent to the peer:

l Total: indicates the total number of
messages sent to the peer.
l Update messages: indicates the number
of Update messages sent to the peer.
l Open messages: indicates the number of
Open messages sent to the peer.
l KeepAlive messages: indicates the
number of Keepalive messages sent to
the peer.
l Notification messages: indicates the
number of Notification messages sent to
the peer.
l Refresh messages: indicates the number
of route-refresh messages sent to the
peer.
Authentication type configured Authentication type
Last keepalive received Last time when a Keepalive message is

received
Last keepalive sent Last time when a Keepalive message is sent
Last update received Last time when an Update message is

received
Last update sent Last time when an Update message is sent

Item Description
No refresh received since peer has been No Route-Refresh packets are received from
configured the peer since the peer relationship is
established
No refresh sent since peer has been No Route-Refresh packets are sent from the
configured peer since the peer relationship is
established
Minimum route advertisement interval is 15 Minimum route advertisement interval:

seconds l EBGP: 30s
l IBGP: 15s
Optional capabilities Optional capabilities of the peer
Route refresh capability has been enabled Route-refresh enabled
4-byte-as capability has been enabled 4-byte AS capability enabled
Connect-interface has been configured Source interface for sending BGP packets
specified
Peer Preferred Value Preferred value of the peer
Split group configured Whether a split horizon group has been

configured
Routing policy configured Whether a routing policy has been

configured
3.3.13 display bgp evpn routing-table
Function
The display bgp evpn routing-table command displays information about EVPN routes.
Format
display bgp evpn all routing-table
display bgp evpn all routing-table statistics
display bgp evpn { all | route-distinguisher route-distinguisher | vpn-instance vpn-

instance-name } routing-table { ad-route | es-route | inclusive-route | mac-route | prefix-
route }
display bgp evpn all routing-table { ad-route | es-route | inclusive-route | mac-route |

prefix-route } prefix { community-list | ext-community | cluster-list | advertised-peer | as-
path }
display bgp evpn route-distinguisher route-distinguisher routing-table { ad-route | es-

route | inclusive-route | mac-route | prefix-route } prefix

display bgp evpn vpn-instance vpn-instance-name routing-table { ad-route | es-route |

inclusive-route | mac-route | prefix-route } prefix [ community-list | ext-community |
cluster-list ]
display bgp evpn all routing-table mac-route backbone-source-mac [ mac-address ]
display bgp evpn all routing-table [ peer ip-address advertised-routes ] { ad-route | es-
route | inclusive-route | mac-route | prefix-route } [ prefix ]
display bgp evpn all routing-table [ peer ip-address advertised-routes ]
display bgp evpn { all | route-distinguisher route-distinguisher | vpn-instance vpn-

instance-name } routing-table { smet-route | join-route | leave-route } [ prefix ]
display bgp evpn all routing-table peer ip-address advertised-routes { smet-route | join-
route | leave-route } [ prefix ]
display bgp evpn all routing-table { smet-route | join-route | leave-route } [ prefix ]

{ community-list | ext-community | cluster-list | advertised-peer | as-path }
display bgp evpn vpn-instance vpn-instance-name routing-table { smet-route | join-route |

leave-route } [ prefix ] { community-list | ext-community | cluster-list }
Parameters

all Displays information -
about EVPN routes of
all EVPN instances.
route- Displays information -
distinguisher about EVPN routes with
route- the specified RD.
distinguisher
vpn-instance Displays information The value is a string of 1 to 31 case-sensitive
vpn-instance- about EVPN routes of a characters, spaces not supported. When
name specified EVPN double quotation marks are used around the
instance. string, spaces are allowed in the string.
ad-route Displays information -
about all Ethernet auto-
discovery routes.
es-route Displays information -
about Ethernet segment
routes.
inclusive-route Displays information -
about inclusive
multicast routes.
mac-route Displays information -
about MAC
advertisement routes.


prefix-route Displays information -
about prefix routes.
smet-route Displays information -
about Selective
Multicast Ethernet Tag
(SMET) routes.
join-route Displays information -
about IGMP Join Synch
routes.
leave-route Displays information -
about IGMP Leave
Synch routes.


prefix Specifies the prefix of An EVPN route prefix has the following
an EVPN route. formats:
l Ethernet auto-discovery route. The value is
in the format of
xxxx.xxxx.xxxx.xxxx.xxxx:M, where:
– xxxx.xxxx.xxxx.xxxx.xxxx indicates
the ESI configured for the device
originating this route.
– M is 0 or 4294967295.
l Ethernet segment route. The value is in the
format of xxxx.xxxx.xxxx.xxxx.xxxx,
where x is a hexadecimal integer ranging
from 0 to F. The value equals the ESI
configured for the device originating this
route.
l Inclusive multicast route. The value is in
the format of M:L:X.X.X.X, where:
– M is fixed at 0.
– X.X.X.X indicates the source address
configured for the device originating
the route.
– L indicates the mask length of the
source address configured for the
device originating the route.
l MAC advertisement route. The value is in
the format of E:M:H-H-H:L:X.X.X.X or
E:M:H-H-H:L: [X:X::X:X], where:
– E indicates the ID of the VLAN to
which the MAC address belongs.
– M is fixed at 48, indicating the length
of the MAC address.
– H-H-H indicates the MAC address. The
value is a 12-digit hexadecimal number,
in the format of H-H-H. Each H is 4
digits. If an H contains fewer than 4
digits, the left-most digits are padded
with zeros.
– L is fixed at 0, indicating the mask
length of the IP address corresponding
to the MAC address.
– X.X.X.X indicates the IP address
corresponding to the MAC address.
Currently, this part can only be
displayed as 0.0.0.0.

– X:X::X:X indicates the IPv6 address

corresponding to the MAC address.
l IP Prefix route. The value is in the format
of L:X.X.X.X:M or L:[X:X::X:X]:M,
where:
– L is fixed at 0.
– X.X.X.X indicates the ip address of
host routes.
– M indicates the mask length of host
routes.
– X:X::X:X indicates the ipv6 address of
host routes.
l SMET route. The value is in the format of
T:SL:SX.SX.SX.SX:GL:GX.GX.GX.GX:
OL:OX.OX.OX.OX:
– T indicates an Ethernet tag ID, which is
the BD tag specified when an EVPN
instance is bound to a BD. If no BD tag
is specified, the Ethernet tag ID is 0.
– SL indicates the mask of a multicast
source address.
– SX.SX.SX.SX indicates a multicast
source address.
– GL indicates the mask of a multicast
group address.
– GX.GX.GX.GX indicates a multicast
group address.
– OL indicates the mask of an EVPN
source address.
– OX.OX.OX.OX indicates an EVPN
source address.
l IGMP Join Synch route. The value is in the
format of
ESI:T:SL:SX.SX.SX.SX:GL:GX.GX.GX.
GX:OL:OX.OX.OX.OX:
– ESI indicates the ESI of an EVPN.
source address.
source address.


group address.
group address.
source address.
source address.
l IGMP Leave Synch route. The value is in
the format of
ESI:T:SL:SX.SX.SX.SX:GL:GX.GX.GX.
GX:OL:OX.OX.OX.OX:SY:
– ESI indicates the ESI of an EVPN.
source address.
source address.
group address.
group address.
source address.
source address.
– SY indicates a synchronization
sequence number.
community-list Displays the community -

list of BGP EVPN
routes.
ext-community Displays the extended -
community list of BGP
EVPN routes.
cluster-list Displays the cluster list -
of BGP EVPN routes.
advertised-peer Displays the advertised -
peer list of BGP EVPN
routes.


as-path Displays the AS_Path -
attribute of BGP EVPN
routes.
backbone- Displays MAC -
source-mac advertisement routes
about B-MAC
addresses.
mac-address Specifies a B-MAC -
address.
peer ip-address Specifies a peer IP The value is in dotted decimal notation.
address.
advertised- Specifies advertises -
routes routes.
Views
All views
Default Level
1: Monitoring level

bgp read
Usage Guidelines
To check information about EVPN routes, including active and inactive routes, run the
display bgp evpn routing-table command.
Information about specified EVPN routes can be displayed by specifying different
parameters.
Example
# Display information about all EVPN routes.
<HUAWEI> display bgp evpn all routing-table




*> 0010.1010.1010.1010.1010:0 127.0.0.1
EVPN-Instance c1:
*> 0010.1010.1010.1010.1010:0 127.0.0.1


*> 0:32:1.1.1.1 127.0.0.1
EVPN-Instance c1:
*> 0:32:1.1.1.1 127.0.0.1


*> 0010.1010.1010.1010.1010 127.0.0.1
EVPN-Instance c1:
*> 0010.1010.1010.1010.1010 127.0.0.1
Table 3-28 Description of the display bgp evpn routing-table command output
Item Description
Local AS number Local AS number of the EVPN routes
BGP Local router ID Router ID of the local BGP device
Number of A-D Routes Number of Ethernet auto-discovery routes
Number of Mac Routes Number of MAC advertisement routes
Number of Inclusive Multicast Routes Number of inclusive multicast routes
Number of ES Routes Number of Ethernet segment routes
Route Distinguisher RD of the EVPN routes
Network Reachable address
ESI Ethernet Segment Identifier
EthTagId VLAN ID
IpAddrLen Mask length
OriginalIp Source IP address

Item Description
NextHop Next hop address
# Display statistics about EVPN routes.

<HUAWEI> display bgp evpn all routing-table statistics
Total number of routes from all PE: 6
Number of SMET Routes: 0

Number of IGMP Leave Synch Routes: 0
Table 3-29 Description of the display bgp evpn routing-table statistics command output
Item Description
Total number of routes from all PE Number of EVPN routes received from all
PEs
Number of Ip Prefix Routes Number of IP prefix routes
Number of SMET Routes Number of SMET routes
Number of IGMP Join Synch Routes Number of IGMP Join Synch routes
Number of IGMP Leave Synch Routes Number of IGMP Leave Synch routes
# Display information about the ES routes with the prefix 0000.1111.1111.4444.5555.

<HUAWEI> display bgp evpn all routing-table es-route 0000.1111.1111.4444.5555

BGP routing table entry information of 0000.1111.1111.4444.5555:
From: 0.0.0.0 (0.0.0.0)
Ext-Community: RT <00e0-fc00-0005>
AS-path Nil, origin incomplete, pref-val 0, valid, local, best, select, pre 255
Route Type: 4 (Ethernet Segment Route)
ESI: 0000.1111.1111.4444.5555, Originating IP:1.1.1.1/32
Advertised to such 1 peers:
3.3.3.3
BGP routing table entry information of 0000.1111.1111.4444.5555:

Local-Cross route
Ext-Community: RT <00e0-fc00-0005>
Route Type: 4 (Ethernet Segment Route)
ESI: 0000.1111.1111.4444.5555, Originating IP:1.1.1.1/32
Table 3-30 Description of the display bgp evpn routing-table es-route command output
Item Description
BGP local router ID Router ID of the local BGP device
Local AS number Local AS number of the EVPN routes
Total routes of Route Distinguisher Total number of EVPN routes with a specified
RD
BGP routing table entry information of Routing entry information
From IP address of the device that advertised routes
Route Duration Duration for route advertisement
Relay IP Nexthop Recursive next hop
Original nexthop Original next hop
Qos information QoS information
Ext-Community BGP EVPN extended community attribute
AS-path AS_Path attribute (Nil indicates that the attribute

value is null)
origin Origin attribute of an EVPN route
pref-val Preferred value of an EVPN route
valid Valid route
local Local route
best Optimal route
select Preferred route
pre Route preference
Route Type EVPN route type:

l Ethernet Auto-Discovery route
l MAC advertisement route
l Inclusive Multicast Route
l Ethernet Segment Route
l Ip Prefix Route

Item Description
ESI Ethernet segment identifier
Originating IP IP address of the device that has originated routes
Advertised to such 1 peers Peers to which routes are advertised
EVPN-Instance evrf1 EVPN instance name
Local-Cross route The route is a local cross route.
# Display information about the EVPN routes with the MAC address 0:48:00e0-
fc00-0009:32:10.0.1.7.
<HUAWEI> display bgp evpn vpn-instance VPN1 routing-table mac-route 0:48:00e0-
fc00-0009:32:10.0.1.7

EVPN-Instance VPN1:
Remote-Cross route
Label information (Received/Applied): 10001 200001/NULL
From: 7.7.7.7 (7.7.7.7)
Relay Tunnel Out-Interface: VXLAN
Ext-Community:RT <10001 : 1>, Tunnel Type <VxLan(8)>, Router's MAC <00e0-
fc00-0004>
AS-path Nil, origin incomplete, localpref 100, pref-val 0, valid, internal, best,
select, pre 255, reoriginated
10.0.1.7/32, ESI:0000.0000.0000.0000.0000
Table 3-31 Description of the display bgp evpn vpn-instance routing-table mac-route
command output
Item Description
BGP routing table Routing entry information. A MAC route entry consists of an
entry information of Ethernet tag ID, host MAC address and length, and host IP
address and mask length.
EVPN-Instance VPN1 EVPN instance name
Number of Mac Routes Number of MAC routes
Remote-Cross route Route received from a peer and crossed to an EVPN instance
Label information Information about labels, including received and sent labels
(Received/Applied)

Item Description
Relay Tunnel Out- Outbound interface of the recursive tunnel

Interface
Tunnel Type Tunnel type
Router's MAC MAC address received from an EVPN peer
Ethernet Tag ID VLAN ID, which is fixed at 0
MAC Address/Len MAC address and length in a MAC route
IP Address/Len IP address and length in a host route
Not advertised to any Route that is not advertised to any EVPN peer
peer yet
# Display information about the Ethernet auto-discovery route with the prefix 0138.ba2f.3cdb.
0201.2100:0.
<HUAWEI> display bgp evpn all routing-table ad-route 0138.ba2f.3cdb.0201.2100:0

BGP routing table entry information of 0138.ba2f.3cdb.0201.2100:0:
From: 3.3.3.3 (10.1.1.2)
ESI: 0138.ba2f.3cdb.0201.2100, Ethernet Tag ID: 0
BGP routing table entry information of 0138.ba2f.3cdb.0201.2100:0:
Remote-Cross route
From: 3.3.3.3 (10.1.1.2)
ESI: 0138.ba2f.3cdb.0201.2100, Ethernet Tag ID: 0

Table 3-32 Description of the display bgp evpn routing-table ad-route command output
Item Description
BGP routing table entry information of Routing entry information. An Ethernet auto-
discovery route entry consists of an ESI and an
Ethernet tag ID.
IGP cost IGP cost.
Originator IP address of the device that has originated

routes.
Cluster list Cluster list contained in a route.
# Display information about the inclusive multicast route with the prefix 0:32:4.4.4.4.
<HUAWEI> display bgp evpn all routing-table inclusive-route 0:32:4.4.4.4

BGP routing table entry information of 0:32:1.1.1.1:
From: 0.0.0.0 (0.0.0.0)
Direct Out-interface:
PMSI: Flags 0, Ingress Replication, Label 0:0:0(0), Tunnel Identifier:1.1.1.1
Route Type: 3 (Inclusive Multicast Route)
Ethernet Tag ID: 0, Originator IP:1.1.1.1/32
3.3.3.3
BGP routing table entry information of 0:32:1.1.1.1:
From: 0.0.0.0 (0.0.0.0)
PMSI: Flags 0, Ingress Replication, Label 0:0:0(0), Tunnel Identifier:1.1.1.1
Route Type: 3 (Inclusive Multicast Route)
Ethernet Tag ID: 0, Originator IP:1.1.1.1/32

Table 3-33 Description of the display bgp evpn routing-table inclusive-route command
output
Item Description
BGP routing table entry information of Routing entry information. An inclusive multicast
route entry consists of an Ethernet tag ID, IP
address of the device that generates this route,
and mask length of the IP address.
Direct Out-interface Directly connected interface.
PMSI P-Multicast Service Interface (PMSI) tunnel

information.
# Display information about the IP prefix route with the prefix of 0:22.22.22.22:32.
<HUAWEI> display bgp evpn all routing-table prefix-route 0:22.22.22.22:32

From: 0.0.0.0 (0.0.0.0)
Direct Out-interface: GigabitEthernet1/0/0.1
Effective nexthop: 192.1.1.1
Qos information : 0
Ext-Community: RT <1 : 1>, Tunnel Type <VxLan>, Router's MAC <00e0-fc00-0002>
AS-path Nil, origin igp, MED 0, pref-val 0, valid, local, best, select, pre 255
Received path-id: 0
0000.0000.0000.0000.0000, GW IP Address: 0.0.0.0
1.1.1.1
# Display information about the IP prefix route with the prefix of 0:22.22.22.22:32.
<HUAWEI> display bgp evpn all routing-table peer 1.1.1.1 advertised-routes prefix-
route 0:22.22.22.22:32
From: 0.0.0.0 (0.0.0.0)
Direct Out-interface: GigabitEthernet1/0/0.1
Effective nexthop: 192.1.1.1
Advertised nexthop: 2.2.2.2
Qos information : 0
Ext-Community: RT <1 : 1>, Tunnel Type <VxLan>, Router's MAC <00e0-fc00-0002>
AS-path Nil, origin igp, MED 0, localpref 100, pref-val 0, valid, local, best,
select, pre 255
Sent path-id: 0
0000.0000.0000.0000.0000, GW IP Address: 0.0.0.0
1.1.1.1

Table 3-34 Description of the display bgp evpn routing-table prefix-route command output
Item Description
Effective nexthop Actual next hop of the IP prefix route
Advertised nexthop Next hop to which the IP prefix route recurses

after being sent
Received path-id ID of the receive path
Sent path-id ID of the transmit path
# Display information about SMET route.

<HUAWEI> display bgp evpn all routing-table smet-route slave


Network(EthTagId/IpAddrLen/SAddr/IpAddrLen/GAddr/IpAddrLen/
OAddr) NextHop
*>i
0:0:0.0.0.0:32:225.0.0.1:32:3.3.3.3
3.3.3.3
EVPN-Instance evpn1:
Network(EthTagId/IpAddrLen/SAddr/IpAddrLen/GAddr/IpAddrLen/
OAddr) NextHop
*>i
0:0:0.0.0.0:32:225.0.0.1:32:3.3.3.3
3.3.3.3
# Display information about IGMP Join Synch routes.

<HUAWEI> display bgp evpn all routing-table join-route slave


OAddr) NextHop
*>
0000.1111.2222.1111.1111:0:0:0.0.0.0:32:225.0.0.1:32:2.2.2.2
127.0.0.1

OAddr) NextHop
*>
0000.1111.2222.1111.1111:0:0:0.0.0.0:32:225.0.0.1:32:2.2.2.2
127.0.0.1
# Display information about IGMP Leave Synch routes.

<HUAWEI> display bgp evpn all routing-table leave-route slave


Network(ESI/EthTagId/IpAddrLen/SAddr/IpAddrLen/GAddr/IpAddrLen/OAddr/
Synch) NextHop
*>
0001.0203.0405.0607.0809:0:32:16.0.0.10:32:232.0.0.1:32:2.2.2.2:0
127.0.0.1
Network(ESI/EthTagId/IpAddrLen/SAddr/IpAddrLen/GAddr/IpAddrLen/OAddr/
Synch) NextHop
*>
0001.0203.0405.0607.0809:0:32:16.0.0.10:32:232.0.0.1:32:2.2.2.2:0
127.0.0.1
# Display information about B-MAC routes.

<HUAWEI> display bgp evpn all routing-table mac-route backbone-source-mac

EVPN-Instance bevpn:
*> 0:48:00e0-fc00-0007:0:0.0.0.0 0.0.0.0
*>i 0:48:00e0-fc00-0003:0:0.0.0.0 2.2.2.2
*>i 0:48:00e0-fc00-0008:0:0.0.0.0 4.4.4.4
*> 0:48:00e0-fc00-0006:0:0.0.0.0 0.0.0.0
* i 2.2.2.2
3.3.14 display default-parameter evpn
Function
The display default-parameter evpn command displays default EVPN configurations during
EVPN initialization.
Format
display default-parameter evpn

Parameters
None
Views
All views
Default Level
1: Monitoring level

bgp read
Usage Guidelines
To check default EVPN configurations during EVPN initialization, such as the default EVPN
instance access mode, EVPN interface service type, and EVPN interface label distribution
mode, run the display default-parameter evpn command.
Example
# Display default EVPN configurations during EVPN initialization.
<HUAWEI> display default-parameter evpn
EVPN Access Mode : Port Access
EVPN Interface Service Mode: Vlan Unaware
Apply Label Mode : Label Per Instance
Table 3-35 Description of the display default-parameter evpn command output

Item Description
EVPN Access Mode EVPN instance access mode
EVPN Interface Service Mode EVPN interface service type
Apply Label Mode EVPN interface label distribution mode
3.3.15 display evpn df result

Function
The display evpn df result command displays the DF election result of an EVPN instance.
Format
display evpn vpn-instance name vpn-instance-name df result [ esi esi ]

Parameters
vpn-instance Displays the DF The value is a string of 1 to 31 case-sensitive
name vpn- election result of an characters, spaces not supported. When double
instance-name EVPN instance with quotation marks are used around the string,
the specified name. spaces are allowed in the string.
esi esi Displays the DF The value is in the format of
election result of an xxxx.xxxx.xxxx.xxxx.xxxx, where x is a
EVPN instance with hexadecimal integer ranging from 0 to F. The
the specified ESI. value must start with 00 or 01 and cannot be all
0s.
Views
All views
Default Level
1: Monitoring level

bgp read
Usage Guidelines
To check the DF election result, corresponding interface, and interface's ESI, run the display
evpn df result command.
Example
# Display the interface-based DF election result of an EVPN instance.
<HUAWEI> display evpn vpn-instance name c1 df result
ESI Count: 1
ESI: 0010.1010.1010.1010.1010
GigabitEthernet1/0/0:
DF Result : Primary
# Display the BD-based DF election result of an EVPN instance.

<HUAWEI> display evpn vpn-instance name c2 df result
ESI Count: 1
ESI: 0010.1010.1010.1010.1010
DF Result : Primary
# Display the DF election result of an I-EVPN instance.

<HUAWEI> display evpn vpn-instance name ievpn df result

ESI Count: 1
ESI: 0010.1010.1010.1010.1010
I-tag : 12
DF Result : Primary
Table 3-36 Description of the display evpn df result command output
Item Description
ESI Count Number of ESIs for the EVPN instance
ESI Specific ESI for the EVPN instance
GigabitEthernet1/0/0 Ethernet interface that has the ESI of

0010.1010.1010.1010.1010 configured
I-tag Specific I-SID for the I-EVPN instance
Current State Current status of GigabitEthernet 1/0/0:

l IFSTATE_UP
l IFSTATE_DOWN
DF Result DF election result:

l Primary: primary DF
l Backup: backup DF
3.3.16 display evpn df-timer state
Function
The display evpn df-timer state command displays the DF timer status of an EVPN instance.
Format
display evpn vpn-instance name vpn-instance-name df-timer state
Parameters

vpn-instance name Specifies the name of The value is a string of 1 to 31 case-
vpn-instance-name an EVPN instance. sensitive characters, spaces not supported.
around the string, spaces are allowed in the
string.

Views
All views
Default Level
1: Monitoring level

bgp read
Usage Guidelines
To check the DF timer status of an EVPN instance, run the display evpn df-timer state
command.
Example
# Display the DF timer status of EVPN instance aaa.
<HUAWEI> display evpn vpn-instance name aaa df-timer state
Ifindex Type Mode
TimerLeft(s)
GigabitEthernet1/0/0 BRM_EVRF_IF_DF_TIMER IDLE
-----
Esi Type Mode

TimerLeft(s)
0010.1010.1010.1010.1010 BRM_EVRF_ESI_DF_TIMER IDLE -----
Table 3-37 Description of the display evpn df-timer state command output
Item Description
Type Timer type:

l BRM_EVRF_IF_DF_TIMER: interface-
based DF timer
l BRM_EVRF_ESI_DF_TIMER: ESI-
based DF timer
Mode DF timer status:

l IDLE: The DF timer is invalid.
l RUNNING: The DF timer is running.
TimerLeft Remaining time before the DF timer expires
Esi Valid ESI

3.3.17 display evpn mac routing-table
Function
The display evpn mac routing-table command displays MAC route information about
EVPN instances.
Format
display evpn mac routing-table { all-evpn-instance | mac-address mac-address }
display evpn mac routing-table evpn-instance vpn-instance-name [ mac-address mac-

address ] [ verbose ]
Parameters
all-evpn- Displays MAC route -
instance information about all
EVPN instances.
mac-address Displays information about The value is a 12-digit hexadecimal
mac-address a MAC route with the number, in the format of H-H-H. Each H is
specified MAC address. 4 digits. If an H contains fewer than 4
digits, the left-most digits are padded with
zeros. For example, e0 is displayed as 00e0.
The MAC address cannot be set to 00e0-
fc00-0002.
evpn-instance Displays MAC route The value is a string of 1 to 31 case-

vpn-instance- information about an sensitive characters, spaces not supported.
name EVPN instance with the When double quotation marks are used
specified name. around the string, spaces are allowed in the
string.
verbose Displays detailed MAC -
route information.
Views
All views
Default Level
1: Monitoring level

route-base read

Usage Guidelines
To check MAC route information about EVPN instances, run the display evpn mac routing-
table command.
Example
# Display MAC route information about all EVPN instances.
<HUAWEI> display evpn mac routing-table all-evpn-instance
EVPN name: aaa

MACs: 5 Entries: 5
MAC-Address VLAN/BD PeerIP Type Interface

00e0-fc00-0001 0 2.2.2.2 Dynamic --
00e0-fc00-0006 0 2.2.2.2 Dynamic --
00e0-fc00-0003 0 2.2.2.2 Dynamic --
00e0-fc00-0004 0 2.2.2.2 Dynamic --
00e0-fc00-0005 0 2.2.2.2 Dynamic --
------------------------------------------------------------------------------
EVPN name: bbb
MACs: 0 Entries: 0
MAC-Address VLAN PeerIP Type Interface
# Display detailed information about a specified MAC route in a specified EVPN instance.
<HUAWEI> display evpn mac routing-table evpn-instance aaa mac-address 00e0-
fc00-0001 verbose
MAC Flag: D - download to fib

------------------------------------------------------------------------------
EVPN name: aaa
Entries: 1
MAC Address: 00e0-fc00-0001

Protocol: BGP VLAN/BD: 0
State: Active Age: 03h29m06s
Type: Dynamic Label: 32828
IndirectID: 0x2F0000C2 PeerIP: 2.2.2.2
Flag: D
TunnelID: 0x0000000001004c7c62 Interface: GigabitEthernet3/0/1
Table 3-38 Description of the display evpn mac routing-table command output
Item Description
MACs Number of MAC addresses
Entries Number of MAC routes
MAC-Address MAC address
VLAN/BD VLAN IDor BD ID
PeerIP Peer IP address corresponding to a MAC

address

Item Description
Type MAC address type:

l Dynamic: The MAC addresses are
dynamically learned by the EVPN peer
and remain dynamic after being
transmitted to the PE.
l Static: The MAC addresses are statically
configured on the EVPN peer and
remain static after being transmitted to
the PE. Static MAC addresses have a
higher priority than dynamic MAC
addresses.
l DynBlk: Blackhole MAC addresses that
are generated due to frequent MAC
address changes. Packets that match the
blackhole MAC routes will be discarded.
l DynLeaf: MAC addresses of interfaces
with the leaf attribute in dynamic E-Tree
scenarios.
l StaLeaf: MAC addresses of interfaces
with the leaf attribute in static E-Tree
scenarios.
Interface Outbound interface
Protocol Origin of MAC routes:

l BGP: learned from BGP peers
l Local: locally reported
VLAN/BD VLAN IDor BD ID
State MAC route status:

l Active
l Invalid
l Inactive
Age MAC route aging time
Label Label
IndirectID IID
Flag MAC route flag:

l D: delivered to interface boards
l --: not delivered to interface boards
TunnelID Tunnel ID

3.3.18 display evpn mac routing-table limit

Function
The display evpn mac routing-table limit command displays MAC address limits of EVPN
instances.
Format
display evpn mac routing-table limit { all-evpn-instance | evpn-instance vpn-instance-
name }
Parameters
all-evpn-instance Displays MAC address limits -
of all EVPN instances.
evpn-instance vpn- Displays MAC address limits The value is a string of 1 to 31 case-
instance-name of an EVPN instance with the sensitive characters, spaces not
specified name. supported. When double quotation
marks are used around the string,
Views
All views
Default Level
1: Monitoring level

route-base read
Usage Guidelines
To check the MAC address limits of EVPN instances, run the display evpn mac routing-
table limit command. The MAC address limits of an EVPN instance are specified using the
mac limit and mac threshold-alarm commands.
Example
# Display MAC address limits of EVPN instance vpn1.
<HUAWEI> display evpn mac routing-table limit evpn-instance vpn1
EVPN Instance Name: vpn1

Limit-Type Max-Limit Upper-Limit Lower-Limit Current
Default 100 80 70 0

Table 3-39 Description of the display evpn mac routing-table limit command output
Item Description
Limit-Type MAC address limit type:

l Simply-Alert: An alarm is generated when the
number of MAC addresses in the EVPN instance
exceeds the upper limit.
l Default: The default configurations.
Max-Limit Maximum number of MAC addresses allowed by

the EVPN instance
Upper-Limit Alarm reporting threshold for MAC addresses in the

EVPN instance
Lower-Limit Alarm clearing threshold for MAC addresses in the

EVPN instance
Current Number of MAC addresses currently in the EVPN

instance
3.3.19 display evpn mac routing-table statistics
Function
The display evpn mac routing-table statistics command displays MAC route statistics of
EVPN instances.
Format
display evpn mac routing-table { all-evpn-instance | evpn-instance vpn-instance-name }
statistics
Parameters

all-evpn-instance Displays MAC route statistics -
of all EVPN instances.
evpn-instance vpn- Displays MAC route statistics The value is a string of 1 to 31 case-
instance-name of an EVPN instance with the sensitive characters, spaces not
specified name. supported. When double quotation
Views
All views

Default Level
1: Monitoring level

route-base read
Usage Guidelines
To check MAC route statistics of EVPN instances, including the numbers of added, deleted,
active, and freed routes, run the display evpn mac routing-table statistics command.
Example
# Display MAC route statistics of all EVPN instances.
<HUAWEI> display evpn mac routing-table all-evpn-instance statistics
Summary Prefixes : 133

Protocol route active added deleted freed
Local 0 0 0 0 0
BGP 133 133 48659 48526 48526
Total 133 133 48659 48526 48526
Table 3-40 Description of the display evpn mac routing-table command output
Item Description
Summary Prefixes Number of prefixes currently in the MAC

routing table
Protocol Origin of routes:

l BGP: learned from BGP peers
l Local: locally reported
route Number of routes in the MAC routing table
active Number of active routes in the MAC routing

table
added Number of routes, including both active and

inactive ones, added to the MAC routing
table
deleted Number of routes with the delete flag in the

MAC routing table
freed Number of routes permanently released

from the MAC routing table

3.3.20 display evpn recover-timer
Function
The display evpn recover-timer command displays information about the recovery timer on
an interface.
Format
display evpn recover-timer [ interface [ interface-type interface_number | interface-name ] ]
Parameters
interface Specifies an interface. -
interface-type Specifies an interface type. -
interface_number Specifies the number of an interface. -
interface-name Specifies the name of an interface. -
Views
All views
Default Level
1: Monitoring level

evpn read
Usage Guidelines
To view the recovery timer information on an interface of the master main control board, run
the display evpn recover-timer [ interface [ interface-type interface_number | interface-
name ] ] command.
Example
# Display the recovery timer information on an interface of the master main control board.
<HUAWEI> display evpn recover-timer
IfName : Eth-Trunk1
Mode : RUNNING
BeginTime : 2017-04-14 06:36:18
EndTime : -----
TimerLeft(s): 27

Table 3-41 Description of the display evpn recover-timer command output

Item Description
IfName Interface name
Mode Mode:
l IDLE: idle state
l RUNNING: running state
BeginTime Date and time when the recovery timer

started
EndTime Date and time when the recovery timer

ended last time
TimerLeft Remaining time of the recovery timer
3.3.21 display evpn vpn-instance

Function
The display evpn vpn-instance command displays EVPN instance information.
Format
display evpn vpn-instance [ name vpn-instance-name ] [ bridge-domain bd-id ] [ verbose ]
Parameters
verbose Display detailed -
information about EVPN
instances.
vpn-instance-name Specifies the name of an The value is a string of 1 to 31 case-
EVPN instance. sensitive characters, spaces not
supported. When double quotation
marks are used around the string, spaces
are allowed in the string.
bridge-domain Specifies a bridge domain The value is an integer ranging from 1 to
bd-id (BD) ID. 32768.
Views
All views
Default Level
1: Monitoring level


bgp read
Usage Guidelines
To check EVPN instance information, run the display evpn vpn-instance command.
If vpn-instance-name is not specified, the display evpn vpn-instance command displays a

summary of all configured EVPN instances.
Example
# Display a summary of all EVPN instances.
<HUAWEI> display evpn vpn-instance
Total EVPN-Instances configured : 2
EVPN-Instance Name RD Address-family

v1 1:1 evpn
v2 evpn
# Display detailed information about EVPN instance evpna.

<HUAWEI> display evpn vpn-instance name evpna verbose
VPN-Instance Name and ID : evpna, 3
Address family evpn
Label Policy : label per instance
Per-Instance Label : 32831,32832
Interfaces : Eth-Trunk10
# Display detailed information about BD-EVPN instance evpnb.

<HUAWEI> display evpn vpn-instance name evpnb verbose
VPN-Instance Name and ID : evpnb, 3
Bridge-domain : 10, tagId: 10
Table 3-42 Description of the display evpn vpn-instance command output

Item Description
Total EVPN-Instances configured Total number of EVPN instances configured
EVPN-Instance Name EVPN instance name
RD EVPN instance RD
Address-family Address family enabled for the EVPN instance
VPN-Instance Name and ID Name and ID of the EVPN instance. The ID is

allocated by the system for indexing.

Item Description
Address family evpn EVPN instance address family
Route Distinguisher EVPN instance RD
Label Policy Label policy of the EVPN instance:

l label per bridge-domain
l label per vpn-instance
Per-Instance Label Label shared by all private network routes in the

EVPN instance
Export VPN Targets List of export VPN targets
Import VPN Targets List of import VPN targets
Interfaces Interfaces bound to the EVPN instance
Bridge-domain BD bound to the EVPN instance
tagId BD tag value.
3.3.22 display evpn vpn-instance inclusive-provider-tunnel
Function
The display evpn vpn-instance inclusive-provider-tunnel command displays multicast
EVPN tunnel information.
Format
display evpn vpn-instance name vpn-instance-name inclusive-provider-tunnel verbose
Parameters

name vpn- Specifies an EVPN The value is a string of 1 to 31 case-
instance-name instance name. sensitive characters, spaces not supported.
string.
verbose Displays detailed peer -
information.
Views
All views

Default Level
1: Monitoring level

bgp read
Usage Guidelines
After configuring a multicast EVPN, to view tunnel information on the root and leaf nodes,
run the display evpn vpn-instance inclusive-provider-tunnel command. The tunnel
information includes the IP address of the root node, P2MP tunnel type, tunnel status, and so
on.
Example
# Display multicast EVPN tunnel information on the root node of an mLDP P2MP tunnel.
<HUAWEI> display evpn vpn-instance name evpna inclusive-provider-tunnel verbose

Bridge-domain : 1
Root ip : 1.1.1.1
Opaque value : 01000400008001
State : up
# Display multicast EVPN tunnel information on a leaf node of an mLDP P2MP tunnel.
<HUAWEI> display evpn vpn-instance name evpna inclusive-provider-tunnel verbose
Bridge-domain : 1
Root ip : 1.1.1.1
Opaque value : 01000400008001
State : up

Table 3-43 Description of the display evpn vpn-instance inclusive-provider-tunnel

command output
Item Description
VPN-Instance Name and ID EVPN instance name and ID
Address family bd-evpn BD-EVPN address family view
Route Distinguisher Route distinguisher (RD) of the EVPN instance
Label Policy Label policy
Export VPN Targets List of export route targets (ERTs)
Import VPN Targets List of import route targets (IRTs)
Bridge-domain BD bound to the EVPN instance
Ingress provider tunnel Ingress of the tunnel
PMSI type P2MP tunnel type
Root ip IP address of the root node over the mLDP P2MP

tunnel
Opaque value Opaque value (in the TLV format) that is carried in
packets and is not decoded
State P2MP tunnel status:

l up
l down
PMSI type P2MP tunnel type
Root ip IP address of the root node over the mLDP P2MP

tunnel
Opaque value Opaque value (in the TLV format) that is carried in
packets and is not decoded
State P2MP tunnel status:

l up
l down
Egress provider tunnel Egress of the tunnel
Egress PMSI count Number of egresses of the P2MP tunnel
3.3.23 display evpn vpn-instance mac-duplication

Function
The display evpn vpn-instance mac-duplication command displays information about
suppression on MAC route flapping.

Format
display evpn vpn-instance name vpn-instance-name mac-duplication
display evpn vpn-instance name vpn-instance-name mac-duplication bridge-domain bd-id
display evpn vpn-instance name vpn-instance-name mac-duplication mac-address mac-
address
display evpn vpn-instance name vpn-instance-name mac-duplication bridge-domain bd-id
mac-address mac-address
Parameters
name vpn- Specifies the name The value is a string of 1 to 31 case-sensitive
instance-name of an EVPN characters, spaces not supported. When double
instance. quotation marks are used around the string,
bridge-domain Specifies a BD ID. The value is an integer ranging from 1 to 32768.
bd-id
mac-address mac- Specifies a MAC The value is a 12-digit hexadecimal number, in
address address. the format of H-H-H. Each H is 4 digits. If an H
contains fewer than 4 digits, the left-most digits
are padded with zeros. For example, e0 is
displayed as 00e0.
Views
All Views
Default Level
1: Monitoring level

bgp read
Usage Guidelines
To view information about MAC duplication suppression, run the display evpn vpn-instance
mac-duplication command. The command output displays parameters related to MAC
duplication suppression and information about the suppressed MAC routes.
Example
# Display information about MAC duplication suppression.
<HUAWEI> display evpn vpn-instance name evrf1 mac-duplication

Status codes: s - suppressed

VPN-Instance Name and ID : vpn1, 5
Detect loop-times : 5
Detect cycle(s) : 180
Retry cycle(s) : 540
Black Hole : Enabled
Mac-address BdTag BdId MTimes LastSource SuppressTime

s 00e0-fc00-0001 0 -- 5 Eth-Trunk10 2018-03-30:15:30:30
Table 3-44 Description of the display evpn vpn-instance mac-duplication command output
Item Description
Status codes Status code
VPN-Instance Name and ID Name and ID of the EVPN instance
Detect loop-times Threshold for the number of times a MAC route flaps
Detect cycle(s) Detection period
Retry cycle(s) Hold-off time to unsuppress MAC duplication
Black Hole Whether black-hole MAC routing is enabled
Mac-address MAC address of the black-hole MAC route
BdTag BD tag
BdId BD ID
MTimes Number of times that a MAC route flaps
LastSource Source port
SuppressTime Date and time when MAC duplication was

suppressed
3.3.24 display evpn vpn-instance name mac-esi

Function
The display evpn vpn-instance name mac-esi command displays MAC routing information.
Format
display evpn vpn-instance name vpn-instance-name mac-esi

Parameters
vpn-instance- Specifies the name of The value is a string of 1 to 31 case-sensitive
name an EVPN instance. characters, spaces not supported. When double
Views
All views
Default Level
1: Monitoring level

evpnbgp read
Usage Guidelines
To view MAC routing information, including the MAC address, ESI, and next-hop address,
run the display evpn vpn-instance name mac-esi command.
Example
# Display MAC routing information.
<HUAWEI> display evpn vpn-instance name evpna mac-esi
EVPN Name : evpna
Number of Macs : 2
Network(EthTagId/MacAddrLen/MacAddr/IpAddrLen/IpAddr)
ESI NextHop
0:48:00e0-fc00-0001:0:0.0.0.0
0000.0000.0000.0000.0000 3.3.3.3
0:48:00e0-fc00-0002:0:0.0.0.0 0138.ba96.a93b.
0101.2100 0.0.0.0
Table 3-45 Description of the display evpn vpn-instance name mac-esi command output
Item Description
EVPN Name EVPN instance name
Number of Macs Number of MAC routes
Network Prefix of a MAC route
ESI ESI corresponding to a MAC route
NextHop Original next hop of a MAC route

3.3.25 display evpn track-peer-timer
Function
The display evpn track-peer-timer command displays information about a timer for peer
status tracking based on an ESI.
Format
display evpn track-peer-timer esi esi
Parameters

esi esi Specifies an The value is in the format of xxxx.xxxx.xxxx.xxxx.xxxx,
Ethernet segment where x is a hexadecimal integer ranging from 0 to F.
identifier (ESI). The value must start with 00 or 01 but cannot be all 0s.
Views
All views
Default Level
1: Monitoring level

bgp read
Usage Guidelines
To view information about a timer for peer status tracking based on an ESI on the master main
control board, run the display evpn track-peer-timer esi esi command.
Example
# Display information about a timer for peer status tracking based on an ESI.
<HUAWEI> display evpn track-peer-timer esi 0099.8888.7777.6666.5555
Esi Type Mode

TimerLeft(s)
0099.8888.7777.6666.5555 BRM_EVPN_TRACK_PEER_TIMER IDLE -----

Table 3-46 Description of the display evpn track-peer-timer command output

Item Description
Esi Ethernet segment identifier (ESI)
Type Timer type:

BRM_EVPN_TRACK_PEER_TIMER,
timer for peer status tracking
Mode Mode:
l IDLE: idle state
l RUNNING: running state
TimerLeft Remaining time of the timer for peer status

tracking
3.3.26 df-election ac-influence enable

Function
The df-election ac-influence enable command enables the function that the AC status
influences designated forwarder (DF) election.
The undo df-election ac-influence enable command disables the function that the AC status
influences DF election.
By default, the function that the AC status influences DF election is not enabled.
Format
undo df-election ac-influence enable
Parameters
None
Views
Global EVPN configuration view
Default Level

bgp write

Usage Guidelines
Usage Scenario
If a PE or AC-side link fails, DF election is triggered. If one of the sub-interfaces on the AC
interface goes Down but the other sub-interfaces bound to an EVPN instance remain Up, an
Ethernet segment (ES) route is not regenerated to trigger DF election, which may cause a
traffic forwarding failure.
After the function that the AC status influences DF election is enabled, a PE generates EVI
AD routes only when the AC interface is Up. During DF election, the system checks whether
the AD routes (including both the ES AD routes and EVI AD routes) advertised by the PE are
received to determine whether the PE can participate in election. If AD routes advertised by
the PE are not received, the PE does not participate in DF election.
Precautions
Multiple PEs participating in DF election must support the same election rule. Therefore, the
function that the AC status influences DF election must be enabled on multi-homed PEs.
Example
# Enable the function that the AC status influences DF election.
[~HUAWEI] evpn
[*HUAWEI-evpn] df-election ac-influence enable
[*HUAWEI-evpn] commit
3.3.27 df-election type vlan

Function
The df-election type vlan command enables VLAN-based designated forwarder (DF)
election.
The undo df-election type vlan command disables VLAN-based DF election.
By default, VLAN-based DF election is not enabled.
Format
undo df-election type vlan
Parameters
None
Views
Default Level


bgp write
Usage Guidelines
Usage Scenario
In EVPN All-Active scenarios, a CE at the near end is multi-homed to PEs, and broadcast,
unknown unicast, and multicast (BUM) packets from the remote end are sent to the PEs. To
prevent the CE from receiving multiple copies of BUM traffic from the PEs, elect one of the
PEs to forward the BUM traffic to the CE.
To meet this requirement, the df-election type vlan command must be run to enable VLAN-
based DF election. This configuration allows the PE->CE BUM traffic to be balanced along
the multi-homed links on a VLAN.
Precautions
Configure the same DF election mode on all the multi-homed PEs on a VLAN.
Example
# Configure VLAN-based DF election.
[~HUAWEI] evpn
[*HUAWEI-evpn] df-election type vlan
3.3.28 esi
Function
The esi command configures an Ethernet Segment Identifier (ESI).
The undo esi command deletes an ESI.
By default, no ESI is configured.
Format
esi esi
undo esi [ esi ]
Parameters
esi Specifies an ESI. The value is in the format of xxxx.xxxx.xxxx.xxxx.xxxx,
where x is a hexadecimal integer ranging from 0 to F. The
value of esi must start with 00 but cannot be all 0s.

Views
Ethernet interface view, Eth-Trunk interface view, Ethernet sub-interface view, GE sub-
interface view, PW-VE interface view, or GE interface view (GE optical interface view)
Default Level

bgp write
Usage Guidelines
Usage Scenario
EVPN defines a unique ESI for connections between multiple PEs connecting to a CE. PEs'
interfaces connecting to the same CE have the same ESI, and PEs' interfaces connecting to
different CEs have different ESIs. PEs exchange routes that carry the ESI so that a PE can
discover other PEs connecting to the same CE as itself.
Precautions
Because an ESI uniquely identifies a connection to a CE, configuring the same ESI on a PE is
not recommended.
Example
# Configure an ESI on GE 2/0/0.
[~HUAWEI] interface gigabitethernet 2/0/0
[*HUAWEI-GigabitEthernet2/0/0] esi 0011.1001.1001.1001.1002
# Configure an ESI on Eth-Trunk1.

<HUAWEI>system-view
[~HUAWEI]interface Eth-Trunk1
[~HUAWEI-Eth-Trunk1]esi 0001.0002.0003.0004.0005
[*HUAWEI-af-vpn-target]commit
3.3.29 esi (BD view)

Function
The esi command configures an ESI for a bridge domain (BD).
The undo esi command deletes an ESI of a BD.
By default, no ESI is configured for BDs.
Format
esi esi

undo esi [ esi ]
Parameters
esi Specifies an ESI. The value is in the format of xxxx.xxxx.xxxx.xxxx.xxxx,
where x is a hexadecimal integer ranging from 0 to F. The
value must start with 00 and cannot be all 0s.
Views
BD view
Default Level

bgp write
Usage Guidelines
Usage Scenario
In a DCI scenario, when EVPN is used to transmit ARP or MAC routes, run the esi command
to configure an ESI for the BD of a PE connecting to a DC gateway. The routes then carry the
ESI to allow the PE to detect the other PEs connecting to the same DC gateway. The ESIs are
the same for the BDs of the PEs connecting to the same DC gateway and are different for the
BDs of the PEs connecting to different DC gateways.
Prerequisites
l The BD is in the Up state.
l The BD has been bound to an EVPN instance using the evpn binding vpn-instance
command.
l The BD has been associated with a VNI using the vxlan vni vni-id command.
Precautions
An ESI identifies a CE to which a PE connects. Using different ESIs on the same PE is
recommended.
Example
# Configure an ESI for BD 10.
[~HUAWEI] evpn vpn-instance evrf1 bd-mode
[*HUAWEI-evpn-instance-evrf1] route-distinguisher 100:1
[*HUAWEI-evpn-instance-evrf1] vpn-target 1:1
[*HUAWEI-evpn-instance-evrf1] quit

[*HUAWEI] bridge-domain 10
[*HUAWEI-bd10] vxlan vni 100 split-horizon-mode
[*HUAWEI-bd10] evpn binding vpn-instance evrf1
[*HUAWEI-bd10] esi 0022.1002.1002.1002.1001
3.3.30 es track evpn-peer(evpn)

Function
The es track evpn-peer command enables EVPN BGP peer status tracking.
The undo es track evpn-peer command disables EVPN BGP peer status tracking.
By default, EVPN BGP peer status tracking is not enabled.
Format
es track evpn-peer peer-address
undo es track evpn-peer peer-address
Parameters
peer-address Specifies the IPv4 address of a peer. The value is in dotted decimal notation.
Views
Eth-Trunk interface view, PW-VE interface view, Port extension interface view
Default Level

bgp write
Usage Guidelines
Usage Scenario
On an EVPN where a CE is multi-homed to PEs, after a PE restarts due to a fault or other
reasons, traffic may be lost. As shown in Figure 3-139, CE1 is dual-homed to PE1 and PE2,
and PE1 is elected as the primary DF. After PE1 fails, PE2 changes to be the primary DF and
takes over the traffic. After PE1 recovers, if PE1 sets up a BGP peer relationship with PE2
before with PE3, PE1 and PE2 send Ethernet segment (ES) routes to each other. At the same
time, PE1 becomes the primary DF, and PE2 becomes the backup DF again. However, PE3
still forwards traffic to PE2, causing traffic loss.
To resolve this issue, run the es track evpn-peer command on PE1's interface connecting to
CE1. This configuration allows PE1 to trigger a delay timer for ES route advertisement after

PE1 recovers and PE1's interface connecting to CE1 goes Up. After the delay timer is
triggered, PE1 tracks the status of its BGP peers PE2 and PE3. If the BGP peer relationships
both go Up within the timer-specified delay, 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 generates and sends ES routes, PE1 performs DF election based
on all the received ES routes.
Figure 3-139 EVPN on which a CE is dual-homed to two PEs
PE1
Backbone
CE1
PE3 CE2
EVPN site
EVPN site
PE2
If the es track evpn-peer command is run, the delay timer for DF election loses effect.
Example
# Enable Eth-Trunk 1 to track the status of BGP peer 1.1.1.1.
<HUAWEI>system-view
[~HUAWEI] bgp 100
[*HUAWEI-bgp] l2vpn-family evpn
[*HUAWEI-bgp-af-evpn] peer 1.1.1.1 enable
[*HUAWEI-bgp-af-evpn] quit
[*HUAWEI-bgp] quit
[*HUAWEI]interface Eth-Trunk 1
[*HUAWEI-Eth-Trunk1]es track evpn-peer 1.1.1.1
3.3.31 es track evpn-peer(BD view)
Function
The es track evpn-peer command enables BGP EVPN peer status tracking.
The undo es track evpn-peer command disables BGP EVPN peer status tracking.
By default, BGP EVPN peer status tracking is disabled.
Format
es track evpn-peer source-address
undo es track evpn-peer source-address

Parameters

source-address Specifies the source IP address of a BGP The value is in dotted decimal
EVPN peer. notation.
Views
BD view
Default Level

bgp write
Usage Guidelines
Usage Scenario
If a CE is multi-homed to several PEs, All-Active mode is configured only on some of the

PEs, and one of the PEs fails, traffic loss may occur. In Figure 3-140, CE1 is dual-homed to
PE1 and PE2, and the redundancy mode of PE1 or PE2 is set to Single-Active. PE1 is elected
as the primary DF. If PE1 fails, the backup DF (PE2) becomes the primary DF and takes over
traffic. If PE1 recovers and establishes a peer relationship with PE2 earlier than with PE3,
PE1 and PE2 exchange Ethernet segment routes, and PE1 becomes the primary DF again,
with PE2 as the backup DF. However, PE3 still forwards traffic to PE2, causing a traffic
interruption.
To address this problem, run the es track evpn-peer command on the interface that connects
PE1 to CE1. After the command is run, if PE1 recovers and the interfaces that connect PE1
and CE1 are Up, PE1 starts the delay timer for sending Ethernet segment routes. After the
timer expires, PE1 starts the delay timer for receiving Ethernet segment routes. PE1 does not
participate in DF election until the latter timer expires. Detailed descriptions about the two
timers are as follows:
1. PE1 first starts the delay timer for sending Ethernet segment routes, and then PE1 tracks
the status of the peer relationships with PE2 and PE3. If both the peer relationships go
Up before the timer expires, PE1 sends Ethernet segment routes to PE2 and PE3. If only
one of the peer relationships goes Up before the timer expires, PE1 sends Ethernet
segment routes only to the peer with whom the peer relationship is Up.
2. PE1 then starts the delay timer for receiving Ethernet segment routes and waits for
Ethernet segment routes from other PEs. When the timer expires, PE1 participates in DF
election according to received Ethernet segment routes.

Figure 3-140 Networking on which a CE is dual-homed to two PEs
PE1
Backbone
CE1
PE3 CE2
EVPN site
EVPN site
PE2
The DF election delay timer expires after the es track evpn-peer command is run.
Example
# Enable BGP EVPN peer status tracking on a device that participates in DF election.
[~HUAWEI] evpn vpn-instance evrf1 bd-mode
[*HUAWEI] bgp 100
[*HUAWEI-bgp-af-evpn] quit
[*HUAWEI-bgp] quit
[*HUAWEI-bd10] evpn binding vpn-instance evrf1
[*HUAWEI-bd10] es track evpn-peer 1.1.1.1
3.3.32 es track bfd
Function
The es track bfd command associates an interface with a BFD session.
The undo es track bfd command cancels the association between an interface and a BFD
session.
By default, an interface is not associated with a BFD session.
Format
es track bfd bfd-session-name
undo es track bfd

Parameters

bfd-session-name Specifies the name of a BFD The value is a case-insensitive string of
session. 1 to 64 characters.
Views
Eth-Trunk interface view, PW-VE interface view
Default Level

bgp write
Usage Guidelines
Usage Scenario
In a scenario where a CE is dual-homed to PEs, a BFD session is set up between the PEs. To
enable BFD to track the dual-homing interfaces on the PEs, run the es track bfd command. If
one of the interfaces goes Down, the corresponding PE detects the fault using BFD, which
triggers a rapid primary/backup DF switchover. This configuration allows DF switching to be
associated with BFD, therefore facilitating a rapid switchover in case of a link failure.
Example
# Associate an interface with a BFD session.
[~HUAWEI] bfd
[*HUAWEI-bfd] quit
[*HUAWEI] bfd bfd1 bind peer-ip 2.2.2.2
[*HUAWEI-bfd-session-bfd1] quit
[*HUAWEI] interface Eth-Trunk 10
[*HUAWEI-Eth-Trunk10] es track bfd bfd1
3.3.33 etree enable
Function
The etree enable command enables EVPN E-Tree.
The undo etree enable command disables EVPN E-Tree.
By default, EVPN E-Tree is disabled.

Format
etree enable
undo etree enable
Parameters
None
Views
EVPN instance view or BD-EVPN instance view
Default Level

bgp write
Usage Guidelines
Usage Scenario
In an EVPN E-Tree scenario, if a basic EVPN instance is configured, the EVPN instance is
bound to an AC interface. If a BD-EVPN instance is configured, the BD-EVPN instance is
bound to a BD, and then the BD is associated with the AC interface. By default, the AC
interface has the root attribute. To set the leaf attribute for the AC interface to which an EVPN
instance is bound, run the etree enable and evpn e-tree-leaf commands. This configuration
disables leaf AC interfaces from sending traffic to each other. Only a leaf AC interface and a
root AC interface can send traffic to each other.
Precautions
The etree enable command cannot be run in the following EVPN instances:
l BD-EVPN instance bound to a BD with the vxlan vni vni-id plit-horizon-mode
command configuration
l BD-EVPN instance with the inclusive-provider-tunnel command configuration
If you want to run the undo etree enable command, ensure that no local interface with the
evpn e-tree-leaf command configuration exists.
Example
# Enable EVPN E-Tree.
[~HUAWEI] evpn vpn-instance evrf1
[~HUAWEI-evpn-instance-evrf1] etree enable

3.3.34 evpl instance (interface view)

Function
The evpl instance command binds an EVPL instance to an interface.
The undo evpl instance command unbinds an EVPL instance from an interface.
By default, no EVPL instance is bound to an interface.
Format
evpl instance evpl-id
undo evpl instance evpl-id
Parameters
evpl-id The value is an integer ranging from 1 to
Specifies an EVPL instance ID.
32768.
Views
Sub-interface view, Ethernet interface view, Eth-trunk interface view, GE interface view, Port
extension interface view, Port extension sub-interface view, PW-VE sub-interface view
Default Level

evpl write
Usage Guidelines
Usage Scenario
EVPL provides a P2P packets transmitting service solution. Regarding this solution, an MPLS
or VXLAN tunnel is established to traverse the backbone network. 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. The evpl instance command binds an
EVPL instance to an AC interface.
Example
# Bind an EVPL instance to a Layer 2 sub-interface.
[*HUAWEI] evpl instance 1 mpls-mode

[*HUAWEI-evpl-mpls1] quit
[*HUAWEI] interface gigabitethernet 1/0/1.1 mode l2
[*HUAWEI-GigabitEthernet1/0/1.1] encapsulation dot1q vid 10
[*HUAWEI-GigabitEthernet1/0/1.1] evpl instance 1
3.3.35 evpl instance (system view)
Function
The evpl instance command creates an EVPL instance.
The undo evpl instance command deletes an EVPL instance.
By default, no EVPL instances exist.
Format
evpl instance evpl-id mpls-mode
evpl instance evpl-id vxlan-mode
undo evpl instance evpl-id mpls-mode
undo evpl instance evpl-id vxlan-mode
Parameters

evpl-id The value is an integer
mpls-mode Specifies to use the MPLS mode for an EVPL -
instance.
vxlan-mode Specifies to use the VXLAN mode for an EVPL -

instance.
Views
System View
Default Level

evpl write

Usage Guidelines
Usage Scenario
In an E-Line scenario, to enable traffic communication between an AC interface and an

MPLS tunnel, first run the evpl instance evpl-id mpls-mode command to create an EVPL
instance in MPLS mode. Then, bind the EVPL instance to the AC interface.
In a scenario where a VXLAN tunnel is used for user access, a P2P VXLAN tunnel must be
created to transmit user packets. To terminate the P2P VXLAN tunnel on a PW-VE interface,
the P2P VXLAN tunnel must be associated with the PW-VE interface. To create the
association, first run the evpl instance evpl-id vxlan-mode command to create an EVPL
instance in VXLAN mode. Then, bind the EVPL instance to the VNI of the P2P VXLAN
tunnel and to the PW-VE interface.
Example
# Create an EVPL instance with the ID being 1 in MPLS mode.
[~HUAWEI] evpl instance 1 mpls-mode
# Create an EVPL instance with the ID being 2 in VXLAN mode.

[~HUAWEI] evpl instance 2 vxlan-mode
3.3.36 evpn (system view)
Function
The evpn command creates and displays the global EVPN configuration view. In this view,
you can configure global EVPN parameters and run related commands.
The undo evpn command deletes the global EVPN configuration view.
By default, the global EVPN configuration view is not created.
Format
evpn
undo evpn
Parameters
None
Views
System view
Default Level


bgp write
Usage Guidelines
Usage Scenario
To create and display the global EVPN configuration view, run the evpn command in the
system view.
After global EVPN configuration view is deleted using the undo evpn command, all
configurations in the global EVPN configuration view are cleared.
Example
# Create and display the global EVPN configuration view.
[~HUAWEI] evpn
3.3.37 evpn binding vpn-instance
Function
The evpn binding vpn-instance command binds a PE's interface to an EVPN instance.
The undo evpn binding vpn-instance command removes the binding relationship between a
PE's interface and an EVPN instance.
By default, a PE's interface is a public network interface without being bound to any EVPN
instance.
Format
evpn binding vpn-instance vpn-instance-name
undo evpn binding vpn-instance vpn-instance-name
Parameters

vpn-instance- Specifies the name of an The value is a string of 1 to 31 case-
name interface to be bound to an sensitive characters, spaces not supported.
EVPN instance. When double quotation marks are used
string.

Views
Ethernet interface view, Ethernet sub-interface view, GE interface view, GE sub-interface
view, Eth-Trunk interface view or PW-VE interface, Port extension interface view, Port
extension sub-interface view, or Eth-Trunk sub-interface view
Default Level

bgp write
Usage Guidelines
Usage Scenario
After an EVPN instance is created on a PE, the PE's interface connecting to a CE must be
bound to the EVPN instance.
Prerequisites
A route distinguisher (RD) has been configured in the view of the EVPN instance to be
bound.
After an interface is bound to or removed from an EVPN instance, the Layer 3 configurations
will be cleared.
Precautions
An EVPN instance has been bound to the Eth-Trunk interface. Running the evpn binding
vpn-instance command on the Eth-Trunk interface to bind another EVPN instance will
overwrite the current binding relationship.
The active-active mode of an accessed service depends on both the E-Trunk mode and EVPN
instance mode. If the Eth-Trunk interfaces of dual-homed PEs are both added to force-master
E-Trunks and the Eth-Trunk interfaces are bound to active-active EVPN instances, services
are accessed in active-active mode. If one of the Eth-Trunk interfaces of dual-homed PEs or
both of them are not added to force-master E-Trunks and the Eth-Trunk interfaces are bound
to single-active EVPN instances, services are accessed in single-active mode. If the modes of
E-Trunks to which Eth-Trunk interfaces are added do not match the modes of the EVPN
instances bound to the Eth-Trunk interfaces, packet loss may occur in the accessed services.
Example
# Bind Ethernet 3/0/1 to the EVPN instance named evrf1.

[~HUAWEI] interface GigabitEthernet 1/0/0

[~HUAWEI-GigabitEthernet1/0/0] evpn binding vpn-instance evrf1
3.3.38 evpn binding vpn-instance (EVPL)
Function
The evpn binding vpn-instance command binds a PE's EVPN instance to an EVPL instance.
The undo evpn binding vpn-instance command removes the binding relationship between a
PE's EVPN instance to an EVPL instance.
By default, a PE's EVPL instance without being bound to any EVPN instance.
Format
evpn binding vpn-instance vpn-instance-name
undo evpn binding vpn-instance vpn-instance-name
Parameters
vpn-instance vpn- Specifies the name of an The value is a string of 1 to 31 case-
instance-name EVPN instance to be bound sensitive characters, spaces not
to an EVPL instance. supported. When double quotation marks
are used around the string, spaces are
allowed in the string.
Views
EVPL instance MPLS mode view
Default Level

bgp write
Usage Guidelines
Usage Scenario
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. The EVPL instance is bound to an EVPN instance for a specified VPWS and bound
to an AC interface, to allow traffic communication between an AC interface on the user side
and a MPLS tunnel interface on the network side,

Example
# Binds a PE's EVPN instance to an EVPL instance.
[~HUAWEI] evpn vpn-instance evrf1 vpws
[*HUAWEI-evpl-mpls1] evpn binding vpn-instance evrf1
3.3.39 evpn enhancement port
Function
The evpn enhancement port command sets the UDP port number used by the PEs in active
state to negotiate the EVPN prune status.
The undo evpn enhancement port command cancels the setting.
By default, no UDP port number is set for the PEs in active state to negotiate the EVPN prune
status.
Format
evpn enhancement port port-id
undo evpn enhancement port port-id
Parameters

port-id Specifies a port number for a UDP interface. The value is an integer
NOTE ranging from 1025 to
The PEs in the active state must have the same UDP 65535.
port number.
Views
System view
Default Level

evpn write

Usage Guidelines
Usage Scenario
In the DCI or CloudVPN active-active scenario, BUM traffic sent to the devices in active
state reaches both Device 1 and Device 2. However, Device3 requires only one copy of BUM
traffic from Device1 or Device 2. Therefore, only cope of the traffic needs to be blocked.
Figure 3-141 Traffic sent to the devices in active state
Device1
Port A
Link A
Device3
Network
Link B
Port B
Device2
If BUM traffic is forwarded along Link B, the BUM traffic switches to Link A after Link B
fails. When Link B recovers, the BUM traffic switches from Link A back to Link B. Port B
can permit the BUM traffic only after Port A has blocked it. If Port B permits the BUM traffic
before Port A has blocked it, Device 3 will receive two copies of the BUM traffic. To resolve
the issue, run the evpn enhancement port port-id command on Device 1 and Device 2. In
this way, when traffic switches from Link A back to Link B, Device 1 and Device 2 will
exchange UDP packets with the configured UDP port number so that Port B can permit traffic
only after Port A has blocked it.
Precautions
This command applies only to the Admin-VS.
Example
# Set the UDP port number used by the PEs in active state to negotiation the EVPN prune
status to 1345.
[~HUAWEI] evpn enhancement port 1345
3.3.40 evpn e-tree-leaf
Function
The evpn e-tree-leaf command sets the leaf attribute for an interface.
The undo evpn e-tree-leaf command deletes the leaf attribute of an interface.
By default, the leaf attribute is not set for an interface.

Format
evpn e-tree-leaf
undo evpn e-tree-leaf
Parameters
None
Views
EVC Layer 2 sub-interface view, Ethernet interface view, Ethernet sub-interfac view, Eth-
Trunk interface view, Eth-Trunk sub-interface view, GE sub-interface view, or GE interface
view
Default Level

bgp write
Usage Guidelines
Usage Scenario
In an EVPN E-Tree scenario, if a basic EVPN instance is configured, the EVPN instance is
bound to an AC interface. If a BD-EVPN instance is configured, the BD-EVPN instance is
bound to a BD, and then the BD is associated with a Layer 2 sub-interface. By default, the AC
interface and Layer 2 sub-interface have the root attribute. To set the leaf attribute for the AC
interface or Layer 2 sub-interface, run the etree enable and evpn e-tree-leaf commands. This
configuration disables leaf AC interfaces from sending traffic to each other. Only a leaf AC
interface and a root AC interface can send traffic to each other.
Prerequisites
EVPN E-Tree has been enabled in a BD-EVPN instance or a basic EVPN instance using the
etree enable command.
For the basic EVPN instance, the instance has been bound to the target AC interface using the
evpn binding vpn-instance vpn-instance-name command. For the BD-EVPN instance, the
target Layer 2 sub-interface has been added to a BD using the bridge-domain bd-id
command.
Example
# Set the leaf attribute for the AC interface to which an EVPN instance is bound.
[~HUAWEI-evpn-instance-evrf1] etree enable

[*HUAWEI] interface GigabitEthernet 1/0/0

[*HUAWEI-GigabitEthernet1/0/0] evpn binding vpn-instance evrf1
[*HUAWEI-GigabitEthernet1/0/0] evpn e-tree-leaf
3.3.41 evpn mpls routing-enable

Function
The evpn mpls routing-enable command enables EVPN to generate and advertise IP prefix
routes and IRB routes.
The undo evpn mpls routing-enable command restores the default configuration.
By default, EVPN is not enabled to generate and advertise IP prefix routes or IRB routes.
Format
undo evpn mpls routing-enable
Parameters
None
Views
VPN instance view, VPN instance IPv4 address family view
Default Level

bgp write
Usage Guidelines
Usage Scenario
To enable EVPN to generate and advertise IP prefix routes and IRB routes, run the evpn mpls
routing-enable command so that the local device can advertise these routes to a BGP EVPN
peer.
Example
# Enable EVPN to generate and advertise IP prefix routes and IRB routes.
[*HUAWEI-vpn-instance-vpn1-af-ipv4] evpn mpls routing-enable

3.3.42 evpn redundancy-mode single-active
Function
The evpn redundancy-mode single-active command configures a device to work in Single-
Active mode.
The undo evpn redundancy-mode single-active command restores the default configuration.
By default, a device works in All-Active mode.
Format
evpn redundancy-mode single-active
undo evpn redundancy-mode single-active
Parameters
None.
Views
System view
Default Level

bgp write
Usage Guidelines
If all PEs connecting to a CE have the All-Active redundancy mode configured, a remote PE
sends unicast traffic destined for the CE to all PEs in load balancing mode. If you do not want
a PE to receive traffic in load balancing mode with other PEs, run the evpn redundancy-
mode single-active command on the PE.
Example
# Configure a device to work in Single-Active mode.
[~HUAWEI] evpn redundancy-mode single-active

3.3.43 evpn source-address

Function
The evpn source-address command configures an EVPN source address for PE
identification.
The undo evpn source-address command deletes an EVPN source address.
By default, no EVPN source address is configured.
Format
evpn source-address ip-address
undo evpn source-address [ ip-address ]
Parameters
ip-address Specifies an EVPN source address. The value is in dotted decimal notation.
Views
System view
Default Level

bgp write
Usage Guidelines
To configure an EVPN source address in an EVPN MPLS scenario, run the evpn source-
address command. The EVPN source address is filled in the Originating Router's IP
Address field of Inclusive Multicast and Ethernet Segment routes. In addition, the RDs of
Ethernet Segment and Ethernet Auto-Discovery Per ES routes are generated based on the
EVPN source address.
NOTE
The IP address configured for a source VXLAN tunnel endpoint (VTEP) using the source ip-address
command cannot be the same as the EVPN source address configured for PE identification using the
evpn source-address ip-address command.
Example
# Set an EVPN source address to 1.1.1.1.

[~HUAWEI] evpn source-address 1.1.1.1
3.3.44 evpn vpn-instance

Function
The evpn vpn-instance command creates an EVPN instance and enters the EVPN instance
view.
The undo evpn vpn-instance command deletes an EVPN instance.
By default, no EVPN instance is created.
Format
evpn vpn-instance vpn-instance-name [ vpws ]
undo evpn vpn-instance vpn-instance-name [ vpws ]
Parameters
name EVPN instance. characters, spaces not supported. In addition,
the VPN instance name must not be _public_.
When double quotation marks are used around
the string, spaces are allowed in the string.
vpws Vpws mode EVPN -
instance.
Views
System view
Default Level

bgp write
Usage Guidelines
Usage Scenario
To allow Layer 2 networks to communicate over a public network, use EVPN. EVPN
instances must be configured on PEs on the public network before you perform EVPN
operations. To configure an EVPN instance, run the evpn vpn-instance command.

An EVPN instance functions as a virtual routing table on a PE and consumes resources on the
PE.
After the undo evpn vpn-instance command is run to delete an EVPN instance, all
configurations of the EVPN instance are deleted.
Follow-up Procedure
After creating an EVPN instance, perform the following operations in the EVPN instance
view:
l Run the route-distinguisher command to configure an RD for the EVPN instance.

l Run the vpn-target command to configure VPN targets for the EVPN instance.
Example
# Create an EVPN instance named vrf1.
[~HUAWEI] evpn vpn-instance vrf1
[*HUAWEI-evpn-instance-vrf1]
Related Topics
3.3.81 route-distinguisher (EVPN)
3.3.86 vpn-target (EVPN)
3.3.45 evpn access vll convergence separate disable
Function
The evpn access vll convergence separate disable command enables the coupling flag in the
EVPN-accessing-VLL direction.
The undo evpn access vll convergence separate disable command enables the decoupling
flag in the EVPN-accessing-VLL direction.
By default, the decoupling flag is enabled in the EVPN-accessing-VLL direction.
Format
evpn access vll convergence separate disable
undo evpn access vll convergence separate disable
Parameters
None
Views
System view

Default Level

l2vpn write
Usage Guidelines
Usage Scenario
To enable the coupling flag in the EVPN-accessing-VLL direction, run the evpn access vll
convergence separate disable command. This configuration allows EVPN services to be
forwarded only through an LDP, TE, or LDP over TE LSP as the public network tunnel.
Precautions
If the coupling flag is enabled in the EVPN-accessing-VLL direction, only LDP, TE, or LDP
over TE LSPs are supported on the public network side of EVPN accessing VLL.
Example
# In the system view, enable the coupling flag in the EVPN-accessing-VLL direction.
[~HUAWEI] evpn access vll convergence separate disable
3.3.46 evpn reserve-interface enhancement

Function
The evpn reserve-interface enhancement command enables 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.
The undo evpn reserve-interface enhancement command restores the default configuration.
By default, board selection for internal loopback is performed based on interface boards when
packets enter a public network from an EVPN or BD EVPN for BUM forwarding.
Format
evpn reserve-interface enhancement
undo evpn reserve-interface enhancement
Parameters
None
Views
System view

Default Level

l2vpn write
Usage Guidelines
Usage Scenario
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.
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.
Example
# Enable board selection for internal loopback on a main control board when packets enter a
public network from an EVPN or BD EVPN for BUM forwarding.
[~HUAWEI] evpn reserve-interface enhancement
3.3.47 filter-policy export (EVPN instance view)
Function
The filter-policy export command configures an EVPN instance to filter MAC advertisement
routes to be sent.
The undo filter-policy export command cancels the filtering of MAC advertisement routes to
be sent.
By default, an EVPN instance does not filter MAC advertisement routes to be sent.
Format
filter-policy { acl-number | acl-name acl-name } export
undo filter-policy { acl-number | acl-name acl-name } export

Parameters

acl-number Specifies a Layer 2 ACL The value is an integer ranging from 4000 to
number. 4999.
acl-name acl- Specifies the name of a The value is a string of 1 to 64 case-

name named ACL. sensitive characters without spaces. The
value must start with a letter (a to z or A to
Z, case sensitive).
Views
EVPN instance view
Default Level

bgp write
Usage Guidelines
Usage Scenario
To allow an EVPN instance to filter MAC advertisement routes to be sent to other PEs, run
the filter-policy export command. This helps control and manage MAC advertisement routes.
If the command is run more than once, the latest configuration overrides the previous one.
Example
# Configure EVPN instance evpn1 to use ACL 4000 to filter MAC advertisement routes to be
sent.
[~HUAWEI] acl 4000
[*HUAWEI-acl-L2-4000] quit
[*HUAWEI] evpn vpn-instance evpn1
[*HUAWEI-evpn-instance-evpn1] filter-policy 4000 export
Related Topics
rule (Layer 2 ACL view)

3.3.48 filter-policy import (EVPN instance view)

Function
The filter-policy import command configures an EVPN instance to filter received MAC
The undo filter-policy import command cancels the filtering of received MAC
By default, an EVPN instance does not filter received MAC advertisement routes.
Format
filter-policy { acl-number | acl-name acl-name } import
undo filter-policy { acl-number | acl-name acl-name } import
Parameters
acl-number Specifies a Layer 2 ACL The value is an integer ranging from 4000 to
number. 4999.
acl-name acl- Specifies the name of a The value is a string of 1 to 64 case-

name named ACL. sensitive characters without spaces. The
value must start with a letter (a to z or A to
Z, case sensitive).
Views
EVPN instance view
Default Level

bgp write
Usage Guidelines
Usage Scenario
To allow an EVPN instance to filter MAC advertisement routes received from other PEs, run
the filter-policy import command. This helps control and manage MAC advertisement
routes.

Example
# Configure EVPN instance evpn1 to use ACL 4000 to filter received MAC advertisement
routes.
[~HUAWEI] acl 4000
[*HUAWEI-acl-L2-4000] quit
[*HUAWEI] evpn vpn-instance evpn1
[*HUAWEI-evpn-instance-evpn1] filter-policy 4000 import
Related Topics
rule (Layer 2 ACL view)
3.3.49 irb-reoriginated compatible
Function
The irb-reoriginated compatible command enables a device to re-encapsulate IRB routes
into IP prefix routes and ARP routes.
The undo irb-reoriginated compatible command restores the default configuration.
By default, a device is not enabled to re-encapsulate IRB routes into IP prefix routes or ARP
routes.
Format
irb-reoriginated compatible
undo irb-reoriginated compatible
Parameters
None
Views
Global EVPN view
Default Level

bgp write

Usage Guidelines
Usage Scenario
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, run the irb-
reoriginated compatible command to enable the device to re-encapsulate IRB routes into the
desired routes.
Example
# Enable a device to re-encapsulate IRB routes into IP prefix routes and ARP routes.
[~HUAWEI] evpn
[*HUAWEI-evpn] irb-reoriginated compatible
3.3.50 inclusive-provider-tunnel (BD-EVPN instance view)

Function
The inclusive-provider-tunnel command creates and displays the EVI I-PMSI view.
The undo inclusive-provider-tunnel command deletes the EVI I-PMSI view and
configurations in the view.
By default, the EVI I-PMSI view is not created.
Format
undo inclusive-provider-tunnel
Parameters
None
Views
BD-EVPN instance view
Default Level

bgp write
Usage Guidelines
Usage Scenario

conserve bandwidth resources, configure EVPN to use an mLDP P2MP tunnel for service
transmission. Configurations required for this function must be performed in the EVI I-PMSI
view. To create and enter the EVI I-PMSI view, run the inclusive-provider-tunnel command.
Example
# Create and display the EVI I-PMSI view.
3.3.51 isolate spoken (EVPN instance view)
Function
The isolate spoken command enables forwarding isolation among AC interfaces in an EVPN
instance.
The undo isolate spoken command disables forwarding isolation among AC interfaces in an
EVPN instance.
By default, forwarding isolation among AC interfaces in an EVPN instance is disabled.
Format
isolate spoken
undo isolate spoken
Parameters
None.
Views
EVPN instance view
Default Level

bgp write
Usage Guidelines
Usage Scenario

If the users using the same service are bound to the EVPN instance, you can use the isolate
spoken command to configure the forwarding isolation function to forbid the users from
accessing each other.
Precautions
The isolate spoken command applies only to MPLS EVPN instances.
Example
# Enable forwarding isolation among AC interfaces in an MPLS EVPN instance.
[*HUAWEI-evpn-instance-evpn1] isolate spoken
3.3.52 l2vpn-family evpn
Function
The l2vpn-family evpn command enables the BGP-EVPN address family and displays the
BGP-EVPN address family view.
The undo l2vpn-family evpn command deletes the BGP-EVPN address family view.
By default, the BGP-EVPN address family is disabled.
Format
l2vpn-family evpn
undo l2vpn-family evpn
Parameters
None
Views
BGP view
Default Level

bgp write

Usage Guidelines
Before you perform configurations in the BGP-EVPN address family view, run the l2vpn-
family evpn command to enable the BGP-EVPN address family and display the BGP-EVPN
address family view.
Example
# Enable the BGP-EVPN address family and display the BGP-EVPN address family view.
[~HUAWEI] bgp 100
[*HUAWEI-bgp-af-evpn]
3.3.53 leaf (EVI I-PMSI view)

Function
The leaf command specifies the current device as a leaf node for a multicast EVPN.
The undo leaf command deletes a leaf node configured for a multicast EVPN.
By default, no device is specified as a leaf node for a multicast EVPN.
Format
leaf
undo leaf
Parameters
None
Views
EVI I-PMSI view
Default Level

bgp write
Usage Guidelines
Usage Scenario
On a multicast EVPN, an mLDP P2MP tunnel has only one root node but may have multiple
leaf nodes. To specify a leaf node and enter the EVI I-PMSI-leaf view for leaf node
configurations, run the leaf command.

Precautions
In a dual-homing scenario, if the dual-homing PEs are configured as root nodes using the root
command, the two PEs can no longer be configured as leaf nodes using the leaf command.
Example
# Configure the current device as a leaf node for a multicast EVPN.
[*HUAWEI-evpn-instance-evpn1-inclusive] leaf
[*HUAWEI-evpn-instance-evpn1-inclusive-leaf]
3.3.54 local-remote frr (EVPN instance view)

Function
The local-remote frr enable command enables fast reroute (FRR) for MAC routes between
the local and remote ends in an EVPN instance.
The undo local-remote frr enable cancels the enabling of FRR for MAC routes between the
local and remote ends in an EVPN instance.
The local-remote frr disable command disables FRR for MAC routes between the local and
remote ends in an EVPN instance.
The undo local-remote frr disable command cancels the disabling of MAC routes between
the local and remote ends in an EVPN instance.
By default, if FRR for MAC routes between the local and remote ends in an EVPN instance is
not configured in an EVPN instance, the global configuration of FRR for MAC routes
between the local and remote ends takes effect.
Format
local-remote frr { enable | disable }
undo local-remote frr { enable | disable }
Parameters
enable Enables the current configuration. -
disable Disables the current configuration. -
Views
EVPN instance view, VPWS EVPN instance view
Default Level


bgp write
Usage Guidelines
Usage Scenario
In an EVPN active-active scenario, a CE is dual-homed to PE1 and PE2. If the link between
the CE and PE1 fails, to prevent downstream unicast traffic from being lost after reaching
PE1, run the local-remote frr command. This configuration allows PE1 to forward traffic to
PE2 so that traffic is sent to the CE through the link between PE2 and the CE.
Precautions
By default, an EVPN instance complies with the global configuration of FRR for MAC routes
between the local and remote ends. if FRR for MAC routes between the local and remote ends
in an EVPN instance is not configured in an EVPN instance, the global configuration of FRR
for MAC routes between the local and remote ends takes effect; if FRR for MAC routes
between the local and remote ends is configured in an EVPN instance, the configuration in the
EVPN instance takes precedence of the global configuration.
Example
# Configure FRR for MAC routes between the local and remote ends in an EVPN instance.
[~HUAWEI-evpn-instance-evpn1] local-remote frr enable
3.3.55 local-remote frr enable (global EVPN configuration view)
Function
The local-remote frr enable command enables fast reroute (FRR) for MAC routes between
the local and remote ends.
The undo local-remote frr enable command cancels the configuration of FRR for MAC
routes between the local and remote ends.
By default, the configuration of FRR for MAC routes between the local and remote ends is
canceled.
Format
undo local-remote frr enable
Parameters
None

Views
Default Level

bgp write
Usage Guidelines
In an EVPN active-active scenario, a CE is dual-homed to PE1 and PE2. If the link between
the CE and PE1 fails, to prevent downstream unicast traffic from being lost after reaching
PE1, run the local-remote frr enable command. This configuration allows PE1 to forward
traffic to PE2 so that traffic is sent to the CE through the link between PE2 and the CE.
Example
# Configure FRR for MAC routes between the local and remote ends in an EVPN instance.
[~HUAWEI] evpn
[~HUAWEI-evpn] local-remote frr enable
3.3.56 local-remote vpws-frr enable(global EVPN configuration

view)
Function
The local-remote vpws-frr enable command enables fast reroute (FRR) for MAC routes at
both local and remote ends of an EVPN VPWS.
The undo local-remote vpws-frr enable command disables FRR for MAC routes at both
local and remote ends of an EVPN VPWS.
By default, FRR for MAC routes is not enabled at both local and remote ends of an EVPN
VPWS.
Format
local-remote vpws-frr enable
undo local-remote vpws-frr enable
Parameters
None

Views
Default Level

bgp write
Usage Guidelines
In an EVPN VPWS multi-homing and single-active scenario shown in the following figure, a
CE is dual-homed to PE1 and PE2. The primary/backup status of PE1 and PE2 is determined
by DF election. Suppose PE1 is the primary DF in this example. In normal conditions,
downstream traffic on PE3 is sent to PE1. To prevent traffic loss, run the local-remote vpws-
frr command on PE1 to enable FRR for MAC routes at both local and remote ends of the
EVPN VPWS. If PE1 detects a link failure between itself and CE1, this configuration allows
PE1 to forward traffic to PE2, which then sends traffic to CE1.
Figure 3-142 EVPN VPWS multi-homing and single-active scenario

PE1
CE1 PE3 CE2

MPLS Network
PE2

AC Interface
EVPL Instance
MPLS LDP Tunnel
Example
# Enable FRR for MAC routes at both local and remote ends of an EVPN VPWS.
[~HUAWEI] evpn
[~HUAWEI-evpn] local-remote vpws-frr enable

3.3.57 local-service-id
Function
The local-service-id command enables a device to send protocol packets with local and
remote service IDs.
The undo local-service-id command disables a device to send protocol packets with local and
remote service IDs.
By default, a device sends protocol packets without local and remote service IDs.
Format
local-service-id service-id remote-service-id service-id
undo local-service-id service-id remote-service-id service-id
Parameters
local-service-id service-id Specifies a local service The value is an integer ranging
ID. from 1 to 16777215.
remote-service-id Specifies a remote service The value is an integer ranging

service-id ID. from 1 to 16777215.
Views
Default Level

bgp write
Usage Guidelines
Usage Scenario
EVPN VPWS is a P2P L2VPN solution. As shown in the following figure, CEs access PEs
through AC interfaces. An MPLS tunnel between the PEs traverses the backbone network.
Each AC interface is bound to an EVPL instance, and each EVPL instance is assigned a
service ID. The EVPL instance on the local PE maps that on the remote PE. To enable the PEs
to exchange protocol packets with local and remote service IDs, run the local-service-id
command. This configuration differentiates CE-accessed traffic and allows P2P interworking.

Figure 3-143 EVPN VPWS networking

Local-AC=AC1 Local-AC=AC2
Remote-AC=AC2 Remote-AC=AC1
EVPN-VPWS Instance
CE1 CE3
RR/P
Tunnel
PE1 MPLS Network PE2

Local-AC=AC3 Local-AC=AC4
Remote-AC=AC4 Remote-AC=AC3
CE2 CE4
AC Interface
EVPL Instance
MPLS LDP Tunnel
Example
# Enable packets to carry local and remote service IDs.
[*HUAWEI-evpl-mpls1] local-service-id 1 remote-service-id 1
3.3.58 mac limit

Function
The mac limit command sets a MAC address limit for an EVPN instance.
The undo mac limit command restores the default configuration.
By default, no MAC address limit is set for an EVPN instance.
Format
mac limit number [ simply-alert | mac-unchanged ]
undo mac limit

Parameters
number Sets the maximum number of MAC addresses The value is an
allowable for an EVPN instance. integer ranging
from 1 to
4294967295.
simply-alert Allows an EVPN instance to continue to process MAC -

addresses even if the number of MAC addresses being
processed exceeds the number value. In this case, only
an alarm is generated.
mac- Allows the existing numbers of MAC address entries -

unchanged and MAC routes to persist even if the number of MAC
addresses being processed by an EVPN instance
exceeds the threshold. In this case, an alarm is
generated, and no new MAC addresses can be
processed. Threshold crossing occurs if the initially
configured MAC address limit or the number value is
reduced.
Views
EVPN instance view
Default Level

route-base write
Usage Guidelines
Usage Scenario
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 being processed by an EVPN instance. After this configuration
is performed, the device checks the number of MAC routes generated based on the local
MAC address information and the number of MAC address entries generated after the device
receives remote MAC routes. If the sum of the two numbers exceeds the number value, an
alarm is generated, prompting you to check the validity of the MAC addresses in the system.

After the mac limit command is run on a device, the device may discard some MAC
addresses.
Precautions
If the mac limit command is run repeatedly, the latest configuration overwrites the previous
one.
Example
# Set a MAC address limit for an EVPN instance and allow only an alarm to be generated if
the number of MAC addresses being processed exceeds the limit.
[*HUAWEI-evpn-instance-evpn1] mac limit 1000 simply-alert
3.3.59 mac-duplication
Function
The mac-duplication command displays the EVPN-MAC-duplication view.
By default, the EVPN-MAC-duplication view is not displayed.
Format
mac-duplication
Parameters
None
Views
EVPN view, EVPN instance view, or BD-EVPN instance view
Default Level

bgp write
Usage Guidelines
Usage Scenario

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. To modify the configuration of MAC duplication
suppression, run the mac-duplication command to enter the EVPN-MAC-duplication view.
Example
# Enter the EVPN-MAC-duplication view.
[~HUAWEI] evpn
[*HUAWEI-evpn] mac-duplication
3.3.60 mac threshold-alarm
Function
The mac threshold-alarm command configures MAC address alarm thresholds for an EVPN
instance.
The undo mac threshold-alarm command restores the default MAC address alarm
thresholds.
By default, the alarm reporting threshold is 80% for EVPN_1.3.6.1.4.1.2011.5.25.145.22.3

hwEvpnMacThresholdExceed, and the alarm clearing threshold is 70% for
EVPN_1.3.6.1.4.1.2011.5.25.145.22.4 hwEvpnMacThresholdExceedClear.
Format
mac threshold-alarm upper-limit upper-limit-value lower-limit lower-limit-value
undo mac threshold-alarm
Parameters
upper-limit Specifies the alarm The value is an integer percent ranging from 1
upper-limit-value reporting threshold for to 100.
MAC addresses in an NOTE
EVPN instance. It is recommended that you specify a value smaller
than 96 for upper-limit-value.
lower-limit Specifies the alarm The value is a percent integer ranging from 1
lower-limit-value clearing threshold for to 100.
MAC addresses in an NOTE
EVPN instance. lower-limit-value must be smaller than upper-limit-
value. If you do not want alarms to be frequently
reported and cleared due to route flapping, ensure
that lower-limit-value is smaller than upper-limit-
value by 10 at least.

Views
EVPN instance view
Default Level

route-base write
Usage Guidelines
Usage Scenario
The number of MAC addresses allowed by an EVPN instance is limited. If the number
exceeds the maximum limit, services may be interrupted. To address this problem, configure
alarm thresholds for MAC addresses in the EVPN instance. You can then check whether
exceptions have occurred based on reported alarms and take immediate measures to prevent
excess MAC addresses from being learned by the EVPN instance.
To adjust alarm reporting and clearing thresholds, run the mac threshold-alarm command.
Precautions
The mac threshold-alarm command simply configures alarm thresholds for MAC addresses
in an EVPN instance. A threshold-crossing alarm can be reported only if the following
conditions are met:
l The alarm function is enabled using the snmp-agent trap enable feature-name evpn
command.
l The number of MAC addresses in the EVPN instance exceeds the alarm reporting
threshold or falls below the alarm clearing threshold.
Example
# Configure an alarm reporting threshold of 85% and an alarm clearing threshold of 65% for
MAC addresses in an EVPN instance.
[*HUAWEI-evpn-instance-evpn1] mac threshold-alarm upper-limit 85 lower-limit 65
3.3.61 mldp p2mp (EVI I-PMSI root view)
Function
The mldp p2mp command configures a BD-EVPN instance to use an mLDP P2MP tunnel to
carry multicast services and displays the EVI I-PMSI root mLDP view.
The undo mldp p2mp command disables a BD-EVPN instance from using an mLDP P2MP
tunnel to carry multicast services.

By default, a BD-EVPN instance does not use an mLDP P2MP tunnel to carry multicast
services.
Format
mldp p2mp
undo mldp p2mp
Parameters
None
Views
Default Level

bgp write
Usage Guidelines
Usage Scenario
conserve bandwidth resources, run the mldp p2mp command to configure a BD-EVPN
instance to use an mLDP P2MP tunnel to carry multicast services.
Example
# Configure a BD-EVPN instance to use an mLDP P2MP tunnel to carry multicast services
and enter the EVI I-PMSI root mLDP view.
[*HUAWEI-evpn-instance-evpn1-inclusive-root] mldp p2mp
[*HUAWEI-evpn-instance-evpn1-inclusive-root-mldpp2mp]
3.3.62 mtu-match ignore (EVPL-MPLS)
Function
The mtu-match ignore command configures an EVPL instance to ignore the MTU matching
check.

The undo mtu-match ignore command disables an EVPL instance from ignoring the MTU
matching check.
By default, an EVPL instance cannot ignore the MTU matching check.
Format
mtu-match ignore
undo mtu-match ignore
Parameters
None
Views
Default Level

bgp write
Usage Guidelines
Usage Scenario
By default, PEs perform the MTU matching check in EVPL instances in MPLS mode. If the
MTUs in EVPL instances in MPLS mode at both ends do not match, the VC cannot go Up. In
a scenario where a Huawei device interworks with a non-Huawei device through an EVPN
VPWS, if the non-Huawei device does not support the MTU matching check in an EVPL
instance in MPLS mode, run the mtu-match ignore command to configure an EVPL instance
to ignore the MTU matching check.
Example
# Configure an EVPL instance to ignore the MTU matching check.
[~HUAWEI-evpl-mpls2] mtu-match ignore

3.3.63 peer advertise
Function
The peer advertise command enables a device to advertise ND, ARP or IRB routes to a BGP
EVPN peer.
The undo peer advertise command restores the default configuration.
By default, a device does not advertise ND, ARP or IRB routes to a BGP EVPN peer.
Format
peer { ipv4-address | group-name } advertise { arp | irb }
undo peer { ipv4-address | group-name } advertise { arp | irb }
peer { ipv4-address | group-name } advertise irbv6
undo peer { ipv4-address | group-name } advertise irbv6
peer { ipv4-address | group-name } advertise nd
undo peer { ipv4-address | group-name } advertise nd
Parameters

ipv4-address Specifies the IPv4 address of a BGP EVPN The value is in dotted decimal
peer. notation.
group-name Specifies the name of a BGP EVPN peer The name is a string of 1 to 47
group. case-sensitive characters, with
spaces not supported. When
double quotation marks are
used around the string, spaces
arp Configures a device to advertise ARP routes -
to its BGP EVPN peers.
irb Configures a device to advertise IRB routes -
nd Configures a device to advertise ND routes -
irbv6 Configures a device to advertise IRBv6 -
routes to its BGP EVPN peers.
Views
BGP-EVPN address family view

Default Level

bgp write
Usage Guidelines
Usage Scenario
To allow a device to advertise ARP or IRB routes to its BGP EVPN peers, run the peer
advertise command. This command allows VTEPs to establish VXLAN tunnels and
implements ARP broadcast suppression on networks. If you specify irb, VTEPs can also
transmit host routes.
If you specify nd or irbv6, the local device can advertise ND or IRBv6 routes to a BGP
EVPN peer. After receiving the routes, the BGP EVPN peer generates a proxy table locally.
After the BGP EVPN peer receives NS packets, it searches the local proxy table. If an entry is
hit, the VXLAN gateway directly performs proxy ND or multicast-to-unicast processing
Precautions
You cannot specify both arp and irb in the same BGP-EVPN address family view.
You cannot specify both nd and irbv6 in the same BGP-EVPN address family view.
Example
# Configure a device to advertise ARP routes to its BGP EVPN peers.
[~HUAWEI] bgp 100
[*HUAWEI-bgp-af-evpn] peer 1.1.1.1 advertise arp
3.3.64 peer advertise route-reoriginated (BGP-EVPN address

family view)
Function
The peer advertise route-reoriginated command configures a device to send the routes that
are regenerated in the EVPN or VPNv4 address family to a BGP EVPN peer.
The undo peer advertise route-reoriginated command restores the default configuration.
By default, a device does not send the routes that are regenerated in the EVPN or VPNv4
address family to a BGP EVPN peer.

Format
peer { ipv4-address | group-name } advertise route-reoriginated { evpn { mac-ip | ip |
mac } | vpnv4 }
undo peer { ipv4-address | group-name } advertise route-reoriginated { evpn { mac-ip | ip

| mac } | vpnv4 }
Parameters
ipv4-address Specifies the IPv4 address of a BGP The value is in dotted decimal
EVPN peer. notation.
group-name Specifies the name of a BGP EVPN peer The name is a string of 1 to 47
group. case-sensitive characters, with
double quotation marks are used
around the string, spaces are
evpn Re-encapsulates received EVPN routes. -
mac-ip Re-encapsulates the IRB or ARP routes -
in received EVPN routes.
ip Re-encapsulates received prefix routes. -
mac Re-encapsulates MAC routes in received -
EVPN routes.
vpnv4 Re-encapsulates received VPNv4 routes. -
Views
Default Level

bgp write
Usage Guidelines
Usage Scenario
Data Center Interconnection (DCI) provides solutions used to interconnect data centers. In
DCI solutions, each DCI-PE re-encapsulates received EVPN or VPNv4 routes before sending
them to its peers.

l After the 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 EVPN
routes that carry the MPLS encapsulation attribute to the BGP EVPN peer on the DCI
backbone network.
l After the EVPN/VPNv4 routes that are received from the BGP EVPN/VPNv4 peer on
the DCI backbone network and carry the MPLS encapsulation attribute are regenerated
on the local DCI-PE, the local DCI-PE advertises EVPN routes that carry the VXLAN
encapsulation attribute to the DC side.
Prerequisites
EVPN or VPNv4 route regeneration has been enabled using the peer { ipv4-address | group-
name } import reoriginate command.
Example
# Configure the DCI-PE to send the ARP routes that are regenerated to a BGP EVPN peer.
[~HUAWEI] bgp 100
[*HUAWEI-bgp-af-evpn] peer 1.1.1.1 advertise route-reoriginated evpn mac-ip
# Configure the DCI-PE to send the MAC routes that are regenerated to a BGP EVPN peer.
[~HUAWEI] bgp 100
[*HUAWEI-bgp-af-evpn] peer 2.2.2.2 advertise route-reoriginated evpn mac
# Configure the DCI-PE to send the VPNv4 routes that are regenerated to a BGP EVPN peer.
[~HUAWEI] bgp 100
[*HUAWEI-bgp-af-evpn] peer 3.3.3.3 advertise route-reoriginated vpnv4
3.3.65 peer advertise route-reoriginated
Function
The peer advertise route-reoriginated command configures a device to send the routes that
are regenerated in the EVPN address family to a VPNv4 peer.
The undo peer advertise route-reoriginated command restores the default configuration.
By default, a device does not send the routes that are regenerated in the EVPN address family
to a VPNv4 peer.
Format
peer { ipv4-address | group-name } advertise route-reoriginated evpn { mac-ip | ip }
undo peer { ipv4-address | group-name } advertise route-reoriginated evpn { mac-ip | ip }

Parameters
ipv4-address Specifies the IPv4 address of a The value is in dotted decimal
VPNv4 peer. notation.
group-name Specifies the name of a VPNv4 peer The name is a string of 1 to 47 case-
group. sensitive characters, with spaces not
evpn Re-encapsulates received EVPN -
routes.
mac-ip Re-encapsulates IRB routes in -
received EVPN routes.
ip Re-encapsulates IP prefix routes in -
received EVPN routes.
Views
BGP-VPNv4 address family view
Default Level

bgp write
Usage Guidelines
Usage Scenario
A DCI is a solution for communication between DCs. In the DCI solution, after the 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 routes that carry the MPLS
encapsulation attribute to the peer on the DCI backbone network.
Prerequisites
EVPN route regeneration has been enabled using the peer { ipv4-address | group-name }
import reoriginate command.
Precautions
The peer advertise route-reoriginated command that is run in the VPNv4 address family
view applies only to the Option A VXLAN Layer 3 access scenario where GWs and DCI-PEs
are separately deployed or to the scenario where users on different network segments
communicate through a VXLAN tunnel.

Example
# Configure the DCI-PE to send the IRB routes that are regenerated to a VPNv4 peer.
[~HUAWEI] bgp 100
[*HUAWEI-bgp-af-vpnv4] peer 1.1.1.1 enable
[*HUAWEI-bgp-af-vpnv4] peer 1.1.1.1 advertise route-reoriginated evpn mac-ip
# Configure the DCI-PE to send the IP prefix routes that are regenerated to a VPNv4 peer.
[~HUAWEI] bgp 100
[*HUAWEI-bgp-af-vpnv4] peer 2.2.2.2 advertise route-reoriginated evpn ip
3.3.66 peer import reoriginate
Function
The peer import reoriginate command enables the function to add the regeneration flag to
the routes received from the peer.
The undo peer import reoriginate command restores the default configuration.
By default, the local device does not add the regeneration flag to the routes received from the
peer.
Format
peer { ipv4-address | group-name } import reoriginate
undo peer { ipv4-address | group-name } import reoriginate
Parameters
ipv4-address Specifies the IPv4 address of The value is in dotted decimal notation.
a BGP peer.
group-name Specifies the name of a BGP The name is a string of 1 to 47 case-sensitive
peer group. characters, with spaces not supported. When
double quotation marks are used around the
string, spaces are allowed in the string.
Views
BGP-EVPN address family view, BGP-VPNv4 address family view
Default Level


bgp write
Usage Guidelines
Usage Scenario
In the data center interconnect (DCI) solution, DCI-PE adds the regeneration flag to the
received EVPN routes or VPNv4 routes before sending the routes to the peer. By default, the
function to add the regeneration flag to the routes received from the peer is disabled.
Specifically, DCI-PE does not re-encapsulate the routes received from the peer. Therefore, to
allow DCI-PE to re-encapsulate the EVPN routes or VPNv4 routes, run the peer import
reoriginate command to enable the function to add the regeneration flag to the routes
received from the peer.
Prerequisites
Route exchange with a specified peer or peer group has been enabled using the peer { group-
name | peer-address } enable command.
Precautions
The peer import reoriginate command applies only to the Option A VXLAN Layer 3 access
scenario where GWs and DCI-PEs are separately deployed or to the scenario where users on
the same network segment or on different network segments communicate through a VXLAN
tunnel.
Example
# Configure the device to add the regeneration flag to the routes to be received from a BGP
EVPN peer in the BGP-EVPN address family view.
[~HUAWEI] bgp 100
[*HUAWEI-bgp-af-evpn] peer 1.1.1.1 import reoriginate
# Configure the device to add the regeneration flag to the routes to be received from a BGP
VPNv4 peer in the BGP-VPNv4 address family view.
[~HUAWEI] bgp 100
[*HUAWEI-bgp-af-vpnv4] peer 2.2.2.2 import reoriginate
3.3.67 peer mac-limit (BGP EVPN view)

Function
The peer mac-limit command configures the maximum number of MAC advertisement
routes allowed to be received from a peer.

The undo peer mac-limit command restores the default configuration.

By default, the number of MAC advertisement routes allowed to be received from a peer is
not limited.
Format
peer { group-name | ipv4-address } mac-limit number [ percentage ] [ alert-only | idle-
forever | idle-timeout times ]
undo peer { group-name | ipv4-address } mac-limit
Parameters
group-name Specifies the name of a peer group. The name is a string of 1 to
47 case-sensitive characters,
with spaces not supported.
When double quotation
marks are used around the
string, spaces are allowed in
the string.
ipv4-address Specifies the IPv4 address of a peer. The value is in dotted
decimal notation.
number Specifies the maximum number of MAC The value is an integer
advertisement routes allowed to be received ranging from 1 to
from a peer. 4294967295.
percentage Specifies a percentage of MAC advertisement The value is an integer
routes for the device to generate an alarm. If ranging from 1 to 100. The
the number of MAC advertisement routes default value is 75.
received from a peer exceeds (number ×
percentage)/100, the device generates an
alarm.
alert-only Indicates that an alarm will be generated and -
additional routes will be denied if the
maximum number of routes allowed have
been received.
NOTE
This parameter is recommended to prevent a peer
disconnection when the number of routes received
by the router exceeds the maximum limit.
idle-forever Indicates that a connection that is interrupted -

after the maximum number of routes allowed
have been received cannot be automatically
re-established.


idle-timeout Specifies a timer for re-establishing a The value is an integer
times connection if the connection is interrupted ranging from 1 to 1200, in
after the maximum number of routes allowed minutes.
have been received. Before the timer expires,
the system does not re-establish a connection.
Views
Default Level

bgp write
Usage Guidelines
Usage Scenario
these routes occupy a large proportion of the total number of MAC advertisement routes, run
the peer mac-limit command to configure the maximum number of MAC advertisement
routes allowed to be received from each peer. If the number of received MAC advertisement
routes exceeds the specified maximum number, the system displays an alarm
EVPN_1.3.6.1.4.1.2011.5.25.145.22.1 hwEvpnMacExceed, instructing users to check the
validity of the MAC advertisement routes received in the EVPN instance.
After this command is run, excess route prefixes of the EVPN instance may be discarded.
If the undo peer mac-limit command is run after the received MAC advertisement routes
exceed the specified maximum number, the system receives route prefixes from PEs again to
construct the BGP EVPN routing table.
If a peer relationship between two devices is in the Established state, the following situations
occur:
l If the number of routes received by the router exceeds the maximum limit after you run
the peer mac-limit command for the first time or run the command to reduce the
maximum limit:
– If you specified alert-only in the command, the router does not disconnect its BGP
peer. The received routes are not removed, and no additional routes will be
accepted.
– If you specified idle-forever in the command, the router disconnects its BGP peer.
To re-establish the connection, run the reset bgp command.

– If you specified idle-timeout in the command, the router disconnects its BGP peer
and re-establishes its BGP peer relationship automatically after the timeout timer
expires. To re-establish the connection before the timeout timer expires, run the
reset bgp command.
l If the upper limit set on the router is increased to be greater than the number of received
routes, the router sends Refresh packets to receive routes again. If the router does not
support the route-refresh capability, the router needs to re-establish the connection with
its peer.
l If the upper limit set on the router is reduced but is still greater than the number of
received routes, only configuration parameters need to be modified.
Assume that none of alert-only, idle-forever, and idle-timeout is configured. If the number
of routes exceeds the upper limit, an alarm is generated and recorded in the log. Then, the
peer relationship is disconnected. The devices try to re-establish the peer relationship after 30
seconds.
Example
# Configure a device only to generate an alarm when more than 1000 MAC advertisement
routes are received.
[~HUAWEI] bgp 100
[*HUAWEI-bgp-af-evpn] peer 2.2.2.2 mac-limit 1000 alert-only
3.3.68 peer esad-route-compatible (BGP-EVPN address family

view)
Function
The peer esad-route-compatible enable command enables a device to send ES AD routes in
the standard format defined in relevant standards.
The peer esad-route-compatible disable command enables a device to send ES AD routes in
a non-standard format.
The peer esad-route-compatible command enables all peers of a peer group to send ES AD
routes in the standard format defined in relevant standards.
The undo peer esad-route-compatible command cancels the standard format in which ES
AD routes are sent.
By default, a device sends ES AD routes in a non-standard format.
Format
peer ipv4-address esad-route-compatible { enable disable }
undo peer ipv4-address esad-route-compatible { enable disable }
peer peer-group-name esad-route-compatible
undo peer peer-group-name esad-route-compatible

Parameters

ipv4-address Specifies the IPv4 address of a peer. The value is in dotted decimal
notation.
peer-group-name Specifies the name of a peer group. -
Views
Default Level

bgp write
Usage Guidelines
Usage Scenario
In an earlier software version, the ESI of an ES AD route is placed in the Label field of EVPN
NLRI instead of being in the ESI field according to relevant standards. Therefore, to ensure
that the devices running earlier and later software versions can communicate with each other,
configure the format in which ES AD routes are to be sent. To send ES AD routes in a
standard format, run the peer esad-route-compatible enable command. To send ES AD
routes in a non-standard format, run the peer esad-route-compatible disable command.
Precautions
After the peer esad-route-compatible command is run for a peer group and the peer esad-
route-compatible enable command is run for a specified peer of the group, if the peer group
and the specified peer are configured to send ES AD routes in different formats, the specified
peer sends ES AD routes in its own configured format.
Example
# Enable a device to send ES AD routes in the standard format defined in relevant standards.
[~HUAWEI] bgp 100
[*HUAWEI-bgp-af-evpn] peer 1.1.1.1 esad-route-compatible enable

3.3.69 peer split-group
Function
The peer split-group command configures a split horizon group (SHG) to which BGP EVPN
peers (or peer groups) belong.
The undo peer split-group command restores the default configuration.
By default, no SHG is configured for BGP EVPN peers (or peer groups).
Format
peer { group-name | ipv4-address } split-group split-group-name
undo peer { group-name | ipv4-address } split-group split-group-name
Parameters
group-name Specifies the name of a BGP The name is a string of 1 to 47 case-
EVPN peer group. sensitive characters, with spaces not
supported. When double quotation marks
ipv4-address Specifies the IPv4 address of The value is in dotted decimal notation.
a BGP EVPN peer.
split-group Specifies the name of the The value is a string of 1 to 31 case-
split-group-name SHG to which BGP EVPN sensitive characters, spaces not supported.
peers (or peer groups) The string can contain spaces if it is
belong. enclosed with double quotation marks (").
Views
Default Level

bgp write
Usage Guidelines
Usage Scenario

In a scenario where segment VXLAN is used to implement Layer 2 interworking between

DCs, a VXLAN tunnel is established in BGP EVPN mode between the DCs. To prevent
forwarding BUM traffic from causing loops, run the peer split-group command on the transit
leaf nodes (edge devices interconnecting the DCs) to configure an SHG to which the BGP
EVPN peers (transit leaf nodes) belong. After the configuration is complete, devices within a
DC belong to the default SHG, and transit leaf nodes between DCs belong to the specified
SHG. In this manner, when a transit leaf node receives BUM traffic, it does not forward traffic
to a device belonging to the same SHG, therefore preventing loops.
Prerequisites
BGP EVPN peers or peer groups have been enabled to exchange route information using the
peer { group-name | ipv4-address } enable command.
Example
# Configure an SHG to which the BGP EVPN peers belong.
[~HUAWEI] bgp 100
[*HUAWEI-bgp-af-evpn] peer 10.1.1.9 split-group aa
3.3.70 peer upe (BGP-EVPN address family view)

Function
The peer upe command configures a BGP EVPN peer or peer group as the UPE.
The undo peer upe command restores the default configuration.
By default, no BGP EVPN peer or peer group is specified as the UPE.
Format
peer { group-name | ipv4-address } upe
undo peer { group-name | ipv4-address } upe
Parameters
group-name Specifies the name of a peer The name is a string of 1 to 47 case-sensitive
group. characters, with spaces not supported. When
ipv4-address Specifies the IPv4 address It is in dotted decimal notation.
of a peer.
Views

Default Level

bgp write
Usage Guidelines
Usage Scenario
In an EVPN HoVPN scenario, run the peer upe command to specify a device as a UPE. After
a UPE is specified on the SPE using the peer upe command, the SPE does not send a specific
route to the UPE. If the peer route-policy export command is run on the SPE to configure
routing policies for the UPE and certain specific routes can pass the filtration of routing
policies, these specific routes can be sent to the UPE.
After you run the peer upe command on an SPE to specify a device as a UPE, the SPE can
change the next hops of routes received from the UPE to itself and reflect these routes to the
NPE.
Prerequisites
A BGP EVPN peer or peer group has been created and the BGP-EVPN address family view
has been enabled.
Example
# Specify the peer 1.1.1.2 as UPE.
[~HUAWEI] bgp 100
[*HUAWEI-bgp-af-evpn] peer 1.1.1.2 upe
3.3.71 peer vpn-orf disable

Function
The peer vpn-orf disable command disables EVPN ORF for a BGP EVPN peer or peer
group.
The undo peer vpn-orf disable command restores the default configuration.
By default, a device with EVPN ORF enabled performs EVPN ORF for all its BGP EVPN
peers.
Format
peer { ipv4-address | group-name } vpn-orf disable
undo peer { ipv4-address | group-name } vpn-orf disable

Parameters
ipv4-address Specifies the IPv4 address of
The value is in dotted decimal notation.
a BGP peer.
peer group. characters, with spaces not supported. When
Views
Default Level

evpnbgp write
Usage Guidelines
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.
Example
# Disable EVPN ORF for a specified BGP EVPN peer.
[~HUAWEI] bgp 100
[*HUAWEI-af-evpn] peer 1.1.1.1 enable
[*HUAWEI-af-evpn] peer 1.1.1.1 vpn-orf disable
3.3.72 refresh bgp evpn

Function
The refresh bgp evpn command configures BGP EVPN soft reset to allow BGP EVPN
connections to be softly reset.

Format
refresh bgp evpn { all | peer-address | group group-name } { export | import }
Parameters
all Softly resets all BGP EVPN -
connections.
peer-address Specifies a BGP EVPN peer IP The value is in dotted decimal
address. notation.
group group- Specifies the name of a peer group. The name is a string of 1 to 47
name case-sensitive characters, with
double quotation marks are used
around the string, spaces are
export Softly resets BGP EVPN -
connections in the outbound
direction.
import Softly resets BGP EVPN -
connections in the inbound
direction.
Views
User view
Default Level

bgp debug
Usage Guidelines
Usage Scenario
To softly reset BGP EVPN connections, run the refresh bgp evpn command. BGP EVPN soft
reset allows the system to refresh a BGP EVPN routing table without tearing down the BGP
EVPN connections and to apply a new filtering policy.
Prerequisites
The route-refresh function has been enabled for BGP EVPN peers.

Example
# Softly reset all BGP EVPN connections in the inbound direction so that new configurations
can take effect.
<HUAWEI> refresh bgp evpn all import
3.3.73 remote frr (VPWS-EVPN instance view)

Function
The remote frr enable command enables fast reroute (FRR) for MAC routes at the remote
end.
The undo remote frr enable command cancels the configuration of FRR for MAC routes at
the remote end.
The remote frr disable command disables FRR for MAC routes at the remote end.
The undo remote frr disable command cancels the disabling of FRR for MAC routes at the
remote end.
By default, FRR for MAC routes is not configured at the remote end.
Format
remote frr [ enable | disable ]
undo remote frr [ enable | disable ]
Parameters
enable Enables the current configuration. -
disable Disables the current configuration. -
Views
VPWS-EVPN instance view
Default Level

bgp write
Usage Guidelines
Usage Scenario

In an EVPN VPWS multi-homing and single-active scenario shown in the following figure, a
CE is dual-homed to PE1 and PE2. The primary/backup status of PE1 and PE2 is determined
by DF election. Suppose PE1 is the primary DF in this example. In normal conditions,
downstream traffic on PE3 is sent to PE1. To prevent traffic loss, run the remote frr enable
command on PE3 to enable FRR for MAC routes at the remote end. If PE3 detects a link
failure between itself and PE1, this configuration allows PE3 to rapidly switch traffic to PE2,
which then sends traffic to CE1.

PE1
CE1 PE3 CE2

MPLS Network
PE2

AC Interface
EVPL Instance
MPLS LDP Tunnel
Precautions
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.
Example
# Enable FRR for MAC routes in an EVPN instance at the remote end.
[~HUAWEI] evpn vpn-instance evpn1 vpws
[~HUAWEI-evpn-instance-evpn1] remote frr enable
3.3.74 remote vpws-frr (global EVPN configuration view)
Function
The remote vpws-frr enable command enables fast reroute (FRR) for MAC routes at the
remote end of an EVPN VPWS.
The undo remote vpws-frr enable command disables FRR for MAC routes at the remote
end of an EVPN VPWS.
By default, FRR for MAC routes at the remote end of an EVPN VPWS is not enabled.
Format
remote vpws-frr enable

undo remote vpws-frr enable
Parameters
None
Views
Default Level

bgp write
Usage Guidelines
In the EVPN VPWS scenario shown in the following figure, a CE is dual-homed to PE1 and
PE2 that work in active-active mode. If an E-Trunk is configured on PE1 and PE2, load
balancing cannot be implemented on PE3. To resolve this issue, run the remote vpws-frr
enable command so that the path between PE3 and PE1 and the path between PE3 and PE2
work in primary/backup mode. Suppose the path between PE1 and PE3 is the primary path. If
PE1's AC interface goes faulty, PE3 quickly switches traffic to PE2 and PE2 forwards traffic
to CE1, therefore preventing traffic loss.
Figure 3-145 EVPN VPWS multi-homing and all-active scenario

PE1
CE1 PE3 CE2

MPLS Network
PE2

AC Interface
EVPL Instance
MPLS LDP Tunnel
In the EVPN VPWS scenario shown in the following figure, a CE is dual-homed to PE1 and
PE2 that work in single-active mode. The primary/backup status of PE1 and PE2 is
determined by DF election. Suppose PE1 is the primary DF in this example. In normal
conditions, downstream traffic on PE3 is sent to PE1. To prevent traffic loss, run the remote
vpws-frr enable command to enable FRR for MAC routes at the remote end. If PE3 detects a

link failure between itself and PE1, this configuration allows PE3 to rapidly switch traffic to
PE2, which then sends traffic to CE1.
PE1
CE1 PE3 CE2

MPLS Network
PE2

AC Interface
EVPL Instance
MPLS LDP Tunnel
Example
# Enable FRR for MAC routes at the remote end of an EVPN VPWS.
[~HUAWEI] evpn
[~HUAWEI-evpn] remote vpws-frr enable
3.3.75 reset bgp evpn
Function
The reset bgp evpn command resets a specified or all BGP EVPN connections.
Format
reset bgp evpn { all | as-number-plain | as-number-dot | ipv4-address | group group-name }
Parameters

all Resets all BGP EVPN -
connections.
as-number-plain Specifies an integral AS The value is an integer ranging from 1 to
number. 4294967295.
as-number-dot Specifies an AS number in The value is in the format of x.y, where x
dotted notation. and y are integers ranging from 1 to 65535
and from 0 to 65535, respectively.
ipv4-address Specifies a BGP EVPN The value is in dotted decimal notation.
peer IP address.


group group- Resets BGP connections of The name is a string of 1 to 47 case-
name the specified peer group. sensitive characters, with spaces not
supported. When double quotation marks
Views
User view
Default Level

bgp debug
Usage Guidelines
Usage Scenario
To reset all BGP EVPN connections, run the reset bgp evpn all command.
This command resets all TCP connections established between BGP EVPN peers and
therefore results in the re-establishment of BGP EVPN peer relationships. Exercise caution
when running this command.
Example
# Reset all BGP EVPN connections.
<HUAWEI> reset bgp evpn all
3.3.76 reset evpn vpn-instance mac-duplication

Function
The reset evpn vpn-instance mac-duplication command clears the suppression state of
MAC routes.
Format
reset evpn vpn-instance vpn-instance-name mac-duplication
reset evpn vpn-instance vpn-instance-name mac-duplication bridge-domain bd-id
reset evpn vpn-instance vpn-instance-name mac-duplication mac-address mac-address

reset evpn vpn-instance vpn-instance-name mac-duplication bridge-domain bd-id mac-

address mac-address
Parameters

name EVPN instance. characters, spaces not supported. When
bridge-domain Specifies a BD in which The value is an integer ranging from 1 to
bd-id the suppression state of 32768.
MAC routes is to be
cleared.
mac-address Specifies a MAC route The value is a 12-digit hexadecimal number,
mac-address whose suppression state is in the format of H-H-H. Each H is 4 digits.
to be cleared. If an H contains fewer than 4 digits, the left-
most digits are padded with zeros. For
example, e0 is displayed as 00e0.
Views
User view
Default Level
3: Management level

bgp debug
Usage Guidelines
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 command. This allows you to manually clear the
suppression state of the MAC routes.
Example
# Clear the suppression state of MAC routes in an EVPN instance.
<HUAWEI> reset evpn vpn-instance evrf1 mac-duplication

3.3.77 retry-cycle
Function
The retry-cycle command sets a hold-off time to unsuppress MAC duplication.
The undo retry-cycle command restores the default configuration.
By default, MAC duplication is unsuppressed after 540 seconds.
Format
retry-cycle retry-times
undo retry-cycle [ retry-times ]
Parameters
retry-times Specifies a hold-off time to The value is an integer ranging from 120 to
unsuppress MAC duplication 3600, in seconds. The value must be a
suppression. multiple of 10.
Views
EVPN-MAC-duplication view, EVPN instance MAC-duplication view
Default Level

bgp write
Usage Guidelines
Usage Scenario
preventing devices from working properly. MAC duplication suppression on the devices
works. 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. Then, the system starts a hold-off timer to unsuppress MAC
duplication. After the timer expires, MAC routes are automatically unsuppressed. To modify
the hold-off time, run the retry-cycle command.

If the retry-cycle command is run in both EVPN instance view and global EVPN
configuration view, the configuration in the EVPN instance view takes precedence.
Example
# Set the hold-off time to unsuppress MAC duplication to 200 seconds.
[~HUAWEI] evpn vpn-instance evpna bd-mode
[~HUAWEI-evpn-instance-evpna] mac-duplication
[~HUAWEI-evpn-instance-evpna-mac-dup] retry-cycle 200
3.3.78 root (EVI I-PMSI view)

Function
The root command specifies the current device as the root node for a multicast EVPN, and
displays the EVI I-PMSI root view.
The undo root command deletes the root node configuration for a multicast EVPN and all
configurations in the EVI I-PMSI root view.
By default, no device is specified as the root node on a multicast EVPN.
Format
root
undo root
Parameters
None
Views
EVI I-PMSI view
Default Level

bgp write
Usage Guidelines
Usage Scenario
On a multicast EVPN, the root node is the ingress of an mLDP P2MP tunnel. An mLDP
P2MP tunnel has multiple leaf nodes, but only one root node. To specify the current device as
the root node for the multicast EVPN and enter the EVI I-PMSI root view for root node
configuration, run the root command.

Precautions
In a dual-homing scenario, if the dual-homing PEs are configured as root nodes using the root
command, the two PEs can no longer be configured as leaf nodes using the leaf command.
Example
# Specify the current device as the root node for a multicast EVPN and display the EVI I-
PMSI root view.
[*HUAWEI-evpn-instance-evpn1-inclusive-root]
3.3.79 root-ip (EVI I-PMSI root mLDP view)
Function
The root-ip command configures an IP address for the root node of an mLDP P2MP tunnel.
The undo root-ip command deletes the IP address configured for the root node of an mLDP
P2MP tunnel.
By default, no IP address is configured for the root node of an mLDP P2MP tunnel.
Format
root-ip ip-address
undo root-ip
Parameters
ip-address Specifies an IP address for the root node of an The value is in dotted
mLDP P2MP tunnel. decimal notation.
Views
EVI I-PMSI root mLDP view
Default Level

bgp write

Usage Guidelines
Usage Scenario
After the root node is specified for an mLDP P2MP tunnel on a multicast EVPN network, run
the root-ip command to configure an IP address for the root node. This IP address can be
used as the destination address of leaf nodes so that the root node and leaf nodes can
communicate.
Precautions
If the root-ip command is run more than once, the latest configuration overrides the previous
one.
Example
# Configure IP address 2.2.2.2 for the root node on an mLDP P2MP tunnel in the BD-EVPN
instance named evpn1.
[*HUAWEI-evpn-instance-evpn1-inclusive-leaf] root-ip 2.2.2.2
3.3.80 root-ip use-next-hop

Function
The root-ip use-next-hop command configures a leaf node to use the next hop of a BGP
EVPN route as the root node IP address.
The undo root-ip use-next-hop command restores the default configuration.
By default, a leaf node does not use the next hop of a BGP EVPN route as the root node IP
address.
Format
root-ip root-ip use-next-hop
undo root-ip root-ip use-next-hop
Parameters
root-ip Specifies the IP address of a root. The value is in dotted decimal notation.
Views
EVI I-PMSI leaf view
Default Level


bgp write
Usage Guidelines
Usage Scenario
In a cross-IGP-area EVPN E-LAN scenario, you must run the root-ip use-next-hop
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.
Example
# Configure a leaf node to use the next hop of a BGP EVPN route as the root node IP address.
[*HUAWEI-evpn-instance-evpn1-inclusive-leaf] root-ip 2.2.2.2 use-next-hop

Function
The route-distinguisher command configures an RD for an EVPN instance.
The undo route-distinguisher command deletes the RD of an EVPN instance.
By default, no RD is configured for an EVPN instance.
Format
route-distinguisher route-distinguisher
undo route-distinguisher route-distinguisher

Parameters
route- Specifies an RD. An RD can be in either of the following formats: -
distinguisher l 2-byte AS number:4-byte user-defined number, such as 1:3. The
AS number ranges from 0 to 65535, and the user-defined
number ranges from 0 to 4294967295. The AS number and
user-defined number cannot be both 0s. Specifically, an RD
cannot be 0:0.
l 4-byte AS number:2-byte user-defined number, such as
65537:3. The AS number ranges from 65536 to 4294967295,
and the user-defined number ranges from 0 to 65535.
l 4-byte AS number in dotted notation:2-byte user-defined
number, such as 0.0:3 or 0.1:0. The AS number is in the format
of x.y, where x and y are integers ranging from 0 to 65535. The
user-defined number also ranges from 0 to 65535. The AS
number and user-defined number cannot be both 0s.
Specifically, an RD cannot be 0.0:0.
l 4-byte IP address:2-byte user-defined number, such as
192.168.122.15:1. The IP address ranges from 0.0.0.0 to
255.255.255.255, and the user-defined number ranges from 0 to
65535.
Views
EVPN instance view, B-EVPN instance view
Default Level

bgp write
Usage Guidelines
Usage Scenario
An RD must be configured for an EVPN instance after the EVPN instance is created. To
configure an RD for an EVPN instance, run the route-distinguisher command.
Different EVPN instances may have the same route prefix. To allow a PE to determine to
which EVPN instance a route belongs, run the route-distinguisher command to configure an
RD for each EVPN instance on the PE. After the configuration, a route sent from an EVPN
instance will carry an RD, making the route a globally unique EVPN route.
Precautions

Running the undo route-distinguisher command in the B-EVPN instance view causes
EVPN-related configurations to be deleted.
Example
# Configure an RD for EVPN instance evpn1.
[*HUAWEI-evpn-instance-evpn1] route-distinguisher 22:1
Related Topics
3.3.82 tnl-policy (EVPN instance view)

Function
The tnl-policy command associates an EVPN instance with a tunnel policy.
The undo tnl-policy command restores the default configuration.
By default, a EVPN instance is not associated with any tunnel policy.
Format
tnl-policy policy-name
undo tnl-policy policy-name
Parameters
policy-name Specifies a tunnel policy name. The value is a string of 1 to 39 characters.
Views
EVPN instance view
Default Level

evpnbgp write
Usage Guidelines
Usage Scenario

To enable EVPN PEs to transmit traffic over TE tunnels, run the tnl-policy command to
associate the EVPN instance with a tunnel policy.
Prerequisites
An RD has been configured using the route-distinguisher command.
Follow-up Procedure
If the associated tunnel policy does not exist, run the tunnel-policy command to create the
tunnel policy.
Precautions
An EVPN instance cannot use GRE tunnels. If a tunnel policy involves the use of GRE
tunnels, this tunnel policy cannot be applied to an EVPN instance.
Example
# Associate a EVPN instance named vrf with a tunnel policy named po1.
[~HUAWEI] tunnel-policy po1
[*HUAWEI-tunnel-policy-po1] tunnel select-seq cr-lsp load-balance-number 2
[*HUAWEI-tunnel-policy-po1] quit
[*HUAWEI] evpn vpn-instance vrf bd-mode
[*HUAWEI-evpn-instance-vrf] route-distinguisher 1:1
[*HUAWEI-evpn-instance-vrf] tnl-policy po1
Related Topics
tunnel-policy
3.3.83 timer df-delay
Function
The timer df-delay command specifies a DF election delay.
The undo timer df-delay command restores the default DF election delay.
By default, a DF election is performed after a delay of 60s.
Format
timer df-delay delay-value
undo timer df-delay [ delay-value ]
Parameters

delay-value Specifies a DF election delay. The value is an integer ranging from 0 to 1200,
in seconds.

Views
Default Level

bgp write
Usage Guidelines
Usage Scenario
If an EVPN instance is bound to multiple VLANs and the network in unstable, the PE
interfaces connecting to a CE will frequently alternate between Up and Down, or ESIs on the
PE interfaces frequently change, resulting in frequent DF elections. As a result, the network
In a dual-homing scenario where interface-based DF election is configured, the following
commands must be run on each of two PEs:
l Run the timer df-delay 0 command to prevent the long existence of dual backup devices
during a switchback and therefore helps prevent a traffic interruption.
l Run the evpn enhancement port command to prevent the access network from
receiving duplicate traffic from the two PEs.
Example
# Set a DF election delay to 10s.
[~HUAWEI] bgp 100
[*HUAWEI-bgp-af-evpn] timer df-delay 10
3.3.84 timer es-recovery (evpn)
Function
The timer es-recovery command sets a delay after which Ethernet segment (ES) routes are
advertised.
The undo timer es-recovery command restores the default setting.
By default, the delay after which ES routes are advertised is 0s.
Format
timer es-recovery seconds

undo timer es-recovery
Parameters
seconds Specifies the delay after which ES The value is an integer ranging from 3
routes are advertised. to 1200, in seconds.
Views
Eth-Trunk interface view, PW-VE interface view, Port extension interface view
Default Level

bgp write
Usage Guidelines
Usage Scenario
In Active-Active scenarios, to prevent ES routes from being sent immediately after an Eth-
Trunk interface recovers, run the timer es-recovery command. This configuration minimizes
packet loss.
Example
# Set a delay on Eth-Trunk1 after which ES routes are advertised.
<HUAWEI>system-view
[~HUAWEI]interface Eth-Trunk1
[~HUAWEI-Eth-Trunk1]timer es-recovery 100
3.3.85 vpn-orf enable (BGP-EVPN address family view)

Function
The vpn-orf enable command enables EVPN ORF.
The undo vpn-orf enable command disables EVPN ORF.
By default, EVPN ORF is disabled.
Format
vpn-orf enable
undo vpn-orf enable

Parameters
None
Views
Default Level

evpnbgp write
Usage Guidelines
Usage Scenario
To allow two devices between which a BGP-VT peer relationship is established to exchange
ORF routes carrying the import VPN target (IRT) of each other's EVPN instance, run the vpn-
orf enable command to enable EVPN ORF. Upon receipt of ORF routes, a device uses the
export VPN target (ERT) carried in the EVPN routes to be advertised to match the IRT in the
received ORF routes so that the peer can receive only the expected routes. This relieves the
pressure on the peer and reduces network load.
Precautions
This command must be used together with the ipv4-family vpn-target and peer enable
(BGP-VT address family view) commands. If only the vpn-orf enable command is run, the
BGP speaker in the BGP-EVPN address family view does not advertise ORF routes to its
peers.
Example
# Enable EVPN ORF.
[~HUAWEI] bgp 100
[*HUAWEI-bgp]peer 1.1.1.1 as-number 100
[*HUAWEI-bgp] ipv4-family vpn-target
[*HUAWEI-bgp-af-vpn-target] commit
[~HUAWEI-bgp-af-vpn-target] quit
[*HUAWEI-bgp-af-evpn] vpn-orf enable

Function
The vpn-target command configures VPN targets for an EVPN instance.
The undo vpn-target command deletes the VPN targets configured for an EVPN instance.

By default, no VPN targets are configured for an EVPN instance.
Format
vpn-target vpn-target &<1-8> [ both | export-extcommunity | import-extcommunity ]
undo vpn-target { all | vpn-target &<1-8> [ both | export-extcommunity | import-

extcommunity ] }
Parameters
vpn-target Specifies the VPN targets to be added to the VPN target list of -
the EVPN instance address family. The value can be in either of
the following formats:
l 2-byte AS number:4-byte user-defined number, such as 1:3.
The AS number ranges from 0 to 65535, and the user-
defined number ranges from 0 to 4294967295. The AS
Specifically, a VPN target cannot be 0:0.
number, such as 0.0:3 or 0.1:0. The AS number is in the
format of x.y, where x and y are integers ranging from 0 to
65535. The user-defined number also ranges from 0 to
65535. The AS number and user-defined number cannot be
both 0s. Specifically, a VPN target cannot be 0.0:0.
255.255.255.255, and the user-defined number ranges from 0
to 65535.
both Adds VPN targets to both the import and export VPN target lists -
of the EVPN instance address family. If you do not specify
both, export-extcommunity, or import-extcommunity, VPN
targets will be added to both the import and export VPN target
lists.
export- Adds VPN targets to the export VPN target list of the EVPN -
extcommunity instance address family.
import- Adds VPN targets to the import VPN target list of the EVPN -
all Deletes all the VPN targets of the current EVPN instance -
address family.
Views

Default Level

evpn write
Usage Guidelines
Usage Scenario
When a PE advertises EVPN routes to other PEs, the PE attaches all the local export VPN
targets to these routes. After a PE receives EVPN routes, the PE matches export VPN targets
carried in these routes against the local import VPN target list and imports these routes to the
local EVPN instance routing table only if at least one export VPN target matches one import
VPN target.
NOTE
One vpn-target command configures a maximum of eight VPN targets. To configure more VPN targets,
Prerequisites
An RD has been configured for the EVPN instance using the route-distinguisher command.
If you do not configure this command, a PE cannot import received EVPN routes to its local
EVPN instance routing table.
After all the VPN targets of an EVPN instance are deleted using the undo vpn-target
command, all EVPN routes learned by the EVPN instance from other EVPN instances will be
deleted.
Example
# Configure both the import and export VPN targets as 5:5 for an EVPN instance.
[*HUAWEI-evpn-instance-evpn1] vpn-target 5:5 both
Related Topics

3.3.87 vpws-df-election type
Function
The vpws-df-election type service-id command enables service ID-based designated
forwarder (DF) election for an EVPN VPWS.
The undo vpws-df-election type service-id command disables service ID-based DF election
for an EVPN VPWS.
By default, service ID-based DF election is not enabled for an EVPN VPWS.
Format
vpws-df-election type service-id
undo vpws-df-election type service-id
Parameters
None
Views
Default Level

bgp write
Usage Guidelines
Usage Scenario
In an EVPN VPWS scenario where a CE is multi-homed to PEs in single-active mode and no

E-Trunk is configured, a CE at the near end is multi-homed to PEs, and traffic from the
remote end are sent to the PEs. To prevent the CE from receiving multiple copies of traffic
from the PEs, one of the PEs must be elected to forward traffic to the CE.
To meet this requirement, run the vpws-df-election type service-id command to enable
service ID-based DF election. This configuration allows PE->CE traffic to be balanced along
the multi-homed links based on service IDs.
Precautions
Configure the same DF election mode on all the multi-homed PEs.

Example
# Configure service ID-based DF election.
[~HUAWEI] evpn
[*HUAWEI-evpn] vpws-df-election type service-id
3.3.88 vlan-extend private enable

Function
The vlan-extend private enable command enables MAC routes to be sent to carry the VLAN
private extended community attribute.
The undo vlan-extend private enable command disables MAC routes to be sent from
carrying the VLAN private extended community attribute.
By default, MAC routes sent by a device do not carry the VLAN private extended community
attribute.
Format
undo vlan-extend private enable
Parameters
None
Views
Default Level

bgp write
Usage Guidelines
Usage Scenario
To enable a locally generated MAC route to carry the VLAN private extended community
attribute, run the vlan-extend private enable command.
In CE dual-homing scenarios, a CE is dual-homed to PE1 and PE2 through Eth-Trunk
interfaces. PE1 learns the MAC address of the CE and sends EVPN MAC advertisement

routes to PE2, and PE2 generates the corresponding MAC address entry. If the remote device
switches to send the PE1–to-CE traffic to PE2 due to a fault, PE2 forwards the traffic to PE1
based on the MAC address entry and then to the CE over PE1. If users want to conserve the
link bandwidth between PE1 and PE2, run the vlan-extend private enable command on PEs
to enable the MAC routes to be sent to carry the VLAN private extended community attribute
and then run the vlan-extend redirect enable command to enable the redirection function.
After the configurations are complete and PE2 learns MAC routes from PE1, PE2 can check
whether the same ESI and VLAN information exists on the local based on the ESI
information and VXLAN private extended community attribute carried in the routes. If the
same ESI and VLAN information exists, the MAC routes are redirected to the local interface
and the corresponding MAC address entry is generated. In this manner, after receiving the
traffic from the remote device to the CE, PE2 sends the traffic to the CE through the local
interface based on the MAC address entry.
Example
# Enable routes to be sent to a peer to carry the VLAN private extended community attribute.
[~HUAWEI] evpn
[~HUAWEI-evpn] vlan-extend private enable
3.3.89 vlan-extend redirect enable
Function
The vlan-extend redirect enable command enables a device to redirect routes carrying the
VLAN private extended community attribute.
The undo vlan-extend redirect enable command disables a device from redirecting routes
carrying the VLAN private extended community attribute.
By default, a device does not redirect routes carrying the VLAN private extended community
attribute.
Format
undo vlan-extend redirect enable
Parameters
None
Views
Default Level


bgp write
Usage Guidelines
Usage Scenario
In a CE dual-homing scenario, a CE is dual-homed to PE1 and PE2 through Eth-Trunk
interfaces. PE1 learns the CE-side MAC address and advertises the MAC route to PE2
through EVPN. The corresponding MAC forwarding entry is generated on PE2. If the traffic
transmitted from a remote device to the CE over PE2 is switched to PE2 due to reasons such
as a fault, PE2 forwards traffic to PE1 based on the MAC forwarding entry. The traffic is then
forwarded to the CE over PE1. To conserve the link bandwidth between PE1 and PE2, run the
vlan-extend redirect enable command. After this command is executed and PE2 learns
MAC routes from PE1, PE2 can check whether the ESI information of the MAC routes exists
on the local device. If such ESI information exists on the local device, PE1 and PE2 are
connected to the same CE. In this case, MAC routes can be redirected to the local interface
and the corresponding MAC forwarding entry is generated. After PE2 receives traffic destined
for the CE from the remote device, PE2 directly sends the traffic to the CE.
The vlan-extend redirect enable command is used together with the local-remote frr enable
command. In a CE dual-homing scenario where both the vlan-extend redirect enable and
local-remote frr enable commands are configured, after the traffic transmitted from a remote
device to the CE over PE1 is switched to PE2 due to reasons such as a fault, traffic is instantly
forwarded based on the MAC forwarding entry. This avoids heavy packet loss after a
switchover due to the generation of new forwarding entries.
Example
# Enable a device to redirect routes carrying the VLAN private extended community attribute.
[~HUAWEI] evpn
[~HUAWEI-evpn] vlan-extend redirect enable

New IP Technologies 4 VXLAN
4 VXLAN
4.1 VXLAN
4.1.1 VXLAN Introduction

Definition
Virtual extensible local area network (VXLAN) is a Network Virtualization over Layer 3
(NVO3) technology that uses MAC-in-UDP encapsulation.
Purpose
As a widely deployed core cloud computing technology, server virtualization greatly reduces
IT and O&M costs and improves service deployment flexibility.

Figure 4-1 Server virtualization
VM VM VM VM VM VM VM VM
VM VM VM VM VM VM VM VM
... ... ... ...

Server1 Server2 Server3 Server4
On the network shown in Figure 4-1, a server is virtualized into multiple virtual machines
(VMs), each of which functions as a host. A great increase in the number of hosts causes the
following problems:
l VM scale is limited by the network specification.
On a legacy large Layer 2 network, data packets are forwarded at Layer 2 based on MAC
entries. However, there is a limit on the MAC table capacity, which subsequently limits
the number of VMs.
l Network isolation capabilities are limited.
Most networks currently use VLANs to implement network isolation. However, the
deployment of VLANs on large-scale virtualized networks has the following limitations:
– The VLAN tag field defined in IEEE 802.1Q has only 12 bits and can support only
a maximum of 4094 VLANs, which cannot meet user identification requirements of
large Layer 2 networks.
– VLANs on legacy Layer 2 networks cannot adapt to dynamic network adjustment.
l VM migration scope is limited by the network architecture.
After a VM is started, it may need to be migrated to a new server due to resource issues
on the original server, for example, when the CPU usage is too high or memory
resources are inadequate. To ensure uninterrupted services during VM migration, the IP
address of the VM must remain unchanged. To carry this out, the service network must
be a Layer 2 network and also provide multipathing redundancy backup and reliability.

VXLAN addresses the preceding problems on large Layer 2 networks.

l Eliminates VM scale limitations imposed by network specifications.
VXLAN encapsulates data packets sent from VMs into UDP packets and encapsulates IP
and MAC addresses used on the physical network into the outer headers. Then the
network is only aware of the encapsulated parameters and not the inner data. This greatly
reduces the MAC address specification requirements of large Layer 2 networks.
l Provides greater network isolation capabilities.
VXLAN uses a 24-bit network segment ID, called VXLAN network identifier (VNI), to
identify users. This VNI is similar to a VLAN ID and supports a maximum of 16M
[(2^24 - 1)/1024^2] VXLAN segments.
l Eliminates VM migration scope limitations imposed by network architecture.
VXLAN uses MAC-in-UDP encapsulation to extend Layer 2 networks. It encapsulates
Ethernet packets into IP packets for these Ethernet packets to be transmitted over routes,
and does not need to be aware of VMs' MAC addresses. There is no limitation on Layer
3 network architecture, and therefore Layer 3 networks are scalable and have strong
automatic fault rectification and load balancing capabilities. This allows for VM
migration irrespective of the network architecture.
Benefits
As server virtualization is being rapidly deployed on data centers based on physical network
infrastructure, VXLAN offers the following benefits:
l A maximum of 16M VXLAN segments are supported using 24-bit VNIs, which allows a
data center to accommodate multiple tenants.
l Non-VXLAN network edge devices do not need to identify the VM's MAC address,
which reduces the number of MAC addresses that have to be learned and enhances
network performance.
l MAC-in-UDP encapsulation extends Layer 2 networks, decoupling between physical
and virtual networks. Tenants are able to plan their own virtual networks, not limited by
the physical network IP addresses or broadcast domains. This greatly simplifies network
management.
4.1.2 VXLAN Basics
4.1.2.1 VXLAN Basic Concepts

Virtual extensible local area network (VXLAN) is an NVO3 network virtualization
technology that encapsulates data packets sent from virtual machines (VMs) into UDP
packets and encapsulates IP and MAC addresses used on the physical network in outer
headers before sending the packets over an IP network. The egress tunnel endpoint then
decapsulates the packets and sends the packets to the destination VM.

Figure 4-2 VXLAN architecture
VBDIF BD
NVE
VNI VTEP UDP 4789
IP2
IP Network VNI VNI
L3 5020 5030
Packet Device3 Gateway
NVE
VAP2 VAP3
VX
LA
VLAN 20 Untag
el
N
nn
Tu
n
Tu
ne
E
NV
l
N
L2
LA
Gateway
VX
u nnel
Device1 AN T Device2
VXL
NVE VSwitch
VSwitch VM1 VM2 ... VMm
VM1 ... VMm Untag
192.168.10.2/24
VLAN 10 VLAN 20
192.168.10.1/24 192.168.20.1/24
Server1 Server2
VXLAN allows a virtual network to provide access services to a large number of tenants. In
addition, tenants are able to plan their own virtual networks, not limited by the physical
network IP addresses or broadcast domains. This greatly simplifies network management.
Table 4-1 describes VXLAN concepts.
Table 4-1 VXLAN concepts

Concept Description
Underlay and VXLAN allows virtual Layer 2 or Layer 3 networks (overlay networks)
overlay to be built over existing physical networks (underlay networks).
networks Overlay networks use encapsulation technologies to transmit tenant
packets between sites over Layer 3 forwarding paths provided by
underlay networks. Tenants are aware of only overlay networks.

Concept Description
Network A network entity that is deployed at the network edge and implements
virtualization network virtualization functions.
edge (NVE) NOTE
vSwitches on devices and servers can function as NVEs.
VXLAN tunnel A VXLAN tunnel endpoint that encapsulates and decapsulates VXLAN
endpoint packets. It is represented by an NVE.
(VTEP) A VTEP connects to a physical network and is assigned a physical
network IP address. This IP address is irrelevant to virtual networks.
In VXLAN packets, the source IP address is the local node's VTEP
address, and the destination IP address is the remote node's VTEP
address. This pair of VTEP addresses corresponds to a VXLAN tunnel.
VXLAN A VXLAN segment identifier similar to a VLAN ID. VMs on different

network VXLAN segments cannot communicate directly at Layer 2.
identifier (VNI) A VNI identifies only one tenant. Even if multiple terminal users
belong to the same VNI, they are considered one tenant. A VNI
consists of 24 bits and supports a maximum of 16M tenants.
A VNI can be a Layer 2 or Layer 3 VNI.
l A Layer 2 VNI is mapped to a BD for intra-segment transmission of
VXLAN packets.
l A Layer 3 VNI is bound to a VPN instance for inter-segment
transmission of VXLAN packets.
Bridge domain A Layer 2 broadcast domain through which VXLAN data packets are
(BD) forwarded.
VNIs identifying VNs must be mapped to BDs so that a BD can
function as a VXLAN network entity to transmit VXLAN traffic.
VBDIF interface A Layer 3 logical interface created for a BD. Configuring IP addresses
for VBDIF interfaces allows communication between VXLANs on
different network segments and between VXLANs and non-VXLANs
and implements Layer 2 network access to a Layer 3 network.
Virtual access A Layer 2 sub-interface used to transmit data packets.

point (VAP) Layer 2 sub-interfaces can have different encapsulation types
configured to transmit various types of data packets.
Gateway A device that ensures communication between VXLANs identified by

different VNIs and between VXLANs and non-VXLANs.
A VXLAN gateway can be a Layer 2 or Layer 3 gateway.
l Layer 2 gateway: allows tenants to access VXLANs and intra-
segment communication on a VXLAN.
l Layer 3 gateway: allows inter-segment VXLAN communication and
access to external networks.

4.1.2.2 Combinations of Underlay and Overlay Networks

A basic network on which a VXLAN tunnel is established is called underlay Network,
whereas the service network carried by the VXLAN tunnel is called overlay network. In
VXLAN scenarios, the following combinations of underlay and overlay networks are
applicable.
Category Definition Example
IPv4 over IPv4 The overlay network and underlay As shown in Figure 4-3, the server
network are both IPv4 networks. IP and VTEP IP addresses are all
IPv4 addresses.
IPv6 over IPv4 The overlay network is an IPv6 As shown in Figure 4-3, the server
network, and the underlay network IP addresses are IPv6 addresses,
is an IPv4 network. and the VTEP IP addresses are
IPv4 addresses.
IPv4 over IPv6 The overlay network is an IPv4 As shown in Figure 4-3, the server
network, and the underlay network IP addresses are IPv4 addresses,
is an IPv6 network. and the VTEP IP addresses are
IPv6 addresses.
IPv6 over IPv6 The overlay network and underlay As shown in Figure 4-3, the server
network are both IPv6 networks. IP and VTEP IP addresses are all
IPv6 addresses.

Figure 4-3 Combinations of underlay and overlay networks
non-VXLAN
networks
VXLAN L3 GW
Device3
VTEP IP
NVE
VX
el
nn
LA
Tu
N
N
Tu
LA L3 Network
nn
VX
VTEP IP
el
VTEP IP
NVE NVE
Device1 VXLAN Tunnel Device2
VSwitch VSwitch VSwitch
VM1 ... VMm VM1 ... VMm VM1 ... VMm
Server IP Server IP Server IP

Server1 Server2 Server3
NOTE
Currently, only the IPv4 over IPv4 network or IPv6 over IPv4 network is supported.
4.1.2.3 VXLAN Packet Format

VXLAN is a network virtualization technique that uses MAC-in-UDP encapsulation by
adding a UDP header and a VXLAN header before an original Ethernet packet.
Figure 4-4 shows the specific VXLAN packet format.

Figure 4-4 VXLAN packet detailed format

MAC MAC 802.1Q Ethernet
DA SA Tag Type
... Protocol ... IP SA IP DA
VXLAN encapsulation Original packet
Outer Outer Outer Inner Inner

VXLAN
Ethernet IP UDP Ethernet IP Payload
header
header header header header header
VXLAN Flags
Reserved VNI Reserved
(00001000)
8 bits 24 bits 24 bits 8 bits
Source DestPort UDP UDP

Port (VXLAN Port) Length Checksum
16 bits 16 bits 16 bits 16 bits
Table 4-2 Fields in the VXLAN packet format

Field Description
VXLAN header l VXLAN Flags (8 bits): The value is 00001000.

l VNI (24 bits): VXLAN Segment ID or VXLAN Network
Identifier used to identify a VXLAN segment.
l Reserved fields (24 bits and 8 bits): must be set to 0.
Outer UDP header l DestPort: destination port number, which is 4789 for UDP.
l Source Port: source port number, which is calculated by
performing the hash operation on the inner packets.
Outer IP header l IP SA: source IP address, which is the IP address of the

local VTEP of a VXLAN tunnel.
l IP DA: destination IP address, which is the IP address of the
remote VTEP of a VXLAN tunnel.

Field Description
Outer Ethernet header l MAC DA: destination MAC address, which is the MAC
address mapped to the next-hop IP address based on the
destination VTEP address in the routing table of the VTEP
on which the VM that sends packets resides.
l MAC SA: source MAC address, which is the MAC address
of the VTEP on which the VM that sends packet resides.
l 802.1Q Tag: VLAN tag carried in packets. This field is
optional.
l Ethernet Type: Ethernet packet type.
4.1.2.4 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 the control plane, and VTEP discovery and MAC addresses
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.
EVPN uses extended BGP and defines new BGP EVPN routes to transmit VTEP addresses
and host information. As such, the application of EVPN on VXLANs moves VTEP discovery
and host information learning from the data plane to the control plane.
BGP EVPN Routes

EVPN NLRI defines the following BGP EVPN route types applicable to the VXLAN control
plane:
Type 2 route—MAC/IP route
Figure 4-5 shows the format of MAC/IP routes.


Table 4-3 The fields of MAC/IP route
Field Description
Route Distinguisher RD value of an EVPN instance

remote devices

device
MAC Address Length Length of the host MAC address

MAC Address Host MAC address carried in the

route
IP Address Length Mask length of the host IP address

IP Address Host IP address carried in the

route
MAC/IP routes function as follows on the VXLAN control plane:
l 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.
l 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.
l 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 Layer 3 VNI. This type of MAC/IP route
is called the integrated routing and bridging (IRB) route.

NOTE
An ARP route carries host MAC and IP addresses and 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.
l 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 as 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 a Layer 3 VNI. MAC/IP routes in this
case are also called IRBv6 routes.
NOTE
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. 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 4-6 shows the
format of inclusive multicast routes.
Prefix
PMSI attribute
Flags (1 byte)
Table 4-4 The fields of an inclusive multicast route
Field Description

Field Description
Ethernet Tag ID VLAN ID

The value is all 0s in this type of
route.
IP Address Length Mask length of the local VTEP's

IP address carried in the route
Originating Router's IP Address Local VTEP's IP address carried

in the route
Flags Flags indicating whether leaf node

information is required for the
tunnel
VXLAN scenarios.
Tunnel Type Tunnel type carried in the route

The value can only be 6,
representing Ingress Replication in
VXLAN scenarios. It is used for
Tunnel Identifier Tunnel identifier carried in the

route
This field is the local VTEP's IP
address in VXLAN scenarios.
This type of route is used on the VXLAN control plane for automatic VTEP discovery and
dynamic VXLAN tunnel establishment. VTEPs that function as BGP EVPN peers transmit
Layer 2 VNIs 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 a Layer 2 VNI. If the remote VTEP's IP address is reachable at Layer 3, a VXLAN
tunnel to the remote VTEP is established. If the remote VNI is the same as the local VNI, an
ingress replication list is created for subsequent BUM packet forwarding.
Type 5 route—IP prefix route
The Figure 4-7 shows the format of IP prefix routes.


Table 4-5 The fields of IP prefix route

Field Description

remote devices

device
IP Prefix Length Length of the IP prefix carried in

the route
IP Prefix IP prefix carried in the route
GW IP Address Default gateway address

VXLAN scenarios.
The IP Prefix Length and IP Prefix fields in an IP prefix route can identify a host IP address
or network segment.
l If the IP Prefix Length and IP Prefix fields in an IP prefix route identify 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.
l If the IP Prefix Length and IP Prefix fields in an IP prefix route identify a network
segment, the route allows external network access.
4.1.2.5 VXLAN Gateway Deployment

To implement Layer 3 interworking, a Layer 3 gateway must be deployed on a VXLAN.
VXLAN gateways can be deployed in centralized or distributed mode.
Centralized VXLAN Gateway Mode

In this mode, Layer 3 gateways are configured on one device. On the network shown in
Figure 4-8, traffic across network segments is forwarded through Layer 3 gateways to
implement centralized traffic management.

Figure 4-8 Centralized VXLAN gateway networking
L3 Spine1 Spine2
Gateway
L2
Gateway
Leaf1 Leaf2

10.1.1.1/24 10.10.1.1/24 10.20.1.1/24
Inter-subnet traffic
Centralized VXLAN gateway deployment has its advantages and disadvantages.

l Advantage: Inter-segment traffic can be centrally managed, and gateway deployment and
management is easy.
l Disadvantages:
– Forwarding paths are not optimal. Inter-segment Layer 3 traffic of data centers
connected to the same Layer 2 gateway must be transmitted to the centralized Layer
3 gateway for forwarding.
– The ARP entry specification is a bottleneck. ARP entries must be generated for
tenants on the Layer 3 gateway. However, only a limited number of ARP entries are
allowed by the Layer 3 gateway, impeding data center network expansion.
Distributed VXLAN Gateway Mode

Deploying distributed VXLAN gateways addresses problems that occur in centralized
VXLAN gateway networking. Distributed VXLAN gateways use the spine-leaf network. In
this networking, leaf nodes, which can function as Layer 3 VXLAN gateways, are used as
VTEPs to establish VXLAN tunnels. Spine nodes are unaware of the VXLAN tunnels and
only forward VXLAN packets between different leaf nodes. On the network shown in Figure
4-9, Server 1 and Server 2 on different network segments both connect to Leaf 1. When
Server 1 and Server 2 communicate, traffic is forwarded only through Leaf 1, not through any
spine node.

Figure 4-9 Distributed VXLAN gateway networking
Spine1 Spine2
L3 GW
Leaf1 Leaf2
L2 GW
Server1 Server2 Server3 Server4

10.1.1.1/24 10.10.1.1/24 10.20.1.1/24 10.10.1.2/24
Inter-subnet traffic
A spine node supports high-speed IP forwarding capabilities.
A leaf node can:

l Function as a Layer 2 VXLAN gateway to connect to physical servers or VMs and allow
tenants to access VXLANs.
l Function as a Layer 3 VXLAN gateway to perform VXLAN encapsulation and
decapsulation to allow inter-segment VXLAN communication and access to external
networks.
Distributed VXLAN gateway networking has the following characteristics:

l Flexible deployment. A leaf node can function as both Layer 2 and Layer 3 VXLAN
gateways.
l Improved network expansion capabilities. A leaf node only needs to learn the ARP or
ND entries of servers attached to it. A centralized Layer 3 gateway in the same scenario,
however, has to learn the ARP or ND entries of all servers on the network. Therefore, the
ARP or ND entry specification is no longer a bottleneck on a distributed VXLAN
gateway.
4.1.3 Functional Scenarios
4.1.3.1 Centralized VXLAN Gateway Deployment in Static Mode

In centralized VXLAN gateway deployment in static mode, the control plane is responsible
for VXLAN tunnel establishment and dynamic MAC address learning; the forwarding plane
is responsible for intra-subnet known unicast packet forwarding, intra-subnet BUM packet
forwarding, and inter-subnet packet forwarding.

Deploying centralized VXLAN gateways in static mode involves heavy workload and is
inflexible, and therefore is inapplicable to large-scale networks. As such, deploying
centralized VXLAN gateways using BGP EVPN is recommended.
The following VXLAN tunnel establishment uses an IPv4 over IPv4 network as an example.
Table 4-6 shows the implementation differences between the other combinations of underlay
and overlay networks and IPv4 over IPv4.
Table 4-6 Implementation differences
Combi Implementation Difference

nation
Categor
y
IPv6 l During dynamic MAC address learning, a Layer 2 gateway learns the local
over host's MAC address using neighbor solicitation (NS) packets sent by the
IPv4 host.
l In the inter-subnet interworking scenario, an IPv6 address must be
configured for the Layer 3 gateway's VBDIF interface. During inter-subnet
packet forwarding, the Layer 3 gateway needs to search its IPv6 routing
table for the next-hop address of the destination IPv6 address, queries the
ND table based on the next-hop address, and then obtains information such
as the destination MAC address.
IPv4 Not supported

over
IPv6
IPv6 Not supported

over
IPv6
VXLAN Tunnel Establishment

A VXLAN tunnel is identified by a pair of VTEP IP addresses. A VXLAN tunnel can be
statically created after you configure local and remote VNIs, VTEP IP addresses, and an
ingress replication list, and the tunnel goes Up when the pair of VTEPs is reachable at Layer
3.
On the network shown in Figure 4-10, Leaf 1 connects to Host 1 and Host 3; Leaf 2 connects
to Host 2; Spine functions as a Layer 3 gateway.
l To allow Host 3 and Host 2 to communicate, Layer 2 VNIs and an ingress replication list
must be configured on Leaf 1 and Leaf 2. The peer VTEPs' IP addresses must be
specified in the ingress replication list. A VXLAN tunnel can be established between
Leaf 1 and Leaf 2 if their VTEPs have Layer 3 routes to each other.
l To allow Host 1 and Host 2 to communicate, Layer 2 VNIs and an ingress replication list
must be configured on Leaf 1, Leaf 2, and also Spine. The peer VTEPs' IP addresses
must be specified in the ingress replication list. A VXLAN tunnel can be established
between Leaf 1 and Spine and between Leaf 2 and Spine if they have Layer 3 routes to
the IP addresses of the VTEPs of each other.

NOTE
Although Host 1 and Host 3 both connect to Leaf 1, they belong to different subnets and must
communicate through the Layer 3 gateway (Spine). Therefore, a VXLAN tunnel is also required
between Leaf 1 and Spine.
Figure 4-10 VXLAN tunnel networking
VNI: 10
VNI: 20
VTEP: 3.3.3.3/32
Spine
Leaf1 Leaf2
VNI: 10
VNI: 20
VNI: 20
VXLAN Tunnel VTEP
VTEP
2.2.2.2/32
1.1.1.1/32
Host1 Host3 Host2

192.168.10.1/24 192.168.20.2/24 192.168.20.1/24
NVE
Dynamic MAC Address Learning

VXLAN supports dynamic MAC address learning to allow communication between tenants.
MAC address entries are dynamically created and do not need to be manually maintained,
greatly reducing maintenance workload. The following example illustrates dynamic MAC
address learning for intra-subnet communication on the network shown in Figure 4-11.

Figure 4-11 Dynamic MAC Address Learning
Spine
MAC BDID Outbound MAC BDID Outbound
MAC3 20 Port1 MAC3 20 VXLAN
2 VXLAN Tunnel 4
Leaf2
Leaf1 Port1
VNI:20
3
VNI:20 VTEP:2.2.2.2/32
VTEP:1.1.1.1/32 1
5
Host3 Host2
MAC3 MAC2
IP3:192.168.20.2/24 IP2:192.168.20.1/24
1. Host 3 sends an ARP request for Host 2's MAC address. The ARP request carries the
source MAC address being MAC3, destination MAC address being all Fs, source IP
address being IP3, and destination IP address being IP2.
2. Upon receipt of the ARP request, Leaf 1 determines that the Layer 2 sub-interface
receiving the ARP request belongs to a BD that has been bound to a VNI (20), meaning
that the ARP request packet must be transmitted over the VXLAN tunnel identified by
VNI 20. Leaf 1 then learns the mapping between Host 3's MAC address, BDID (Layer 2
broadcast domain ID), and inbound interface (Port1 for the Layer 2 sub-interface) that
has received the ARP request and generates a MAC address entry for Host 3. The MAC
address entry's outbound interface is Port1.
3. Leaf 1 then performs VXLAN encapsulation on the ARP request, with the VNI being the
one bound to the BD, source IP address in the outer IP header being the VTEP's IP
address of Leaf 1, destination IP address in the outer IP header being the VTEP's IP
address of Leaf 2, source MAC address in the outer Ethernet header being NVE1's MAC
address of Leaf 1, and destination MAC address in the outer Ethernet header being the
MAC address of the next hop pointing to the destination IP address. Figure 4-12 shows
the VXLAN packet format. The VXLAN packet is then transmitted over the IP network
based on the IP and MAC addresses in the outer headers and finally reaches Leaf 2.

Figure 4-12 VXLAN packet format

Outer destination MAC: Next hop MAC
Outer source MAC: NVE1 MAC
Outer source IP: 1.1.1.1/32
Outer destination: 2.2.2.2/32
UDP
VNI: 20
ARP request
Ethernet destination MAC: All Fs
Ethernet source MAC: MAC3
Source MAC: MAC3
Source IP: IP3
Destination MAC: All 0s
Destination IP: IP2
4. After Leaf 2 receives the VXLAN packet, it decapsulates the packet and obtains the ARP
request originated from Host 3. Leaf 2 then learns the mapping between Host 3's MAC
address, BDID, and VTEP's IP address of Leaf 1 and generates a MAC address entry for
Host 3. Based on the next hop (VTEP's IP address of Leaf 1), the MAC address entry's
outbound interface recurses to the VXLAN tunnel destined for Leaf1.
5. Leaf 2 broadcasts the ARP request in the Layer 2 domain. Upon receipt of the ARP
request, Host 2 finds that the destination IP address is its own IP address and saves Host
3's MAC address to the local MAC address table. Host 2 then responds with an ARP
reply.
So far, Host 2 has learned Host 3's MAC address. Therefore, Host 2 responds with a unicast
ARP reply. The ARP reply is transmitted to Host 3 in the same manner. After Host 2 and Host
3 learn the MAC address of each other, they will subsequently communicate with each other
in unicast mode.
NOTE
Dynamic MAC address learning is required only between hosts and Layer 3 gateways in inter-subnet
communication scenarios. The process is the same as that for intra-subnet communication.
Intra-Subnet Known Unicast Packet Forwarding

Intra-subnet known unicast packets are forwarded only through Layer 2 VXLAN gateways
and are unknown to Layer 3 VXLAN gateways. Figure 4-13 shows the intra-subnet known
unicast packet forwarding process.

Figure 4-13 Intra-subnet known unicast packet forwarding
Spine
VXLAN Tunnel
Leaf1 Leaf2
VNI:20 VNI:20
VTEP:1.1.1.1/32 VTEP:2.2.2.2/32
Host3 Host2
MAC3 MAC2
IP3:192.168.20.2/24 IP2:192.168.20.1/24
VLAN3 VLAN2
Layer 2 packet
Layer 2 packet VXLAN packet encapsulated by Leaf 2
sent from Host3 encapsulated by Leaf 1 after VXLAN decapsulation
DMAC MAC2 DMAC Net MAC DMAC MAC2
SMAC MAC3 SMAC NVE1 MAC SMAC MAC3
VLAN SIP 1.1.1.1 VLAN
3 2
Tag DIP 2.2.2.2 Tag
UDP S_P HASH
UDP D_P 4789
VNI 20
DMAC MAC2
SMAC MAC3
1. After Leaf 1 receives Host 3's packet, it determines the Layer 2 BD of the packet based
on the access interface and VLAN information and searches for the outbound interface
and encapsulation information in the BD.
2. Leaf 1's VTEP performs VXLAN encapsulation based on the encapsulation information
obtained and forwards the packets through the outbound interface obtained.
3. Upon receipt of the VXLAN packet, Leaf 2's VTEP verifies the VXLAN packet based
on the UDP destination port number, source and destination IP addresses, and VNI. Leaf
2 obtains the Layer 2 BD based on the VNI and performs VXLAN decapsulation to
obtain the inner Layer 2 packet.
4. Leaf 2 obtains the destination MAC address of the inner Layer 2 packet, adds VLAN
tags to the packets based on the outbound interface and encapsulation information in the
local MAC address table, and forwards the packets to Host 2.
Host 2 sends packets to Host 3 in the same manner.

Intra-Subnet BUM Packet Forwarding

Intra-subnet BUM packet forwarding is completed between Layer 2 VXLAN gateways in
ingress replication mode. Layer 3 VXLAN gateways do not need to be aware of the process.
In ingress replication mode, when a BUM packet enters a VXLAN tunnel, the ingress VTEP
uses ingress replication to perform VXLAN encapsulation and send a copy of the BUM
packet to every egress VTEP in the list. When the BUM packet leaves the VXLAN tunnel, the
egress VTEP decapsulates the BUM packet. Figure 4-14 shows the BUM packet forwarding
process.

Figure 4-14 Ingress replication for forwarding BUM packets

Terminal C:
IP3
MAC3
VLAN4
VXLAN Leaf 3
L2 gateway VNI: 20
NV VTEP: 3.3.3.3
VXLAN E3
L2 gateway
NVE1
Network
Terminal A: Leaf 1
E2
IP1 VNI: 20
NV
MAC1 VTEP: 1.1.1.1 VXLAN
VLAN2 Leaf 2 L2 gateway
VNI: 20
VTEP: 2.2.2.2
Terminal B:
IP 2
MAC 2
VLAN 3
Layer 2 packet
Layer 2 packet VXLAN packet encapsulated by Leaf 1 encapsulated by Leaf 2/
sent from Leaf 3 after VXLAN
Terminal A Leaf1—>Leaf2 Leaf1—>Leaf3 decapsulation
DMAC Net MAC DMAC Net MAC DMAC All Fs
DMAC All Fs
SMAC NVE1 MAC1 SMAC NVE1 MAC1 SMAC MAC1
SMAC MAC1 SIP 1.1.1.1 SIP 1.1.1.1 VLAN
VLAN 3
2 DIP 2.2.2.2 DIP 3.3.3.3 Tag
Tag
UDP S_P HASH UDP S_P HASH DMAC All Fs
UDP D_P 4789 UDP D_P 4789 SMAC MAC1
VNI 20 VNI 20 VLAN
4
DMAC All Fs DMAC All Fs Tag
SMAC MAC1 SMAC MAC1
1. After Leaf 1 receives Terminal A's packet, it determines the Layer 2 BD of the packet
based on the access interface and VLAN information.
2. Leaf 1's VTEP obtains the ingress replication list for the VNI, replicates packets based
on the list, and performs VXLAN encapsulation by adding outer headers. Leaf 1 then
forwards the VXLAN packet through the outbound interface.
3. Upon receipt of the VXLAN packet, Leaf 2's VTEP and Leaf 3's VTEP verify the
VXLAN packet based on the UDP destination port number, source and destination IP

addresses, and VNI. Leaf 2/Leaf 3 obtains the Layer 2 BD based on the VNI and
performs VXLAN decapsulation to obtain the inner Layer 2 packet.
4. Leaf 2/Leaf 3 checks the destination MAC address of the inner Layer 2 packet and finds
it a BUM MAC address. Therefore, Leaf 2/Leaf 3 broadcasts the packet onto the network
connected to the terminals (not the VXLAN tunnel side) in the Layer 2 broadcast
domain. Specifically, Leaf 2/Leaf 3 finds the outbound interfaces and encapsulation
information not related to the VXLAN tunnel, adds VLAN tags to the packet, and
forwards the packet to Terminal B/Terminal C.
NOTE
Terminal B/Terminal C responds to Terminal A in the same process as intra-subnet known unicast
packet forwarding.
Inter-Subnet Packet Forwarding

Inter-subnet packets must be forwarded through a Layer 3 gateway. Figure 4-15 shows inter-
subnet packet forwarding in centralized VXLAN gateway scenarios.

Figure 4-15 Inter-subnet packet forwarding
F
I
D Routing Table
B
V Destination NextHop Interface
192.168.10.1/32 192.168.10.10/24 VBDIF10
Spine
BD
VNI:10 192.168.20.1/32 192.168.20.10/24 VBDIF20
VNI:20
VTEP:3.3.3.3
VNI L3 Gateway:
VBDIF10:192.168.10.10/24 MAC3
NVE3 VBDIF20:192.168.20.10/24 MAC4
Packet
Leaf1 Leaf2
VNI:10 VNI:20
L2 Gateway L2 Gateway VTEP:2.2.2.2
VTEP:1.1.1.1
Host1 Host2
IP1：192.168.10.1/24 IP2：192.168.20.1/24
MAC1 MAC2
VLAN10 VLAN20
Packet flow
Packet obtained by Leaf
Inter-subnet IP packet VXLAN packet VXLAN packet 2 after VXLAN
sent from Host 1 encapsulated by Leaf 1 encapsulated by Spine decapsulation
DMAC MAC3 DMAC NET MAC DMAC NET MAC DMAC MAC2
SMAC MAC1 SMAC NVE1 MAC SMAC NVE3 MAC SMAC MAC4
SIP IP1 SIP 1.1.1.1 SIP 3.3.3.3 SIP IP1
DIP IP2 DIP 3.3.3.3 DIP 2.2.2.2 DIP IP2
Pay-load UDP S_P HASH UDP S_P HASH Pay-load
UDP D_P 4789 UDP D_P 4789
VNI 10 VNI 20
DMAC MAC3 DMAC MAC2
SMAC MAC1 SMAC MAC4
SIP IP1 SIP IP1
DIP IP2 DIP IP2
Pay-load Pay-load
2. Leaf 1's VTEP performs VXLAN encapsulation based on the outbound interface and
encapsulation information and forwards the packets to Spine.

3. After Spine receives the VXLAN packet, it decapsulates the packet and finds that the
destination MAC address of the inner packet is the MAC address (MAC3) of the Layer 3
gateway interface (VBDIF10) so that the packet must be forwarded at Layer 3.
4. Spine removes the inner Ethernet header, parses the destination IP address, and searches
the routing table for a next hop address. Spine then searches the ARP table based on the
next hop address to obtain the destination MAC address, VXLAN tunnel's outbound
interface, and VNI.
5. Spine performs VXLAN encapsulation on the inner packet again and forwards the
VXLAN packet to Leaf 2, with the source MAC address in the inner Ethernet header
being the MAC address (MAC4) of the Layer 3 gateway interface (VBDIF20).
2 then obtains the Layer 2 broadcast domain based on the VNI and removes the outer
headers to obtain the inner Layer 2 packet. It then searches for the outbound interface
and encapsulation information in the Layer 2 broadcast domain.
7. Leaf 2 adds VLAN tags to the packets based on the outbound interface and encapsulation
information and forwards the packets to Host 2.
4.1.3.2 Centralized VXLAN Gateway Deployment Using BGP EVPN

In centralized VXLAN gateway deployment using BGP EVPN, the control plane is
responsible for the following process:
l VXLAN tunnel establishment
l Dynamic MAC address learning
The forwarding plane is responsible for the following process:
l Intra-subnet known unicast packet forwarding
l Intra-subnet BUM packet forwarding
l Inter-subnet packet forwarding
This deployment mode is flexible because EVPN allows dynamic VTEP discovery and
VXLAN tunnel establishment, and is therefore applicable to large-scale networks. If
centralized VXLAN gateway deployment is needed, using this mode is recommended.


nation
Categor
y
IPv6 l During dynamic MAC address learning, a Layer 2 gateway learns the local
over host's MAC address by the neighbor discovery function. Hosts at both ends
IPv4 learn each other's MAC addresses by exchanging neighbor solicitation (NS)
or neighbor advertisement (NA) packets.
l In the inter-subnet interworking scenario, an IPv6 address must be
configured for the Layer 3 gateway's VBDIF interface. During inter-subnet
packet forwarding, the Layer 3 gateway needs to search its IPv6 routing
table for the next-hop address of the destination IPv6 address, queries the
ND table based on the next-hop address, and then obtains information such
as the destination MAC address.
IPv4 Not supported

over
IPv6
IPv6 Not supported

over
IPv6

A VXLAN tunnel is identified by a pair of VTEP IP addresses. During VXLAN tunnel
establishment, the local and remote VTEPs attempt to obtain the IP addresses of each other. A
VXLAN tunnel can be established if the IP addresses obtained are reachable at Layer 3. When
BGP EVPN is used to dynamically establish a VXLAN tunnel, the local and remote VTEPs
first establish a BGP EVPN peer relationship and then exchange BGP EVPN routes to
transmit VNIs and VTEPs' IP addresses.
On the network shown in Figure 4-16, Leaf 1 connects to Host 1 and Host 3; Leaf 2 connects
to Host 2; Spine functions as a Layer 3 gateway. To allow Host 3 and Host 2 to communicate,
establish a VXLAN tunnel between Leaf 1 and Leaf 2. To allow Host 1 and Host 2 to
communicate, establish a VXLAN tunnel between Leaf 1 and Spine and between Spine and
Leaf 2. Although Host 1 and Host 3 both connect to Leaf 1, they belong to different subnets
and must communicate through the Layer 3 gateway (Spine). Therefore, a VXLAN tunnel is
also required between Leaf 1 and Spine.
NOTE
A VXLAN tunnel is identified by a pair of VTEP IP addresses. If the local VTEP repeatedly receives the
remote VTEP IP address, only one VXLAN tunnel is established, although the respective VNI is
encapsulated in packets.

VNI: 10
VNI: 20
VTEP: 3.3.3.3/32
Spine
Leaf1 Leaf2
VNI: 10
VNI: 20
VNI: 20
VXLAN Tunnel VTEP
VTEP
2.2.2.2/32
1.1.1.1/32
Host1 Host3 Host2

192.168.10.1/24 192.168.20.2/24 192.168.20.1/24
NVE
The following example illustrates how to use BGP EVPN to dynamically establish a VXLAN
tunnel between Leaf 1 and Leaf 2.

Figure 4-17 Dynamic VXLAN tunnel establishment

Spine
VNI: 10
VNI: 20
VTEP: 3.3.3.3
EVPN2 EVPN1
RD : 3:1 RD : 4:1
ERT: 10:1 ERT: 20:1
IRT : 10:1 IRT : 20:1
EVPN2
RD : 2:1
ERT: 10:1
Type3 route Leaf2
Leaf1 IRT : 10:1
VNI: 20
VNI: 10 2 ERT(20:1) 1
VTEP: 2.2.2.2
VNI: 20
VTEP: 1.1.1.1
1 Type3 route 2 EVPN1
EVPN1
ERT(20:1) RD : 5:1
RD : 1:1
ERT: 20:1
ERT: 20:1
IRT : 20:1
IRT : 20:1
NVE
1. Leaf 1 and Leaf 2 establish a BGP EVPN peer relationship. Then, Layer 2 broadcast
domains are created on Leaf 1 and Leaf 2 and bound to VNIs. A local EVPN instance is
created in the Layer 2 broadcast domain, and an RD, export VPN targets (ERT), and
import VPN targets (IRT) are configured for the EVPN instance. After the local VTEP's
IP address is configured on Leaf 1 and Leaf 2, they generate a BGP EVPN route and
send it to each other. The BGP EVPN route carries the local EVPN instance's export
VPN target and an inclusive multicast route (Type 3 route defined in BGP EVPN).
Figure 4-18 shows the format of an inclusive multicast route, which comprises a prefix
and a PMSI attribute. VTEP IP addresses are stored in the Originating Router's IP
Address field in the inclusive multicast route prefix, and VNIs are stored in the MPLS
Label field in the PMSI attribute.


Prefix
PMSI attribute
Flags (1 byte)
2. After Leaf 1 and Leaf 2 receive a BGP EVPN route from each other, they match the
export VPN targets of the route against the import VPN targets of the local EVPN
instance. If a match is found, the route is accepted. If no match is found, the route is
discarded. If the route is accepted, Leaf 1/Leaf 2 obtains the remote VTEP's IP address
and VNI carried in the route. If the remote VTEP's IP address is reachable at Layer 3, a
VXLAN tunnel to the remote VTEP is established. If the remote VNI is the same as the
local VNI, an ingress replication list is created for subsequent BUM packet forwarding.
The processes for dynamic VXLAN tunnel establishment using BGP EVPN between Leaf 1
and Spine and between Leaf 2 and Spine are the same.
NOTE
A VPN target is an extended community attribute of BGP for advertising VPN routes. An EVPN
instance can have import and export VPN targets configured. The local EVPN instance's export VPN
target must match the remote EVPN instance's import VPN target for EVPN route advertisement. If not,
VXLAN tunnels cannot be dynamically established. If only one end can successfully accept the BGP
EVPN route, this end can establish a VXLAN tunnel to the other end, but cannot exchange data packets
with the other end. The other end drops packets after confirming that there is no VXLAN tunnel to the
end that has sent these packets.
For details on VPN targets, see Basic BGP/MPLS IP VPN.

greatly reducing maintenance workload. The following example illustrates dynamic MAC
address learning for intra-subnet communication on the network shown in Figure 4-19.

Figure 4-19 Dynamic MAC address learning
Spine

VXLAN Tunnel
Leaf1 Port1 Leaf2
2
VNI:20 1 Type2 route VNI:20
VTEP:1.1.1.1/32 VTEP:2.2.2.2/32
NextHop
ERT
Host3 Host2
MAC3 MAC2
IP3:192.168.20.2/24 IP2:192.168.20.1/24
1. When Host 3 communicates with Leaf 1 for the first time, Leaf 1 learns the mapping
between Host 3's MAC address, BDID (Layer 2 broadcast domain ID), and inbound
interface (Port1 for the Layer 2 sub-interface) that has received the dynamic ARP packet
and generates a MAC address entry for Host 3. The MAC address entry's outbound
interface is Port1. Leaf 1 generates and sends a BGP EVPN route based on the ARP
entry of Host 3 to Leaf 2. The BGP EVPN route carries the local EVPN instance's export
VPN targets, Next_Hop attribute, and a Type 2 route (MAC/IP route) defined in BGP
EVPN. The Next_Hop attribute carries the local VTEP's IP address. The MAC Address
Length and MAC Address fields identify Host 3's MAC address. The Layer 2 VNI is
stored in the MPLS Label1 field. Figure 4-20 shows the format of a MAC/IP route.

IP Address (0, 4 or 16 bytes）
2. After Leaf 2 receives a BGP EVPN route from Leaf 1, Leaf 2 matches the export VPN
targets of the route against the import VPN targets of the local EVPN instance. If a
match is found, the route is accepted. If no match is found, the route is discarded. If the
route is accepted, Leaf 2 obtains the mapping between Host 3's MAC address, BDID,

Leaf 1's VTEP IP address (Next_Hop attribute) and generates a MAC address entry for
Host 3. Based on the next hop, the MAC address entry's outbound interface recurses to
the VXLAN tunnel destined for Leaf1.
Leaf 1 learns the MAC address of Host 2 in the same process.
NOTE
l Dynamic MAC address learning is required only between hosts and Layer 3 gateways in inter-subnet
communication scenarios. The process is the same as that for intra-subnet communication.
l Leaf nodes can learn the MAC addresses of hosts during data forwarding, if this capability is
enabled. If VXLAN tunnels are established using BGP EVPN, leaf nodes can dynamically learn the
MAC addresses of hosts through BGP EVPN routes, rather than data forwarding.


Spine
VXLAN Tunnel
Leaf1 Leaf2
VNI:20 VNI:20
VTEP:1.1.1.1/32 VTEP:2.2.2.2/32
Host3 Host2
MAC3 MAC2
IP3:192.168.20.2/24 IP2:192.168.20.1/24
VLAN3 VLAN2
Layer 2 packet
3 2
Tag DIP 2.2.2.2 Tag
UDP S_P HASH
UDP D_P 4789
VNI 20
DMAC MAC2
SMAC MAC3


process.


Terminal C:
IP3
MAC3
VLAN4
VXLAN Leaf 3
L2 gateway VNI: 20
NV VTEP: 3.3.3.3
VXLAN E3
L2 gateway
NVE1
Network
Terminal A: Leaf 1
E2
IP1 VNI: 20
NV
VNI: 20
VTEP: 2.2.2.2
Terminal B:
IP 2
MAC 2
VLAN 3
Layer 2 packet
DMAC All Fs
VLAN 3
2 DIP 2.2.2.2 DIP 3.3.3.3 Tag
Tag
VNI 20 VNI 20 VLAN
4
SMAC MAC1 SMAC MAC1

NOTE
packet forwarding.

Inter-subnet packets must be forwarded through a Layer 3 gateway. Figure 4-23 shows the
inter-subnet packet forwarding process.

F
I
D Routing Table
B
V Destination NextHop Interface
192.168.10.1/32 192.168.10.10/24 VBDIF10
Spine
BD
VNI:10 192.168.20.1/32 192.168.20.10/24 VBDIF20
VNI:20
VTEP:3.3.3.3
VNI L3 Gateway:
VBDIF10:192.168.10.10/24 MAC3
NVE3 VBDIF20:192.168.20.10/24 MAC4
Packet
Leaf1 Leaf2
VNI:10 VNI:20
L2 Gateway L2 Gateway VTEP:2.2.2.2
VTEP:1.1.1.1
Host1 Host2
IP1：192.168.10.1/24 IP2：192.168.20.1/24
MAC1 MAC2
VLAN10 VLAN20
Packet flow
Packet obtained by Leaf
Inter-subnet IP packet VXLAN packet VXLAN packet 2 after VXLAN
sent from Host 1 encapsulated by Leaf 1 encapsulated by Spine decapsulation
DMAC MAC3 DMAC NET MAC DMAC NET MAC DMAC MAC2
SMAC MAC1 SMAC NVE1 MAC SMAC NVE3 MAC SMAC MAC4
SIP IP1 SIP 1.1.1.1 SIP 3.3.3.3 SIP IP1
DIP IP2 DIP 3.3.3.3 DIP 2.2.2.2 DIP IP2
Pay-load UDP S_P HASH UDP S_P HASH Pay-load
UDP D_P 4789 UDP D_P 4789
VNI 10 VNI 20
DMAC MAC3 DMAC MAC2
SMAC MAC1 SMAC MAC4
SIP IP1 SIP IP1
DIP IP2 DIP IP2
Pay-load Pay-load
2. Leaf 1's VTEP performs VXLAN encapsulation based on the outbound interface and
encapsulation information and forwards the packets to Spine.

3. After Spine receives the VXLAN packet, it decapsulates the packet and finds that the
destination MAC address of the inner packet is the MAC address (MAC3) of the Layer 3
gateway interface (VBDIF10) so that the packet must be forwarded at Layer 3.
4. Spine removes the inner Ethernet header, parses the destination IP address, and searches
the routing table for a next hop address. Spine then searches the ARP table based on the
next hop address to obtain the destination MAC address, VXLAN tunnel's outbound
interface, and VNI.
5. Spine performs VXLAN encapsulation on the inner packet again and forwards the
VXLAN packet to Leaf 2, with the source MAC address in the inner Ethernet header
being the MAC address (MAC4) of the Layer 3 gateway interface (VBDIF20).
2 then obtains the Layer 2 broadcast domain based on the VNI and removes the outer
headers to obtain the inner Layer 2 packet. It then searches for the outbound interface
and encapsulation information in the Layer 2 broadcast domain.
7. Leaf 2 adds VLAN tags to the packets based on the outbound interface and encapsulation
information and forwards the packets to Host 2.
4.1.3.3 Distributed VXLAN Gateway Deployment Using BGP EVPN

In distributed VXLAN gateway deployment using BGP EVPN, the control plane is
responsible for the following process:
l VXLAN tunnel establishment
l Dynamic MAC address learning
The forwarding plane is responsible for the following process:
l Intra-subnet known unicast packet forwarding
l Intra-subnet BUM packet forwarding
l Inter-subnet packet forwarding
This mode supports IP route advertisement, MAC address advertisement, and ARP
advertisement. For details on the functions, see 4.1.2.4 EVPN VXLAN Fundamentals. If
distributed VXLAN gateways are needed, deploying distributed VXLAN gateways using
BGP EVPN is recommended.


nation
Categor
y
IPv6 l When a VXLAN tunnel is established using BGP EVPN in inter-subnet

over interworking scenarios, if VXLAN gateways are configured to advertise IP
IPv4 prefix routes, only network segment routes can be advertised currently, and
host routes cannot be advertised.
l During dynamic MAC address learning, a Layer 2 gateway learns the local
host's MAC address by the neighbor discovery function. Hosts at both ends
learn each other's MAC addresses by exchanging neighbor solicitation (NS)
or neighbor advertisement (NA) packets.
l During inter-subnet packet forwarding, a gateway must search the IPv6
routing table in the local L3VPN instance.
IPv4 Not supported

over
IPv6
IPv6 Not supported

over
IPv6

A VXLAN tunnel is identified by a pair of VTEP IP addresses. During VXLAN tunnel
establishment, the local and remote VTEPs attempt to obtain the IP addresses of each other. A
VXLAN tunnel can be established if the IP addresses obtained are reachable at Layer 3. When
BGP EVPN is used to dynamically establish a VXLAN tunnel, the local and remote VTEPs
first establish a BGP EVPN peer relationship and then exchange BGP EVPN routes to
transmit VNIs and VTEPs' IP addresses.
In distributed VXLAN gateway scenarios, leaf nodes function as both Layer 2 and Layer 3
VXLAN gateways. Spine nodes are unaware of the VXLAN tunnels and only forward
VXLAN packets between different leaf nodes. On the network shown in Figure 4-24, a
VXLAN tunnel is established between Leaf 1 and Leaf 2 for Host 1 and Host 2 or Host 3 and
Host 2 to communicate. Host 1 and Host 3 both connect to Leaf 1, and therefore the
communication traffic between Host 1 and Host 3 is processed only by Leaf 1, without being
forwarded by the VXLAN tunnel.
NOTE
A VXLAN tunnel is identified by a pair of VTEP IP addresses. If the local VTEP repeatedly receives the
remote VTEP IP address, only one VXLAN tunnel is established, although the respective VNI is
encapsulated in packets.

Spine
VNI: 10
VNI: 20 VNI: 20
VTEP VTEP
1.1.1.1/32 2.2.2.2/32
Leaf1 Leaf2
L3 Gatevay
VXLAN Tunnel
L2 Gatevay
Host1 Host3 Host2

192.168.10.1/24 192.168.20.2/24 192.168.20.1/24
NVE
In distributed VXLAN gateway scenarios, VXLAN tunnels can be dynamically established

using BGP EVPN for intra-subnet and inter-subnet communication.
Intra-subnet communication
On the network shown in Figure 4-25, intra-subnet communication between Host 2 and Host
3 requires only Layer 2 forwarding. The process for establishing a VXLAN tunnel using BGP
EVPN is as follows:

Figure 4-25 Dynamic VXLAN tunnel establishment 1

Spine
Leaf1 Leaf2
VNI: 20 VNI: 20
VTEP: 1.1.1.1 VTEP: 2.2.2.2
Type3 route
EVPN1 1 ERT(20:1) 2 EVPN1
RD : 2:1 RD : 1:1
ERT: 20:1 ERT: 20:1
2 Type3 route 1
IRT : 20:1 IRT : 20:1
ERT(20:1)
NVE
1. Leaf 1 and Leaf 2 establish a BGP EVPN peer relationship. Then, Layer 2 broadcast
domains are created on Leaf 1 and Leaf 2 and bound to VNIs. An EVPN instance is
configured in a Layer 2 broadcast domain, and an RD and export and import VPN targets
are configured for the EVPN instance. After the local VTEP's IP address is configured
on Leaf 1 and Leaf 2, they generate a BGP EVPN route and send it to each other. The
BGP EVPN route carries the local EVPN instance's export VPN target and an inclusive
multicast route (Type 3 route defined in BGP EVPN). Figure 4-26 shows the format of
an inclusive multicast route, which comprises a prefix and a PMSI attribute. VTEP IP
addresses are stored in the Originating Router's IP Address field in the inclusive
multicast route prefix, and Layer 2 VNIs are stored in the MPLS Label field in the PMSI
attribute.

Prefix
PMSI attribute
Flags (1 byte)
2. After Leaf 1 and Leaf 2 receive a BGP EVPN route from each other, they match the
export VPN targets of the route against the import VPN targets of the local EVPN
instance. If a match is found, the route is accepted. If no match is found, the route is
discarded. If the route is accepted, Leaf 1/Leaf 2 obtains the remote VTEP's IP address
and Layer 2 VNI carried in the route. If the remote VTEP's IP address is reachable at
Layer 3, a VXLAN tunnel to the remote VTEP is established. If the remote Layer 2 VNI
is the same as the local Layer 2 VNI, an ingress replication list is created for subsequent
NOTE
A VPN target is a 32-bit extended community attribute of BGP. An EVPN instance can have import and
export VPN targets configured. The local EVPN instance's export VPN target must match the remote
EVPN instance's import VPN target for EVPN route advertisement. If not, VXLAN tunnels cannot be
dynamically established. If only one end can successfully accept the BGP EVPN route, this end can
establish a VXLAN tunnel to the other end, but cannot exchange data packets with the other end. The
other end drops packets after confirming that there is no VXLAN tunnel to the end that has sent these
packets.
For details on VPN targets, see Basic BGP/MPLS IP VPN.
Inter-subnet communication
Inter-subnet communication between Host 1 and Host 2 requires Layer 3 forwarding. When
VXLAN tunnels are established using BGP EVPN, Leaf 1 and Leaf 2 must advertise the host
IP routes. Generally, 32-bit host IP routes are advertised. Because different leaf nodes may
connect to the same network segment on VXLANs, the network segment routes advertised by
these leaf nodes may conflict. This conflict may cause host unreachability of some leaf nodes.
Leaf nodes can advertise network segment routes in the following scenarios:
l The network segment that a leaf node connects is unique on a VXLAN, and a large
number of specific host routes are available. In this case, the network segment routes to
which the host IP routes belong can be advertised so that leaf nodes do not have to store
all these routes.
l When hosts on a VXLAN need to access external networks, leaf nodes can advertise
routes destined for external networks onto the VXLAN to allow other leaf nodes to learn
the routes.

Before establishing a VXLAN tunnel, perform the following configurations on Leaf 1 and
Leaf 2.
Key steps Function
Create a Layer 2 BD and associate a Layer 2 A BD functions as a VXLAN network

VNI to the Layer 2 BD. entity to transmit VXLAN data packets.
Establish a BGP EVPN peer relationship This configuration is used to exchange BGP
between Leaf 1 and Leaf 2. EVPN routes.
Configure an EVPN instance in a Layer 2 This configuration is used to generate BGP

BD, and configure an RD, export VPN EVPN routes.
target (ERT), and import VPN target (IRT)
for the EVPN instance.
Configure L3VPN instances for tenants and This configuration is used to differentiate
bind the L3VPN instances to the VBDIF and isolate IP routing tables of different
interfaces of the Layer 2 BD. tenants.
Specify a Layer 3 VNI for an L3VPN This configuration allows the leaf nodes to
instance. determine the L3VPN routing table for
forwarding data packets.
Configure export VPN targets (eERT) from This configuration controls advertisement
an L3VPN instance to an EVPN instance and reception of BGP EVPN routes between
and import VPN targets (eIRT) from an the local L3VPN instance and EVPN
EVPN instance to an L3VPN instance. instance.
Configure the type of route to be advertised This configuration is used to advertise IP

between Leaf 1 and Leaf 2. routes between Host 1 and Host 2. Two
types of routes are available, IRB and IP
prefix routes, which can be selected as
needed.
l IRB routes advertise only 32-bit host IP
routes. IRB routes carry ARP routes. If
only 32-bit host IP route advertisement
is needed, advertising IRB routes is
recommended.
l IP prefix routes can advertise both 32-bit
host IP routes and network segment
routes. However, before IP prefix routes
advertise 32-bit host IP routes, direct
routes to the host IP addresses must be
generated. This will affect VM
migration. If only 32-bit host IP route
advertisement is needed, advertising IP
prefix routes is not recommended.
Advertise IP prefix routes only when
network segment route advertisement is
needed.

Dynamic VXLAN tunnel establishment varies depending on how host IP routes are
advertised.
l Host IP routes are advertised through IRB routes. (Figure 4-27 shows the process.)
Spine
IRB route
Leaf1 Next hop(1.1.1.1) Leaf2
VNI: 10 Extended VNI: 20
VTEP: 1.1.1.1 community VTEP: 2.2.2.2
3 ERT(20:1)
1 EVPN1 EVPN1
RD : 2:1 RD : 1:1 4
ERT: 20:1 ERT: 20:1
IRT : 20:1 IRT : 20:1
2
Host1 L3VPN1 L3VPN1 Host2
192.168.10.1/24 L3VNI: 100 L3VNI: 100 192.168.20.1/24
RD : 3:1 RD : 4:1
eERT: 20:1 eERT: 20:1
eIRT : 20:1 eIRT : 20:1
NVE
a. When Host 1 communicates with Leaf 1 for the first time, Leaf 1 learns the ARP
entry of Host 1 after receiving dynamic ARP packets. Leaf 1 then finds the L3VPN
instance bound to the VBDIF interface of the Layer 2 BD where Host 1 resides, and
obtains the Layer 3 VNI associated with the L3VPN instance. The EVPN instance
of Leaf 1 then generates an IRB route based on the information obtained. Figure
4-28 shows the IRB route. The host IP address is stored in the IP Address Length
and IP Address fields; the Layer 3 VNI is stored in the MPLS Label2 field.

Figure 4-28 IRB route

b. Leaf 1 generates and sends a BGP EVPN route to Leaf 2. The BGP EVPN route
carries the local EVPN instance's export VPN targets (ERT), extended community
attribute, Next_Hop attribute, and the IRB route. The extended community attribute
carries the tunnel type (VXLAN tunnel) and local VTEP MAC address; the
Next_Hop attribute carries the local VTEP IP address.
c. After Leaf 2 receives the BGP EVPN route from Leaf 1, Leaf 2 processes the route
as follows:
n Matches the ERT of the route against the import VPN targets (IRT) of the local
EVPN instance. If a match is found, the route is accepted. After the EVPN
instance obtains IRB routes, it can extract ARP routes from the IRB routes to
implement ARP advertisement.
n Matches the ERT of the route against the import VPN targets (eIRT) of the
local L3VPN instance. If a match is found, the route is accepted. The L3VPN
instance obtains the IRB route, extracts Host 1's IP address and Layer 3 VNI,
and stores Host 1's IP route in the routing table. Based on the next hop, the IP
route's outbound interface recurses to the VXLAN tunnel destined for Leaf1.
Figure 4-29 shows the host route.
NOTE
Only when the ERT in a BGP EVPN route is different from the local EVPN instance's
IRT and local L3VPN instance's eIRT, the route is discarded.
Figure 4-29 Remote host IP route

Destination L3 VNI Next Hop Outbound Interface
192.168.10.1/32 100 1.1.1.1 VXLAN tunnel
n If the route is accepted by the EVPN instance or L3VPN instance, Leaf 2

obtains Leaf 1's VTEP IP address from the Next_Hop attribute. If the VTEP IP
address is reachable at Layer 3, a VXLAN tunnel to Leaf 1 is established.
Leaf 1 establishes a VXLAN tunnel to Leaf 2 in the same process.
l Host IP routes are advertised through IP prefix routes. Figure 4-30 shows the process.

Spine
IP prefix route
Leaf1 Next hop(1.1.1.1) Leaf2
VNI: 10 Extended VNI: 20
VTEP: 1.1.1.1 community VTEP: 2.2.2.2
3 eERT(20:1)
1 EVPN1 EVPN1
RD : 1:1 4
RD : 2:1
ERT: 20:1 ERT: 20:1
IRT : 20:1 IRT : 20:1
2
Host1 L3VPN1 L3VPN1 Host2
192.168.10.1/24 L3VNI: 100 L3VNI: 100 192.168.20.1/24
RD : 3:1 RD : 4:1
eERT: 20:1 eERT: 20:1
eIRT : 20:1 eIRT : 20:1
NVE
a. Leaf 1 generates a direct route to Host 1's IP address. Then, Leaf 1 has an L3VPN
instance configured to import the direct route, so that Host 1's IP route is saved to
the routing table of the L3VPN instance and the Layer 3 VNI associated with the
L3VPN instance is added. Figure 4-31 shows the host IP route.
Figure 4-31 Local host IP route

192.168.10.1/32 100 0.0.0.0 VBDIF
NOTE
If network segment route advertisement is required, use a dynamic routing protocol, such as
OSPF. Then, configure an L3VPN instance to import the routes of the dynamic routing
protocol.
b. If Leaf 1 is configured to advertise IP routes in the L3VPN instance to the EVPN
instance, Leaf 1 advertise Host 1's IP routes in the L3VPN instance to the EVPN
instance. The EVPN instance then generates IP prefix routes. Figure 4-32 shows
the IP prefix route. The host IP address is stored in the IP Prefix Length and IP
Prefix fields; the Layer 3 VNI is stored in the MPLS Label field.


IP Prefix Length (1 byte)
c. Leaf 1 generates and sends a BGP EVPN route to Leaf 2. The BGP EVPN route
carries the local L3VPN instance's export VPN targets (eERT), extended
community attribute, Next_Hop attribute, and the IP prefix route. The extended
community attribute carries the tunnel type (VXLAN tunnel) and local VTEP MAC
address; the Next_Hop attribute carries the local VTEP IP address.
d. After Leaf 2 receives the BGP EVPN route from Leaf 1, Leaf 2 processes the route
as follows:
n Matches the eERT of the route against the import VPN targets (eIRT) of the
local L3VPN instance. If a match is found, the route is accepted. If no match is
found, the route is discarded. The L3VPN instance obtains the IP prefix route,
extracts Host 1's IP address and Layer 3 VNI, stores Host 1's IP route in the
routing table. Based on the next hop, the IP route's outbound interface recurses
to the VXLAN tunnel destined for Leaf1. Figure 4-33 shows the host route.
Figure 4-33 Remote host IP route

192.168.10.1/32 100 1.1.1.1 VXLAN tunnel
n If the route is accepted by the L3VPN instance, Leaf 2 obtains Leaf 1's VTEP
IP address from the Next_Hop attribute. If the VTEP IP address is reachable at
Layer 3, a VXLAN tunnel to Leaf 1 is established.
Leaf 1 establishes a VXLAN tunnel to Leaf 2 in the same process.

greatly reducing maintenance workload. In distributed VXLAN gateway scenarios, inter-
subnet communication requires Layer 3 forwarding; MAC address learning is implemented
using ARP between the local host and gateway. The following example illustrates dynamic
MAC address learning for intra-subnet communication on the network shown in Figure 4-34.

Figure 4-34 Dynamic MAC address learning
Spine

VXLAN Tunnel
Leaf1 Port1 Leaf2
2
VNI:20 1 Type2 route VNI:20
VTEP:1.1.1.1/32 VTEP:2.2.2.2/32
NextHop
ERT
Host3 Host2
MAC3 MAC2
IP3:192.168.20.2/24 IP2:192.168.20.1/24
1. When Host 3 communicates with Leaf 1 for the first time, Leaf 1 learns the mapping
between Host 3's MAC address, BDID (Layer 2 broadcast domain ID), and inbound
interface (Port1 for the Layer 2 sub-interface) that has received the dynamic ARP packet
and generates a MAC address entry for Host 3. The MAC address entry's outbound
interface is Port1. Leaf 1 generates and sends a BGP EVPN route based on the ARP
entry of Host 3 to Leaf 2. The BGP EVPN route carries the local EVPN instance's export
VPN targets, Next_Hop attribute, and a Type 2 route (MAC/IP route) defined in BGP
EVPN. The Next_Hop attribute carries the local VTEP's IP address. The MAC Address
Length and MAC Address fields identify Host 3's MAC address. The Layer 2 VNI is
stored in the MPLS Label1 field. Figure 4-35 shows the format of a MAC/IP route.

IP Address (0, 4 or 16 bytes）
2. After Leaf 2 receives a BGP EVPN route from Leaf 1, Leaf 2 matches the export VPN
targets of the route against the import VPN targets of the local EVPN instance. If a
match is found, the route is accepted. If no match is found, the route is discarded. If the
route is accepted, Leaf 2 obtains the mapping between Host 3's MAC address, ID of the

BD bound to the VNI, Leaf 1's VTEP IP address (Next_Hop attribute) and generates a
MAC address entry for Host 3. Based on the next hop, the MAC address entry's
outbound interface recurses to the VXLAN tunnel destined for Leaf1.
Leaf 1 learns the MAC route of Host 2 in the same process.
NOTE
Leaf nodes can learn the MAC addresses of hosts during data forwarding, if this capability is enabled. If
VXLAN tunnels are established using BGP EVPN, leaf nodes can dynamically learn the MAC
addresses of hosts through BGP EVPN routes, rather than data forwarding.

Spine
VXLAN Tunnel
Leaf1 Leaf2
VNI:20 VNI:20
VTEP:1.1.1.1/32 VTEP:2.2.2.2/32
Host3 Host2
MAC3 MAC2
IP3:192.168.20.2/24 IP2:192.168.20.1/24
VLAN3 VLAN2
Layer 2 packet
3 2
Tag DIP 2.2.2.2 Tag
UDP S_P HASH
UDP D_P 4789
VNI 20
DMAC MAC2
SMAC MAC3

Host 2 sends packets to Host 3 in the same process.

process.


Terminal C:
IP3
MAC3
VLAN4
VXLAN Leaf 3
L2 gateway VNI: 20
NV VTEP: 3.3.3.3
VXLAN E3
L2 gateway
NVE1
Network
Terminal A: Leaf 1
E2
IP1 VNI: 20
NV
VNI: 20
VTEP: 2.2.2.2
Terminal B:
IP 2
MAC 2
VLAN 3
Layer 2 packet
DMAC All Fs
VLAN 3
2 DIP 2.2.2.2 DIP 3.3.3.3 Tag
Tag
VNI 20 VNI 20 VLAN
4
SMAC MAC1 SMAC MAC1

NOTE
packet forwarding.

Inter-subnet packets must be forwarded through a Layer 3 gateway. Figure 4-38 shows the
inter-subnet packet forwarding process in distributed VXLAN gateway scenarios.


Spine
L3 gateway MAC: GW1 MAC L3 gateway MAC: GW2 MAC

NVE interface MAC: NVE1 MAC NVE interface MAC: NVE2 MAC
Leaf1 Leaf2
VNI:10 VXLAN Tunnel VNI:20
VTEP:1.1.1.1 VTEP:2.2.2.2
L3VPN1 L3VPN1
L3VNI: 100 L3VNI: 100
Host1： Host2：
IP1：192.168.10.1/24 IP2：192.168.20.1/24
MAC1 MAC2
Packet sent VXLAN packet Packet after

from Host1 encapsulated by Leaf 1 decapsulated by Leaf 2
DMAC GW1 MAC DMAC Nexthop MAC DMAC MAC2
SMAC MAC1 SMAC Outport MAC SMAC GW2 MAC
SIP IP1 SIP 1.1.1.1 SIP IP1
DIP IP2 DIP 2.2.2.2 DIP IP2
Pay-load UDP S_P HASH Pay-load
UDP D_P 4789
VNI 100
DMAC NVE2 MAC
SMAC GW1 MAC
SIP IP1
DIP IP2
Pay-load
1. After Leaf 1 receives a packet from Host 1, it finds that the destination MAC address of
the packet is a gateway MAC address so that the packet must be forwarded at Layer 3.
2. Leaf 1 determines the Layer 2 broadcast domain of the packet based on the inbound
interface and accordingly finds the L3VPN instance bound to the VBDIF interface of the
Layer 2 broadcast domain. Leaf 1 then searches the L3VPN routing table and finds the
destination address of packet. Figure 4-39 shows the host route in the L3VPN routing
table. Leaf 1 obtains the Layer 3 VNI and next hop address of the host route and find that
the outbound interface is a VXLAN tunnel. Therefore, Leaf 1 determines that the packet
must be transmitted through a VXLAN tunnel. Because the packet must be transmitted
over a VXLAN tunnel, Leaf 1 performs VXLAN encapsulation as follows:
– Obtains the MAC address based on the VXLAN tunnel's source and destination IP
addresses and replace the source and destination MAC addresses in the inner
Ethernet header.

– Encapsulates the packet with the Layer 3 VNI.

– Encapsulates the VXLAN tunnels' source and destination IP addresses in the outer
IP header, and Leaf 1's outbound interface MAC address as the source MAC
address and MAC address of the next hop pointing to the destination IP address as
the destination MAC address in the outer Ethernet header.
Figure 4-39 Host route in the L3VPN routing table

L3VPN1:
Destination L3 VNI Next HopOutbound Interface
192.168.20.1/32 100 2.2.2.2 VXLAN tunnel
3. The VXLAN packet is then transmitted over the IP network based on the IP and MAC
addresses in the outer headers and finally reaches Leaf 2.
4. After Leaf 2 receives the VXLAN packet, it decapsulates the packet and finds that the
destination MAC address is its own MAC address so that the packet must be forwarded
at Layer 3.
5. Leaf 2 determines the L3VPN instance bound to the Layer 3 VNI of the packet, searches
the L3VPN routing table, and finds the next hop being the gateway IP address in prefix
route. Leaf 2 replaces the destination MAC address with Host 2's MAC address (MAC2)
and source MAC address with Leaf 2's MAC address and sends the packet to Host 2.
Host 2 sends packets to Host 1 in the same process.
NOTE
When a Huawei device communicates with a non-Huawei device, ensure that the non-Huawei device
uses the same forwarding mode as that of the Huawei device. If they use different forwarding modes, the
communication may fail.
4.1.4 Function Enhancements
4.1.4.1 Using Three-Segment VXLAN to Implement Layer 3 Interconnection

Between DCs
Background
To meet the requirements of geographical redundancy, inter-regional operations, and user
access, an increasing number of enterprises are deploying data centers (DCs) across multiple
regions.Data Center Interconnect (DCI) is a solution that enables intercommunication
between the VMs of multiple DCs. Using technologies such as VXLAN and BGP EVPN,
DCI securely and reliably transmits DC packets over carrier networks. With DCI, Layer 3
intercommunication between the VMs on different subnets of multiple DCs can be
implemented.
Benefits
This solution offers the following benefits to users:
l Implements Layer 3 interworking between hosts in different DCs.
l The routing protocols running in different DCs are independent. DCs are not required to
use the same protocols.

l It is not necessary to orchestrate information between DCs.
Principles
Three-segment VXLAN establishes one VXLAN tunnel segment in each of the two DCs and
also establishes one VXLAN tunnel segment between the DCs. As shown in Figure 4-40,
BGP EVPN is used to create VXLAN tunnels in distributed gateway mode within both DC A
and DC B so that the VMs deployed in each DC can communicate with each other. Leaf 2 and
Leaf 3 are the edge devices within the DCs that connect to the backbone network. BGP EVPN
is used to configure VXLAN tunnels on Leaf 2 and Leaf 3 so that the VXLAN packets
received by one DC can be decapsulated, re-encapsulated, and sent to the peer DC. This
process provides end-to-end bearing for inter-DC VXLAN packets and ensures that VMs in
different DCs can communicate with each other.
NOTE
This function is only supported for IPv4 over IPv4 networks.

In three-segment VXLAN, only VXLAN tunnels in distributed gateway mode can be deployed within
DCs.
Figure 4-40 Using three-segment VXLAN to implement DCI
IP network
Device1 Device2
DC-A DC-B
Spine1 Spine2
Leaf2 Leaf3
Leaf1 VXLAN VXLAN VXLAN Leaf4
VMa1 VMa2 VMb1 VMb2
VLAN 10 VLAN 20 VLAN 10 VLAN 20
Control Plane
The following describes how three-segment VXLAN tunnels are established.
NOTE
The process of advertising routes on Leaf 1 and Leaf 4 is not described in this section. For details, see
VXLAN Tunnel Establishment.

1. Leaf 4 learns the IP address of VMb2 in DC B and saves it to the routing table for the
L3VPN instance. Leaf 4 then sends a BGP EVPN route to Leaf 3.
2. As shown in Figure 4-41, Leaf 3 receives the BGP EVPN route and obtains the host IP
route contained in it. Leaf 3 then establishes a VXLAN tunnel to Leaf 4 according to the
process described in VXLAN Tunnel Establishment. It sets the next hop of the route to
the VTEP address of Leaf 3, re-encapsulates the route with the Layer 3 VNI of the
L3VPN instance, and sets its source MAC address to the MAC address of Leaf 3.
Finally, Leaf 4 sends the re-encapsulated BGP EVPN route to Leaf 2.
Figure 4-41 Control plane

Leaf2 Leaf3
VNI: 10 VNI: 20
VTEP: 2.2.2.2 VTEP: 3.3.3.3
L3VPN1 L3VPN1
L3VNI: 100 L3VNI: 100
Leaf3 decapsulates
Leaf2 decapsulates and then re-
and then re- encapsulates the Leaf3 receives a
encapsulates the received BGP
received BGP BGP EVPN
EVPN route.
EVPN route. route.
... ... ...
Next hop (2.2.2.2) Next hop (3.3.3.3) Next hop (Leaf4 VTEP)
Extended community Extended community Extended community
attribute (Leaf2 MAC) attribute (Leaf3 MAC) attribute (Leaf4 MAC)
… ... ...
L3VNI (100) L3VNI (100) L3VNI (100)
NVE
Route advertisement
3. Leaf 2 receives the BGP EVPN route and obtains the host IP route contained in it. Leaf 2
then establishes a VXLAN tunnel to Leaf 3 according to the process described in
VXLAN Tunnel Establishment. It sets the next hop of the route to the VTEP address of
Leaf 2, re-encapsulates the route with the Layer 3 VNI of the L3VPN instance, and sets
its source MAC address to the MAC address of Leaf 2. Finally, Leaf 2 sends the re-
encapsulated BGP EVPN route to Leaf 1.
4. Leaf 1 receives the BGP EVPN route and establishes a VXLAN tunnel to Leaf 2
according to the process described in VXLAN Tunnel Establishment.
Data Packet Forwarding
NOTE
A general overview of the packet forwarding process on Leaf 1 and Leaf 4 is provided as follows. For
additional information, see Intra-Subnet Packet Forwarding.
1. Leaf 1 receives Layer 2 packets destined for VMb2 from VMa1 and determines that the
destination MAC addresses in these packets are all gateway interface MAC addresses.
Leaf 1 terminates the Layer 2 packets and finds the L3VPN instance corresponding to

the BDIF interface through which VMa1 accessed the bridge domain. Leaf 1 then
searches the L3VPN instance routing table for the VMb2 host route, encapsulates the
received packets as VXLAN packets, and sends them to Leaf 2 over the VXLAN tunnel.
2. As shown in Figure 4-42, Leaf 2 receives and parses these VXLAN packets. Leaf 2
finds the L3VPN instance corresponding to the Layer 3 VNI of the packets and then
searches the L3VPN instance routing table for the VMb2 host route. Leaf 2 re-
encapsulates these VXLAN packets, setting the Layer 3 VNI to that carried in the VMb2
host route sent by Leaf 3 and the inner destination MAC address to the MAC address
carried in the VMb2 host route sent by Leaf 3. Finally, Leaf 2 sends these packets to
Leaf 3.
Figure 4-42 Data packet forwarding
Leaf2 Leaf3
VNI: 10 VXLAN Tunnel VNI: 20
VTEP: 2.2.2.2 VTEP: 3.3.3.3
L3VPN1 L3VPN1
L3VNI: 100 L3VNI: 100
VMa1: VMb2：
IP1: 192.168.10.1/32 IP2: 192.168.20.1/32
MAC1 MAC2
VLAN10 VLAN20
Leaf2 receives a Leaf2 decapsulates and Leaf3 decapsulates and
VXLAN packet then re-encapsulates the then re-encapsulates the
from Leaf1. VXLAN packet. VXLAN packet.
DMAC NET MAC DMAC NET MAC DMAC NET MAC
SMAC NVE1 MAC SMAC NVE2 MAC SMAC NVE3 MAC
SIP Leaf1 IP SIP 2.2.2.2 SIP 3.3.3.3
DIP 2.2.2.2 DIP 3.3.3.3 DIP Leaf4 IP
UDP S_P HASH UDP S_P HASH UDP S_P HASH
UDP D_P 4789 UDP D_P 4789 UDP D_P 4789
VNI 100 VNI 100 VNI 100
DMAC Leaf2 MAC DMAC Leaf3 MAC DMAC Leaf4 MAC
SMAC Leaf1 MAC SMAC Leaf2 MAC SMAC Leaf3 MAC
SIP IP1 SIP IP1 SIP IP1
DIP IP2 DIP IP2 DIP IP2
Pay-load Pay-load Pay-load
3. As shown in Figure 4-42, Leaf 3 receives and parses these VXLAN packets. Leaf 3
finds the L3VPN instance corresponding to the Layer 3 VNI of the packets and then
searches the L3VPN instance routing table for the VMb2 host route. Leaf 3 re-
encapsulates these VXLAN packets, setting the Layer 3 VNI and the inner destination
MAC address to the Layer 3 VNI and MAC address carried in the VMb2 host route sent
by Leaf 4. Finally, Leaf 3 sends these packets to Leaf 4.
4. Leaf 4 receives and parses these VXLAN packets. Leaf 4 finds the L3VPN instance
corresponding to the Layer 3 VNI of the packets and then searches the L3VPN instance

routing table for the VMb2 host route. Using this routing information, it forwards the
packets to VMb2.
4.1.4.2 Using Three-Segment VXLAN to Implement Layer 2 Interconnection

Between DCs
Background
Figure 4-43 shows the scenario where three-segment VXLAN is deployed to implement
Layer 2 interconnection between DCs. VXLAN tunnels are configured both within DC A and
DC B and between transit leaf nodes in both DCs. To enable communication between VM1
and VM2, implement Layer 2 communication between DC A and DC B. If the VXLAN
tunnels within DC A and DC B use the same VXLAN Network Identifier (VNI), this VNI can
also be used to establish a VXLAN tunnel between Transit Leaf1 and Transit Leaf2. In
practice, however, different DCs have their own VNI spaces. Therefore, the VXLAN tunnels
within DC A and DC B tend to use different VNIs. In this case, to establish a VXLAN tunnel
between Transit Leaf1 and Transit Leaf2, VNIs conversion must be implemented.
Figure 4-43 Deployment of three-segment VXLAN for Layer 2 interworking
Spine Spine
DC A DC B
Server Transit Transit Server

Leaf1 Leaf1 Leaf2 Leaf2
VXLAN VXLAN VXLAN
VNI 10 VNI 20
VSwitch VSwitch
VM1 VM2
VLAN 10 VLAN 10
Benefits
This solution offers the following benefits to users:
l Implements Layer 2 interconnection between hosts in different DCs.
l Decouples the VNI space of the network within a DC from that of the network between
DCs, simplifying network maintenance.
l Isolates network faults within a DC from those between DCs, facilitating fault location.
Principles
Currently, this solution is implemented in the local VNI mode. It is similar to downstream
label allocation. The local VNI of the peer transit leaf node functions as the outbound VNI,
which is used by packets that the local transit leaf node sends to the peer transit leaf node for
VXLAN encapsulation.
Control Plane

NOTE
This function is only supported for IPv4 over IPv4 networks.

The establishment of VXLAN tunnels between leaf nodes is the same as VXLAN tunnel establishment
for intra-subnet interworking in common VXLAN scenarios. Therefore, the detailed process is not
described here. Regarding the control plane, MAC address learning by a host is described here.
On the network shown in Figure 4-44, the control plane is implemented as follows:
Figure 4-44 Control plane for VXLAN mapping in local VNI mode
DC A DC B
Type2 route Type2 route Type2 route
Next hop Next hop Next hop
Extended community Extended Extended community

attribute community attribute attribute
ERT ERT ERT

Transit Leaf1 Transit Leaf2
Server Leaf1 Server Leaf2
VXLAN VXLAN VXLAN
VNI 10 VNI 20
VM1 MAC Outbound MAC Outbound MAC Outbound VM2

address interface address interface address interface
VXLAN VXLAN VXLAN
VM1-MAC VM1-MAC VM1-MAC
tunnel tunnel tunnel
VNI 10 Out VNI 10 VNI 20
1. Server Leaf1 learns VM1's MAC address, generates a BGP EVPN route, and sends it to
Transit Leaf1. The BGP EVPN route contains the following information:
– Type 2 route: EVPN instance's RD value, VM1's MAC address, and Server Leaf1's
local VNI.
– Next hop: Server Leaf1's VTEP IP address.
– Extended community attribute: encapsulated tunnel type (VXLAN).
– ERT: EVPN instance's export RT value.
2. Upon receipt, Transit Leaf1 adds the BGP EVPN route to its local EVPN instance and
generates a MAC address entry for VM1 in the EVPN instance-bound BD. Based on the
next hop and encapsulated tunnel type, the MAC address entry's outbound interface
recurses to the VXLAN tunnel destined for Server Leaf1. The VNI in VXLAN tunnel
encapsulation information is Transit Leaf1's local VNI.
3. Transit Leaf1 re-originates the BGP EVPN route and then advertises the route to Transit
Leaf2. The re-originated BGP EVPN route contains the following information:
– Type 2 route: EVPN instance's RD value, VM1's MAC address, and Transit Leaf1's
local VNI.
– Next hop: Transit Leaf1's VTEP IP address.
4. Upon receipt, Transit Leaf2 adds the re-originated BGP EVPN route to its local EVPN
instance and generates a MAC address entry for VM1 in the EVPN instance-bound BD.
Based on the next hop and encapsulated tunnel type, the MAC address entry's outbound
interface recurses to the VXLAN tunnel destined for Transit Leaf1. The outbound VNI
in VXLAN tunnel encapsulation information is Transit Leaf1's local VNI.

5. Transit Leaf2 re-originates the BGP EVPN route and then advertises the route to Server
Leaf2. The re-originated BGP EVPN route contains the following information:
– Type 2 route: EVPN instance's RD value, VM1's MAC address, and Transit Leaf2's
local VNI.
– Next hop: Transit Leaf2's VTEP IP address.
6. Upon receipt, Server Leaf2 adds the re-originated BGP EVPN route to its local EVPN
instance and generates a MAC address entry for VM1 in the EVPN instance-bound BD.
Based on the next hop and encapsulated tunnel type, the MAC address entry's outbound
interface recurses to the VXLAN tunnel destined for Transit Leaf2. The VNI in VXLAN
tunnel encapsulation information is Server Leaf2's local VNI.
NOTE
The preceding process takes MAC address learning by VM1 for example. MAC address learning by
VM2 is the same, which is not described here.
Forwarding Plane
Figure 4-45 shows the known unicast packets are forwarded. The following example process
shows how VM2 sends Layer 2 packets to VM1:
Figure 4-45 Known unicast packet forwarding with VXLAN mapping in local VNI mode
DC A DC B
Transit Transit Server
Server
Leaf1 VNI 10 Leaf1 VNI 10 Leaf2 VNI 20 Leaf2
VXLAN VXLAN VXLAN
Outer MAC Outer MAC Outer MAC VM2

VM1
SIP (TL1) SIP (TL2) SIP (SL2)
DIP (SL1) DIP (TL1) DIP (TL2)
VNI (10) VNI (10) VNI (20)
DMAC (VM1) DMAC (VM1) DMAC (VM1)
SMAC (VM2) SMAC (VM2) SMAC (VM2)
1. After receiving a Layer 2 packet from VM2 through a BD Layer 2 sub-interface, Server
Leaf2 searches the BD's MAC address table based on the destination MAC address for
the VXLAN tunnel's outbound interface and obtains VXLAN tunnel encapsulation
information (local VNI, destination VTEP IP address, and source VTEP IP address).
Based on the obtained information, the Layer 2 packet is encapsulated through the
VXLAN tunnel and then forwarded to Transit Leaf2.
2. Upon receipt, Transit Leaf2 decapsulates the VXLAN packet, finds the target BD based
on the VNI, searches the BD's MAC address table based on the destination MAC address
for the VXLAN tunnel's outbound interface, and obtains the VXLAN tunnel
encapsulation information (outbound VNI, destination VTEP IP address, and source
VTEP IP address). Based on the obtained information, the Layer 2 packet is
encapsulated through the VXLAN tunnel and then forwarded to Transit Leaf1.

3. Upon receipt, Transit Leaf1 decapsulates the VXLAN packet. Because the packet's VNI
is Transit Leaf1's local VNI, the target BD can be found based on this VNI. Transit Leaf1
also searches the BD's MAC address table based on the destination MAC address for the
VXLAN tunnel's outbound interface and obtains the VXLAN tunnel encapsulation
information (local VNI, destination VTEP IP address, and source VTEP IP address).
Based on the obtained information, the Layer 2 packet is encapsulated through the
VXLAN tunnel and then forwarded to Server Leaf1.
4. Upon receipt, Server Leaf1 decapsulates the VXLAN packet and forwards it at Layer 2
to VM1.
NOTE
In the scenario with three-segment VXLAN for Layer 2 interworking, BUM packet forwarding is the
same as that in the common VXLAN scenario except that the split horizon group is used to prevent
loops. The similarities are not described here.
l After receiving BUM packets from a Server Leaf node in the same DC, a Transit Leaf node obtains
the split horizon group to which the source VTEP belongs. Because all nodes in the same DC belong
to the default split horizon group, BUM packets will not be replicated to other Server Leaf nodes
within the DC. Because the peer Transit Leaf node belongs to a different split horizon group, BUM
packets will be replicated to the peer Transit Leaf node.
l Upon receipt, the peer Transit Leaf node obtains the split horizon group to which the source VTEP
belongs. Because the Transit Leaf nodes at both ends belong to the same split horizon group, BUM
packets will not be replicated to the peer Transit Leaf node. Because the Server Leaf nodes within
the DC belong to a different split horizon group, BUM packets will be replicated to them.
4.1.4.3 VXLAN Active-Active Reliability
Basic Concepts
NOTE
This function is supported on IPv4 over IPv4 and IPv6 over IPv4 networks.
The network in Figure 4-46 shows a scenario where an enterprise site (CPE) connects to a
data center. The VPN GWs (PE1 and PE2) and CPE are connected through VXLAN tunnels
to exchange the L2/L3 services between the CPE and data center. The data center gateway
(CE1) is dual-homed to PE1 and PE2 to access the VXLAN network for enhanced network
access reliability. If one PE fails, services can be rapidly switched to the other PE, minimizing
service loss.
PE1 and PE2 on the network use the same virtual address as an NVE interface address
(Anycast VTEP address) at the network side. In this way, the CPE is aware of only one
remote NVE interface. After the CPE establishes a VXLAN tunnel with this virtual address,
the packets from the CPE can reach CE1 through either PE1 or PE2. However, when a single-
homed CE, such as CE2 or CE3, exists on the network, the packets from the CPE to the
single-homed CE may need to detour to the other PE after reaching one PE. To achieve PE1-
PE2 reachability, a bypass VXLAN tunnel needs to be established between PE1 and PE2. To
establish this tunnel, an EVPN peer relationship is established between PE1 and PE2, and
different addresses, namely, bypass VTEP addresses, are configured for PE1 and PE2.

Figure 4-46 Basic networking of the VXLAN active-active scenario
CPE
VXLAN Tunnel
Anycast VTEP
PE1 PE2
Bypass VXLAN Tunnel
Trunk
CE2 CE1 CE3
Control Plane
l PE1 and PE2 exchange Inclusive Multicast routes (Type 3) whose source IP address is
their shared anycast VTEP address. Each route carries a bypass VXLAN extended
community attribute, which contains the bypass VTEP address of PE1 or PE2.
l After receiving the Inclusive Multicast route from each other, PE1 and PE2 consider that
they form an anycast relationship based on the following details: The source IP address
(anycast VTEP address) of the route is identical to PE1's and PE2's local virtual
addresses, and the route carries a bypass VXLAN extended community attribute. PE1
and PE2 then establish a bypass VXLAN tunnel between them.
l PE1 and PE2 learn the MAC addresses of the CEs through the upstream packets from the
AC side and advertise the MAC/IP routes (Type 2) to each other. The routes carry the
ESIs of the access links of the CEs, information about the VLANs that the CEs access,
and the bypass VXLAN extended community attribute.
l PE1 and PE2 learn the MAC address of the CPE through downstream packets from the
network side. After learning that the next-hop address of the MAC route can be recursed
to a static VXLAN tunnel, PE1 and PE2 advertise the route to each other through an
MAC/IP route, without changing the next-hop address.
Data Packets Processing

l Layer 2 unicast packet forwarding
– Uplink
As shown in Figure 4-47, after receiving Layer 2 unicast packets destined for the
CPE from CE1, CE2, and CE3, PE1 and PE2 search for their local MAC address
table to obtain outbound interfaces, perform VXLAN encapsulation on the packets,
and forward them to the CPE.

Figure 4-47 Uplink unicast packet forwarding
CPE
VXLAN
VLAN
Trunk
CE2 CE1 CE3

– Downlink
As shown in Figure 4-48:
After receiving a Layer 2 unicast packet sent by the CPE to CE1, PE1 performs
VXLAN decapsulation on the packet, searches the local MAC address table for the
destination MAC address, obtains the outbound interface, and forwards the packet
to CE1.
destination MAC address, obtains the outbound interface, and forwards the packet
to CE2.
destination MAC address, and forwards it to PE2 over the bypass VXLAN tunnel.
After the packet reaches PE2, PE2 searches the destination MAC address, obtains
the outbound interface, and forwards the packet to CE3.
The process for PE2 to forward packets from the CPE is the same as that for PE1 to
forward packets from the CPE.

Figure 4-48 Downlink unicast packet forwarding
CPE
VXLAN
VLAN
Trunk
CE2 CE1 CE3
l BUM packet forwarding

– As shown in Figure 4-49, if the destination address of a BUM packet from the CPE
is the Anycast VTEP address of PE1 and PE2, the BUM packet may be forwarded
to either PE1 or PE2. If the BUM packet reaches PE2 first, PE2 sends a copy of the
packet to CE3 and CE1. In addition, PE2 sends a copy of the packet to PE1 through
the bypass VXLAN tunnel between PE1 and PE2. After the copy of the packet
reaches PE1, PE1 sends it to CE2, not to the CPE or CE1. In this way, CE1 receives
only one copy of the packet.
Figure 4-49 BUM packets from the CPE
CPE
VXLAN
VLAN
Trunk
CE2 CE1 CE3

– As shown in Figure 4-50, after a BUM packet from CE2 reaches PE1, PE1 sends a
copy of the packet to CE1 and the CPE. In addition, PE1 sends a copy of the packet
to PE2 through the bypass VXLAN tunnel between PE1 and PE2. After the copy of
the packet reaches PE2, PE2 sends it to CE3, not to the CPE or CE1.
Figure 4-50 BUM packets from CE2
CPE
VXLAN
CloudGW1 Anycast VTEP CloudGW2
VLAN
Trunk
CE2 CE1 CE3

– As shown in Figure 4-51, after a BUM packet from CE1 reaches PE1, PE1 sends a
copy of the packet to CE2 and the CPE. In addition, PE1 sends a copy of the packet
to PE2 through the bypass VXLAN tunnel between PE1 and PE2. After the copy of
the packet reaches PE2, PE2 sends it to CE3, not to the CPE or CE1.
Figure 4-51 BUM packets from CE1
CPE
VXLAN
VLAN
Trunk
CE2 CE1 CE3

l Layer 3 packets transmitted on the same subnet

– Uplink
As shown in Figure 4-47, after receiving Layer 3 unicast packets destined for the
CPE from CE1, CE2, and CE3, PE1 and PE2 search for the destination address and
directly forward them to the CPE because they are on the same network segment.
– Downlink
After the Layer 3 unicast packet sent from the CPE to CE1 reaches PE1, PE1
searches for the destination address and directly sends it to CE1 because they are on
the same network segment.
searches for the destination address and directly sends it to CE2 because they are on
the same network segment.
searches for the destination address and sends it to PE2, then sends it to CE3,
because they are on the same network segment.
l Layer 3 packets transmitted across subnets
– Uplink
Because the CPE is on a different network segment from PE1 and PE2, the
destination MAC address of a Layer 3 unicast packet sent from CE1, CE2, or CE3
to the CPE is the MAC address of the BDIF interface on the Layer 3 gateway of
PE1 or PE2. After receiving the packet, PE1 or PE2 removes the Layer 2 tag from
the packet, searches for a matching Layer 3 routing entry, and obtains the outbound
interface that is the BDIF interface connecting the CPE to the Layer 3 gateway. The
BDIF interface searches the ARP table, obtains the destination MAC address,
encapsulates the packet into a VXLAN packet, and sends it to the CPE through the
VXLAN tunnel.
After receiving the Layer 3 packet from PE1 or PE2, the CPE removes the Layer 2
tag from the packet because the destination MAC address is the MAC address of
the BDIF interface on the CPE. Then the CPE searches the Layer 3 routing table to
obtain a next-hop address to forward the packet.
– Downlink
Before sending a Layer 3 unicast packet to CE1 across subnets, the CPE searches its
Layer 3 routing table and obtains the outbound interface that is the BDIF interface
on the Layer 3 gateway connecting to PE1. The BDIF interface searches the ARP
table to obtain the destination MAC address, encapsulates the packet into a VXLAN
packet, and forwards it to PE1 over the VXLAN tunnel.
After receiving the packet from the CPE, PE1 removes the Layer 2 tag from the
packet because the destination address of the packet is the MAC address of PE1's
BDIF interface. Then PE1 searches the Layer 3 routing table and obtains the
outbound interface that is the BDIF interface connecting PE1 to its attached CE.
The BDIF interface searches its ARP table and obtains the destination address,
performs Layer-2 encapsulation for the packet, and sends it to CE1.

4.1.4.4 NFVI Distributed Gateway

Huawei's Network Function Virtualization Infrastructure (NFVI) telecommunications (telco)
cloud is a networking solution that incorporates Data Center Interconnect (DCI) and data
communication network (DCN) technologies. Mobile phone traffic enters the DCN and
accesses its virtualized unified gateway (vUGW) and virtual multiservice engine (vMSE).
After being processed by these, the phone traffic (IPv4 or IPv6) is forwarded over the Internet
through the DCN to the destination devices. Equally, response traffic sent over the Internet
from the destination devices to the mobile phones also undergoes this process. For this to take
place and to ensure that the traffic is balanced within the DCN, you need to deploy the NFVI
distributed gateway function on the DCN.
NOTE
The vUGW is a unified packet gateway developed based on Huawei's CloudEdge solution. It can be
used for 3rd Generation Partnership Project (3GPP) access in general packet radio service (GPRS),
Universal Mobile Telecommunications System (UMTS), and Long Term Evolution (LTE) modes. The
vUGW can function as a gateway GPRS support node (GGSN), serving gateway (S-GW), or packet data
network gateway (P-GW) to meet carriers' various networking requirements in different phases and
operational scenarios.
The vMSE is developed based on Huawei's multi-service engine (MSE). The carrier's network has
multiple functional boxes deployed, such as an external service awareness box, firewall box, video
acceleration box, packet header enhancement box, and URL filtering box. Adding any function is
implemented by installing a patch. As a result, the network gets slower, and service rollout and
maintenance become difficult. To solve this problem, the vMSE integrates the functions of these boxes
and manages them in a unified manner, providing value-added service processing for data services
initiated by subscribers.
Network Topology
Figure 4-52 shows the DCN on which the NFVI distributed gateway is deployed. DCGW1
and DCGW2 are the DCN's border gateways. The DCGWs exchange Internet routes with the
external network through the PEs. L2GW/L3GW1 and L2GW/L3GW2 access the virtualized
network functions (VNFs). VNF1 and VNF2 that function as virtualized NEs can be deployed
separately to implement the functions of the vUGW and vMSE. VNF1 and VNF2 are
connected to L2GW/L3GW1 and L2GW/L3GW2 through respective interface process units
(IPUs).

Figure 4-52 NFVI distributed gateway network
I n t e r n et
PE1 PE2
Bypass VXLAN Tunnel

Anycast VTEP
DCGW1 DCGW2
VX
DCN
l
BGP
ne
LA
Network
n
EVPN
Tu
BGP VPN
N
Tu
N
LA
nn
VX
el
L2GW/ L2GW/
L3GW1 L3GW2
VXLAN Tunnel
VPN
Static
IPU1 IPU2 IPU3 IPU4 IPU5
VNF1 VNF2
This networking can be considered a combination of the distributed gateway function and
VXLAN active-active/quad-active gateway function.
l The VXLAN active-active/quad-active gateway function is deployed on DC-GWs.
Specifically, a bypass VLAN tunnel is established between DC-GWs, and all DC-GWs
use the same virtual anycast VTEP address to establish VXLAN tunnels with L2GW/
L3GW1 and L2GW/L3GW2, respectively.
l The distributed gateway function is deployed on L2GW/L3GW1 and L2GW/L3GW2,
and a VXLAN tunnel is established between them.

NOTE
When the NFVI distributed gateway is used, the NE40E functions as either a DCGW or an L2GW/
L3GW. However, if the NE40E is used as an L2GW/L3GW, east-west traffic cannot be balanced.
Each L2GW/L3GW in Figure 4-52 represents two devices on the live network. EVPN VXLAN active-
active is configured on the devices to function as one, which improves network reliability.
The method of deploying the VXLAN quad-active gateway function on DC-GWs is similar to that of
deploying the VXLAN active-active gateway function on DC-GWs. This section describes how to
deploy the VXLAN active-active gateway function.
Function Deployment
On the network shown in Figure 4-52, the number of bridge domains (BDs) must be planned
according to the number of network segments the IPUs belong to. For example, if five IP
addresses planned for five IPUs can be allocated to four network segments, you need to plan
four different BDs. You also need to configure all BDs and VBDIF interfaces on each of the
DCGWs and L2GW/L3GWs, and bind all VBDIF interfaces to the same L3VPN instance. In
addition, the following functions have to be deployed on the network:
l A VPN BGP peer relationship is set up between a VNF and DCGW so that the VNF can
advertise mobile phone routes (to the IP address of a piece of user equipment (UE)) to
the DCGW.
l Static VPN routes are configured on L2GW/L3GW1 and L2GW/L3GW2 to connect to
the VNFs. The routes' destination IP addresses are the VNFs' IP addresses, and the next
hops are the IP addresses of the IPUs.
l A BGP EVPN peer relationship is established (full-mesh) between any two of the
DCGWs and L2GW/L3GWs. An L2GW/L3GW can flood static routes to the VNFs to
other devices through BGP EVPN peer relationships. A DCGW can advertise local
loopback routes and default routes to the L2GW/L3GWs through the BGP EVPN peer
relationships.
l Traffic between a mobile phone and the Internet that is forwarded through a VNF is
called north-south traffic, whereas the traffic between VNF1 and VNF2 is called east-
west traffic. To balance both of these, you need to configure load balancing on the
DCGWs and L2GW/L3GWs.
Generation of Forwarding Entries

On the NFVI distributed gateway network, all traffic is forwarded in Layer 2 mode from a
DCGW to a VNF after entering the DCN, regardless of whether it is from mobile phones to
the Internet or vice versa. However, after it leaves the DCN, traffic is forwarded in Layer 3
mode from the VNF to the DCGW. This prevents a traffic loop between the DCGW and
L2GW/L3GW. In Figure 4-53, IPUs are connected to multiple Layer 2 or Layer 3 gateways.
If traffic from DCGWs to VNFs is forwarded at Layer 3, some traffic from a Layer 2 or Layer
3 gateway to a VNF is forwarded to another Layer 2 or Layer 3 gateway for load balancing.
Similarly, Layer 2 or Layer 3 gateway 2 forwards traffic to Layer 2 or Layer 3 gateway 1,
resulting in a traffic loop. If Layer 2 forwarding is used, a Layer 2 or Layer 3 gateway does
not forward Layer 2 traffic received from another Layer 2 or Layer 3 gateway back to the
gateway, preventing loops.

Figure 4-53 Traffic loop

L2GW/ L2GW/
L3GW1 L3GW2
VXLAN Tunnel
IPU3 IPU4 IPU5
VNF2
Forwarding entries are generated on the DCGW and L2GW/L3GW through the following
process:
1. BDs are deployed on the L2GW/L3GW and bound to the links that are connected to the
IPUs on the associated network segments. Then, VBDIF interfaces are configured as the
gateways of the IPUs. The number of BDs is the same as the number of network
segments to which the IPUs belong. A static VPN route is configured on the L2GW/
L3GW so that the L2GW/L3GW can generate a route forwarding entry. The route's
destination address is a VNF's destination address, the next hop is the IP address of an
IPU, and the outbound interface is the associated VBDIF.
Figure 4-54 Static route forwarding entries on the L2GW/L3GW

Destination Outbound
Next hop
address interface
VNF IP IPU IP VBDIF
L2GW/
L3GW
IPU
VNF
2. The L2GW/L3GW learns the MAC address and ARP information of an IPU through the
data plane, and then advertises the information to the DCGW through an EVPN route.
The information is then used to generate an ARP entry and MAC forwarding entry for
Layer 2 forwarding.
– The destination MAC addresses in MAC forwarding entries on the L2GW/L3GW
are the MAC addresses of the IPUs. For the IPUs directly connected to an L2GW/
L3GW (for example, in Figure 4-52, IPU1, IPU2, and IPU3 directly connected to
L2GW/L3GW1), the IPUs are used as the outbound interfaces in the MAC
forwarding entries. For the IPUs connected to the other L2GW/L3GW (IPU4 and
IPU5 connected to L2GW/L3GW2 in Figure 4-52), the MAC forwarding entries
have a next hop, which is the VTEP address of L2GW/L3GW2, and carry the L2
VNI used for Layer 2 forwarding.
– The destination MAC address in the DCGW's MAC forwarding entry is the MAC
address of an IPU and, the next hop is the VTEP address of the L2GW/L3GW. The
MAC forwarding entry also stores the L2 VNI information of the corresponding
BD.

NOTE
For incoming traffic to be forwarded only at Layer 2, you are advised to configure devices so that
they only advertise ARP (ND) routes to each other. In this way, the DCGW and L2GW/L3GW do
not generate IP prefix routes based on IP addresses. If the devices are configured to advertise IRB
(IRBv6) routes to each other, enable the IRB asymmetric mode on the devices that receive routes.
Figure 4-55 MAC forwarding entries on the DCGW and L2GW/L3GW

DCGW
ARP entry
Outbound
IP MACinterface
IPU IP IPU MAC VBDIF
MAC entry
VXLAN Tunnel
MAC VTEP VNI

L2GW/
IPU MAC L2 VNI
L3GW IP
ARP entry
IP MAC Interface/VTEP IP
IPU or L2GW/
IPU IP IPU MAC
L3GW IP
L2GW/
L3GW MAC entry
MAC Interface/VTEP IP VNI

IPU
IPU or L2GW/
IPU MAC L2 VNI
L3GW IP
VNF
3. After static VPN routes are configured on the L2GW/L3GW, they are imported into the
BGP EVPN routing table and then sent in IP prefix routes to the DCGW through the
BGP EVPN peer relationship.
NOTE
Multiple links and static routes exist between the L2GW/L3GW and VNF. To implement load
balancing, you need to enable the Add-Path function when importing static routes into the BGP
EVPN routing table.
4. By default, the next hop address of an IP prefix route received by the DCGW is the IP
address of the L2GW/L3GW, and the route recurses to the VXLAN tunnel. In this case,
incoming traffic is forwarded at Layer 3. To forward incoming traffic at Layer 2, a route
policy must be configured on the L2GW/L3GW to add the Gateway IP attribute to the
static routes destined for the DCGW. Gateway IP addresses are the IP addresses of the
IPU interfaces. After receiving an IP prefix route carrying the Gateway IP attribute, the
DCGW does not recurse the route to the VXLAN tunnel. Instead, it performs IP
recursion. As a result, the destination address of a route forwarding entry on the DCGW
is the IP address of the VNF, the next hop is the IP address of an IPU interface, and the
outbound interface is the VBDIF interface corresponding to the network segment on

which the IPU resides. If traffic needs to be sent to the VNF, the forwarding entry can be
used to find the corresponding VBDIF interface, which then can be used to find the
corresponding ARP entry and MAC entry for Layer 2 forwarding.
Figure 4-56 Forwarding entries on the DCGW and L2GW/L3GW

Next hop
address interface
VNF IP IPU IP VBDIF
DCGW
ARP entry
Outbound
IP MACinterface
MAC entry
VXLAN Tunnel
MAC VTEP VNI

L2GW/
IPU MAC L2 VNI
L3GW IP
ARP entry
IPU or L2GW/
IPU IP IPU MAC
L3GW IP
L2GW/
L3GW MAC entry

IPU
IPU or L2GW/
IPU MAC L2 VNI
L3GW IP
VNF
5. To establish a VPN BGP peer relationship with the VNF, the DCGW needs to advertise
its loopback address to the L2GW/L3GW. In addition, because an anycast VTEP address
is used to establish a VXLAN tunnel between the DCGW and L2GW/L3GW, the VNF1-
to-DCGW1 loopback protocol packets may be sent to DCGW2. Therefore, DCGW1
needs to advertise its loopback address to DCGW2. Finally, each of the DCGWs and
L2GW/L3GWs has a forwarding entry for the VPN route to the loopback address of
DCGW1. After the VNF and DCGW establish a BGP peer relationship, the VNF can
send mobile phone routes to the DCGW. The routes' next hop is the VNF's IP address.


Destination
Next hop
address
UE IP VNF IP
Next hop
address interface
VNF IP IPU IP VBDIF
DCGW
ARP entry
Outbound
IP MACinterface
MAC entry
VXLAN Tunnel
MAC VTEP VNI

L2GW/
IPU MAC L2 VNI
L3GW IP
ARP entry
IPU or L2GW/
IPU IP IPU MAC
L3GW IP
L2GW/
L3GW MAC entry

IPU
IPU or L2GW/
IPU MAC L2 VNI
L3GW IP
VNF
6. The DCN does not need to sense external routes. Therefore, a route policy must be
configured on the DCGW so that the DCGW can send default routes and loopback routes
to the L2GW/L3GW.


Destination
Next hop
address
UE IP VNF IP
Next hop
address interface
VNF IP IPU IP VBDIF
DCGW
ARP entry
Outbound
IP MACinterface
MAC entry
VXLAN Tunnel
MAC VTEP VNI
L2GW/
IPU MAC L2 VNI
L3GW IP
ARP entry
Destination
Next hop VNI IP MAC Interface/VTEP IP
address
0.0.0.0/0 DCGW L3 VNI IPU or L2GW/
IPU IP IPU MAC
L3GW IP
L2GW/
L3GW MAC entry

IPU
IPU or L2GW/
IPU MAC L2 VNI
L3GW IP
VNF
7. As the border gateway of the DCN, the DCGW can exchange Internet routes with
external PEs, such as routes to Internet server IP addresses.


Destination
Next hop
address
UE IP VNF IP
Next hop
address interface
Destination
Next hop VNF IP IPU IP VBDIF
address DCGW
Internet IP PE IP
ARP entry
Outbound
IP MACinterface
MAC entry
VXLAN Tunnel
MAC VTEP VNI
L2GW/
IPU MAC L2 VNI
L3GW IP
ARP entry
Destination
Next hop VNI IP MAC Interface/VTEP IP
address
0.0.0.0/0 DCGW L3 VNI IPU or L2GW/
IPU IP IPU MAC
L3GW IP
L2GW/
L3GW MAC entry

IPU
IPU or L2GW/
IPU MAC L2 VNI
L3GW IP
VNF
8. To implement load balancing during traffic transmission, load balancing and Add-Path
can be configured on the DCGW and L2GW/L3GW. This balances both north-south and
east-west traffic.
– North-south traffic balancing: Take DCGW1 in Figure 4-52 as an example.
DCGW1 can receive EVPN routes to VNF2 from L2GW/L3GW1 and L2GW/
L3GW2. By default, after load balancing is configured, DCGW1 sends half of the
DCGW1-VNF2 traffic to each of L2GW/L3GW1 and L2GW/L3GW2. However,
although L2GW/L3GW2 has two links to VNF2, L2GW/L3GW1 only has one. As
a result, the traffic is not evenly balanced. To address this issue, the Add-Path
function must be configured on L2GW/L3GW2. After Add-Path is configured,
L2GW/L3GW2 advertises the two routes with the same destination address to
DCGW1 to implement load balancing.
– East-west traffic balancing: Take L2GW/L3GW1 in Figure 4-52 as an example.
Because Add-Path is configured on L2GW/L3GW2, L2GW/L3GW1 receives two
EVPN routes from L2GW/L3GW2. In addition, L2GW/L3GW1 has a static route
with the next hop being IPU3. The destination address of these three routes is the IP

address of VNF2. To implement load balancing, load balancing among static and
EVPN routes must be configured.
Traffic Forwarding Process

Figure 4-60 shows the process of forwarding north-south traffic (from a mobile phone to the
Internet).
Figure 4-60 Process of forwarding north-south traffic (from a mobile phone to the Internet)
1 DIP: VNF IP
SIP: Node IP
DIP: Internet IP
SIP: UE IP
DIP: Internet IP Data
SIP: UE IP
DCGW
Data
2 VTEP:L2GW/
6 L3GW IP
L2 VNI
DMAC:
IPU MAC
VTEP: DCGW IP SMAC:
DCGW MAC
VXLAN Tunnel
L3 VNI DIP: VNF IP

DMAC: DCGW
SIP: Node IP
MAC
SMAC: DIP: Internet IP
L2GWL3GW SIP: UE IP
MAC
DIP: Internet IP Data
SIP: UE IP
Data
3 DMAC:
IPU MAC
DIP: Internet IP 5
SMAC:
SIP: UE IP L2GW/ DCGW MAC
Data L3GW DIP: VNF IP
SIP: Node IP
IPU DIP: Internet IP
SIP: UE IP
VNF Data
The traffic forwarding process is as follows:

1. Traffic is sent to the base station (Node), where it is encapsulated into a GPRS tunneling
protocol (GTP) tunnel. The tunnel's destination address is the VNF's IP address. The
encapsulated packets reach the DCGW through IP forwarding.
2. Upon receipt, the DCGW searches the virtual routing and forwarding (VRF) table and
finds that the next hop of the forwarding entry that corresponds to VNF's IP address is an

IPU's IP address. It also finds that the outbound interface is a VBDIF interface.
Therefore, the received packets match the network segment on which the VBDIF
interface resides. The DCGW searches for the desired ARP entry on the network
segment, finds the MAC forwarding entry based on the ARP entry, and recurses the
packets to the VXLAN tunnel based on the MAC forwarding entry. Then, the packets are
forwarded to L2GW/L3GW.
3. Upon receipt, the L2GW/L3GW finds the target BD based on the L2 VNI, searches for
the MAC forwarding entry in the BD, and then forwards the packets to VNF based on
the MAC forwarding entry.
4. After the packets reach the VNF, the VNF decapsulates them in the GTP tunnel, searches
the routing table based on their destination IP address, and forwards them to L2GW/
L3GW through the VNF's default gateway.
5. After the packets reach the L2GW/L3GW, the system searches the VRF table on the
L2GW/L3GW. Over the default route advertised by the DCGW to the L2GW/L3GW, the
packets are encapsulated with the L3 VNI and then forwarded to the DCGW through the
VXLAN tunnel.
6. When the packets reach the DCGW, the system finds and uses the corresponding VPN
route forwarding entry to forward the packets to the Internet based on the L3 VNI.
Figure 4-61 shows the process of forwarding north-south traffic (from the Internet to the
mobile phone through the VNF).

Figure 4-61 Process of forwarding north-south traffic (from the Internet to a mobile phone)
DIP: Node IP
SIP: VNF IP
DIP: UE IP
1
SIP: Internet IP
DIP: UE IP Data
SIP: Internet IP
DCGW 6
Data
VTEP:DCGW
Anycast IP
L3 VNI
2
DMAC:
DCGW MAC
SMAC:
VTEP: L2GWL3GW
L2GWL3GW IP MAC
VXLAN Tunnel
L2 VNI DIP: Node IP

DMAC: SIP: VNF IP
IPU MAC DIP: UE IP
SMAC: SIP: Internet IP
DCGW MAC
DIP: UE IP Data
SIP: Internet IP
Data
3
5
DIP: UE IP
SIP: Internet IP L2GW/
Data L3GW DIP: Node IP
SIP: VNF IP
IPU DIP: UE IP
SIP: Internet IP
VNF Data
1. A device on the Internet sends response traffic to a mobile phone. The destination
address of the response traffic is the destination address of the mobile phone route. The
mobile phone route is advertised by the VNF to the DCGW through the VPN BGP peer
relationship, and the DCGW advertises the route to the Internet. Therefore, the response
traffic must first be forwarded to the VNF.
2. After receiving the response packets, the DCGW searches the routing table for
forwarding entries for the mobile phone routes. The routes come from the VPN BGP
peer relationship between the DCGW and VNF. These routes recurse to one or more
VBDIF interfaces, and traffic is balanced to these VBDIF interfaces. ARP information is
searched on the VBDIF interfaces, and MAC forwarding entries are found. Based on the
MAC forwarding entries, the response packets are encapsulated with the L2 VNI,
redirected to the VXLAN tunnel through recursion, and then forwarded to the L2GW/
L3GW.

3. Upon receipt, the L2GW/L3GW finds the BD based on the L2 VNI, searches for the
target MAC forwarding entry in the BD, obtains the outbound interface according to the
MAC information, and forwards the packets to the VNF.
4. Upon receipt, the VNF processes the packets, finds the base station corresponding to the
destination address of the mobile phone, encapsulates the tunnel information with the
base station as the destination, and forwards the packets to the L2GW/L3GW through the
default gateway.
5. Upon receipt, the L2GW/L3GW searches the VRF table for the default route advertised
by the DCGW to the L2GW/L3GW. Then, the L2GW/L3GW encapsulates the packets
with the L3 VNI and forwards them to the DCGW through the VXLAN tunnel.
6. Upon receipt, the DCGW searches the VRF table for the default (or specific) route based
on the L3 VNI so that the packets are forwarded to the destination base station. Then, the
base station decapsulates the packets and sends them to the target mobile phone.
During this process, the VNF may send the received packets to another VNF for value-added
service processing, based on the packet information. In this case, east-west traffic is
generated. Figure 4-62 shows the process of forwarding east-west traffic (from VNF1 to
VNF2), which differs from the north-south traffic forwarding process in packet processing
after packets reach VNF1.
Figure 4-62 Process of forwarding east-west traffic (from VNF1 to VNF2)

Destination
address Next hop
VNF2 IP IPU3 IP
VNF2 IP IPU4 IP
VNF2 IP IPU5 IP
IPU IP MAC Interface/VTEP L2 VNI

IPU3 IP IPU3 MAC IPU3
IPU4 IP IPU4 MAC L2GW/L3GW2 IP L2 VNI1
IPU5 IP IPU5 MAC L2GW/L3GW2 IP L2 VNI2
L2GW/ VXLAN Tunnel L2GW/

L3GW1 L3GW2
VNF1 VNF2
Data
1. If VNF1 needs to send a received packet to VNF2 for processing, VNF1 re-encapsulates
the packet into the VXLAN tunnel and uses VNF2's IP address as the destination
address. The packet is then sent to the L2GW/L3GW over the default route.

2. Upon receipt, the L2GW/L3GW searches the VRF table and finds that multiple load-
balancing forwarding entries exist. The IPU is the outbound interface of some entries,
and the next hop of these entries is the L2GW/L3GW.
3. If the path to the other L2GW/L3GW (L2GW/L3GW2) is selected preferentially, the
packet is encapsulated with the L2 VNI, redirected to the VXLAN tunnel through
recursion, and forwarded to L2GW/L3GW2. L2GW/L3GW2 finds the target BD based
on the L2 VNI and the destination MAC address, and forwards the packet to VNF2.
4. Upon receipt, VNF2 processes the packet and forwards it to the Internet server. The
subsequent forwarding process is the same as the process for forwarding north-south
traffic.
4.1.5 Application Scenarios for VXLAN
4.1.5.1 Application for Communication Between Terminal Users on a VXLAN
Service Description
Currently, data centers are expanding on a large scale for enterprises and carriers, with
increasing deployment of virtualization and cloud computing. In addition, to accommodate
more services while reducing maintenance costs, data centers are employing large Layer 2
and virtualization technologies.
As server virtualization is implemented in the physical network infrastructure for data centers,
VXLAN, an NVO3 technology, has adapted to the trend by providing virtualization solutions
for data centers.
On the network shown in Figure 4-63, an enterprise has VMs deployed in different data
centers. Different network segments run different services. The VMs running the same service
or different services in different data centers need to communicate with each other. For
example, VMs of the financial department residing on the same network segment need to
communicate, and VMs of the financial and engineering departments residing on different
network segments also need to communicate.

Figure 4-63 Communication between terminal users on a VXLAN
IP core
network
Device 3
Layer 3 VXLAN
NVE gateway
VX
l
ne
LA
tun
N
N
tun
LA
ne
VX
l
NV E
E NV
Device 1 VXLAN tunnel Device 2
vSwitch vSwitch vSwitch vSwitch

VM1 VM2 VM3 VM4
Financial Engineering Financial Engineering
Server 1 Server 2 Server 3 Server 4

10.1.1.2/24 10.1.2.2/24 10.1.1.3/24 10.1.2.3/24
Feature Deployment
l Deploy Device 1 and Device 2 as Layer 2 VXLAN gateways and establish a VXLAN
tunnel between Device 1 and Device 2 to allow communication between terminal users
on the same network segment.
l Deploy Device 3 as a Layer 3 VXLAN gateway and establish a VXLAN tunnel between
Device 1 and Device 3 and between Device 2 and Device 3 to allow communication
between terminal users on different network segments.
Configure VXLAN on devices to trigger VXLAN tunnel establishment and dynamic learning
of ARP and MAC address entries. By now, terminal users on the same network segment and
different network segments can communicate through the Layer 2 and Layer 3 VXLAN
gateways based on ARP and routing entries.
4.1.5.2 Application for Communication Between Terminal Users on a VXLAN

and Legacy Network
Service Description
Currently, data centers are expanding on a large scale for enterprises and carriers, with
increasing deployment of virtualization and cloud computing. In addition, to accommodate
more services while reducing maintenance costs, data centers are employing large Layer 2
and virtualization technologies.

As server virtualization is implemented in the physical network infrastructure for data centers,
VXLAN, an NVO3 technology, has adapted to the trend by providing virtualization solutions
for data centers, allowing intra-VXLAN communication and communication between
VXLANs and legacy networks.
On the network shown in Figure 4-64, an enterprise has VMs deployed for the finance and
engineering departments and a legacy network for the human resource department. The
finance and engineering departments need to communicate with the human resource
department.
Figure 4-64 Communication between terminal users on a VXLAN and legacy network
IP core
network
Device 3
Layer 3 VXLAN
NVE
gateway
VX
l
ne
LA
tun
N
N
tun
LA
ne
VX
NV E
E NV
Device 1 Device 2
HR dept vSwitch
VM1 VM2
Financial Engineering
10.2.2.2/24 Server 2
10.2.1.2/24
Feature Deployment
Deploy Device 1 and Device 2 as Layer 2 VXLAN gateways and Device 3 as a Layer 3
VXLAN gateway. The VXLAN gateways are VXLANs' edge devices connecting to legacy
networks and are responsible for VXLAN encapsulation and decapsulation. Establish a
VXLAN tunnel between Device 1 and Device 3 and between Device 2 and Device 3 for
VXLAN packet transmission.
When the human resource department sends a packet to VM1 of the financial department, the
process is as follows:
1. Device 1 receives the packet and encapsulates it into a VXLAN packet before sending it
to Device 3.

2. Upon receipt, Device 3 decapsulates the VXLAN packet and removes the Ethernet
header in the inner packet, parses the destination IP address, and searches the routing
table for a next hop address. Then, Device 3 searches the ARP table based on the next
hop address to determine the destination MAC address, VXLAN tunnel's outbound
interface, and VNI.
3. Device 3 encapsulates the VXLAN tunnel's outbound interface and VNI into the packet
and sends the VXLAN packet to Device 2.
4. Upon receipt, Device 2 decapsulates the VXLAN packet, finds the outbound interface
based on the destination MAC address, and forwards the packet to VM1.
4.1.5.3 Application in VM Migration Scenarios
Service Description
Enterprises on data center networks deploy server virtualization to implement IT resource
integration, improve resource usage, and reduce network costs. With the wider deployment of
server virtualization, more VMs are running in physical servers, and more applications are
running in virtualization environments, which brings challenges to virtual networks.
On the network shown in Figure 4-65, an enterprise has two clusters in the data center:
engineering and finance departments in Cluster1 and the marketing department in Cluster2.
The computation space on Cluster1 is inadequate, whereas that on Cluster2 is not fully
utilized. The network administrator wants to migrate the engineering department to Cluster2
without affecting services.

Figure 4-65 Enterprise distribution networking
Network
NVE
NVE
VXLAN Tunnel
Device1 Device2
VSwitch VSwitch
VM VM VM VM VM VM VM
PG-Engineering PG-Finance PG-Marketing
Server1 Server2
Engineering (VLAN10):10.1.1.1/24
Finance (VLAN20):10.1.1.1/24
Marketing (VLAN30):10.1.1.2/24
Feature Deployment
To ensure that services are not interrupted during the migration of the engineering department,
the IP and MAC addresses of the engineering department must remain unchanged. This
requires that the two Servers belong to the same Layer 2 network. Conventional methods
would require additional physical devices for traffic distribution and may also result in
network loops and additional system and management costs.
VXLAN can be used to migrate the engineering department to Server2. VXLAN is a network
virtualization technique that uses MAC-in-UDP encapsulation. All terminal users that are
reachable at Layer 3 can construct a large Layer 2 network as long as the physical network
supports IP forwarding.
VXLAN allows the engineering department to migrate, whereas the network is unaware of it.
After the engineering department is migrated from Cluster1 to Cluster2, tenants send
gratuitous ARP or RARP packets. The MAC address and ARP tables of VMs pre-migration
saved on gateways are replaced by new MAC address and ARP tables of VMs post-migration.
4.1.5.4 Application for BRAS Access Through VXLAN

As virtual networks develop, if device resources become insufficient for processing access
user traffic, traffic can be load balanced to virtual BRASs in data centers. Specifically, a
device can establish a VXLAN tunnel with a virtual BRAS for user access.
BRAS access can be implemented through a VXLAN tunnel or through a PW and a VXLAN
tunnel.

BRAS Access Through a VXLAN Tunnel
Figure 4-66 Configuring BRAS access through a VXLAN tunnel

Outer Ethernet header
Outer IP header
Inner Ethernet
Outer UDP header Inner Ethernet
header
header
Inner IP header VXLAN header
Inner IP header
Inner Ethernet header
Payload
Inner IP header Payload
Pay-load
VXLAN Tunnel Internet
PC OLT Device BRAS
On the network shown in Figure 4-66, the device deployed at the network edge establishes a
VXLAN tunnel with a virtual BRAS for user access.
1. After a user terminal starts or an IPoE, PPPoE, or L2TP user dials up, the terminal sends
an access message, which is relayed to the edge device through an optical line terminal
(OLT).
2. The edge device encapsulates the access message with a VXLAN header to form a
VXLAN packet and transparently transmits it to the BRAS through a VXLAN tunnel.
3. The BRAS removes the VXLAN header of the received VXLAN packet and processes
the access message.
BRAS Access Through a PW and a VXLAN Tunnel
Figure 4-67 Configuring BRAS access through a PW and a VXLAN tunnel

OLT1 Device1 Device2
PC1 BRAS1
PW
VXLAN Tunnel
PW
VRRP Internet
VXLAN Tunnel
PW
PC2 OLT2 Device3 Device4 BRAS2
Master Device
Backup Device
On the network shown in Figure 4-67, a VPLS network and a VXLAN network intersect at
Device 2 and Device 4 for BRAS access. The user access implementation is as follows:

1. After a user terminal starts or an IPoE, PPPoE, or L2TP user dials up, the terminal sends
an access message, which is relayed to edge devices (Device 1 and Device 3) through
OLTs.
2. Device 1 and Device 3 create a VSI for each OLT so that each OLT is identified by a
VSI. Device 1 through Device 4 internetwork using VPLS.
3. Device 2 and Device 4 back up each other, with Device 2 the master and Device 4 the
backup. VSIs are mapped to VXLAN VNIs in 1:1 mode. Device 2 and Device 4 have the
same VTEP IP address configured to exchange packets between the PW and VXLAN
tunnel.
4. Device 2 and Device 4 have a VRRP backup group configured to implement link
protection in case the link between Device 2 and BRAS 1 fails.
5. VRRP is associated with the virtual VTEP's route priority on the Device 2 and Device 4
interfaces connecting to the BRASs, and the route priority of the virtual VTEP on the
master device is higher than that of the virtual VTEP on the backup device. Downstream
VXLAN traffic of the BRASs is transmitted through the master device. After
downstream traffic is transmitted to Device 1 and Device 3, their MAC address entries
are updated for guiding upstream traffic to the master device.
6. VRRP is associated with PWs on the Device 2 and Device 4 interfaces connecting to the
BRASs so that the PW interface of the backup device does not receive or forward
VXLAN traffic. User access packets are broadcast to both Device 2 and Device 4 in the
VSI. Because PW packets are blocked on the backup device, only the master device
forwards the user access packets.
7. VRRP is associated with the Device 2 and Device 4 interfaces connecting to the VPLS
network. If link S on the VPLS network fails, protection switching is performed.
8. Device 2 and Device 4 establish VXLAN tunnels with the BRASs for VXLAN packet
encapsulation and decapsulation, implementing BRAS access.
4.1.6 Terminology for VXLAN

Terms
Term Description
NVO3 Network Virtualization over L3. A network virtualization technology

implemented at Layer 3 for traffic isolation and IP independence
between multi-tenants of data centers so independent Layer 2 subnets
can be provided for tenants. In addition, NVO3 supports VM deployment
and migration on Layer 2 subnets of tenants.
VXLAN Virtual extensible local area network. An NVO3 network virtualization

technology that encapsulates data packets sent from VMs into UDP
packets and encapsulates IP and MAC addresses used on the physical
network in the outer headers before sending the packets over an IP
network. The egress tunnel endpoint then decapsulates the packets and
sends the packets to the destination VM.


Abbreviation
BD bridge domain
BUM broadcast, unknown unicast, and multicast
VNI VXLAN network identifier
VTEP VXLAN tunnel endpoints
4.2 VXLAN Configuration

This section describes how to configure VXLAN on devices, without any controller.
4.2.1 Overview of VXLAN

Background
Server virtualization is widely used in cloud computing scenarios and greatly reduces IT and
O&M costs in addition to improving service deployment flexibility. It allows a physical server
to be virtualized into multiple virtual machines (VMs), each of which functions as a host.
However, a great increase in the number of hosts causes the following problems:
l VM scale is limited by network specifications.
On a large Layer 2 network, data packets are forwarded at Layer 2 based on MAC
entries. However, the MAC table capacity is limited, which subsequently limits the
number of VMs.
l Network isolation capabilities are limited.
Most networks currently use VLANs to implement network isolation. However, the
deployment of VLANs on large-scale virtualized networks has the following limitations:
– The VLAN tag field defined in IEEE 802.1Q has only 12 bits and can support only
a maximum of 4094 VLANs, which cannot meet user identification requirements of
large Layer 2 networks.
– VLANs on legacy Layer 2 networks cannot adapt to dynamic network adjustment.
l VM migration scope is limited by the network architecture.
A running VM may need to be migrated to a new server due to resource issues on the
original server (for example, migration may be required if the CPU usage is too high, or
memory resources are inadequate). To ensure service continuity during VM migration,
the IP address of the VM must remain unchanged. Therefore, the service network must
be a Layer 2 network and provide multipathing redundancy backup and reliability.
VXLAN addresses the preceding problems on large Layer 2 networks.
l Eliminates VM scale limitations imposed by network specifications.

VXLAN encapsulates data packets sent from VMs into UDP packets and encapsulates IP
and MAC addresses used on the physical network into the outer headers. As a result, the
network is aware of only the encapsulated parameters and not the inner data. This
implementation greatly reduces the MAC address specification requirements of large
Layer 2 networks.
l Provides greater network isolation capabilities.
VXLAN uses a 24-bit network segment ID, called a VXLAN network identifier (VNI),
to identify users. This VNI is similar to a VLAN ID, but supports a maximum of 16M
VXLAN segments.
l Eliminates VM migration scope limitations imposed by network architecture.
VXLAN uses MAC-in-UDP encapsulation to extend Layer 2 networks. It encapsulates
Ethernet packets into IP packets for these Ethernet packets to be transmitted over routes,
and does not need to be aware of VMs' MAC addresses. Because there is no limitation
on Layer 3 network architecture, Layer 3 networks are scalable and have strong
automatic fault rectification and load balancing capabilities. This allows for VM
migration irrespective of the network architecture.

Related Concepts
Figure 4-68 VXLAN architecture
VBDIF
BD
NVE
VNI VTEP UDP 4789
IP2
IP Network VNI VNI
5020 5030
L3
Packet Device3 Gateway
VAP2 VAP3
VLAN 20 Untag
L2
Device2
Gateway
Device1
NVE VSwitch
VSwitch VM1 VM2 ... VMm
VM1 ... VMm Untag
192.168.10.2/24
VLAN 10 VLAN 20
192.168.10.1/24 192.168.20.1/24
Server1 Server2
NVE
VXLAN Tunnel
Table 4-9 describes VXLAN concepts.

Table 4-9 VXLAN concepts

Concept Description
Underlay and VXLAN allows virtual Layer 2 or Layer 3 networks (overlay networks)
overlay to be built over existing physical networks (underlay networks).
networks Overlay networks use encapsulation technologies to transmit tenant
packets between sites over Layer 3 forwarding paths provided by
underlay networks. Tenants are aware of only overlay networks.
Network A network entity that is deployed at the network edge and implements
virtualization network virtualization functions.
edge (NVE) NOTE
vSwitches on devices and servers can function as NVEs.
VXLAN tunnel A VXLAN tunnel endpoint that encapsulates and decapsulates VXLAN
endpoint packets. It is represented by an NVE.
(VTEP) A VTEP connects to a physical network and is assigned a physical
network IP address. This IP address is irrelevant to virtual networks.
In VXLAN packets, the source IP address is the local node's VTEP
address, and the destination IP address is the remote node's VTEP
address. This pair of VTEP addresses corresponds to a VXLAN tunnel.
VXLAN A VXLAN segment identifier similar to a VLAN ID. VMs on different

network VXLAN segments cannot communicate directly at Layer 2.
identifier (VNI) A VNI identifies only one tenant. Even if multiple terminal users
belong to the same VNI, they are considered one tenant. A VNI
consists of 24 bits and supports a maximum of 16M tenants.
A VNI can be a Layer 2 or Layer 3 VNI.
l A Layer 2 VNI is mapped to a BD for intra-segment transmission of
VXLAN packets.
l A Layer 3 VNI is bound to a VPN instance for inter-segment
transmission of VXLAN packets.
Bridge domain A Layer 2 broadcast domain through which VXLAN data packets are
(BD) forwarded.
VNIs identifying VNs must be mapped to BDs so that a BD can
function as a VXLAN network entity to transmit VXLAN traffic.
VBDIF interface A Layer 3 logical interface created for a BD. Configuring IP addresses
for VBDIF interfaces allows communication between VXLANs on
different network segments and between VXLANs and non-VXLANs
and implements Layer 2 network access to a Layer 3 network.
Virtual access A Layer 2 sub-interface used to transmit data packets.

point (VAP) Layer 2 sub-interfaces can have different encapsulation types

Concept Description
Gateway A device that ensures communication between VXLANs identified by

different VNIs and between VXLANs and non-VXLANs.
A VXLAN gateway can be a Layer 2 or Layer 3 gateway.
l Layer 2 gateway: allows tenants to access VXLANs and intra-
segment communication on a VXLAN.
l Layer 3 gateway: allows inter-segment VXLAN communication and
access to external networks.
NVE Deployment Mode

On VXLANs, VTEPs are represented by NVEs, and therefore VXLAN tunnels can be
established after NVEs are deployed. The following NVE deployment modes are available
where NVEs are deployed.
l Hardware mode: On the network shown in Figure 4-69, all NVEs are deployed on NVE-
capable devices, which perform VXLAN encapsulation and decapsulation.
Figure 4-69 Hardware mode
L3 Network
NVE NVE NVE
Device1 Device2 Device3
vSwitch vSwitch VLAN 20

10.1.1.3/24
VM1 ... VMm ...
VM1 VMn
Physical Server
VLAN 10 Untag
10.1.1.1/24 10.1.1.2/24
Server1 Server2
l Software mode: On the network shown in Figure 4-70, all NVEs are deployed on
vSwitches, which perform VXLAN encapsulation and decapsulation.

Figure 4-70 Software mode
L3 Network
NVE NVE NVE

vSwitch vSwitch vSwitch
VLAN 10 VLAN 20 Untag

10.1.1.1/24 10.1.1.2/24 10.1.1.3/24
l Hybrid mode: On the network shown in Figure 4-71, some NVEs are deployed on
vSwitches, and others on NVE-capable devices. Both vSwitches and NVE-capable
devices may perform VXLAN encapsulation and decapsulation.
Figure 4-71 Hybrid mode
L3 Network
NVE
NVE NVE VLAN 20

vSwitch vSwitch 10.1.1.3/24
VM1 ... VMm VM1 ... VMm

Physical Server
VLAN 10 VLAN 20
10.1.1.1/24 10.1.1.2/24
Server1 Server2

NOTE
This document describes how to configure VXLAN when NVEs are deployed on NVE-capable devices.
If software mode is used, devices only need to transparently transmit VXLAN packets.
4.2.2 Licensing Requirements and Limitations for VXLAN

Item Requirement

VxLAN Function feature:
License This license
controls
VXLAN.

100G VxLAN feature:
Port License(per This license
100G) controls
VxLAN for a
100G interface
on the CM
board.

10G VxLAN Port feature:
License(per 10G) This license
controls
VxLAN for a
10G interface
on the CM
board.
If the number of existing Delete the unwanted None

VXLAN tunnels exceeds the VXLAN tunnels.
upper threshold, subsequent
VXLAN tunnels cannot be
established, and an alarm
message is sent to prompt
users the cause for the
establishment failure.

In the scenario where a None Multicast packets are

VXLAN tunnel is bound to discarded.
a VNI, the VNI is bound to
a BD, and a VBDIF
interface serves as a Layer 3
gateway, the VXLAN tunnel
does not support the
multicast function on the
VBDIF interface.
Only two VXLANv4 packet Prevent inter-board Error packets may exist.
fragments can reassembled reassembly during service
on the same board. Inter- planning.
board reassembly is not
supported.
Restrictions on VXLAN In VXLAN networking, the Fragmented packets cannot

packet fragmentation: MTU of a non-VXLAN be transmitted over the
VXLAN tunnels do not device is set to be 1500 or a VXLAN tunnel.
support the MTU smaller value, and the
configuration, and packets lengths of the packets are
entering VXLAN tunnels do limited within 1500 bytes.
not support fragmentation.
Restrictions of EVPN None None

control plane of VXLAN
networks are as follows:
l The BD, VNI, and
EVPN support only 1:1
binding mode.
l After a BD is bound to a
VNI, the BD can be
bound to an EVPN.
l Traffic statistics on VNI
+peer and VNIs are
using the same statistical
resource. As a result, the
two commands are
mutually exclusive.
Traffic statistics on VNI
+peer support only the
split-horizon-mode mode
of VNIs, and do not
support common VNIs.

Restrictions for the VXLAN None None

dual-active function are as
follows:
l Only Eth-Trunk access is
supported.
l The shutdown state of
sub-interfaces is not
supported.
l Scenarios where BDs are
shut down are not
supported.
l Scenarios where sub-
interfaces are unbound
from BDs are not
supported. (Two
interfaces where
VXLAN dual-active is
configured should have
the same configuration.)
l Dynamic ESIs and
dynamic VXLAN
tunnels are not
supported.
l When MAC FRR is
enabled, FRR for MAC
addresses need to be
learnt, which deletes
MAC addresses.
l A BD should be bound
to an EVPN to advertise
MAC routes before
being bound to an EVC
interface or static
VXLAN.
VXLAN and virtual access None None

are mutually exclusive.
VNI-based HQoS supports Configure HQoS based on Traffic control model is

only level-3 scheduling interfaces. incomplete.
(GQ, SQ, and FQ), and does
not support DP and VI level
scheduling.

If the number of existing Delete the unwanted None

VXLAN tunnels exceeds the VXLAN tunnels.
upper threshold, subsequent
VXLAN tunnels cannot be
established, and an alarm
message is sent to prompt
users the cause for the
establishment failure.
A UNI can be bound to only Plan a proper configuration. None

one service instance
(BD/VRF/EVPL).
VXLAN does not support Plan a proper configuration. DHCP snooping is not
DHCP snooping. supported by VXLAN.
When a distributed gateway Set the source address of the The ping fails.
is configured to a ping a ICMP echo-request packet
host address, the source to a non-gateway IP address
address of the ICMP echo- of the device.
request packet to be sent
should be set to a non-
gateway IP address of the
device.
After a BD accesses a VSI Plan a proper configuration. VBDIF interfaces are not
and a VXLAN network, no supported in the sceNonerio.
VBDIF interface can be
created.
After a BD accesses a VSI Plan a proper configuration. Layer 2 sub-interfaces are

and a VXLAN network, the not supported in the
BD cannot be bound to any sceNonerio.
Layer 2 sub-interface.
If an EVPN instance has Plan a proper configuration. None

been bound to a BD, the
binding of the EVPN
instance and the
corresponding VNI cannot
be modified or deleted.
4.2.3 Configuring VXLAN in Centralized Gateway Mode for

Static Tunnel Establishment
When VXLAN in centralized gateway mode for static tunnel establishment is deployed,
traffic across network segments is forwarded through Layer 3 VXLAN gateways to
implement centralized traffic management.

Usage Scenario
An enterprise has allocated VMs in different locations to a tenant. Some of the VMs reside on
the same network segment, and the others reside on different network segments. To allow
communication between VMs, deploy Layer 2 and Layer 3 VXLAN gateways and establish
VXLAN tunnels.
On the network shown in Figure 4-72, Server 2 and Server 3 belong to the same network
segment and access the VXLAN through Device 1 and Device 2, respectively; Server 1 and
Server 2 belong to different network segments and both access the VXLAN through Device 1.
l To allow VM 1 on Server 2 and VM 1 on Server 3 to communicate, deploy Layer 2
VXLAN gateways on Device 1 and Device 2 and establish a VXLAN tunnel between
Device 1 and Device 2 so that tenants on the same network segment can communicate.
l To allow VM 1 on Server 1 and VM 1 on Server 3 to communicate, deploy a Layer 3
VXLAN gateway on Device 3 and establish a VXLAN tunnel between Device 1 and
Device 3 and between Device 2 and Device 3 so that tenants on different network
segments can communicate.
Either IPv4 or IPv6 addresses can be configured for VMs and Layer 3 VXLAN gateways.
This means that a VXLAN overlay network can be an IPv4 or IPv6 network. Figure 4-72
shows an IPv4 overlay network.
Figure 4-72 VXLAN in centralized gateway mode
non-VXLAN
networks
VXLAN L3 GW Device3
NVE
L3 Network
NVE NVE
Device1 Device2

10.1.1.1/24 10.2.1.2/24 10.2.1.1/24
VXLAN tunnel

Before configuring VXLAN in centralized gateway mode for static tunnel establishment,
ensure that the network is reachable at Layer 3.
Figure 4-73 Flowchart for configuring centralized VXLAN gateways
No Layer3 VXLAN gateway A Layer3 VXLAN gateway

is deployed. is deployed.
Configure a service access Configure a service access
point. point.
Configure a VXLAN tunnel. Configure a VXLAN tunnel.
Configure Static MAC Address Configure a Layer 3 VXLAN

Entries and MAC Address Limiting Gateway.
Configure Static MAC Address

Entries and MAC Address Limiting
Mandatory
Optional
NOTE
If only VMs on the same network segment need to communicate with each other, Layer 3 VXLAN
gateways do not need to be deployed. If VMs on different network segments need to communicate with
each other or VMs on the same network segment need to communicate with external networks, Layer 3
VXLAN gateways must be deployed.
The following table lists the differences between the centralized gateway configuration
procedures for an IPv4 overlay network and an IPv6 overlay network.
Differed Configuration IPv4 Overlay Network IPv6 Overlay Network
Task
Configuring a Layer 3 Configure an IPv4 address Configure an IPv6 address

VXLAN Gateway for a VBDIF interface. for a VBDIF interface.
4.2.3.1 Configuring a VXLAN Service Access Point

Layer 2 sub-interfaces are used for service access on VXLANs. These Layer 2 sub-interfaces
can have different encapsulation types configured to transmit various types of data packets. A
bridge domain (BD) is a broadcast domain. After a Layer 2 sub-interface is associated with a
BD, the sub-interface can transmit data packets through this BD.

Context
As shown in Table 4-10, Layer 2 sub-interfaces can have different encapsulation types
Table 4-10 Traffic encapsulation types

Traffic Description
Encapsulation
Type
dot1q This type of sub-interface accepts only packets with a specified tag.
When encapsulating an original packet to a VXLAN packet, this type
of sub-interface removes all the VLAN tags from the original packet.
When decapsulating a VXLAN packet, if the packet carries an inner
VLAN tag, the sub-interface replaces the tag with a specified tag
before forwarding the packet to the destination. If the packet does not
carry any inner VLAN tag, it adds a specified VLAN tag before
forwarding.
The dot1q traffic encapsulation type has the following restrictions:
l The VLAN ID encapsulated by a Layer 2 sub-interface cannot be
the same as that allowed to pass by the Layer 2 interface where
the sub-interface resides.
l The VLAN IDs encapsulated by a Layer 2 sub-interface and a
Layer 3 sub-interface cannot be the same.
untag This type of sub-interface accepts only untagged packets.

of sub-interface does not add any VLAN tag. When decapsulating a
VXLAN packet, if the packet carries an inner VLAN tag, the sub-
interface removes the VLAN tag before forwarding. For a QinQ
packet, the sub-interface removes only the outer VLAN tag.
The untag traffic encapsulation type has the following restrictions:
l The physical interface where the sub-interface resides must have
only default configurations.
l Only Layer 2 physical interfaces and Layer 2 Eth-Trunk interfaces
can have untag Layer 2 sub-interfaces created.
l Only one untag Layer 2 sub-interface can be created on a main
interface.

Traffic Description
Encapsulation
Type
default This type of sub-interface accepts all packets, irrespective of whether

the packets carry VLAN tags.
For VXLAN packet encapsulation or decapsulation, this type of sub-
interface does not perform any VLAN tag-related action on the
original packets, be it addition, replacement, or removal.
The default traffic encapsulation type has the following restrictions:
l The interface where the sub-interface resides must not be added to
any VLAN.
can have default Layer 2 sub-interfaces created.
l If default is configured for a Layer 2 sub-interface on a main
interface, the main interface cannot have other types of Layer 2
sub-interfaces configured.
qinq Packets received by this type of sub-interface carry two or more

VLAN tags. The sub-interface determines whether to accept the
packets based on the innermost two VLAN tags.
Configure a service access point on a Layer 2 gateway:
Procedure
A BD is created, and the BD view is displayed.
Step 3 (Optional) Run description description
A description is configured for the BD.
Step 4 Run quit
NOTE
Step 6 Run encapsulation { dot1q [ vid vid ] | default | untag | qinq [ vid pe-vid ce-vid { low-ce-
vid [ to high-ce-vid ] } ] }

A traffic encapsulation type is specified for the Layer 2 sub-interface.

The sub-interface is enabled to remove single or double VLAN tags from received packets.
If the received packets each carry a single VLAN tag, specify single.
If the traffic encapsulation type is specified as qinq in the preceding step using the
encapsulation qinq vid pe-vid ce-vid { low-ce-vid [ to high-ce-vid ] | default } command,
specify double.
NOTE
If a default Layer 2 sub-interface is added to a BD, no BDIF interface can be created for the BD.
Step 9 Run commit

----End
4.2.3.2 Configuring a VXLAN Tunnel

VXLAN uses MAC-in-UDP encapsulation to extend Layer 2 networks, allowing a large
number of tenant accesses to virtual networks.
Context
To ensure VXLAN packet forwarding, VXLAN tunnels must be configured on VXLAN
gateways.
Procedure
bd-id specified here must be the same as that of the BD created in Step 2 in Configuring a
Service Access Point.
Step 3 Run vxlan vni vni-id
A VNI is created and mapped to the BD.
When a VXLAN network and a VPLS network intersect, run the vxlan vni vni-id split-
horizon-mode command on the edge devices at the intersection of the two networks to create
a VNI and bind it to a BD, and configure split horizon for packet forwarding.
Step 4 Run quit

Step 5 Run interface nve nve-number
An NVE interface is created, and the NVE interface view is displayed.
Step 6 Run source ip-address
An IP address is configured for the source VTEP.
Either a physical interface's IP address or loopback interface address can be specified for a
source VTEP. Using the loopback interface address as the source VTEP's IP address is
recommended.
Step 7 Run vni vni-id head-end peer-list ip-address &<1-10>
After the ingress of a VXLAN tunnel receives broadcast, unknown unicast, and multicast
(BUM) packets, it replicates these packets and sends a copy to each VTEP in the ingress
replication list. The ingress replication list is a collection of remote VTEP IP addresses to
which the ingress of a VXLAN tunnel should send replicated BUM packets.
NOTE
BUM packet forwarding is implemented only using ingress replication. To establish a VXLAN tunnel
between a Huawei device and a non-Huawei device, ensure that the non-Huawei device also has ingress
replication configured. Otherwise, communication fails.
Step 8 (Optional) Run vxlan central-reassemble enable
Centralized inter-board reassembly is enabled on VXLAN tunnels.
Step 9 Run commit
----End
4.2.3.3 Configuring a Layer 3 VXLAN Gateway

This section describes how to configure a Layer 3 VXLAN gateway. To allow VMs on
different network segments to communicate, a Layer 3 VXLAN gateway must be deployed,
and the default gateway address of the VMs must be the IP address of the BDIF interface of
the Layer 3 gateway.
Procedure
A BDIF interface is created, and the BDIF interface view is displayed.
The BD ID specified must exist.
Step 3 Configure an IP address for the VBDIF interface to implement Layer 3 interworking.
l On IPv4 overlay networks, run ip address ip-address { mask | mask-length } [ sub ].
An IPv4 address is configured for the VBDIF interface.

l On IPv6 overlay networks, perform the following operations:

a. Run ipv6 enable
IPv6 is enabled for the VBDIF interface.
b. Run ipv6 address { ipv6-address prefix-length | ipv6-address/prefix-length }
Or, ipv6 address { ipv6-address prefix-length | ipv6-address/prefix-length } eui-64
A global unicast address is configured for the VBDIF interface.
Step 4 (Option) Run mac-address mac-address
An MAC address is configured for the BDIF interface.
Step 5 (Option) Run bandwidth bandwidth
The bandwidth is configured for the VBDIF interface.
Step 6 Run commit
----End
4.2.3.4 (Optional) Configuring Static MAC Address Entries and MAC Address
Limiting
Static MAC address entries can be configured for traffic forwarding, and MAC address
limiting can be configured to improve VXLAN security.
Context
After the source NVE on a VXLAN tunnel receives broadcast, unknown unicast, and
multicast (BUM) packets, the local VTEP sends a copy of the BUM packets to every VTEP in
the ingress replication list. Configuring static MAC address entries helps reduce broadcast
traffic and prevent unauthorized data access from bogus users.
The maximum number of MAC addresses that a device can learn can be configured to limit
the number of access users and prevent against attacks on MAC address tables. If the device
has learned the maximum number of MAC addresses allowed, no more addresses can be
learned. The device can also be configured to discard packets after learning the maximum
allowed number of MAC addresses, improving network security.
If Layer 3 VXLAN gateway does not need to learn MAC addresses of packets in a BD, MAC
address learning can be disabled from the BD to conserve MAC address entry resources. If
the network topology of a VXLAN becomes stable and MAC address entry learning is
complete, MAC address learning can also be disabled.
Configuring static MAC address entries and MAC address limiting applies to Layer 2
VXLAN gateways; disabling MAC address limiting applies to both Layer 2 and Layer 3
VXLAN gateways.
Procedure
l Configure a static MAC address entry.
a. Run system-view

b. Run mac-address static mac-address bridge-domain bd-id source source-ip-

address peer peer-ip vni vni-id
A static MAC address entry is configured.
c. Run commit
l Configure MAC address limiting.
a. Run system-view
*
c. Run mac-limit { action { discard | forward } | maximum max [ rate interval ] }
MAC address limiting is configured.
d. (Optional) Run mac-limit up-threshold up-threshold down-threshold down-
threshold
The threshold percentage of MAC addresses that have alarms generated and cleared
is configured.
e. Run commit
l Disable MAC address learning.
a. Run system-view
c. Run mac-address learning disable
MAC address learning is disabled.
d. Run commit
----End
4.2.3.5 Verifying the Configuration of VXLAN in Centralized Gateway Mode

After configuring VXLAN in centralized gateway mode for static tunnel establishment, check
VXLAN tunnel, VNI, and VBDIF interface information.
Prerequisites
VXLAN in centralized gateway mode has been configured for static tunnel establishment.
Procedure
l Run the display bridge-domain [ binding-info | [ bd-id [ brief | verbose | binding-
info ] ] ] command to check bridge domain configurations.
l Run the display interface nve [ nve-number | main ] command to check NVE interface
information.

tunnel information.
l Run the display vxlan vni [ vni-id [ verbose ] ] command to check VNI information.
l Run the display mac-address static bridge-domain bd-id command to check static
MAC address entries in a BD.
l Run the display mac-limit bridge-domain bd-id command to check MAC address
limiting configurations of a BD.
----End
4.2.4 Configuring VXLAN in Centralized Gateway Mode Using

BGP EVPN
When VXLAN in centralized gateway mode using BGP EVPN is deployed, traffic across
network segments is forwarded through Layer 3 VXLAN gateways to implement centralized
traffic management.
Usage Scenario
An enterprise has allocated VMs in different locations to a tenant. Some of the VMs reside on
the same network segment, and the others reside on different network segments. To allow
communication between VMs, deploy Layer 2 and Layer 3 VXLAN gateways and establish
VXLAN tunnels.
On the network shown in Figure 4-74, Server 2 and Server 3 belong to the same network
segment and access the VXLAN through Device 1 and Device 2, respectively; Server 1 and
Server 2 belong to different network segments and both access the VXLAN through Device 1.
l To allow VM 1 on Server 2 and VM 1 on Server 3 to communicate, deploy Layer 2
VXLAN gateways on Device 1 and Device 2 and establish a VXLAN tunnel between
Device 1 and Device 2 so that tenants on the same network segment can communicate.
l To allow VM 1 on Server 1 and VM 1 on Server 3 to communicate, deploy a Layer 3
VXLAN gateway on Device 3 and establish a VXLAN tunnel between Device 1 and
Device 3 and between Device 2 and Device 3 so that tenants on different network
Either IPv4 or IPv6 addresses can be configured for VMs and Layer 3 VXLAN gateways.

Figure 4-74 VXLAN in centralized gateway mode
non-VXLAN
networks
VXLAN L3 GW Device3
NVE
L3 Network
NVE NVE
Device1 Device2

10.1.1.1/24 10.2.1.2/24 10.2.1.1/24
VXLAN tunnel
Before configuring VXLAN in centralized gateway mode for static tunnel establishment,
ensure that the network is reachable at Layer 3.

Figure 4-75 Flowchart for configuring centralized VXLAN gateways

point. point.


Mandatory
Optional
NOTE
Task
Configuring a Layer 3 Configure an IPv4 address Configure an IPv6 address

VXLAN Gateway for a VBDIF interface. for a VBDIF interface.
4.2.4.1 Configuring a Service Access Point

Context


Traffic Description
Encapsulation
Type
forwarding.

interface.

any VLAN.

Traffic Description
Encapsulation
Type

Procedure
Step 4 Run quit
NOTE
specify double.

NOTE
Step 9 Run commit

----End

To allow VXLAN tunnel establishment using EVPN, establish a BGP EVPN peer
relationship, configure an EVPN instance, and configure ingress replication.
Context
In centralized VXLAN gateway scenarios, perform the following steps on the Layer 2 and
Layer 3 VXLAN gateways to use EVPN for establishing VXLAN tunnels:
1. Configure a BGP EVPN peer relationship. Configure VXLAN gateways to establish
BGP EVPN peer relationships so that they can exchange EVPN routes. If an RR has
been deployed, each VXLAN gateway only needs to establish a BGP EVPN peer
relationship with the RR.
2. (Optional) Configure an RR. The deployment of RRs reduces the number of BGP EVPN
peer relationships to be established, simplifying configuration. A live-network device
can be used as an RR, or a standalone RR can be deployed. Layer 3 VXLAN gateways
are generally used as RRs, and Layer 2 VXLAN gateways as RR clients.
3. Configure an EVPN instance. EVPN instances are used to receive and advertise EVPN
routes.
4. Configure ingress replication. After ingress replication is configured for a VNI, the
system uses BGP EVPN to construct a list of remote VTEPs. After a VXLAN gateway
receives BUM packets, its sends a copy of the BUM packets to every VXLAN gateway
in the list.
NOTE
Procedure
Step 1 Configure a BGP EVPN peer relationship.
A router ID is set.
3. Run peer ipv4-address as-number as-number
The peer device is configured as a BGP peer.

A source interface and a source address are specified to set up a TCP connection with the
BGP peer.
NOTE
When 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
5. (Optional) Run peer ipv4-address ebgp-max-hop [ hop-count ]
The maximum number of hops is set for an EBGP EVPN connection.
In most cases, a directly connected physical link must be available between EBGP
EVPN peers. If you want to establish EBGP EVPN peer relationships between indirectly
connected peers, run the peer ebgp-max-hop command. The command also can
configure the maximum number of hops for an EBGP EVPN connection.
NOTE
When the IP address of loopback interface to establish an EBGP EVPN peer relationship, run the
peer ebgp-max-hop (of which the value of hop-count is not less than 2) command. Otherwise, the
peer relationship fails to be established.

7. Run peer { group-name | ipv4-address } enable
The device is enabled to exchange EVPN routes with a specified peer or peer group.
8. Run peer { group-name | ipv4-address } advertise encap-type vxlan
The device is enabled to advertise EVPN routes that carry the VXLAN encapsulation
attribute to the peer.
9. (Optional) Run peer { group-name | ipv4-address } route-policy route-policy-name
{ import | export }
A routing policy is specified for routes received from or to be advertised to a BGP EVPN
peer or peer group.
After the routing policy is applied, the routes received from or to be advertised to a
specified BGP EVPN peer or peer group will be filtered, ensuring that only desired
routes are imported or advertised. This configuration helps manage routes and reduce
required routing entries and system resources.
10. (Optional) Run peer { group-name | ipv4-address } 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.
11. Run quit

12. Run quit
Step 2 (Optional) Configure a Layer 3 VXLAN gateway as an RR. If an RR is configured, each

VXLAN gateway only needs to establish a BGP EVPN peer relationship with the RR,
reducing the number of BGP EVPN peer relationships to be established and simplifying
configuration.


4. (Optional) Run peer { ipv4-address | group-name } next-hop-invariable
The device is prevented from changing the next hop address of a route when advertising
the route to an EBGP peer.
The device is configured as an RR and an RR client is specified.

6. Run undo policy vpn-target
The function to filter received EVPN routes based on VPN targets is disabled. If you do
not perform this step, the RR will fail to receive and reflect the routes sent by clients.
7. Run quit

8. Run quit
Step 3 Configure an EVPN instance.

A BD EVPN instance is created, and the EVPN instance view is displayed.


extcommunity ]
VPN targets are configured for the EVPN instance. The export VPN target of the local
end must be the same as the import VPN target of the remote end, and the import VPN
target of the local end must be the same as the export VPN target of the remote end.
The current EVPN instance is associated with an import routing policy.

The current EVPN instance is associated with an export routing policy.


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.
8. Run quit
9. Run bridge-domain bd-id
10. Run vxlan vni vni-id split-horizon-mode
A VNI is created and associated with the BD, and split horizon is applied to the BD.
11. 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.
12. Run quit
Step 4 Configure an ingress replication list.
1. Run interface nve nve-number
2. Run source ip-address
3. Run vni vni-id head-end peer-list protocol bgp
replication list. The ingress replication list is a collection of remote VTEP IP addresses
to which the ingress of a VXLAN tunnel should send replicated BUM packets.
4. Run quit
Step 5 Run commit
----End


To allow users on different network segments to communicate, a Layer 3 VXLAN gateway
must be deployed, and the default gateway address of the users must be the IP address of the
VBDIF interface of the Layer 3 gateway.
Context
A tenant is identified by a VNI. VNIs can be mapped to BDs in 1:1 mode so that a BD can
function as a VXLAN network entity to transmit VXLAN data packets. A VBDIF interface is
a Layer 3 logical interface created for a BD. After an IP address is configured for a VBDIF
interface of a BD, the VBDIF interface can function as the gateway for tenants in the BD for
Layer 3 forwarding. VBDIF interfaces allow Layer 3 communication between VXLANs on
different network segments and between VXLANs and non-VXLANs, and implement Layer
2 network access to a Layer 3 network.
VBDIF interfaces are configured on Layer 3 VXLAN gateways for inter-segment

communication, and are not needed in the case of intra-segment communication.
NOTE
The DHCP relay function can be configured on the VBDIF interface so that hosts can request IP
addresses from the external DHCP server.
Procedure
Step 3 Configure an IP address for the VBDIF interface to implement Layer 3 interworking.
l On IPv4 overlay networks, run ip address ip-address { mask | mask-length } [ sub ].
l On IPv6 overlay networks, perform the following operations:
a. Run ipv6 enable
b. Run ipv6 address { ipv6-address prefix-length | ipv6-address/prefix-length }
Or, ipv6 address { ipv6-address prefix-length | ipv6-address/prefix-length } eui-64
Step 4 (Optional) Run mac-address mac-address
Step 5 (Option) Run bandwidth bandwidth
Step 6 Run commit

----End
Limiting
Context
VXLAN gateways.
Procedure
a. Run system-view
c. Run commit
a. Run system-view
*


threshold
is configured.
e. Run commit
a. Run system-view
d. Run commit
----End
4.2.4.5 Verifying the Configuration of VXLAN in Centralized Gateway Mode

Using BGP EVPN
After configuring VXLAN in centralized gateway mode for dynamic tunnel establishment,
check VXLAN tunnel, VNI, and VBDIF interface information.
Prerequisites
VXLAN in centralized gateway mode has been configured for dynamic tunnel establishment.
Procedure
information.
l Run the display bgp evpn peer [ [ ipv4-address ] verbose ] command to check BGP
EVPN peer information.
l Run the display vxlan peer [ vni vni-id ] command to check ingress replication lists of a
VNI or all VNIs.
tunnel information.
l Run the display interface vbdif [ bd-id ] command to check VBDIF interface
information and statistics.
l Run the display mac-address limit bridge-domain bd-id command to check
dynamically learning MAC address limiting configurations of a BD.

l Run the display bgp evpn all routing-table command to check EVPN route
information.
----End
4.2.5 Configuring VXLAN in Distributed Gateway Mode Using

BGP EVPN
Distributed VXLAN gateways can be configured to address problems that occur in legacy
centralized VXLAN gateway networking, for example, forwarding paths are not optimal, and
the ARP entry specification is a bottleneck on Layer 3 gateways.
Usage Scenario
In legacy networking, a centralized Layer 3 gateway is deployed on a spine node. On the
network shown in Figure 4-76, packets across different networks must be forwarded through
a centralized Layer 3 gateway, resulting in the following problems:
l Forwarding paths are not optimal. All Layer 3 traffic must be transmitted to the
centralized Layer 3 gateway for forwarding.
l The ARP or ND entry specification is a bottleneck. ARP or ND entries must be
generated for tenants on the Layer 3 gateway. However, only a limited number of ARP
or ND entries can be configured for the Layer 3 gateway, impeding data center network
expansion.
Figure 4-76 Centralized VXLAN gateway networking

Layer 3 Spine 1 Spine 2
gateway
Layer 2
gateway
Leaf 1 Leaf 2
Server 1 Server 2
Server 3 Server 4
10.1.1.1/24 10.10.1.1/24
10.20.1.1/24 10.10.1.2/24
Inter-segment traffic
To address these problems, distributed VXLAN gateways can be configured. On the network
shown in Figure 4-77, Server 1 and Server 2 on different network segments both connect to
Leaf 1. When Server 1 and Server 2 communicate, traffic is forwarded only through Leaf 1,
not through any spine node.

Figure 4-77 Distributed VXLAN gateway networking

Spine 1 Spine 2
Layer 3
gateway
Leaf 1 Leaf 2
Layer 2
gateway
Server 1 Server 2 Server 3 Server 4

10.1.1.1/24 10.10.1.1/24 10.20.1.1/24 10.10.1.2/24
Inter-segment traffic
Distributed VXLAN gateway networking has the following characteristics:

l Flexible deployment. A leaf node can function as both Layer 2 and Layer 3 VXLAN
gateways.
l Improved network expansion capabilities. A leaf node only needs to learn the ARP or
ND entries of servers attached to it. A centralized Layer 3 gateway in the same scenario,
however, has to learn the ARP or ND entries of all servers on the network. Therefore, the
ARP or ND entry specification is no longer a bottleneck on a distributed VXLAN
gateway.
Either IPv4 or IPv6 addresses can be configured for the VMs and Layer 3 VXLAN gateway.
Before configuring VXLAN in distributed gateway mode, ensure that reachable routes are
available.

Figure 4-78 Flowchart for configuring distributed VXLAN gateways

point. point.


Mandatory
Optional
NOTE


Task
Configure a Layer 3 l During configuration of l During configuration of

VXLAN gateway. a VPN instance for route a VPN instance for route
exchange with an EVPN exchange with an EVPN
instance, enable the IPv4 instance, enable the IPv6
address family of the address family of the
VPN instance and then VPN instance and then
complete other complete other
configurations in the configurations in the
IPv4 address family IPv6 address family
view. view.
l Configure an IPv4 l Configure an IPv6
address for a VBDIF address for a VBDIF
interface of the Layer 3 interface of the Layer 3
VXLAN gateway. VXLAN gateway.
l Complete configurations l Complete configurations
of IP prefix route of IP prefix route
advertisement between advertisement between
VXLAN gateways in the VXLAN gateways in the
IPv4 address family view IPv6 address family view
of the BGP-VPN of the BGP-VPN
instance. instance.
l If VXLAN gateways l If VXLAN gateways
advertise IP prefix advertise IP prefix
routes, both host IP routes, only network
routes and network segment routes can be
segment routes can be advertised.
advertised. l If VXLAN gateways
l If VXLAN gateways advertise IRBv6 routes,
advertise IRB routes, run run the ipv6 nd collect
the arp collect host host enable command to
enable command to configure IPv6 host route
configure host route advertisement.
advertisement.
4.2.5.1 Configuring a Service Access Point

Context


Traffic Description
Encapsulation
Type
forwarding.

interface.

any VLAN.

Traffic Description
Encapsulation
Type

Procedure
Step 4 Run quit
NOTE
specify double.

NOTE
Step 9 Run commit

----End

To allow VXLAN tunnel establishment using EVPN, configure an EVPN instance, establish a
BGP EVPN peer relationship, and configure ingress replication.
Context
VXLAN packets are transmitted through VXLAN tunnels. In distributed VXLAN gateway
scenarios, perform the following steps on a VXLAN gateway to use EVPN for establishing
VXLAN tunnels:
1. Configure a BGP EVPN peer relationship. Configure VXLAN gateways to establish
BGP EVPN peer relationships so that they can exchange EVPN routes. If an RR has
been deployed, each VXLAN gateway only needs to establish a BGP EVPN peer
relationship with the RR.
2. (Optional) Configure an RR. The deployment of RRs reduces the number of BGP EVPN
peer relationships to be established, simplifying configuration. A live-network device
can be used as an RR, or a standalone RR can be deployed. Spine nodes are generally
used as RRs, and leaf nodes as RR clients.
3. Configure an EVPN instance. EVPN instances are used to receive and advertise EVPN
routes.
4. Configure ingress replication. After ingress replication is configured for a VNI, the
system uses BGP EVPN to construct a list of remote VTEPs. After a VXLAN gateway
receives BUM packets, its sends a copy of the BUM packets to every VXLAN gateway
in the list.
NOTE
Procedure
Step 1 Configure a BGP EVPN peer relationship. If an RR has been deployed, each VXLAN
gateway only needs to establish a BGP EVPN peer relationship with the RR. If the spine node
and gateway reside in different ASs, the gateway must establish an EBGP EVPN peer
relationship with the spine node.
A router ID is set.
3. Run peer ipv4-address as-number as-number

The peer device is configured as a BGP peer.

A source interface and a source address are specified to set up a TCP connection with the
BGP peer.
NOTE
When 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
5. (Optional) Run peer ipv4-address ebgp-max-hop [ hop-count ]
The maximum number of hops is set for an EBGP EVPN connection.
In most cases, a directly connected physical link must be available between EBGP
EVPN peers. If you want to establish EBGP EVPN peer relationships between indirectly
connected peers, run the peer ebgp-max-hop command. The command also can
configure the maximum number of hops for an EBGP EVPN connection.
NOTE
When the IP address of loopback interface to establish an EBGP EVPN peer relationship, run the
peer ebgp-max-hop (of which the value of hop-count is not less than 2) command. Otherwise, the
peer relationship fails to be established.
8. Run peer { ipv4-address | group-name } advertise encap-type vxlan
The device is enabled to advertise EVPN routes that carry the VXLAN encapsulation
attribute to the peer.
9. (Optional) Run peer { group-name | ipv4-address } route-policy route-policy-name
{ import | export }
A routing policy is specified for routes received from or to be advertised to a BGP EVPN
peer or peer group.
After the routing 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.
the route to an EBGP peer. If the spine node and gateway have established an EBGP
EVPN peer relationship, run the peer next-hop-invariable command to ensure that the
next hops of routes received by the gateway point to other gateways.
11. (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.
12. Run quit
13. Run quit
Step 2 (Optional) Configure an RR. If an RR is configured, each VXLAN gateway only needs to
establish a BGP EVPN peer relationship with the RR, reducing the number of BGP EVPN
peer relationships to be established and simplifying configuration.
the route to an EBGP peer.
The device is configured as an RR and an RR client is specified.
6. Run undo policy vpn-target
The function to filter received EVPN routes based on VPN targets is disabled. If you do
not perform this step, the RR will fail to receive and reflect the routes sent by clients.
7. Run quit
8. Run quit
Step 3 Configure an EVPN instance.
A BD EVPN instance is created, and the EVPN instance view is displayed.
extcommunity ]
VPN targets are configured for the EVPN instance. The export VPN target of the local
end must be the same as the import VPN target of the remote end, and the import VPN
target of the local end must be the same as the export VPN target of the remote end.


The current EVPN instance is associated with an import routing policy.
To control route import more precisely, perform this step to associate the EVPN instance
with an import routing policy and set attributes for eligible routes.
The current EVPN instance is associated with an export routing policy.
To control route export more precisely, perform this step to associate the EVPN instance
This configuration enables PEs to use TE tunnels to transmit data packets.
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.
8. Run quit
By default, no BD is created.
11. 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.
12. Run quit
3. Run vni vni-id head-end peer-list protocol bgp

replication list. The ingress replication list is a collection of remote VTEP IP addresses
to which the ingress of a VXLAN tunnel should send replicated BUM packets.
4. Run quit
Step 5 (Optional) Configure MAC addresses for NVE interfaces.
In distributed VXLAN gateway (EVPN BGP) scenarios, if you want to use active-active
VXLAN gateways to load-balance traffic, configure the same VTEP MAC address on the two
VXLAN gateways. Otherwise, the two gateways cannot forward traffic properly on the
VXLAN network.
The NVE interface view is displayed.

2. Run mac-address mac-address
A MAC address is configured for the NVE interface.

3. Run quit
Exit from the NVE interface view.
Step 6 Run commit
----End

When distributed VXLAN gateways are deployed using BGP EVPN, Layer 3 VXLAN
gateways must be configured to implement inter-subnet communication.
Context
In distributed VXLAN gateway scenarios, inter-subnet communication between hosts requires
Layer 3 forwarding. To allow this, Layer 3 VXLAN gateways must learn host routes. Perform
the following operations on VXLAN gateways:
1. Configure a VPN instance whose routes can be installed into the routing table of the
EVPN instance. This VPN instance is used to store host routes or network segment
routes.
2. Bind the VPN instance to a Layer 3 VXLAN gateway, enable distributed gateway, and
configure host route advertisement.
3. Configure the type of route to be advertised between VXLAN gateways. VXLAN
gateways can send different information through different types of routes. If an RR is
deployed on the network, only the type of route to be advertised between the RR and
VXLAN gateways needs to be configured.

NOTE
If tenants on the same network segment connect to different Layer 3 VXLAN gateways, the Layer 3
VXLAN gateways must have the same IP address and MAC address configured. When tenants are
moved to a different location, the tenants can retain Layer 3 gateway configurations, reducing
maintenance workload.
Procedure
Step 1 Configure a VPN instance whose routes can be installed into the routing table of the EVPN
instance.
On IPv4 overlay networks, perform the following operations:
2. Run vxlan vni vni-id
A VNI is created and mapped to the VPN instance.
3. Run ipv4-family
extcommunity ]
VPN targets are configured for the VPN instance IPv4 address family.
A VPN target is the extended community attribute of BGP. It controls reception and
advertisement of VPN routes. A maximum of eight VPN targets can be configured each
time the vpn-target command is run. To configure more VPN targets for the VPN
instance IPv4 address family, run the vpn-target command several times.
extcommunity ] evpn
The routes advertised by the VPN instance IPv4 address family to an EVPN instance do
not carry the export VPN targets of the VPN instance IPv4 address family. Instead, the
routes carry all VPN targets in the export VPN target list configured for the EVPN
instance in the BD.
vpn-target specified here must be the same as the RT configured for the EVPN instance
in the BD view. This implementation ensures that routes in the VPN instance can be
installed into the routing table of the specified EVPN instance.
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.
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 attributes for eligible routes.
9. Run quit
The VPN instance IPv4 address family view is exited.

10. Run quit
The VPN instance view is exited.

On IPv6 overlay networks, perform the following operations:
1. Run system-view


3. Run vxlan vni vni-id
A VNI is created and mapped to the VPN instance.

4. Run ipv6-family

6. (Optional) Run vpn-target vpn-target &<1-8> [ both | export-extcommunity | import-
extcommunity ]
VPN targets are configured for the VPN instance IPv6 address family.
If the current node needs to exchange L3VPN routes with other nodes in the same VPN
instance, perform this step to configure a VPN target value for the VPN instance.
extcommunity ] evpn
VPN targets are configured for the VPN instance IPv6 address family for exchanging
routes with the EVPN instance. vpn-target specified must be the same as the RT of the
EVPN instance configured in the BD view.
The routes advertised by the VPN instance IPv6 address family to an EVPN instance do
not carry the export VPN targets of the VPN instance IPv6 address family. Instead, the
routes carry all VPN targets in the export VPN target list configured for the EVPN
instance in the BD.
The routes advertised by an EVPN instance can be added to the routing table of the VPN
instance IPv6 address family only when the VPN targets of the routes are carried in the
import VPN target list of the VPN instance IPv6 address family.
8. Run quit

9. Run quit

Step 2 Bind the VPN instance to a Layer 3 gateway, enable distributed gateway, and configure host
route advertisement.
1. Run interface vbdif bd-id

A VPN instance is bound to the VBDIF interface.

3. Configure an IP address for the VBDIF interface to implement Layer 3 interworking.
– On IPv4 overlay networks, run ip address ip-address { mask | mask-length }
[ sub ].
– On IPv6 overlay networks:
i. Run ipv6 enable
ii. Run ipv6 address { ipv6-address prefix-length | ipv6-address/prefix-length }
Or, ipv6 address { ipv6-address prefix-length | ipv6-address/prefix-length }
eui-64
If different Layer 3 gateways connect to the same network segment, the same IP address
must be configured for the VBDIF interfaces of these Layer 3 gateways.
4. (Optional) Run mac-address mac-address
By default, the MAC address of a VBDIF interface is the system MAC address. On a
network with distributed or multi-active VXLAN gateways that need to be simulated into
one, you need to run the mac-address command to configure the same MAC address for
the VBDIF interfaces of VXLAN Layer 3 gateways.
5. (Optional) Run bandwidth bandwidth

6. Run vxlan anycast-gateway enable
Distributed gateway is enabled.
NOTE
After distributed gateway is enabled on a Layer 3 gateway, the Layer 3 gateway discards network-
side ARP or NS packets and learns only user-side ARP or NS packets.
7. Perform either of the following steps to configure host route advertisement:
On IPv4 overlay networks:
– If VXLAN gateways advertise IRB routes to each other, run the arp collect host
enable command for host route advertisement.
– If VXLAN gateways advertise IP prefix routes to each other, run the arp vlink-
direct-route advertise [ route-policy route-policy-name | route-filter route-filter-
name command in the VPN instance view which was bound to the VBDIF interface
for host route advertisement.

When the overlay network is an IPv6 network, VXLAN gateways can be configured
only to advertise IRBv6 routes. In this case, the ipv6 nd collect host enable command
needs to be run.
NOTE
When the overlay network is an IPv6 network, if VXLAN gateways are configured to advertise IP
prefix routes, only network segment routes can be advertised currently, and host routes cannot be
advertised.
8. Run quit
Step 3 Configure the type of route to be advertised between VXLAN gateways. If an RR is deployed
on the network, only the type of route to be advertised between the RR and VXLAN gateways
needs to be configured.
NOTE
Host routes can be advertised through IRB routes, IP prefix routes, or both. IRB routes are
recommended. In contrast, network segment routes can be advertised only through IP prefix routes.

l Configure IRB route advertisement.
a. Run bgp as-number
c. Run peer { ipv4-address | group-name } advertise irb
IRB route advertisement is configured.
IRB routes can be used to advertise host IP routes as well as ARP entries. In
addition, host ARP entry advertisement allows VM migration in distributed
gateway scenarios. As such, configuring IRB route advertisement is recommended.
d. Run quit
e. Run quit
f. Run commit
l Configure IP prefix route advertisement.
b. Run ipv4-family vpn-instance vpn-instance-name
c. Run import-route { direct | isis process-id | ospf process-id | rip process-id |
static } [ med med | route-policy route-policy-name ] *
A type of route is imported to the BGP-VPN instance IPv4 address family view.
If host IP route advertisement is required, configure direct in the command. If
network segment route advertisement is required, use a dynamic routing protocol,

such as OSPF. Then, configure the BGP-VPN instance IPv4 address family to
import the routes of the dynamic routing protocol.
d. Run advertise l2vpn evpn
IP prefix route advertisement is configured.
IP prefix routes are used to advertise host IP routes as well as network segment
routes to which the host IP routes belong. If a large number of specific host routes
are available, configure IP prefix route advertisement so that the network segment
routes can be imported to the BGP-VPN instance IPv4 address family, sparing the
VXLAN gateways from storing all specific host routes.
NOTE
n A VXLAN gateway can advertise network segment routes only if the network segments
attached to the gateway are unique network-wide.
n After configuring IP prefix route advertisement, you must run the arp vlink-direct-
route advertise command for host route advertisement. Then, VM migration will be
affected. To avoid this problem, configure IRB route advertisement.
e. Run quit
f. Run quit
g. Run commit
l Configure IRBv6 route advertisement.

c. Run peer { ipv4-address | group-name } advertise irbv6
IRBv6 route advertisement is configured.
d. Run quit
e. Run quit
f. Run commit
l Configure IP prefix route advertisement.
b. Run ipv6-family vpn-instance vpn-instance-name
c. Run import-route { isis process-id | ospfv3 process-id | ripng process-id | static }
[ med med | route-policy route-policy-name ] *

Routes of other protocols are introduced to the IPv6 address family of the current
BGP-VPN instance.
To advertise routes on the IPv6 network segment where the host resides, use a
dynamic routing protocol (such as OSPFv3) to advertise routes on the network
segment and configure the dynamic routing protocol to import routes.
d. Run advertise l2vpn evpn
IP prefix route advertisement is configured.
e. Run quit
f. Run quit
g. Run commit
Step 4 Run commit
----End
Limiting
Context
VXLAN gateways.
Procedure

a. Run system-view
c. Run commit
a. Run system-view
*
threshold
is configured.
e. Run commit
a. Run system-view
d. Run commit
----End
4.2.5.5 Verifying the Configuration of VXLAN in Distributed Gateway Mode

Using BGP EVPN
After configuring VXLAN in distributed gateway mode using BGP EVPN, verify the
configuration, and you can find that VXLAN tunnels are dynamically established and are in
the Up state.
Prerequisites
VXLAN in distributed gateway mode has been configured using BGP EVPN.

Procedure
information.
VNI or all VNIs.
tunnel information.
information.
----End
4.2.6 Configuring Three-Segment VXLAN to Implement DCI

Three-Segment VXLAN can be configured to enable communication between VMs in
different DCs.
Usage Scenario
To meet the requirements of geographical redundancy, inter-regional operations, and user
access, an increasing number of enterprises are deploying data centers (DCs) across multiple
regions.Data Center Interconnect (DCI) is a solution that enables intercommunication
between the VMs of multiple DCs. Using technologies such as VXLAN and BGP EVPN,
DCI securely and reliably transmits DC packets over carrier networks. Three-segment
VXLAN can be configured to enable communications between VMs in different DCs.
Before configuring three-segment VXLAN to implement DCI, complete the following tasks:
l Configure an IGP in DCs.
4.2.6.1 Configuring Three-Segment VXLAN to Implement Layer 3 Interworking

The three-segment VXLAN can be configured to enable communications between inter-
subnet VMs in DCs that belong to different ASs.

Context
As shown in Figure 4-79, BGP EVPN must be configured to create VXLAN tunnels between
distributed gateways in each DC and to create VXLAN tunnels between leaf nodes so that the
inter-subnet VMs in DC A and DC B can communicate with each other.
When DC A and DC B belong to the same BGP AS, Leaf 2 or Leaf 3 does not forward EVPN
routes received from an IBGP EVPN peer to other IBGP EVPN peers. Therefore, it is
necessary to configure Leaf 2 and Leaf 3 as route reflectors (RRs).
Figure 4-79 Configuring the three-segment VXLAN tunnels
IP network
Device1 Device2
DC-A DC-B
Spine1 Spine2
Leaf2 Leaf3
（RR）（RR）
VMa1 VMa2 VMb1 VMb2
Procedure
Step 1 Configure BGP EVPN within DC A and DC B to establish VXLAN tunnels. For details, see
4.2.5 Configuring VXLAN in Distributed Gateway Mode Using BGP EVPN.
Step 2 Configure BGP EVPN on Leaf 2 and Leaf 3 to establish a VXLAN tunnel between them. For
details, see 4.2.5 Configuring VXLAN in Distributed Gateway Mode Using BGP EVPN.
Step 3 (Optional) Configure Leaf 2 and Leaf 3 as RRs. For details, see Configuring a BGP Route
Reflector.
Step 4 Configure Leaf 2 and Leaf 3 to advertise routes that are re-originated by the EVPN address
family to BGP EVPN peers.


The function to re-originate routes received from BGP EVPN peers is enabled.
4. Run peer { ipv4-address | group-name } advertise route-reoriginated evpn { mac-ip |
ip }
The function to advertise re-originated EVPN routes to BGP EVPN peers is enabled.
After route re-origination is enabled, Leaf 2 or Leaf 3 changes the next hop of a received
EVPN route to itself, replaces the router MAC address in the gateway MAC address
attribute with its own router MAC address, and replaces the Layer 3 VNI with the VPN
instance Layer 3 VNI.
Step 5 Run commit
----End
4.2.6.2 Configuring Three-Segment VXLAN to Implement Layer 2 Interworking

Three-segment VXLAN tunnels can be configured to enable communication between VMs
that belong to the same subnet but different DCs.
Context
On the network shown in Figure 4-80, VXLAN tunnels are configured both within DC A and
DC B and between transit leaf nodes in both DCs. To enable communication between VM 1
and VM 2, implement Layer 2 communication between DC A and DC B. If the VXLAN
tunnels within DC A and DC B use the same VXLAN Network Identifier (VNI), this VNI can
also be used to establish a VXLAN tunnel between Transit Leaf 1 and Transit Leaf 2. In
practice, however, different DCs have their own VNI spaces, and therefore the VXLAN
tunnels within DC A and DC B mostly likely use different VNIs. To configure a VXLAN
tunnel between Transit Leaf 1 and Transit Leaf 2 in such cases, perform a VNI conversion.
Such as shown in Figure 4-80, the VXLAN tunnel in DC A uses the VNI 10, and that in DC
B uses the VNI 20. Transit Leaf 2's VNI (20) must be configured as the outbound VNI on
Transit Leaf 1, and Transit Leaf 1's VNI (10) as the outbound VNI on Transit Leaf 2. After the
configuration is complete, Layer 2 packets can be forwarded properly. Take DC A sending
packets to DC B as an example. After receiving VXLAN packets within DC A, Transit Leaf 1
decapsulates the packets and then uses the outbound VNI 20 to re-encapsulate the packets
before sending them to Transit Leaf 2. Upon receipt, Transit Leaf 2 forwards them as normal
VXLAN packets.

Figure 4-80 Configuring three-segment VXLAN to implement Layer 2 interworking
Spine Spine
DC A DC B
Server Transit Transit Server

Leaf1 Leaf1 Leaf2 Leaf2
VXLAN VXLAN VXLAN
VNI 10 VNI 20
Out VNI 20 Out VNI 10
VSwitch VSwitch
VM1 VM2
VLAN 10 VLAN 10
NOTE
l Layer 2 communication between VMs in different DCs is implemented here, therefore avoiding the
need to configure a Layer 3 gateway.
l If DC A and DC B belong to the same AS, configure an RR on the edge device. If DC A and DC B
do not belong to the same AS, establish an EBGP EVPN peer relationship between edge devices.
Procedure
Step 1 Configure BGP EVPN within DC A and DC B to establish VXLAN tunnels. For details, see
4.2.4 Configuring VXLAN in Centralized Gateway Mode Using BGP EVPN. There is no
need to configure a VXLAN Layer 3 gateway.
Step 2 Configure BGP EVPN on Transit Leaf 1 and Transit Leaf 2 to establish a VXLAN tunnel
between them. For details, see 4.2.4 Configuring VXLAN in Centralized Gateway Mode
Using BGP EVPN. There is no need to configure a VXLAN Layer 3 gateway.
Step 3 Configure Transit Leaf 1 and Transit Leaf 2 to advertise routes that are re-originated by the
EVPN address family to BGP EVPN peers.
3. Run peer { group-name | ipv4-address } split-group split-group-name
A split horizon group (SHG) to which BGP EVPN peers (or peer groups) belong is
configured.
In Layer 2 interworking scenarios, to prevent forwarding BUM traffic from causing a
loop, an SHG must be configured. Separately specify the name of the SHG between
Transit Leaf 1 and Transit Leaf 2 on each, so that devices within DC A and DC B belong
to the default SHG and Transit Leaf 1 and Transit Leaf 2 belong to the specified SHG. In
this manner, when a transit leaf node receives BUM traffic, it does not forward traffic to
a device belonging to the same SHG, therefore preventing loops.

The function to re-originate routes received from BGP EVPN peers is enabled.
Enable on transit leaf nodes the function to re-originate routes received from BGP EVPN
peers within DCs and between the DCs (between transit leaf nodes).
5. Run peer { ipv4-address | group-name } advertise route-reoriginated evpn mac
The function to advertise re-originated EVPN routes to BGP EVPN peers is enabled.
In Layer 2 interworking scenarios, configure the function to advertise only re-originated
MAC routes to BGP EVPN peers. Enable on transit leaf nodes the function to advertise
re-originated MAC routes to BGP EVPN peers within DCs and between the DCs
(between transit leaf nodes).
6. Run commit
----End
4.2.6.3 Verifying the Configuration of Using Three-Segment VXLAN to

Implement DCI
After configuring three-segment VXLAN to implement DCI, verify the configuration, such as
EVPN instances and VXLAN tunnel information.
Prerequisites
Configurations of using three-segment VXLAN to implement DCI have been complete.
Procedure
information.
VNI or all VNIs.
tunnel information.
information.
----End

4.2.7 Configuring the Static VXLAN Active-Active Scenario

In the scenario where a data center is interconnected with an enterprise site, a CE is dual-
homed to a VXLAN network. In this way, carriers can enhance VXLAN access reliability to
improve the stability of user services so that rapid convergence can be implemented in case of
a fault.
Context
On the network shown in Figure 4-81, CE1 is dual-homed to PE1 and PE2. PE1 and PE2 use
a virtual address as an NVE interface address at the network side, namely, an Anycast VTEP
address. In this way, the CPE is aware of only one remote NVE interface. A VTEP address is
configured on the CPE to establish a VXLAN tunnel with the Anycast VTEP address so that
PE1, PE2, and the CPE can communicate.
The packets from the CPE can reach CE1 through either PE1 or PE2. However, single-homed
CEs may exist, such as CE2 and CE3. As a result, after reaching a PE, the packets from the
CPE may need to be forwarded by the other PE to a single-homed CE. Therefore, a bypass
VXLAN tunnel needs to be established between PE1 and PE2.
NOTE
Before an IPv6 network is used to transmit traffic between a CPE and PE, an IPv4 over IPv6 tunnel must
be configured between them. To enable a VXLAN tunnel to recurse routes to the IPv4 over IPv6 tunnel,
static routes must be configured on the CPE and PE, and the outbound interface of the route destined for
the VXLAN tunnel's destination IP address must be set to the IPv4 over IPv6 tunnel interface.
Figure 4-81 Networking diagram for configuring the static VXLAN active-active scenario
CPE
VXLAN Tunnel
Anycast VTEP
PE1 PE2
Bypass VXLAN Tunnel
Trunk
CE2 CE1 CE3
Procedure
Step 1 Configure AC-side service access.

1. Configure an Eth-Trunk interface on CE1 to dual-home CE1 to PE1 and PE2.

2. Configure service access points. For configuration details, see the section 4.2.3.1
Configuring a VXLAN Service Access Point.
3. Configure the same Ethernet Segment Identifier (ESI) for the links connecting CE1 to
PE1 and PE2.
a. Run the interface eth-trunk command to enter the Eth-Trunk interface view.
b. Run the esi command to configure an ESI.
c. Run the commit command to commit the configuration.
Step 2 Configure static VXLAN tunnels between the CPE and PEs. For configuration details, see the
section 4.2.3.2 Configuring a VXLAN Tunnel.
Step 3 Configure a bypass VXLAN tunnel between PE1 and PE2.
a. Run the bgp as-number command to enable BGP and enter the BGP view.
b. Run the peer ipv4-address as-number as-number command to configure the peer
device as a BGP peer.
c. Run the l2vpn-family evpn command to enter the BGP-EVPN address family view.
d. Run the peer { ipv4-address | group-name } enable command to enable the device
to exchange EVPN routes with a specified peer or peer group.
e. Run the peer { ipv4-address | group-name } advertise encap-type vxlan command
to advertise EVPN routes that carry the VXLAN encapsulation attribute to the peer.
f. Run the quit command to exit from the BGP-EVPN address family view.
g. Run the quit command to exit from the BGP view.
h. Run the commit command to commit the configuration.
2. Configure a VPN instance or EVPN instance.
– Layer 2 communication (Configure an EVPN instance.)
i. Run the evpn vpn-instance vpn-instance-name bd-mode command to create a
BD EVPN instance and enter the EVPN instance view.
ii. Run the route-distinguisher route-distinguisher command to configure an RD
for the EVPN instance.
iii. Run the vpn-target vpn-target &<1-8> [ both | export-extcommunity |
import-extcommunity ] command
to configure VPN target for the EVPN instance.
NOTE
The export VPN target of the local end must be the same as the import VPN target of the
remote end, and the import VPN target of the local end must be the same as the export VPN
target of the remote end.
iv. Run the quit command to exit from the EVPN instance view.
v. Run the bridge-domain bd-id command to enter the BD view.
vi. Run the vxlan vni vni-id split-horizon-mode command
to create a VNI, associate the VNI with the BD, and apply split horizon to the
BD.
vii. 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, you can bind multiple BDs with different VLANs to the same
EVPN instance and isolate services in the BDs..
viii. Run the quit command to exit from the BD view.
ix. Run the commit command to commit the configuration.
– Layer 3 communication (Configure a VPN instance.)
i. Run the ip vpn-instance vpn-instance-name command to create a VPN
instance and enter the VPN instance view.
ii. Run the ipv4-family [ unicast ] command to enable the IPv4 address family
for a VPN instance.
iii. Run the route-distinguisher route-distinguisher command to configure an RD
for the VPN instance.
iv. Run the vpn-target vpn-target &<1-8> [ both | export-extcommunity |
import-extcommunity ] [ evpn ] command
to configure VPN targets for the EVPN instance.
NOTE
The export VPN target of the local end must be the same as the import VPN target of the
remote end, and the import VPN target of the local end must be the same as the export VPN
target of the remote end.
v. Run the quit command to exit from the VPN instance ipv4-family view.
vi. Run the quit command to exit from the VPN instance view.
vii. Run the bridge-domain bd-id command to enter the BD view.
viii. Run the vxlan vni vni-id split-horizon-mode command to create a VNI,
associate the VNI with the BD, and apply split horizon to the BD.
ix. Run the quit command to exit from the BD view.
x. Run the commit command to commit the configuration.
3. Enable the inter-chassis VXLAN function on PE1 and PE2.
a. Run the evpn command to enter the EVPN view.
b. Run the bypass-vxlan enable command to enable the inter-chassis VXLAN
function.
c. Run the quit command to exit from the EVPN view.
d. Run the commit command to commit the configuration.
4. Configure an ingress replication list.
a. Run the interface nve nve-number command to enter the NVE interface view.
b. Run the source ip-address command to configure an IP address for the source
VTEP.
c. Run the vni vni-id head-end peer-list protocol bgp command to configure an
ingress replication list.
d. Run the bypass source ip-address command to configure a source VTEP address
for the bypass VLAN tunnel.
e. Run the mac-address mac-address command to configure a VTEP MAC address.
f. Run the quit command to exit from the NVE interface view.
g. Run the commit command to commit the configuration.
Step 4 Configure FRR on the PEs.

l Layer 2 communication
b. Run the vlan-extend private command to enable routes to be sent to carry the
VLAN private extended community attribute.
c. Run the vlan-extend redirect command to enable the function of redirecting
received routes the VLAN private extended community attribute.
d. Run the local-remote frr command to enable FRR for MAC routes between the
local and remote ends.
e. Run the quit command to exit from the EVPN view.
f. Run the commit command to commit the configuration.
a. Run the bgp as-number command to enter the BGP view.
b. Run the ipv4-family vpn-instance vpn-instance-name command to enable the
BGP-VPN instance IPv4 address family and displays the address family view.
c. Run the auto-frr command to enable BGP auto FRR.
d. Run the peer { ipv4-address | group-name } enable command to enable the
function of exchanging EVPN routes with a specified peer or peer group. The IP
address is a CE address.
e. Run the advertise l2vpn evpn command to enable a VPN instance to advertise IP
routes to an EVPN instance.
f. Run the quit command to exit from the BGP-VPN instance IPv4 address family
view.
g. Run the quit command to exit from the BGP view.
Step 5 (Optional) Configure a UDP port on the PEs to prevent the receiving of replicated packets.
1. Run the evpn enhancement port port-id command to configure a UDP port.
The same UDP port number must be set for the PEs in the active state.
2. Run the commit command to commit the configuration.
Step 6 (Optional) Configure a VXLAN over IPSec tunnel between the CPE and PE to enhance the
security for packets traversing an insecure network.
For configuration details, see the section Example for Configuring VXLAN over IPsec.
----End
Checking the Configuration

After configuring the VXLAN active-active scenario, check information on the VXLAN
tunnel, VNI status, and VBDIF. For details, see the section 4.2.5.5 Verifying the
Configuration of VXLAN in Distributed Gateway Mode Using BGP EVPN.
4.2.8 Configuring the Dynamic VXLAN Active-Active Scenario

a fault.

Context
On the network shown in Figure 4-82, CE1 is dual-homed to PE1 and PE2. PE1 and PE2 use
a virtual address as an NVE interface address at the network side, namely, an Anycast VTEP
address. In this way, the CPE is aware of only one remote VTEP IP. A VTEP address is
configured on the CPE to establish a dynamic VXLAN tunnel with the Anycast VTEP
address so that PE1, PE2, and the CPE can communicate.
Figure 4-82 Networking diagram for configuring the dynamic VXLAN active-active scenario
CPE
VXLAN Tunnel
Anycast VTEP
PE1 PE2
Bypass VXLAN Tunnel
Trunk
CE2 CE1 CE3
Procedure
Step 1 Configure AC-side service access.
1. Configure an Eth-Trunk interface on CE1 to dual-home CE1 to PE1 and PE2.
2. Configure service access points. For configuration details, see the section 4.2.3.1
Configuring a VXLAN Service Access Point.
3. Configure the same Ethernet Segment Identifier (ESI) for the links connecting CE1 to
PE1 and PE2.
a. Run the interface eth-trunk command to enter the Eth-Trunk interface view.
b. Run the esi command to configure an ESI.
c. Run the commit command to commit the configuration.
Step 2 Configure static VXLAN tunnels between the CPE and PEs. For configuration details, see the
section 4.2.4.2 Configuring a VXLAN Tunnel.

Step 3 Configure a bypass VXLAN tunnel between PE1 and PE2.

a. Run the bgp as-number, BGP is enabled, and the BGP view is displayed.
b. Run the peer ipv4-address as-number as-number. The peer device is configured as
a BGP peer.
c. Run the l2vpn-family evpn. The BGP-EVPN address family view is displayed.
d. Run the peer { ipv4-address | group-name } enable. The device is enabled to
exchange EVPN routes with a specified peer or peer group.
e. Run the peer { ipv4-address | group-name } advertise encap-type vxlan command
to advertise EVPN routes that carry the VXLAN encapsulation attribute to the peer.
f. Run the quit, exit from the BGP-EVPN address family view.
g. Run the quit, exit from the BGP view.
h. Run the commit,command to commit the configuration.
2. Configure an EVPN instance.
a. Run the evpn vpn-instance vpn-instance-name bd-mode. A BD EVPN instance is
created, and the EVPN instance view is displayed.
b. Run the route-distinguisher route-distinguisher. An RD is configured for the
EVPN instance.
c. Run the vpn-target vpn-target &<1-8> [ both | export-extcommunity | import-
extcommunity ]
VPN targets are configured for the EVPN instance. The export VPN target of the
local end must be the same as the import VPN target of the remote end, and the
import VPN target of the local end must be the same as the export VPN target of the
remote end.
d. Run the quit, exit from the EVPN instance view.
e. Run the bridge-domain bd-id, the BD view is displayed.
f. Run the vxlan vni vni-id split-horizon-mode.
g. Run the 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.
h. Run the quit, exit from theBDview.
i. Run the commit,command to commit the configuration.
3. Enable the inter-chassis VXLAN function on PE1 and PE2.
b. Run the bypass-vxlan enable command to enable the inter-chassis VXLAN
function.
c. Run the quit, exit from the EVPN view.
d. Run the commit command to commit the configuration.
a. Run the interface nve nve-number command to enter the NVE interface view.
b. Run the source ip-address, an IP address is configured for the source VTEP.

c. Run the vni vni-id head-end peer-list protocol bgp, an ingress replication list is
configured.
d. Run the bypass source ip-address command configures a source VTEP address for
the bypass VLAN tunnel.
e. Run the mac-address mac-address command to configure a VTEP MAC address.
f. Run the quit, exit from the NVE interface view.
g. Run the commit command to commit the configuration.
Step 4 Configure FRR on the PEs.

b. Run the vlan-extend private enable command to enable routes to be sent to carry
the VLAN private extended community attribute.
c. Run the vlan-extend redirect enable command to enable the function of
redirecting received routes the VLAN private extended community attribute.
d. Run the local-remote frr enable command to enable FRR for MAC routes between
the local and remote ends.
e. Run the quit, exit from the EVPN view.
f. Run the commit command to commit the configuration.
a. Run the bgp as-number command to enter the BGP view.
b. Run the ipv4-family vpn-instance vpn-instance-name command enables the BGP-
VPN instance IPv4 address family and displays the address family view.
c. Run the auto-frr command to enable BGP auto FRR.
d. Run the peer { ipv4-address | group-name } as-number as-number. The IP address
of the peer and the number of the AS where the peer resides are specified.
e. Run the advertise l2vpn evpn command to enable a VPN instance to advertise IP
routes to an EVPN instance.
f. Run the quit, exit from the BGP-VPN instance IPv4 address family view.
g. Run the quit, exit from the BGP view.
1. Run the evpn enhancement port port-id command to configure a UDP port.
2. Run the commit,command to commit the configuration.
Step 6 (Optional) Configure a VXLAN over IPSec tunnel between the CPE and PE to enhance the
security for packets traversing an insecure network.
For configuration details, see the section Example for Configuring VXLAN over IPsec.
----End

Checking the Configuration

After configuring the VXLAN active-active scenario, check information on the VXLAN
tunnel, VNI status, and VBDIF. For details, see the section 4.2.5.5 Verifying the
Configuration of VXLAN in Distributed Gateway Mode Using BGP EVPN.
4.2.9 Configuring BRAS Access Through a PW and a VXLAN

Tunnel
As virtual networks develop, if device resources become insufficient for processing access
user traffic, traffic can be load balanced to virtual BRASs in data centers. Specifically, a
device can establish a VXLAN tunnel with a virtual BRAS for user access.
Usage Scenario
On the network shown in Figure 4-83, a VPLS network and a VXLAN network intersect at
Device 2 and Device 4 that back up each other. VRRP is configured to implement device and
link reliability. Users can access the BRAS through a PW and a VXLAN tunnel.
Figure 4-83 Configuring BRAS access through a PW and a VXLAN tunnel
Before configuring BRAS access through a PW and a VXLAN tunnel, complete the following
tasks:
l The VPLS network has been created.
l The network is reachable at Layer 3.
Perform the following steps on devices at the intersection of the VPLS and VXLAN
networks:
Procedure
1. Run system-view



Either a physical interface's IP address or loopback interface address can be specified for
a source VTEP. Using the loopback interface address as the source VTEP's IP address is
recommended.
3. Run vni vni-id head-end peer-list ip-address &<1-10>
NOTE
BUM packets can only be transmitted in ingress replication mode. When a Huawei device
interworks with a non-Huawei device, the non-Huawei device must also have the ingress
replication mode configured before they can establish a VXLAN tunnel.
4. Run commit
Step 2 Configure a BD and bind it to a VSI.

1. Run system-view


A VNI is created and bound to a BD, and split horizon is configured for packet
forwarding.
4. Run l2 binding vsi vsi-name [ pw-tag pw-tag-value ]
The BD is bound to a VSI.

5. Run commit
Step 3 Configure a VRRP backup group to track interface status and create an mVRRP group.
1. Run system-view

2. Run interface interface-type interface-number.subinterface-number
The sub-interface view is displayed.

3. Run vlan-type dot1q vlan-id
VLAN encapsulation and a VLAN are configured for the sub-interface.

An IP address is configured for the sub-interface.

5. Run vrrp vrid virtual-router-id [ virtual-ip virtual-address ]
A VRRP backup group is configured.

6. Run vrrp vrid track virtual-router-id interface interface-type interface-number reduced

value-reduced
The VRRP backup group is configured to track an interface.
7. Run admin-vrrp vrid virtual-router-id [ ignore-if-down ]
An mVRRP group is created.
8. Run commit
Step 4 Associate VRRP with the virtual VTEP's route priority.
An IP address is configured for the loopback interface.
The IP address configured for a loopback interface must be the one configured for the
source VTEP.
3. Run direct-route track vrrp vrrp interface interface-type interface-number vrid
virtual-router-id degrade-cost cost-value
VRRP is associated with the virtual VTEP's route priority.
vrid virtual-router-id must be an mVRRP group that has been created.
4. Run commit
Step 5 Bind a service PW in a service VSI to an mVRRP group.
1. Run system-view
2. Run vsi vsi-name [ static | auto ] bd-mode
3. Run pwsignal ldp
The VSI-LDP view is displayed.
4. Run vsi-id vsi-id
5. Run peer peer-address
A peer is configured for the VSI.
6. Run peer peer-address [ negotiation-vc-id vc-id ] track admin-vrrp interface
interface-type interface-number vrid virtual-router-id pw-redundancy backup-block-
all
A service PW in a service VSI is bound to an mVRRP group.
7. Run commit
----End

4.2.10 Configuring NFVI Distributed Gateway

In the Network Function Virtualization Infrastructure (NFVI) telco cloud solution, the NFVI
distributed gateway function enables mobile phone service traffic to pass through the data
communication network (DCN) and to be processed by the virtualized unified gateway
(vUGW) and virtual multiservice engine (vMSE). In addition, traffic can be balanced during
internal transmission over the DCN.
Usage Scenario
Huawei's NFVI telecommunications (telco) cloud is a networking solution that incorporates
Data Center Interconnect (DCI) and DCN technologies. Mobile phone traffic enters the DCN
and accesses its virtualized unified gateway (vUGW) and virtual multiservice engine (vMSE).
After being processed by these, the phone traffic is forwarded over the Internet through the
DCN to the destination devices. Equally, response traffic sent over the Internet from the
destination devices to the mobile phones also undergoes this process. For this to take place
and to ensure that the traffic is balanced within the DCN, you need to deploy the NFVI
distributed gateway function on the DCN.
Figure 4-84 or Figure 4-85 shows the network of NFVI distributed gateways. DC-GWs are
the boundary gateways of the DCN network and can be used to exchange Internet routes with
the external network. L2GW/L3GW1 and L2GW/L3GW2 are connected to virtualized
network function (VNF) devices. VNF1 and VNF2 can be deployed as virtualized NEs to
implement the vUGW and vMSE functions and connected to the L2GW/L3GW1 and L2GW/
L3GW2 through the interface process unit (IPU).
This networking can be considered a combination of the distributed gateway function and
VXLAN dual-active /quad-active gateway function.
l The VXLAN dual-active /quad-active gateway function is deployed on DC-GW1 and
DC-GW2. Specifically, a bypass VXLAN tunnel is established between DC-GWs and
these DC-GWs use the same virtual anycast VTEP address to establish VXLAN tunnels
with L2GW/L3GW1 and L2GW/L3GW2.
and a VXLAN tunnels are established between L2GW/L3GW1 and L2GW/L3GW2.
On the NFVI distributed gateway network, the number of bridge domains (BDs) must be
planned according to the number of network segments that the IPUs belong to. For example,
if five IPU interfaces correspond to four network segments, four different BDs must be
planned. You also need to configure all BDs and VBDIF interfaces on each of the DCGWs
and L2GW/L3GWs, and bind all VBDIF interfaces to the same L3VPN instance. In addition,
the following functions have to be deployed on the network:
l A VPN BGP peer relationship is set up between a VNF and DCGW so that the VNF can
advertise user equipment (UE) routes to the DCGW.
l Static VPN routes are configured on L2GW/L3GW1 and L2GW/L3GW2 to connect to
the VNFs. The routes' destination IP addresses are the VNFs' IP addresses, and the next
hops are the IP addresses of the IPUs.
l A BGP EVPN peer relationship is established (full-mesh) between any two of the
DCGWs and L2GW/L3GWs. An L2GW/L3GW can flood static routes to the VNFs to
other devices through BGP EVPN peer relationships. A DCGW can advertise local
loopback routes and default routes to the L2GW/L3GWs through the BGP EVPN peer
relationships.
l Traffic between a mobile phone and the Internet that is forwarded through a VNF is
called north-south traffic, whereas the traffic between VNF1 and VNF2 is called east-

west traffic. To balance both of these, you need to configure load balancing on the
DCGWs and L2GW/L3GWs.
NOTE
The NFVI distributed gateway function is supported for both IPv4 and IPv6 services. If a configuration
step is not differentiated in terms of IPv4 and IPv6, this step applies to both IPv4 and IPv6 services.
When the NFVI distributed gateway is used, the NE40E functions as either a DCGW or an L2GW/
L3GW. However, if the NE40E is used as an L2GW/L3GW, east-west traffic cannot be balanced.
Figure 4-84 NFVI distributed gateway network (DC-GW dual-active)
Bypass VXLAN Tunnel

Anycast VTEP
DCGW1 DCGW2
VX
BGP
l
ne
LA
EVPN
n
BGP VPN
Tu
N
Tu
N
LA
nn
VX
L2GW/ el L2GW/
L3GW1 L3GW2
VXLAN Tunnel
VPN
Static
VNF1 VNF2

Figure 4-85 NFVI distributed gateway network (DC-GW quad-active)
DCGW3 DCGW4
Bypass VXLAN Tunnel
DCGW1 DCGW2
Anycast VTEP
BGP
VX
EVPN
el
nn
LA
Tu
N
Tu
N
BGP VPN
LA
nn
VX
el
L2GW/ L2GW/
L3GW1 L3GW2
VXLAN Tunnel
VPN
Static
VNF1 VNF2
Before configuring NFVI distributed gateway, complete the following tasks:
l Configure the Static VXLAN Active-Active Scenario or Configure the Dynamic
VXLAN Active-Active Scenario on each DCGW and each L2GW/L3GW.
l 4.2.5 Configuring VXLAN in Distributed Gateway Mode Using BGP EVPN on each
L2GW/L3GW.
l Configure static routes to VNF1 and VNF2 on each L2GW/L3GW. For configuration
details, see Creating IPv4 Static Routes or Creating IPv6 Static Routes.
4.2.10.1 Configuring an L3VPN Instance on a DCGW

You can configure an L3VPN instance to store and manage received mobile phone routes and
VPN routes reachable to VNFs.
Procedure
Step 2 Run ip vpn-instance vpn-instance-name

Step 3 Run vxlan vni vni-id
A VNI is created and associated with the VPN instance.
Step 4 Enter the VPN instance IPv4/IPv6 address family view.

l Run ipv4-family
The VPN instance IPv4 address family view is displayed.
l Run ipv6-family
Step 5 Configure an RD for the VPN instance.

l Run route-distinguisher route-distinguisher
l Run route-distinguisher route-distinguisher
Step 6 Configure VPN targets for the VPN instance.

l Run vpn-target vpn-target &<1-8> [ both | export-extcommunity | import-
extcommunity ] evpn
VPN targets used to import routes into and from the remote device's L3VPN instance are
configured for the VPN instance IPv4 address family.
l Run vpn-target vpn-target &<1-8> [ both | export-extcommunity | import-
extcommunity ] evpn
VPN targets used to import routes into and from the remote device's L3VPN instance are
configured for the VPN instance IPv6 address family.
When the local device advertises EVPN routes to the remote device, the EVPN routes carry
the export VPN target configured using this command. When the local device receives an
EVPN route from the remote end, the route can be imported into the routing table of the VPN
instance IPv4/IPv6 address family only if the VPN target carried in the EVPN route is
included in the import VPN target list of the VPN instance IPv4/IPv6 address family.
Step 7 Run quit
Exit from the VPN instance IPv4/IPv6 address family view.
Step 8 Run quit
The number of VBDIF interfaces to be created is the same as the number of planned BDs.
The VBDIF interface is bound to the VPN instance.
Step 11 (Optional) Run ipv6 enable
IPv6 is enabled on the interface. This step is mandatory if an IPv6 address is planned for the
VBDIF interface.

Step 12 Configure an IPv4/IPv6 address for the VBDIF interface.

l Run ip address ip-address { mask | mask-length }
An IPv4 address is configured for the interface.
l Run ipv6 address { ipv6-address prefix-length | ipv6-address/prefix-length }
Step 13 Run vxlan anycast-gateway enable
The distributed gateway function is enabled.
Step 14 Configure a DCGW to generate ARP (ND) entries for Layer 2 forwarding based on ARP/ND
information in EVPN routes.
l Run arp generate-rd-table enable
The DCGW is enabled to generate ARP entries used for Layer 2 forwarding based on
ARP information.
l Run ipv6 nd generate-rd-table enable
The DCGW is enabled to generate ND entries used for Layer 2 forwarding based on ND
information.
Step 15 Run commit
----End
4.2.10.2 Configuring Route Advertisement on a DC-GW

After route advertisement is configured on a DC-GW, the DC-GW can construct its own
forwarding entries based on received EVPN or BGP routes.
Procedure
Step 1 Configure EVPN on the DC-GW to advertise default static routes and loopback routes in a
VPN instance.
1. Run system-view
2. Run interface Loopback interface-number
The loopback interface view is displayed.
An L3VPN instance is bound to the loopback interface.
4. (Optional) Run ipv6 enable
IPv6 is enabled on the interface. This step is mandatory if the interface requires an IPv6
address.
5. Configure an IPv4/IPv6 address for the interface.
– Run ip address ip-address { mask | mask-length }
– Run ipv6 address { ipv6-address prefix-length | ipv6-address/prefix-length }


6. Run quit
Exit from the loopback interface view.
7. Configure a default static route for the VPN instance.
– 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 ] } [ tag tag ]
– Run ipv6 route-static vpn-instance vpn-instance-name :: 0 { nexthop-ipv6–
address | interface-type interface-number [ nexthop-ipv6-address ] } [ tag tag ]
8. Create a route policy to filter default static routes and loopback routes in the VPN
instance. For configuration details, see Configuring a Route-Policy.
The VPN instance view is displayed.
10. Enter the VPN instance IPv4/IPv6 address family view.
– Run ipv4-family
– Run ipv6-family
11. Run export route-policy policy-name evpn
The VPN instance is associated with an export route policy, which filters routes that the
VPN instance will advertise to an EVPN instance. This ensures that the VPN instance
advertises only its default static routes and loopback routes to the EVPN instance.
12. Run quit
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 BGP-VPN instance IPv4/IPv6 address family view.

– Run ipv4-family vpn-instance vpn-instance-name

20. Run import-route direct [ med med | route-policy route-policy-name ] *
Importing loopback routes in the VPN instance to the BGP-VPN instance IPv4/IPv6
address family view is enabled on the device.
21. Run network { 0.0.0.0 0 | :: 0 }
Importing default static routes in the VPN instance to the BGP-VPN instance IPv4/IPv6
address family view is enabled on the device.
22. Run advertise l2vpn evpn
Advertising IP routes to the EVPN instance is enabled in the VPN instance.
23. Run quit
Exit from the BGP-VPN instance IPv4/IPv6 address family view.
24. Run quit
Step 2 Configure the DC-GW to establish a VPN BGP peer relationship with a VNF.
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 VPN BGP peer relationship is established.
6. Run peer { ipv4-address | ipv6-address | group-name } connect-interface interface-type
interface-number [ ipv4-source-address ]
7. Run peer { ipv4-address | ipv6-address | group-name } route-policy route-policy-name
export
The route policy is applied so that the DC-GW does not advertise VPN BGP routes to
the VNF to prevent route loops.

8. Run quit
Step 3 (Optional) Configure the asymmetric mode for IRB routes. If an L2GW/L3GW is configured
to advertise IRB (IRBv6) routes to the DC-GW, you need to configure the IRB asymmetric
function on the DC-GW.
2. Run irb asymmetric
The asymmetric mode is enabled for IRB routes.
Step 4 Run commit
----End
4.2.10.3 Configuring Route Advertisement on an L2GW/L3GW

After route advertisement is configured on an L2GW/L3GW, the L2GW/L3GW can construct
its own forwarding entries based on received EVPN or BGP routes.
Procedure
Step 1 Configure an L2GW/L3GW to generate ARP (ND) entries for Layer 2 forwarding based on
ARP/ND information in EVPN routes.
1. Run system-view

2. Run interface vbdif bd-id

3. Configure a DCGW to generate ARP (ND) entries for Layer 2 forwarding based on
ARP/ND information in EVPN routes.
– Run arp generate-rd-table enable
The L2GW/L3GW is enabled to generate ARP entries used for Layer 2 forwarding
based on ARP information.
– Run ipv6 nd generate-rd-table enable
The L2GW/L3GW is enabled to generate ND entries used for Layer 2 forwarding
based on ND information.
4. Run quit
Exit from the VBDIF interface view.
Step 2 Configure an L3VPN instance on the L2GW/L3GW to advertise static VPN routes reachable
to a VNF to EVPN.

1. Create a route policy to filter the static VPN routes reachable to the VNF from the
L3VPN instance. For details on how to configure a route policy, see Configuring a
Route-Policy. When you specify an apply clause, run the apply gateway-ip { origin-
nexthop | ipv4-address } or apply ipv6 gateway-ip { origin-nexthop | ipv6-address }
command to set the original next hop of a static route to the gateway IP address.
The view of a VPN instance is displayed.
3. Enter the VPN instance IPv4/IPv6 address family view.
– Run ipv4-family
– Run ipv6-family
4. Run export route-policy policy-name evpn
The L3VPN instance is associated with an export route policy, which filters routes that
the L3VPN instance will advertise to an EVPN instance. This ensures that the L3VPN
instance advertises only static VPN routes reachable to the VNF to EVPN.
5. Run quit
6. Run quit
9. Run import-route static [ med med | route-policy route-policy-name ] *
The device is enabled to import static routes into the routing table of the BGP-VPN
instance IPv4/IPv6 address family.
10. Run advertise l2vpn evpn [ import-route-multipath ]
The VPN instance is enabled to advertise IP routes to the EVPN instance. If load
balancing is required, specifying the import-route-multipath parameter is
recommended, so that the VPN instance can advertise all 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 (ND) routes to each other, skip this step. If L2GW/L3GWs are configured
to advertise IRB (IRBv6) routes each other, perform this step so that the L2GW/L3GWs
do not generate IP prefix routes. This helps prevent route loops.
12. Run quit

Step 3 Configure the L2GW/L3GW to advertise IRB (IRBv6) or ARP (ND) routes to a DCGW.

2. Run peer { ipv4-address | group-name } advertise { irb | arp | irbv6 | nd }
The device is enabled to advertise IRB (IRBv6) or ARP (ND) routes. If ARP (ND)
routes need to be advertised, the L2GW/L3GW sends only routes carrying MAC and
ARP information to the DCGW. If IRB (IRBv6) routes need to be advertised, the L2GW/
L3GW sends the MAC addresses, ARP information, and L3 VNI to the DCGW. In this
case, however, the irb asymmetric command must be enabled on the DCGW so that the
DCGW does not generate IP prefix routes based on the IP address and L3 VNI. This
prevents route loops on the network.
3. Run quit

4. Run quit
Step 4 Run commit
----End
4.2.10.4 Configuring Load Balancing

You must configure load balancing to balance traffic over a DCN.
Procedure
l Configure DCGWs.

b. Enter the BGP-VPN instance IPv4/IPv6 address family view.
n Run ipv4-family vpn-instance vpn-instance-name
c. Run maximum load-balancing [ ebgp | ibgp ] number [ ecmp-nexthop-changed ]
The maximum number of equal-cost routes for load balancing is set.

d. Run quit


f. Run peer { ipv4-address | group-name } capability-advertise add-path { send |
receive | both }

Sending Add-Path routes to or receiving Add-Path routes from a specified peer is

enabled on this device.
g. Run peer { ipv4-address | group-name } advertise add-path path-number path-
number
The number of routes that the device can send to a specified peer is configured.
h. Run quit
i. Run quit
j. Run commit
l Configure L2GW/L3GWs.
b. Enter the BGP-VPN instance IPv4/IPv6 address family view.
c. Run maximum load-balancing [ ebgp | ibgp ] number [ ecmp-nexthop-changed ]
The maximum number of equal-cost routes for load balancing is set.
d. Run quit
f. Run bestroute add-path path-number path-number
BGP Add-Path is enabled, and the number of routes that the device can select is
configured.
g. Run peer { ipv4-address | group-name } capability-advertise add-path { send |
receive | both }
Sending Add-Path routes to or receiving Add-Path routes from a specified peer is
enabled on this device.
h. Run peer { ipv4-address | group-name } advertise add-path path-number path-
number
The number of routes that the device can send to a specified peer is configured.
i. Run quit
j. Run quit

k. Run commit
----End
4.2.10.5 Verifying the NFVI Distributed Gateway Configuration

After configuring the NFVI distributed gateway function, verify the configuration.
Prerequisites
The NFVI distributed gateway configurations have been completed.
Procedure
Step 1 Run the display bgp { vpnv4 | vpnv6 } vpn-instance vpn-instance-name peer command on
each DCGW to check whether the VPN BGP peer relationships between the DCGW and
VNFs are Established.
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 each DCGW to check
whether the DCGW has received mobile phone routes from the VNF and whether the next
hop of the routes is the VNF IP address.
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 each DCGW to check the DCGW's VPN
routing table. The command output shows information about mobile phone routes and the
outbound interfaces are VBDIF interfaces.
----End
4.2.11 Maintaining VXLAN

This section describes how to clear VXLAN statistics and monitor the VXLAN running
status.
4.2.11.1 Configuring the VXLAN Alarm Function

To learn about the VXLAN operating status in time, configure the VXLAN alarm function so
that the NMS will be notified of the VXLAN status changes. This facilitates O&M.
Procedure
Step 2 Run snmp-agent trap enable feature-name nvo3 [ trap-name { hwnvo3vxlantnldown |

hwnvo3vxlantnlup } ]
The VXLAN alarm function is enabled.
Step 3 Run commit

----End

After the VXLAN alarm function is enabled, check the VXLAN alarm status.
Run the display snmp-agent trap feature-name nvo3 all command to check configurations
of all alarm functions of the VXLAN module.
4.2.11.2 Collecting and Checking VXLAN Packet Statistics

To check the network status or locate network faults, you can enable the traffic statistics
function to view VXLAN packet statistics.
Procedure
l Collect and view VXLAN packet statistics in a BD.
a. Run system-view
c. Run statistic enable
VXLAN packet statistics in a BD is enabled.
d. Run commit
l Collect and view VXLAN packet statistics collected by VNI.
a. Run system-view
b. Run vni vni-id
A VNI is created, and the VNI view is displayed.
c. Run statistic enable
VXLAN packet statistics collection is enabled.
d. Run commit
l Collect and view VXLAN packet statistics collected by VNI and VXLAN tunnel.
a. Run system-view
b. Run interface nve nve-number
c. Run source ip-address
The IP address of the source VTEP is configured.
d. Run vni vni-id head-end peer-list ip-address &<1-10>
An ingress replication list is configured for the VNI.

e. Run vxlan statistics peer peer-ip vni vni-id [ inbound | outbound ] enable
VXLAN packet statistics collection by VNI and VXLAN tunnel is displayed.
f. Run vxlan statistic l3-mode peer peer-ip vni vni-id inbound enable
Upstream Layer 3 traffic statistics collection by VNI and VXLAN tunnel is
enabled.
Run vxlan statistics l3-mode peer peer-ip [ vni vni-id ] outbound enable
Downstream Layer 3 traffic statistics collection by VNI and VXLAN tunnel is
enabled.
g. Run commit
Postrequisite
l Run the display bridge-domain vni vni-id command to view VXLAN packet statistics
in the BD.
l Run the display vxlan statistics vni vni-id command to view VXLAN packet statistics
collected by VNI.
l Run the display vxlan statistics source source-ip peer peer-ip vni vni-id command to
view VXLAN packet statistics collected by VNI and VXLAN tunnel.
l Run the display vxlan statistics l3-mode source source-ip peer peer-ip local-vni vni-id
command to view upstream Layer 3 VXLAN traffic statistics collected by VNI and
VXLAN tunnel.
l Run the display vxlan statistics l3-mode source source-ip peer peer-ip remote-vni vni-
id command to view downstream Layer 3 VXLAN traffic statistics collected by VNI and
VXLAN tunnel.
4.2.11.3 Clearing VXLAN Packet Statistics

This section describes how to clear VXLAN packet statistics in a BD, VXLAN packet
statistics collected per VNI, or per VNI and VXLAN tunnel.
Context
NOTE
Packet statistics cannot be restored after they are cleared. Exercise caution when running the reset
commands.
Procedure
l Run the reset bridge-domain bd-id statistics command in the user view to delete packet
statistics in a specified BD.
l Run the reset vxlan statistics vni vni-id command in the user view to delete VXLAN
packet statistics collected per VNI.
l Run the reset vxlan statistics source source-ip peer peer-ip vni vni-id command in the
user view to delete packet statistics collected per VNI and VXLAN tunnel.
l Run the reset vxlan statistics source source-ip peer peer-ip local-vni local-vni-id
command in the user view to delete upstream VXLAN packet statistics collected based
on the local VNI ID.

l Run the reset vxlan statistics source source-ip peer peer-ip remote-vni remote-vni-id
command in the user view to delete downstream VXLAN packet statistics collected
based on the remote VNI ID.
l Run the reset vxlan statistics l3-mode source source-ip peer peer-ip local-vni vni-id
command in the user view to delete Layer 3 upstream packet statistics collected per VNI
and VXLAN tunnel.
l Run the reset vxlan statistics l3-mode source source-ip peer peer-ip remote-vni vni-id
command in the user view to delete Layer 3 downstream packet statistics collected per
VNI and VXLAN tunnel.
----End
4.2.11.4 Checking Statistics about MAC Address Entries in a BD

Statistics about MAC address entries in a BD can be viewed to monitor the VXLAN
operating status.
Context
In routine maintenance, run the following commands in any view to check the VXLAN
operating status.
Procedure
l Run the display mac-address [ mac-address ] bridge-domain bd-id command to check
statistics about all MAC address entries in a BD.
----End
4.2.11.5 Clearing Statistics about Dynamic MAC Address Entries in a BD

To view dynamic MAC address entries in a BD within a specified period of time, clear
existing dynamic MAC address entry information before starting statistics collection to ensure
information accuracy.
Context
NOTE
Statistics about dynamic MAC address entries in a BD cannot be restored after they are cleared. Exercise
caution when running the reset command.
Procedure
l Run the reset mac-address bridge-domain bd-id command in the user view to clear
statistics about dynamic MAC address entries in a BD.
----End
4.2.12 Configuration Examples for VXLAN

This section describes the typical application scenarios of VXLANs, including networking
requirements, configuration roadmap, and data preparation, and provides related configuration
files.

4.2.12.1 Example for Configuring Users on the Same Network Segment to

Communicate Through a VXLAN Tunnel
This section provides an example for configuring users on the same network segment to
communicate through a VXLAN tunnel.
centers. VM1 on Server1 belongs to VLAN10, and VM1 on Server2 belongs to VLAN20.
VM1 on Server1 and VM1 on Server2 reside on the same network segment. To allow VM1s
in different data centers to communicate with each other, configure a VXLAN tunnel between
Device1 and Device3.
Figure 4-86 Configuring users on the same network segment to communicate through a
VXLAN tunnel
NOTE
Interface 1 and Interface 2 stand for GE 1/0/1 and GE 1/0/2, respectively.
Loopback 1
3.3.3.3/32
Device2
e1 in
r f ac 4 19 terfa
e 2 2.1 ce2 19
e1 .1/24 int .1.2/ 68 2.1 inter
ac 6 8 . 2.1 68 face
rf 8.1 . 1 .2.
te
in 2.16 19
2 /2 4 2/2 1
9 4
1
Device1 VXLAN Tunnel Device3

interface2
interface2
Loopback 1
Loopback 1 4.4.4.4/32
2.2.2.2/32
VSwitch VSwitch
VM1 ... VMm VM1 ... VMn
VLAN 10 VLAN 20
Server1 Server2
192.168.10.1/24 192.168.10.2/24
NVE

1. Configure a routing protocol on Device1, Device2, and Device3 to allow them to

communicate at Layer 3.
2. Configure a service access point on Device1 and Device3 to differentiate service traffic.
3. Configure a VXLAN tunnel on Device1 and Device3 to forward service traffic.
Data Preparation
l VMs' VLAN IDs (10 and 20)

l IP addresses of interfaces connecting devices
l Interior Gateway Protocol (IGP) running between devices (OSPF in this example)
l BD ID (10)
l VNI ID (5010)
Procedure
Step 1 Configure a routing protocol.
Assign an IP address to each interface on Device1, Device2, and Device3 according to Figure
4-86.
# Configure Device1.
[~HUAWEI] sysname Device1
[*HUAWEI] commit
[~Device1] interface loopback 1
[*Device1-LoopBack1] ip address 2.2.2.2 32
[*Device1-LoopBack1] quit
[*Device1] interface gigabitethernet 1/0/1
[*Device1-GigabitEthernet1/0/1] ip address 192.168.1.1 24
[*Device1-GigabitEthernet1/0/1] quit
[*Device1] ospf
[*Device1-ospf-1] area 0
[*Device1-ospf-1-area-0.0.0.0] network 2.2.2.2 0.0.0.0
[*Device1-ospf-1-area-0.0.0.0] quit
[*Device1-ospf-1] quit
[*Device1] commit
Repeat these steps for Device2 and Device3. For configuration details, see Configuration
After OSPF is configured, the devices can use OSPF to learn the IP addresses of loopback
interfaces of each other and successfully ping each other. The following example shows the
command output on Device1 after it pings Device3:
[~Device1] ping 4.4.4.4

0.00% packet loss

Step 2 Configure a service access point on Device1 and Device3.

[~Device1] bridge-domain 10
[*Device1-bd10] quit
[*Device1] interface gigabitethernet1/0/2.1 mode l2
[*Device1-GigabitEthernet1/0/2.1] encapsulation dot1q vid 10
[*Device1-GigabitEthernet1/0/2.1] rewrite pop single
[*Device1-GigabitEthernet1/0/2.1] bridge-domain 10
[*Device1-GigabitEthernet1/0/2.1] quit
[*Device1] commit
Repeat these steps for Device3. For configuration details, see Configuration Files in this
section.
Step 3 Configure a VXLAN tunnel on Device1 and Device3.
[~Device1-bd10] vxlan vni 5010
[*Device1] interface nve 1
[*Device1-Nve1] source 2.2.2.2
[*Device1-Nve1] vni 5010 head-end peer-list 4.4.4.4
[*Device1-Nve1] quit
[*Device1] commit
section.
After completing the configurations, run the display vxlan vni and display vxlan tunnel
commands on Device1 and Device3 to check the VNI status and VXLAN tunnel information,
respectively. The VNIs are Up on Device1 and Device3. The following example shows the
command output on Device1.
[~Device1] display vxlan vni
Number of vxlan vni: 1
VNI BD-ID State
---------------------------------------
5010 10 up
[~Device1] display vxlan tunnel
-------------------------------------------------------------------
4026531842 2.2.2.2 4.4.4.4 up static 0028h16m
By now, users on the same network can communicate through the VXLAN tunnel.
----End
Configuration Files
l Device1 configuration file
#
sysname Device1
#
bridge-domain 10
vxlan vni 5010
#
undo shutdown
ip address 192.168.1.1 255.255.255.0
#

undo shutdown
#
rewrite pop single
bridge-domain 10
#
interface LoopBack1
ip address 2.2.2.2 255.255.255.255
#
interface Nve1
source 2.2.2.2
vni 5010 head-end peer-list 4.4.4.4
#
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
#
return
#
sysname Device2
#
undo shutdown
ip address 192.168.1.2 255.255.255.0
#
undo shutdown
ip address 192.168.2.1 255.255.255.0
#
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 192.168.1.0 0.0.0.255
network 192.168.2.0 0.0.0.255
#
return
#
sysname Device3
#
bridge-domain 10
vxlan vni 5010
#
undo shutdown
ip address 192.168.2.2 255.255.255.0
#
undo shutdown
#
rewrite pop single
bridge-domain 10
#
interface LoopBack1
ip address 4.4.4.4 255.255.255.255
#
interface Nve1
source 4.4.4.4
#

ospf 1
area 0.0.0.0
network 4.4.4.4 0.0.0.0
network 192.168.2.0 0.0.0.255
#
return
4.2.12.2 Example for Configuring Users on Different Network Segments to

Communicate Through a VXLAN Layer 3 Gateway
This section provides an example for configuring users on different network segments to
communicate through a VXLAN Layer 3 gateway. To achieve this, the default gateway
address of the users must be the IP address of the BDIF interface of the Layer 3 gateway.
centers. VM1 on Server1 belongs to VLAN10, and VM1 on Server2 belongs to VLAN20.
VM1 on Server1 and VM1 on Server2 reside on different network segments. To allow VM1s
in different data centers to communicate with each other, configure a VXLAN tunnel between
Device1 and Device2 and one between Device2 and Device3.
Figure 4-87 Configuring users on different network segments to communicate through a

VXLAN Layer 3 gateway
NOTE
Interface 1 and Interface 2 stand for GE 1/0/1 and GE 1/0/2, respectively.
Loopback 1
3.3.3.3/32
Device2
in
n el ace1 1 terfa VXL 19 in
e1 /2 4 T un ter 2/24 92.1 ce2 AN 2.16 terfa
f
ac .1 N in .1. 68 Tu 8 c
t erf 68.1 XLA 68 .2 . nn .2.2 e1
n 1 1 e / 2
i 2.1 V 2. /24 l 4
19 19
Device1 L3 Gateway IP Address: Device3

interface2
interface2
Loopback 1 BDIF10:192.168.10.10/24 Loopback 1

2.2.2.2/32 BDIF20:192.168.20.10/24 4.4.4.4/32
VSwitch VSwitch
VM1 ... VMm VM1 ... VMn
VLAN 10 VLAN 20
Server1 Server2
192.168.10.1/24 192.168.20.1/24
NVE

1. Configure a routing protocol on Device1, Device2, and Device3 to allow them to
2. Configure a service access point on Device1 and Device3 to differentiate service traffic.
3. Configure a VXLAN tunnel on Device1, Device2, and Device3 to forward service
traffic.
4. Configure Device2 as a VXLAN Layer 3 gateway to allow users on different network
segments to communicate.
Data Preparation
l BD IDs (10 and 20)
l VNI IDs (5010 and 5020)
Procedure
Assign an IP address to each interface on Device1, Device2, and Device3 according to Figure
4-87.
[*HUAWEI] commit
[*Device1] ospf
[*Device1] commit
Repeat these steps for Device2 and Device3. For configuration details, see Configuration
After OSPF is configured, the devices can use OSPF to learn the IP addresses of loopback
interfaces of each other and successfully ping each other. The following example shows the
command output on Device1 after it pings Device3:



0.00% packet loss
Step 2 Configure a service access point on Device1 and Device3.

[*Device1] commit
section.
Step 3 Configure a VXLAN tunnel on Device1, Device2, and Device3.
[*Device1-bd10] vxlan vni 5010
[*Device1] commit
[*Device2] commit
[*Device3] commit
Step 4 Configure Device2 as a VXLAN Layer 3 gateway.

[~Device2] interface vbdif 10
[*Device2-Vbdif10] ip address 192.168.10.10 24
[*Device2-Vbdif10] quit
[*Device2] interface vbdif 20

[*Device2-Vbdif20] commit

After completing the configurations, run the display vxlan vni and display vxlan tunnel
commands on Device1, Device2, and Device3 to check the VNI status and VXLAN tunnel
information, respectively. The VNIs are Up on Device1, Device2, and Device3. The following
example shows the command output on Device2.
VNI BD-ID State
---------------------------------------
5010 10 up
5020 20 up
Number of Vxlan tunnel : 2
---------------------------------------------------------------------
4026531841 2.2.2.2 3.3.3.3 up static 0029h30m
40265318412 2.2.2.2 4.4.4.4 up static 0029h44m
VM1 in VLAN10 on Server1 has the default gateway address as the IP address
192.168.10.10/24 of BDIF10.
VM1 in VLAN20 on Server2 has the default gateway address as the IP address
192.168.20.10/24 of BDIF20.
Therefore, VM1s on different network segments can communicate.
----End
Configuration Files
#
sysname Device1
#
bridge-domain 10
vxlan vni 5010
#
undo shutdown
ip address 192.168.1.1 255.255.255.0
#
undo shutdown
ip address 10.1.1.2 255.255.255.0
#
rewrite pop single
bridge-domain 10
#
interface LoopBack1
ip address 2.2.2.2 255.255.255.255
#
interface Nve1
source 2.2.2.2
#
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
network 192.168.1.0 0.0.0.255

#
return
#
sysname Device2
#
bridge-domain 10
vxlan vni 5010
#
bridge-domain 20
vxlan vni 5020
#
interface Vbdif10
ip address 192.168.10.10 255.255.255.0
#
interface Vbdif20
ip address 192.168.20.10 255.255.255.0
#
undo shutdown
ip address 192.168.1.2 255.255.255.0
#
undo shutdown
ip address 192.168.2.1 255.255.255.0
#
interface LoopBack1
ip address 3.3.3.3 255.255.255.255
#
interface Nve1
source 3.3.3.3
#
ospf 1
area 0.0.0.0
network 3.3.3.3 0.0.0.0
network 192.168.1.0 0.0.0.255
network 192.168.2.0 0.0.0.255
#
return
#
sysname Device3
#
bridge-domain 20
vxlan vni 5020
#
undo shutdown
ip address 192.168.2.2 255.255.255.0
#
undo shutdown
ip address 10.2.1.2 255.255.255.0
#
rewrite pop single
bridge-domain 20
#
interface LoopBack1
ip address 4.4.4.4 255.255.255.255
#
interface Nve1
source 4.4.4.4
#

ospf 1
area 0.0.0.0
network 4.4.4.4 0.0.0.0
network 10.2.1.0 0.0.0.255
network 192.168.2.0 0.0.0.255
#
return
4.2.12.3 Example for Configuring VXLAN in Centralized Gateway Mode Using

BGP EVPN
This section provides an example for configuring VXLAN in centralized gateway mode for
dynamic tunnel establishment so that users on the same network segment or different network
On the network shown in Figure 4-88, an enterprise has VMs deployed in different areas of a
data center. VM 1 on Server 1 belongs to VLAN 10, VM 1 on Server 2 belongs to VLAN 20,
and VM 1 on Server 3 belongs to VLAN 30. Server 1 and Server 2 reside on different
network segments, whereas Server 2 and Server 3 reside on the same network segment. To
allow VM 1s on different servers to communicate with each other, configure IPv6 VXLAN in
centralized gateway mode.
Figure 4-88 VXLAN in centralized gateway mode for dynamic tunnel establishment
NOTE
In this example, most configurations are performed on Device 1, Device 2, and Device 3. NE40Es can
be deployed as these devices.
Interface 1, Interface 2, and Interface 3 represent GE 1/0/1, GE 1/0/2, and GE 1/0/3, respectively.

L3 Gateway IP Address:
BDIF10:192.168.10.10/24
Loopback 1
BDIF20:192.168.20.10/24
3.3.3.3/32
Device2
2/ 1
int 2.1
1. ce
24
19
er 68
8. rfa
fa .2
1 6 te
c e .1
2. in
2 /
VX
19
LA
24
el
N
nn
19
Tu
Tu
VX /24
2.
nn
in 8.2.
16 e1
N
1
16
te 2
el
LA
1.
2 . fa c
rfa /2
8.
1 9 te r
ce 4
Device1
in
1
Loopback 1
2.2.2.2/32 Device3
VXLAN Tunnel Loopback 1
in 4.4.4.4/32
t er
interface2
e2
fa
ce
rfac
3
inte
VM1 ... VMm VM1 ... VMm ...

VM1 VMn
VLAN 10 VLAN 30 VLAN 20

192.168.10.1/24 192.168.20.2/24 192.168.20.1/24
NVE
1. Configure a routing protocol on Device 1, Device 2, and Device 3 to allow them to
2. Configure a service access point on Device 1 and Device 3 to differentiate service traffic.
4. Configure EVPN instances.
6. Configure Device 2 as a Layer 3 VXLAN gateway.
Data Preparation
To complete the configuration, you need the following data.
l VMs' VLAN IDs (10, 20, and 30)


l EVPN instances' RDs (11:1, 12:1, 31:1, and 31:2) and RTs (1:1 and 2:2)
Procedure
Assign an IP address to each interface on Device 1, Device 2, and Device 3 according to
Figure 4-88.
# Configure Device 1.
[*HUAWEI] commit
[*Device1] ospf
[*Device1] commit
Repeat this step for Device 2 and Device 3. For configuration details, see Configuration
After OSPF is configured, the devices can use OSPF to learn the IP addresses of each other's
loopback interfaces and successfully ping each other. The following example shows the
command output on Device 1 after it pings Device 3:

0.00% packet loss
Step 2 Configure a service access point on Device 1 and Device 3.

[*Device1] bridge-domain 20


[*Device1] commit
Repeat this step for Device 3. For configuration details, see Configuration Files in this
section.
Step 3 Configure a BGP EVPN peer relationship.
[~Device1] bgp 100
[*Device1-bgp] peer 3.3.3.3 as-number 100
[*Device1-bgp] peer 3.3.3.3 connect-interface LoopBack1
[*Device1-bgp] l2vpn-family evpn
[*Device1-bgp-af-evpn] peer 3.3.3.3 enable
[*Device1-bgp-af-evpn] peer 3.3.3.3 advertise encap-type vxlan
[*Device1-bgp-af-evpn] quit
[*Device1-bgp] quit
[*Device1] commit
Step 4 Configure an EVPN instance on Device 1, Device 2, and Device 3.
[~Device1] evpn vpn-instance evrf3 bd-mode
[*Device1-evpn-instance-evrf3] route-distinguisher 11:1
[*Device1-evpn-instance-evrf3] vpn-target 1:1
[*Device1-evpn-instance-evrf3] quit
[*Device1-bd10] vxlan vni 5010 split-horizon-mode
[*Device1-bd10] evpn binding vpn-instance evrf3
[*Device1] evpn vpn-instance evrf4 bd-mode
[*Device1] commit
[~Device1] interface nve 1
[*Device1-Nve1] vni 5010 head-end peer-list protocol bgp
[*Device1] commit
section.
Step 6 Configure Device 2 as a Layer 3 VXLAN gateway.

[~Device2] interface vbdif 10

[*Device2] interface vbdif 20
[*Device2-Vbdif20] commit

After completing the configurations, run the display vxlan tunnel and display vxlan vni
commands on Device 1, Device 2, and Device 3 to check the VXLAN tunnel and VNI
information, respectively. The VNIs are Up. The following example shows the command
output on Device 1.
-------------------------------------------------------------------
4026531843 2.2.2.2 4.4.4.4 up dynamic 0035h21m
4026531844 2.2.2.2 3.3.3.3 up dynamic 0036h10m
Number of vxlan vni : 2
VNI BD-ID State
---------------------------------------
5010 10 up
5020 20 up
Run the display bgp evpn all routing-table command to check EVPN route information.
[~Device1] display bgp evpn all routing-table

EVN address family:

*> 0:32:2.2.2.2 0.0.0.0
*> 0:32:2.2.2.2 0.0.0.0
*>i 0:32:3.3.3.3 3.3.3.3
*>i 0:32:3.3.3.3 3.3.3.3
*>i 0:32:4.4.4.4 4.4.4.4
VM1s on different servers can communicate.
----End
Configuration Files
#
sysname Device1
#


#
bridge-domain 10
#
#
bridge-domain 20
#
undo shutdown
ip address 192.168.1.1 255.255.255.0
#
rewrite pop single
bridge-domain 10
#
rewrite pop single
bridge-domain 20
#
interface LoopBack1
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
peer 4.4.4.4 enable
#
l2vpn-family evpn
peer 3.3.3.3 enable
peer 4.4.4.4 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
#
return
#
sysname Device2
#


#
bridge-domain 10
#
#
bridge-domain 20
#
interface Vbdif10
ip address 192.168.10.10 255.255.255.0
#
interface Vbdif20
ip address 192.168.20.10 255.255.255.0
#
undo shutdown
ip address 192.168.1.2 255.255.255.0
#
undo shutdown
ip address 192.168.2.1 255.255.255.0
#
interface LoopBack1
ip address 3.3.3.3 255.255.255.255
#
interface Nve1
source 3.3.3.3
#
bgp 100
#
ipv4-family unicast
peer 2.2.2.2 enable
peer 4.4.4.4 enable
#
l2vpn-family evpn
peer 2.2.2.2 enable
peer 4.4.4.4 enable
#
ospf 1
area 0.0.0.0
network 3.3.3.3 0.0.0.0
network 192.168.1.0 0.0.0.255
network 192.168.2.0 0.0.0.255
#
return
#
sysname Device3
#

#
bridge-domain 20
#
undo shutdown
ip address 192.168.2.2 255.255.255.0
#
rewrite pop single
bridge-domain 20
#
interface LoopBack1
ip address 4.4.4.4 255.255.255.255
#
interface Nve1
source 4.4.4.4
#
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 4.4.4.4 0.0.0.0
network 192.168.2.0 0.0.0.255
#
return
4.2.12.4 Example for Configuring VXLAN in Distributed Gateway Mode Using

BGP EVPN
This section provides an example for configuring VXLAN in distributed gateway mode using
BGP EVPN.
Distributed VXLAN gateways can be configured to address problems that occur in legacy
centralized VXLAN gateway networking, for example, forwarding paths are not optimal, and
the ARP entry specification is a bottleneck.
centers. VM 1 on Server 1 belongs to VLAN 10, and VM 1 on Server 2 belongs to VLAN 20.
VM 1 on Server 1 and VM 1 on Server 2 reside on different network segments. To allow
VM1s in different data centers to communicate with each other, configure distributed
VXLAN gateways.

Figure 4-89 VXLAN in distributed gateway mode using BGP EVPN

NOTE
In this example, most configurations are performed on Device 1, Device 2, and Device 3. Devices can be
deployed as these devices.
Interface 1 and Interface 2 represent GE 1/0/0 and GE 1/0/1, respectively.
LoopBack0
Device 1
LoopBack0 LoopBack0
VXLAN Tunnel
Device 2 Device 3
VSwitch VSwitch
VM1 ... VMm ...

VM1 VMn
VLAN 10 VLAN 20
Server1 Server2
NVE

Device 1 GigabitEthernet 1/0/1 192.168.2.2/24

Device 2

Device 3

1. Configure IGP to run between Device 1 and Device 2 and between Device 1 and Device
3.
2. Configure a service access point on Device 2 and Device 3 to differentiate service traffic.
3. Specify Device 1 as a BGP EVPN peer for Device 2 and Device 3.
4. Specify Device 2 and Device 3 as BGP EVPN peers for Device 1 and configure Device 2
and Device 3 as RR clients.
5. Configure VPN and EVPN instances on Device 2 and Device 3.
6. Configure an ingress replication list on Device 2 and Device 3.
7. Configure Device 2 and Device 3 as Layer 3 VXLAN gateways.
8. Configure IRB route advertisement on Device 1, Device 2, and Device 3.
Data Preparation
To complete the configuration, you need the following data.
l VNI ID in VPN instance (5010)
Procedure
Step 1 Configure IGP routing protocol.
Assign an IP address to each interface on Device 1, Device 2, and Device 3 according to
Figure 4-89.
[*HUAWEI] commit
[~Device1] isis 1
[*Device1-isis-1] network-entity 10.0000.0000.0001.00
[*Device1-isis-1] quit
[*Device1] commit
[*Device1-LoopBack0] isis enable 1
[*Device1] interface GigabitEthernet1/0/0
[*Device1-GigabitEthernet1/0/0] isis enable 1
[*Device1] interface GigabitEthernet1/0/1
[*Device1-GigabitEthernet1/0/1] isis enable 1
[*Device1] commit
Repeat the other steps for Device 2 and Device 3. For configuration details, see
Step 2 Configure a service access point on Device 2 and Device 3.

[*Device2] interface GigabitEthernet1/0/1.1 mode l2
[*Device2] commit
section.
Step 3 Specify Device 1 as a BGP EVPN peer for Device 2 and Device 3.
# Specify Device 1 as a BGP EVPN peer for Device 2.

[~Device2] bgp 100
[*Device2-bgp-af-evpn] policy vpn-target
[*Device2-bgp] quit
[*Device2] commit
section.
Step 4 Specify Device 2 and Device 3 as BGP EVPN peers for Device 1 and configure them as RR
clients.
# Specify BGP EVPN peers for Device 1.

[~Device1] bgp 100
[*Device1-bgp-af-evpn] peer 2.2.2.2 reflect-client
[*Device1-bgp-af-evpn] peer 3.3.3.3 reflect-client
[*Device1-bgp-af-evpn] undo policy vpn-target
[*Device1-bgp] quit
[*Device1] commit
Step 5 Configure VPN and EVPN instances on Device 2 and Device 3.

# Configure VPN and EVPN instances on Device 2.
[~Device2] ip vpn-instance vpn1
[*Device2-vpn-instance-vpn1] vxlan vni 5010
[*Device2-vpn-instance-vpn1] ipv4-family
[*Device2-vpn-instance-vpn1-af-ipv4] route-distinguisher 11:11
[*Device2-vpn-instance-vpn1-af-ipv4] vpn-target 11:1 evpn
[*Device2-vpn-instance-vpn1-af-ipv4] quit
[*Device2-vpn-instance-vpn1] quit
[*Device2] evpn vpn-instance evrf3 bd-mode

[*Device2] commit
section.
Step 6 Configure an ingress replication list on Device 2 and Device 3.
# Configure an ingress replication list on Device 2.
[~Device2] interface nve 1
[*Device2] commit
section.
Step 7 Configure Device 2 and Device 3 as Layer 3 VXLAN gateways.
[~Device2] interface Vbdif10
[*Device2-Vbdif10] ip binding vpn-instance vpn1
[*Device2-Vbdif10] ip address 10.1.1.1 255.255.255.0
[*Device2-Vbdif10] arp distribute-gateway enable
[*Device2-Vbdif10] arp collect host enable
[*Device2] commit
Repeat this step for Device 3. Note that the IP addresses of VBDIF interfaces on Device 2 and
Device 3 must belong to different network segments. For configuration details, see
Step 8 Configure IRB route advertisement on Device 1, Device 2, and Device 3.
[~Device1] bgp 100
[~Device1-bgp] l2vpn-family evpn
[~Device1-bgp-af-evpn] peer 2.2.2.2 advertise irb
[*Device1-bgp-af-evpn] peer 3.3.3.3 advertise irb
[*Device1-bgp] quit
[*Device1] commit
[~Device2] bgp 100
[~Device2-bgp] l2vpn-family evpn
[~Device2-bgp-af-evpn] peer 1.1.1.1 advertise irb
[*Device2-bgp] quit
[*Device2] commit
section.
After completing the configurations, run the display vxlan tunnel command on Device 2 and
Device 3 to check VXLAN tunnel information. The following example uses the command
output on Device 2.
[*Device2] display vxlan tunnel

--------------------------------------------------------------------
4026531841 2.2.2.2 3.3.3.3 up dynamic 0026h29m
Run the display bgp evpn all routing-table command to check EVPN route information.
[*Device2]display bgp evpn all routing-table

EVN address family:

*> 0:48:00e0-fc00-0002:0:0.0.0.0 0.0.0.0
*>i 0:48:00e0-fc00-0003:0:0.0.0.0 3.3.3.3
EVN address family:

*> 0:32:2.2.2.2 0.0.0.0
*>i 0:32:3.3.3.3 3.3.3.3
VM1s on different servers can communicate.
----End
Configuration Files
#
sysname Device1
#
isis 1
network-entity 10.0000.0000.0001.00
#
undo shutdown
ip address 192.168.3.2 255.255.255.0
isis enable 1
#
undo shutdown
ip address 192.168.2.2 255.255.255.0
isis enable 1
#
interface LoopBack0
ip address 1.1.1.1 255.255.255.255
isis enable 1
#
bgp 100
#
l2vpn-family evpn
peer 2.2.2.2 enable


peer 3.3.3.3 enable
#
return
#
sysname Device2
#
isis 1
network-entity 10.0000.0000.0002.00
#
ipv4-family
vxlan vni 5010
#
#
bridge-domain 10
#
interface Vbdif10
ip address 10.1.1.1 255.255.255.0
#
undo shutdown
ip address 192.168.2.1 255.255.255.0
isis enable 1
#
rewrite pop single
bridge-domain 10
#
interface LoopBack0
ip address 2.2.2.2 255.255.255.255
isis enable 1
#
interface Nve1
source 2.2.2.2
#
bgp 100
#
l2vpn-family evpn
policy vpn-target
peer 1.1.1.1 enable
#
return

#
sysname Device3
#
isis 1
network-entity 10.0000.0000.0003.00
#
ipv4-family
vxlan vni 5010
#
#
bridge-domain 20
#
interface Vbdif20
ip address 20.1.1.1 255.255.255.0
#
undo shutdown
ip address 192.168.3.1 255.255.255.0
isis enable 1
#
rewrite pop single
bridge-domain 20
#
interface LoopBack0
ip address 3.3.3.3 255.255.255.255
isis enable 1
#
interface Nve1
source 3.3.3.3
#
bgp 100
#
l2vpn-family evpn
policy vpn-target
peer 1.1.1.1 enable
#
return
4.2.12.5 Example for Configuring Three-Segment VXLAN to Implement Layer 3

Interworking
This section provides an example for configuring three-segment VXLAN to enable Layer 3
communication between VMs that belong to the different DCs.

In Figure 4-90, DC-A and DC-B reside in different BGP ASs. To allow intra-DC VM
communication (VMa1 and VMa2 in DC-A, and VMb1 and VMb2 in DC-B), configure BGP
EVPN on the devices in the DCs to create VXLAN tunnels between distributed gateways. To
allow VMs in different DCs (for example, VMa1 and VMb2) to communicate with each
other, configure BGP EVPN on Leaf2 and Leaf3 to create another VXLAN tunnel. In this
way, three-segment VXLAN tunnels are established to implement DC interconnection (DCI).
Figure 4-90 Three-segment VXLAN

NOTE
Interface1, interface2, and interface3 in this example stand for GE 1/0/0, GE 2/0/0, and GE 3/0/0,
respectively.
Loopback1 Loopback1
IP network
interface2
Device1 Device2
interface2
Loopback1 Loopback1
AS: 100 AS: 200
DC-A Spine1
Spine2 DC-B

interface1 interf interf
ace3 ace3
interface2 interface2 Leaf2 Leaf3 interface2 interface2
VMa1 VMa2 VMb1 VMb2
Device Interface Name IP Address Device Interface IP Address

Name Name Name
Device GE 1/0/0 192.168.50. Device GE 1/0/0 192.168.60.

1 1/24 2 1/24

Device Interface Name IP Address Device Interface IP Address

Name Name Name
GE 2/0/0 192.168.1.1/ GE 2/0/0 192.168.1.2/

24 24
Loopback1 1.1.1.1/32 Loopback1 2.2.2.2/32
GE 1/0/0 192.168.10. GE 1/0/0 192.168.30.

1/24 1/24
Spine1 GE 2/0/0 192.168.20. Spine2 GE 2/0/0 192.168.40.

1/24 1/24
GE 1/0/0 192.168.10. GE 1/0/0 192.168.40.

2/24 2/24
Leaf1 Leaf4
GE 2/0/0 - GE 2/0/0 -
GE 1/0/0 192.168.20. GE 1/0/0 192.168.30.

2/24 2/24
GE 2/0/0 - GE 2/0/0 -
Leaf2 Leaf3
GE 3/0/0 192.168.50. GE 3/0/0 192.168.60.
2/24 2/24
1. Assign an IP address to each interface.

2. Configure an IGP to ensure route reachability between nodes.
3. Configure static routes to achieve interworking between DCs.
4. Configure BGP EVPN on Leaf1 and Leaf2 in DC-A and Leaf3 and Leaf4 in DC-B to
create VXLAN tunnels between distributed gateways.
5. Configure BGP EVPN on DC edge nodes Leaf2 and Leaf3 to create a VXLAN tunnel
between DCs.
Data Preparation
l VLAN IDs of the VMs

l BD IDs
l VXLAN network identifiers (VNIs) in BDs and VNIs in VPN instances

Procedure
Step 1 Assign an IP address to each interface (including each loopback interface) on each node.
Step 2 Configure an IGP. In this example, OSPF is used.
Step 3 Configure static routes to achieve interworking between DCs.
Step 4 Configure BGP EVPN on Leaf1 and Leaf2 in DC-A and Leaf3 and Leaf4 in DC-B to create
VXLAN tunnels between distributed gateways.
1. Configure a service access point on leaf nodes.
# Configure Leaf1.
[~Leaf1] bridge-domain 10
[*Leaf1-bd10] quit
[*Leaf1] interface GigabitEthernet 2/0/0.1 mode l2
[*Leaf1-GigabitEthernet2/0/0.1] encapsulation dot1q vid 10
[*Leaf1-GigabitEthernet2/0/0.1] rewrite pop single
[*Leaf1-GigabitEthernet2/0/0.1] bridge-domain 10
[*Leaf1-GigabitEthernet2/0/0.1] quit
[*Leaf1] commit
The configurations of Leaf2, Leaf3, and Leaf4 are similar to the configurations of Leaf1.
2. Configure an IBGP EVPN peer relationship between Leaf1 and Leaf2 in DC-A and
between Leaf3 and Leaf4 in DC-B.
# Configure Leaf1.
[~Leaf1] bgp 100
[*Leaf1-bgp] peer 6.6.6.6 as-number 100
[*Leaf1-bgp] peer 6.6.6.6 connect-interface LoopBack 1
[*Leaf1-bgp] l2vpn-family evpn
[*Leaf1-bgp-af-evpn] peer 6.6.6.6 enable
[*Leaf1-bgp-af-evpn] peer 6.6.6.6 advertise encap-type vxlan
[*Leaf1-bgp-af-evpn] quit
[*Leaf1-bgp] quit
[*Leaf1] commit
3. Configure VPN instances and EVPN instances on leaf nodes.
# Configure Leaf1.
[~Leaf1] ip vpn-instance vpn1
[*Leaf1-vpn-instance-vpn1] vxlan vni 5010
[*Leaf1-vpn-instance-vpn1] ipv4-family
[*Leaf1-vpn-instance-vpn1-af-ipv4] route-distinguisher 11:11
[*Leaf1-vpn-instance-vpn1-af-ipv4] vpn-target 1:1
[*Leaf1-vpn-instance-vpn1-af-ipv4] vpn-target 11:1 evpn
[*Leaf1-vpn-instance-vpn1-af-ipv4] quit
[*Leaf1-vpn-instance-vpn1] quit
[*Leaf1] evpn vpn-instance evrf1 bd-mode
[*Leaf1-evpn-instance-evrf1] route-distinguisher 10:1
[*Leaf1-evpn-instance-evrf1] vpn-target 11:1
[*Leaf1-evpn-instance-evrf1] quit
[*Leaf1] bridge-domain 10

[*Leaf1-bd10] vxlan vni 10 split-horizon-mode

[*Leaf1-bd10] evpn binding vpn-instance evrf1
[*Leaf1-bd10] quit
[*Leaf1] commit
4. Configure an ingress replication list on leaf nodes.
# Configure Leaf1.
[~Leaf1] interface nve 1
[*Leaf1-Nve1] source 5.5.5.5
[*Leaf1-Nve1] vni 10 head-end peer-list protocol bgp
[*Leaf1-Nve1] quit
[*Leaf1] commit
5. Configure leaf nodes as Layer 3 VXLAN gateways.
# Configure Leaf1.
[~Leaf1] interface vbdif10
[*Leaf1-Vbdif10] ip binding vpn-instance vpn1
[*Leaf1-Vbdif10] ip address 10.1.1.1 24
[*Leaf1-Vbdif10] arp distribute-gateway enable
[*Leaf1-Vbdif10] arp collect host enable
[*Leaf1-Vbdif10] quit
[*Leaf1] commit
6. Configure IRB route advertisement on leaf nodes.
# Configure Leaf1.
[~Leaf1] bgp 100
[*Leaf1-bgp-af-evpn] peer 6.6.6.6 advertise irb
[*Leaf1-bgp] quit
[*Leaf1] commit
# Configure Leaf2.
[~Leaf2] bgp 100
[*Leaf2-bgp] quit
[*Leaf2] commit
The configurations of Leaf4 are similar to the configurations of Leaf1, and those of
Leaf3 are similar to the configurations of Leaf2. For configuration details, see
After the configurations are complete, run the display vxlan tunnel command on leaf
nodes to check VXLAN tunnel information. The following example uses the command
output on Leaf1. The command output shows that the VXLAN tunnel is Up.
[~Leaf1] display vxlan tunnel

---------------------------------------------------------------------
4026531841 5.5.5.5 6.6.6.6 up dynamic 00:05:36
Step 5 Configure BGP EVPN on Leaf2 and Leaf3 to create a VXLAN tunnel.
1. Configure an EBGP EVPN peer relationship between Leaf2 and Leaf3.
NOTE
As VPN and EVPN instances have been configured on Leaf2 and Leaf3, you only need to
configure an EBGP EVPN peer relationship between Leaf2 and Leaf3 to ensure IP route
reachability.
# Configure Leaf2.
[~Leaf2] bgp 100
[*Leaf2-bgp] peer 7.7.7.7 connect-interface LoopBack1
[*Leaf2-bgp] peer 7.7.7.7 ebgp-max-hop 255
[*Leaf2-bgp] quit
[*Leaf2] commit
# Configure Leaf3.
[~Leaf3] bgp 200
[*Leaf3-bgp] peer 6.6.6.6 connect-interface LoopBack1
[*Leaf3-bgp] quit
[*Leaf3] commit
2. Configure the regeneration of IRB routes and IP prefix routes in EVPN routing tables.
# Configure Leaf2.
[~Leaf2] bgp 100
[*Leaf2-bgp-af-evpn] peer 5.5.5.5 import reoriginate
[*Leaf2-bgp-af-evpn] peer 5.5.5.5 advertise route-reoriginated evpn ip
[*Leaf2-bgp] quit
[*Leaf2] commit
# Configure Leaf3.
[~Leaf3] bgp 200
[*Leaf3-bgp] quit
[*Leaf3] commit

Run the display vxlan tunnel command on leaf nodes to check VXLAN tunnel information.
The following example uses the command output on Leaf2. The command output shows that
the VXLAN tunnels are Up.


---------------------------------------------------------------------
4026531841 6.6.6.6 5.5.5.5 up dynamic 00:11:01
4026531842 6.6.6.6 7.7.7.7 up dynamic 00:12:11
Run the display ip routing-table vpn-instance vpn1 command to check IP route

information. The following example uses the command output on Leaf1.
[~Leaf1] display ip routing-table vpn-instance vpn1
route
------------------------------------------------------------------------------
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
20.1.1.0/24 IBGP 255 0 RD 6.6.6.6 VXLAN
30.1.1.0/24 IBGP 255 0 RD 6.6.6.6 VXLAN
40.1.1.0/24 IBGP 255 0 RD 6.6.6.6 VXLAN
After the configurations are complete, VMa1 and VMb2 can communicate with each other.
----End
Configuration Files
l Spine1 configuration file
#
sysname Spine1
#
undo shutdown
ip address 192.168.10.1 255.255.255.0
#
undo shutdown
ip address 192.168.20.1 255.255.255.0
#
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 192.168.10.0 0.0.0.255
network 192.168.20.0 0.0.0.255
#
return
l Leaf1 configuration file

#
sysname Leaf1
#
#
ipv4-family

vxlan vni 5010
#
bridge-domain 10
#
interface Vbdif10
ip address 10.1.1.1 255.255.255.0
#
undo shutdown
ip address 192.168.10.2 255.255.255.0
#
undo shutdown
#
rewrite pop single
bridge-domain 10
#
interface LoopBack1
ip address 5.5.5.5 255.255.255.255
#
interface Nve1
source 5.5.5.5
#
bgp 100
#
ipv4-family unicast
peer 6.6.6.6 enable
#
import-route direct
#
l2vpn-family evpn
peer 6.6.6.6 enable
#
ospf 1
area 0.0.0.0
network 5.5.5.5 0.0.0.0
network 192.168.10.0 0.0.0.255
#
return
#
sysname Leaf2
#
#

ipv4-family
vxlan vni 5010
#
bridge-domain 20
#
interface Vbdif20
ip address 20.1.1.1 255.255.255.0
#
undo shutdown
ip address 192.168.20.2 255.255.255.0
#
undo shutdown
#
rewrite pop single
bridge-domain 20
#
undo shutdown
ip address 192.168.50.2 255.255.255.0
#
interface LoopBack1
ip address 6.6.6.6 255.255.255.255
#
interface Nve1
source 6.6.6.6
#
bgp 100
#
ipv4-family unicast
peer 5.5.5.5 enable
peer 7.7.7.7 enable
#
import-route direct
#
l2vpn-family evpn
peer 5.5.5.5 enable
peer 7.7.7.7 enable


#
ospf 1
area 0.0.0.0
network 6.6.6.6 0.0.0.0
network 192.168.20.0 0.0.0.255
#
ip route-static 7.7.7.7 255.255.255.255 192.168.50.1
ip route-static 192.168.1.0 255.255.255.0 192.168.50.1
ip route-static 192.168.60.0 255.255.255.0 192.168.50.1
#
return
l Spine2 configuration file
#
sysname Spine2
#
undo shutdown
ip address 192.168.30.1 255.255.255.0
#
undo shutdown
ip address 192.168.40.1 255.255.255.0
#
interface LoopBack1
ip address 4.4.4.4 255.255.255.255
#
ospf 1
area 0.0.0.0
network 4.4.4.4 0.0.0.0
network 192.168.30.0 0.0.0.255
network 192.168.40.0 0.0.0.255
#
return
#
sysname Leaf3
#
#
ipv4-family
vxlan vni 5010
#
bridge-domain 10
#
interface Vbdif10
ip address 30.1.1.1 255.255.255.0
#
undo shutdown
ip address 192.168.30.2 255.255.255.0
#
undo shutdown

#
rewrite pop single
bridge-domain 10
#
undo shutdown
ip address 192.168.60.2 255.255.255.0
#
interface LoopBack1
ip address 7.7.7.7 255.255.255.255
#
interface Nve1
source 7.7.7.7
#
bgp 200
#
ipv4-family unicast
peer 6.6.6.6 enable
peer 8.8.8.8 enable
#
import-route direct
#
l2vpn-family evpn
peer 6.6.6.6 enable
peer 8.8.8.8 enable
#
ospf 1
area 0.0.0.0
network 7.7.7.7 0.0.0.0
network 192.168.30.0 0.0.0.255
#
ip route-static 6.6.6.6 255.255.255.255 192.168.60.1
ip route-static 192.168.1.0 255.255.255.0 192.168.60.1
ip route-static 192.168.50.0 255.255.255.0 192.168.60.1
#
return
#
sysname Leaf4
#
#
ipv4-family


vxlan vni 5010
#
bridge-domain 20
#
interface Vbdif20
ip address 40.1.1.1 255.255.255.0
#
undo shutdown
ip address 192.168.40.2 255.255.255.0
#
undo shutdown
#
rewrite pop single
bridge-domain 20
#
interface LoopBack1
ip address 8.8.8.8 255.255.255.255
#
interface Nve1
source 8.8.8.8
#
bgp 200
#
ipv4-family unicast
peer 7.7.7.7 enable
#
import-route direct
#
l2vpn-family evpn
peer 7.7.7.7 enable
#
ospf 1
area 0.0.0.0
network 8.8.8.8 0.0.0.0
network 192.168.40.0 0.0.0.255
#
return
#
sysname Device1
#
undo shutdown
ip address 192.168.50.1 255.255.255.0
#
undo shutdown
ip address 192.168.1.1 255.255.255.0

#
interface LoopBack1
ip address 1.1.1.1 255.255.255.255
#
ip route-static 6.6.6.6 255.255.255.255 192.168.50.2
ip route-static 7.7.7.7 255.255.255.255 192.168.1.2
ip route-static 192.168.60.0 255.255.255.0 192.168.1.2
#
return

#
sysname Device2
#
undo shutdown
ip address 192.168.60.1 255.255.255.0
#
undo shutdown
ip address 192.168.1.2 255.255.255.0
#
interface LoopBack1
ip address 2.2.2.2 255.255.255.255
#
ip route-static 6.6.6.6 255.255.255.255 192.168.1.1
ip route-static 7.7.7.7 255.255.255.255 192.168.60.2
ip route-static 192.168.50.0 255.255.255.0 192.168.1.1
#
return
4.2.12.6 Example for Configuring Three-Segment VXLAN to Implement Layer 2

Interworking
This section provides an example for configuring three-segment VXLAN tunnels to enable
Layer 2 communication between VMs that belong to the different DCs.
On the network shown in Figure 4-91, BGP EVPN is configured within DC A and DC B to
establish VXLAN tunnels. BGP EVPN is also configured on Leaf 2 and Leaf 3 to establish a
VXLAN tunnel between them. To enable communication between VM 1 and VM 2,
implement Layer 2 communication between DC A and DC B. In this example, the VXLAN
tunnel in DC A uses the VNI 10, and that in DC B uses the VNI 20. VNI conversion must be
Implemented before establishing a VXLAN tunnel between Leaf 2 and Leaf 3.
Figure 4-91 Configuring three-segment VXLAN to implement Layer 2 interworking

NOTE

DC A Spine2 DC B
Spine1
interface1 interface1 Leaf2 Leaf3 interface1 interface1

VSwitch VSwitch
VM1 VM2
VLAN 10 VLAN 10
AS 100 AS 200

Device Interface IP Address Device Interface IP Address
GE 1/0/0 192.168.10. GE 1/0/0 192.168.30.

1/24 1/24
Spine 1 Spine 2
GE 2/0/0 192.168.20. GE 2/0/0 192.168.40.
1/24 1/24
GE 1/0/0 192.168.10. GE 1/0/0 192.168.40.

2/24 2/24
Leaf 1 Leaf 4
GE 2/0/0 - GE 2/0/0 -
Loopback 1 1.1.1.1/32 Loopback 1 4.4.4.4/32
GE 1/0/0 192.168.20. GE 1/0/0 192.168.30.

2/24 2/24
Leaf 2 GE 2/0/0 192.168.50. Leaf 3 GE 2/0/0 192.168.50.

1/24 2/24
Loopback 1 2.2.2.2/32 Loopback 1 3.3.3.3/32
1. Assign an IP address to each interface.
2. Configure an IGP to allow devices to communicate with each other.
3. Configure static routes to achieve interworking between DCs.
4. Configure BGP EVPN within DC A and DC B to establish VXLAN tunnels.

5. Configure BGP EVPN on Leaf 2 and Leaf 3 to establish a VXLAN tunnel between them.
6. Configure Leaf 2 and Leaf 3 to advertise routes that are re-originated by the EVPN
address family to BGP EVPN peers.
Data Preparation
l VLAN IDs of the VMs

l BD IDs
l VNI IDs associated with BDs within DC A and DC B
l Number of the AS to which DC A and DC B belong
l Name of the SHG to which Leaf 2 and Leaf 3 belong
Procedure
Step 1 Assign an IP address to each interface (including the loopback interface) on each node.
Step 2 Configure an IGP. In this example, OSPF is used.
Step 3 Configure static routes to achieve interworking between DCs.
Step 4 Configure BGP EVPN within DC A and DC B to create VXLAN tunnels.

1. Configuring service access points on Leaf 1 and Leaf 4.
# Configure Leaf 1.
[~Leaf1] bridge-domain 10
[*Leaf1-bd10] quit
[*Leaf1] interface GE 2/0/0.1 mode l2
[*Leaf1-GE2/0/0.1] encapsulation dot1q vid 10
[*Leaf1-GE2/0/0.1] rewrite pop single
[*Leaf1-GE2/0/0.1] bridge-domain 10
[*Leaf1-GE2/0/0.1] quit
[*Leaf1] commit
Repeat these steps for Leaf 4. For configuration details, see "Configuration Files" in
this section.
2. Configure BGP EVPN peer relationships between Leaf 1 and Leaf 2 in DC A and
between Leaf 3 and Leaf 4 in DC B.
# Configure a BGP EVPN peer relationship on Leaf 1.

[~Leaf1] bgp 100
[*Leaf1-bgp] quit
[*Leaf1] commit

Repeat these steps for Leaf 2, Leaf 3, and Leaf 4. For configuration details, see
3. Configure EVPN an instance on each leaf node.
# Configure Leaf 1.
[~Leaf1] evpn vpn-instance evrf1 bd-mode
[*Leaf1-evpn-instance-evrf1] route-distinguisher 10:1
[*Leaf1-evpn-instance-evrf1] vpn-target 11:1
[*Leaf1-evpn-instance-evrf1] quit
[*Leaf1] bridge-domain 10
[*Leaf1-bd10] vxlan vni 10 split-horizon-mode
[*Leaf1-bd10] evpn binding vpn-instance evrf1
[*Leaf1-bd10] quit
[*Leaf1] commit
4. Configure an ingress replication list on each leaf node.
# Configure Leaf 1.
[~Leaf1] interface nve 1
[*Leaf1-Nve1] source 1.1.1.1
[*Leaf1-Nve1] vni 10 head-end peer-list protocol bgp
[*Leaf1-Nve1] quit
[*Leaf1] commit
Step 5 Configure BGP EVPN on Leaf 2 and Leaf 3 to establish a VXLAN tunnel between them.
# Configure Leaf 2.
[~Leaf2] bgp 100
[*Leaf2-bgp] network 2.2.2.2 32
[*Leaf2-bgp] quit
[*Leaf2] commit
# Configure Leaf 3.
[~Leaf3] bgp 200
[*Leaf3-bgp] network 3.3.3.3 32
[*Leaf3-bgp] quit
[*Leaf3] commit
Step 6 Configure Leaf 2 and Leaf 3 to advertise routes that are re-originated by the EVPN address
family to BGP EVPN peers..
1. Configure an SHG to which the BGP EVPN peers belong.

# Configure Leaf 2.
[~Leaf2] bgp 100
[~Leaf2-bgp] l2vpn-family evpn
[~Leaf2-bgp-af-evpn] peer 3.3.3.3 split-group sg1
[*Leaf2-bgp-af-evpn] commit
# Configure Leaf 3.
[~Leaf3] bgp 200
[~Leaf3-bgp] l2vpn-family evpn
[~Leaf3-bgp-af-evpn] peer 2.2.2.2 split-group sg1
[*Leaf3-bgp-af-evpn] commit
2. Enable the function to re-originate MAC routes.
# Configure Leaf 2.
[~Leaf2-bgp-af-evpn] peer 1.1.1.1 import reoriginate
[*Leaf2-bgp-af-evpn] peer 1.1.1.1 advertise route-reoriginated evpn mac
[*Leaf2-bgp] quit
[*Leaf2] commit
# Configure Leaf 3.
[~Leaf3-bgp-af-evpn] peer 4.4.4.4 import reoriginate
[*Leaf3-bgp] quit
[*Leaf3] commit
Run the display vxlan tunnel command on each leaf node to view information about the
VXLAN tunnels. The following example uses the command output on Leaf 2. The command
output shows that the VXLAN tunnels are Up.
----------------------------------------------------------------------------------
-
4026531924 2.2.2.2 1.1.1.1 up dynamic 00:39:19
4026531925 2.2.2.2 3.3.3.3 up dynamic 00:39:09
Run the display vxlan peer command on Leaf 2 to view information about the VXLAN
peers.
[~Leaf2] display vxlan peer
Number of peers : 2
Vni ID Source Destination Type Out Vni ID
-------------------------------------------------------------------------------
10 2.2.2.2 1.1.1.1 dynamic 10
10 2.2.2.2 3.3.3.3 dynamic 20
After the preceding configurations are complete, Layer 2 communication can be implemented
between VM 1 and VM 2.
----End

Configuration Files
l Spine 1 configuration file
#
sysname Spine1
#
interface GE1/0/0
undo shutdown
ip address 192.168.10.1 255.255.255.0
#
interface GE2/0/0
undo shutdown
ip address 192.168.20.1 255.255.255.0
#
ospf 1
area 0.0.0.0
network 192.168.10.0 0.0.0.255
network 192.168.20.0 0.0.0.255
#
return
l Leaf 1 configuration file

#
sysname Leaf1
#
#
bridge-domain 10
#
interface GE1/0/0
undo shutdown
ip address 192.168.10.2 255.255.255.0
#
interface GE2/0/0
undo shutdown
#
interface GE2/0/0.1 mode l2
rewrite pop single
bridge-domain 10
#
interface LoopBack1
ip address 1.1.1.1 255.255.255.255
#
interface Nve1
source 1.1.1.1
#
bgp 100
#
ipv4-family unicast
peer 2.2.2.2 enable
#
l2vpn-family evpn
peer 2.2.2.2 enable
#
ospf 1
area 0.0.0.0
network 1.1.1.1 0.0.0.0
network 192.168.10.0 0.0.0.255

#
return
#
sysname Leaf2
#
#
bridge-domain 10
#
interface GE1/0/0
undo shutdown
ip address 192.168.20.2 255.255.255.0
#
interface GE2/0/0
undo shutdown
ip address 192.168.50.1 255.255.255.0
#
interface LoopBack1
ip address 2.2.2.2 255.255.255.255
#
interface Nve1
source 2.2.2.2
#
bgp 100
#
ipv4-family unicast
network 2.2.2.2 255.255.255.255
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
peer 3.3.3.3 split-group sg1
#
ospf 1
area 0.0.0.0
network 2.2.2.2 0.0.0.0
network 192.168.20.0 0.0.0.255
#
ip route-static 3.3.3.3 255.255.255.255 192.168.50.2
#
return
l Spine 2 configuration file
#
sysname Spine2
#
interface GE1/0/0
undo shutdown

ip address 192.168.30.1 255.255.255.0

#
interface GE2/0/0
undo shutdown
ip address 192.168.40.1 255.255.255.0
#
ospf 1
area 0.0.0.0
network 192.168.30.0 0.0.0.255
network 192.168.40.0 0.0.0.255
#
return
#
sysname Leaf3
#
#
bridge-domain 10
#
interface GE1/0/0
undo shutdown
ip address 192.168.30.2 255.255.255.0
#
interface GE2/0/0
undo shutdown
ip address 192.168.50.2 255.255.255.0
#
interface LoopBack1
ip address 3.3.3.3 255.255.255.255
#
interface Nve1
source 3.3.3.3
#
bgp 200
#
ipv4-family unicast
network 3.3.3.3 255.255.255.255
peer 2.2.2.2 enable
peer 4.4.4.4 enable
#
l2vpn-family evpn
peer 2.2.2.2 enable
peer 2.2.2.2 split-group sg1
peer 4.4.4.4 enable
#
ospf 1
area 0.0.0.0
network 3.3.3.3 0.0.0.0
network 192.168.30.0 0.0.0.255

#
ip route-static 2.2.2.2 255.255.255.255 192.168.50.1
#
return

#
sysname Leaf4
#
#
bridge-domain 10
#
interface GE1/0/0
undo shutdown
ip address 192.168.40.2 255.255.255.0
#
interface GE2/0/0
undo shutdown
#
interface GE2/0/0.1 mode l2
rewrite pop single
bridge-domain 10
#
interface LoopBack1
ip address 4.4.4.4 255.255.255.255
#
interface Nve1
source 4.4.4.4
#
bgp 200
#
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 192.168.40.0 0.0.0.255
#
return
4.2.12.7 Example for Configuring the Static VXLAN Active-Active Scenario

(Layer 2 Communication)
homed to a VXLAN network. Operators can enhance VXLAN access reliability to improve
the stability of user services so that rapid convergence can be implemented in case of a fault.

As shown in Figure 4-92, CE1 is dual-homed to PE1 and PE2 through an Eth-Trunk link;
PE1 and PE2 uses a virtual address as the source VTEP address of an NVE interface, namely,
an Anycast VTEP address. In this way, the CPE is aware of only one remote NVE interface
and establishes a static VXLAN tunnel with the Anycast VTEP address.
(Layer 2 communication)
NOTE
Interface 1, interface 2, and interface 3 stand for GigabitEthernet1/0/1, GigabitEthernet1/0/2, and

GigabitEthernet1/0/3, respectively.
Enterprise
Site
interface3
CPE
VXLAN Tunnel
in
3
te
ce
rfa
rfa
ce
te
PE1 3
in
PE2
Anycast VTEP
Bypass VXLAN Tunnel
i nt e2
er f ac
ac er f
e2 i nt
int
e rfa e2
ac
ce erf
1 int
CE2 CE1 CE3
Table 4-16 Interface IP address


GigabitEthernet 1/0/2 -
CE1 GigabitEthernet 1/0/1 -
CPE GigabitEthernet 1/0/1 10.1.1.2/24
GigabitEthernet1/0/3 -
1. Configure an IGP on the PEs and CPE to implement network connectivity.

2. On PE1 and PE2, Configure service access points and set the same ESI for the access
links of CE1 so that CE1 is dual-homed to PE1 and PE2.
3. Configure the same virtual Anycast VTEP address on PE1 and PE2 as the source NVE
interface address to establish a VXLAN tunnel with the CPE. Establish static VXLAN
tunnels between the PEs and CPE so that the PEs and CEP can communicate.
4. Establish an EVPN peer relationship between PE1 and PE2 to receive and send VXLAN
EVPN routes.
5. Configure EVPN instances in BD mode on PE1 and PE2 and bind the BD to the
corresponding EVPN instances.
6. Enable the inter-chassis VXLAN function on PE1 and PE2, configure different bypass
addresses for PE1 and PE2, and establish a bypass VXLAN tunnel on PE1 and PE2 so
that PE1 and PE2 can communicate.
7. (Optional) Configure a UDP port on the PEs to prevent the receiving of replicated
packets.
8. Configure a BD on PE1 and PE2.

9. On PE1 and PE2, enable routes to be sent to carry extended community attributes and the
function of redirecting received routes carrying the extended VLAN community
attribute.
10. On PE1 and PE2, enable FRR for MAC routes between the local and remote ends. When
a PE fails, the downstream traffic of the CPE can quickly switch to the other PE.
11. (Optional) When PE1 and PE2 establish an EBGP peer relationship, set the function of
not changing the next-hop addresses of routes. When PE1 and PE2 establish an IBGP
peer relationship, this function is not required.
Data Preparation
l Names of VPN and EVPN instances
l VPN targets of the received and sent routes in VPN and EVPN instances
Procedure
addresses.
For detailed configurations, see Configuration Files.
Step 2 Configure an IGP at the AC side and on the backbone. In this example, IS-IS is adopted.
Step 3 Configure EVPN.
Configure PE1.
[~PE1] evpn
[*PE1-evpn] quit
[*PE1] commit
Step 4 Configure a BGP peer relationship between PE1 and PE2.
# Configure PE1.
[~PE1] bgp 100
[*PE1-bgp] ipv4-family unicast
[*PE1-bgp-af-ipv4] undo synchronization
[*PE1-bgp-af-ipv4] peer 2.2.2.2 enable
[*PE1-bgp-af-ipv4] quit
[*PE1-bgp-af-evpn] undo policy vpn-target
[*PE1-bgp] quit
[*PE1] commit

Step 5 Create a VXLAN tunnel.

1. Configure EVPN instances and bind them to BDs on the PEs.
# Configure PE1.
[*PE1-bd10] quit
[*PE1] commit
section.
2. Enable ingress replication on the PEs.
# Configure the CPE.

[~CPE] interface nve 1
[*CPE-Nve1] source 4.4.4.4
[*CPE-Nve1] vni 10 head-end peer-list 3.3.3.3
[*CPE-Nve1] quit
[*CPE] commit
# Configure PE1.
[*PE1-Nve1] vni 10 head-end peer-list 4.4.4.4
[*PE1-Nve1] quit
[*PE1] commit
section.
Step 6 Configure CE1 to access the PEs.
Configure PE1.
[*PE1] e-trunk 1
[*PE1-Eth-Trunk1] mac-address 00e0-fc12-3456
[*PE1-Eth-Trunk1] esi 0000.0001.0001.0001.0001
[*PE1] interface eth-trunk1.1 mode l2
[~PE1] commit


Run the display vxlan tunnel command on PE1 to view VXLAN tunnel information. The
following example uses the command output on PE1.
----------------------------------------------------------------------------------
-
4026531842 1.1.1.1 2.2.2.2 up dynamic 00:43:14
4026531843 3.3.3.3 4.4.4.4 up static 00:08:30
----End
Configuration Files
#
sysname PE1
#
evpn enhancement port 1345
#
evpn
bypass-vxlan enable
#
#
bridge-domain 10
#
e-trunk 1
priority 10
#
isis 1
network-entity 10.0000.0000.0001.00
frr
#
mode lacp-static
e-trunk 1
esi 0000.0001.0001.0001.0001
#
rewrite pop single
bridge-domain 10
#
undo shutdown
ip address 10.1.20.1 255.255.255.0
isis enable 1
#
undo shutdown
eth-trunk 1

#
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 LoopBack2
ip address 3.3.3.3 255.255.255.255
isis enable 1
#
interface Nve1
source 3.3.3.3
#
bgp 100
#
ipv4-family unicast
peer 2.2.2.2 enable
#
l2vpn-family evpn
peer 2.2.2.2 enable
#
return
#
sysname PE2
#
#
evpn
bypass-vxlan enable
#
#
bridge-domain 10
#
e-trunk 1
priority 10
#
isis 1
network-entity 10.0000.0000.0002.00
frr
#
mode lacp-static
e-trunk 1


esi 0000.0001.0001.0001.0001
#
rewrite pop single
bridge-domain 10
#
undo shutdown
ip address 10.1.20.2 255.255.255.0
isis enable 1
#
undo shutdown
eth-trunk 1
#
undo shutdown
ip address 10.1.2.1 255.255.255.0
isis enable 1
#
interface LoopBack1
ip address 2.2.2.2 255.255.255.255
isis enable 1
#
interface LoopBack2
ip address 3.3.3.3 255.255.255.255
isis enable 1
#
interface Nve1
source 3.3.3.3
#
bgp 100
#
ipv4-family unicast
peer 1.1.1.1 enable
#
l2vpn-family evpn
peer 1.1.1.1 enable
#
return
#
sysname CE
#
vlan batch 1 to 4094
#
portswitch
#
undo shutdown
eth-trunk 1
#

undo shutdown
eth-trunk 1
#
return
l CPE configuration file
#
sysname CPE
#
bridge-domain 10
#
isis 1
network-entity 20.0000.0000.0001.00
frr
#
undo shutdown
ip address 10.1.1.2 255.255.255.0
isis enable 1
#
undo shutdown
ip address 10.1.2.2 255.255.255.0
isis enable 1
#
undo shutdown
esi 0000.0000.0000.0000.0017
#
rewrite pop single
bridge-domain 10
#
interface LoopBack1
ip address 4.4.4.4 255.255.255.255
isis enable 1
#
interface Nve1
source 4.4.4.4
#
return
4.2.12.8 Example for Configuring the Static VXLAN Active-Active Scenario

(Layer 3 Communication)
a fault.
In Figure 4-93, the CPE establishes static VXLAN tunnels with PE1 and PE2. An EVPN peer
relationship and a bypass VXLAN tunnel are established between PE1 and PE2. CE1 is dual-
homed to PE1 and PE2. When a PE fails, traffic can rapidly switch to the other PE.

(Layer 3 communication)
NOTE
Interface 1, interface 2, and interface 3 stand for GigabitEthernet1/0/1, GigabitEthernet1/0/2 , and

CPE
VXLAN Tunnel
in
3
te
ce
rfa
rfa
ce
te
PE1 3
in
PE2
Anycast VTEP
Bypass VXLAN Tunnel
i nt e2
er f fac
ac er
e2 int
int e2
er f
ac er fa c
e1 i nt
CE2 CE1 CE3

CE GigabitEthernet 1/0/1 192.168.1.2/24

CPE GigabitEthernet 1/0/1 10.1.1.2/24
1. Configure an IGP on the PEs and CPE to implement Layer 3 network connectivity.
2. Configure CE1 to import routes from the VPN instances of the PEs through BGP.
Configure CE1 to be dual-homed to PE1 and PE2.
3. Configure service access points on PE1 and PE2.
4. Configure the same virtual Anycast VTEP address on PE1 and PE2 as the source NVE
interface address to establish a VXLAN tunnel with the CPE. Establish static VXLAN
tunnels between the PEs and CPE so that the PEs and CEP can communicate.
5. Enable the inter-chassis VXLAN function on PE1 and PE2, configure different bypass
addresses for PE1 and PE2, and establish a BGP EVPN peer relationship and a bypass
VXLAN tunnel between PE1 and PE2 so that PE1 and PE2 can communicate.
6. Enable auto-FRR in the BGP VPN address family view of PE1 and PE2. When a PE
fails, the downstream traffic of the CPE can quickly switch to the other PE.
Procedure
addresses.
Step 2 Configure an IGP on the DCI backbone. In this example, IS-IS is adopted.
Configure PE1.
[~PE1] evpn
[*PE1-evpn] quit
[*PE1] commit
Step 4 Configuring VPN Instances
Configure PE1.
[~PE1] ip vpn-instance vpn1

[*PE1-vpn-instance-vpn1-af-ipv4] vpn-target 1:1 import-extcommunity
[*PE1-vpn-instance-vpn1-af-ipv4] vpn-target 1:1 export-extcommunity
[*PE1-vpn-instance-vpn1-af-ipv4] vpn-target 1:1 import-extcommunity evpn
[*PE1-vpn-instance-vpn1-af-ipv4] vpn-target 1:1 export-extcommunity evpn
[*PE1] commit
Step 5 Configure BGP and BGP VPN peer relationships.
# Configure CE1.
[~CE1] bgp 200
[*CE1-bgp] peer 192.168.1.1 ebgp-max-hop 255
[*CE1-bgp] peer 192.168.2.1 ebgp-max-hop 255
[*CE1-bgp] network 5.5.5.5 255.255.255.255
[*CE1-bgp] quit
[*CE1] commit
# Configure PE1.
[~PE1] bgp 100
[*PE1-bgp-vpn1] auto-frr
[*PE1-bgp-vpn1] peer 192.168.1.2 as-number 200
[*PE1-bgp-vpn1] peer 192.168.1.2 connect-interface GigabitEthernet1/0/2
[*PE1-bgp] quit
[*PE1] commit
Step 6 Create static VXLAN tunnels between the CPE and PE1 and between the CPE and PE2 and a
bypass VXLAN tunnel between PE1 and PE2.
[*CPE] interface nve 1
[*CPE-Nve1] quit
[*CPE] commit
# Configure PE1.
[~PE1] bridge-domain 10
[*PE1-bd10] quit
[*PE1] interface nve 1
[*PE1-Nve1] quit
[*PE1] commit

Step 7 Configure VBDIF interfaces and bind them to VPN instances.
# Configure PE1.
[~PE1] interface vbdif10
[*PE1-Vbdif10] ip address 10.1.10.1 24
[*PE1-Vbdif10] mac-address 00e0-fc12-3456
[*PE1-Vbdif10] quit
[*PE1] commit
Run the display vxlan tunnel command on PE1 to view VXLAN tunnel information. The
following example uses the command output on PE1.
Tunnel ID Source Destination State TyPE Uptime
-------------------------------------------------------------------
4026531841 1.1.1.1 2.2.2.2 up dynamic 0033h12m
4026531842 3.3.3.3 4.4.4.4 up dynamic 0033h12m
----End
Configuration Files
#
sysname PE1
#
evpn
bypass-vxlan enable
#
ipv4-family
vxlan vni 100
#
bridge-domain 10
#
isis 1
network-entity 10.0000.0000.0010.00
frr
#
isis 2 vpn-instance vpn1
network-entity 20.0000.0000.0010.00
#
interface Vbdif10
ip address 10.1.10.1 255.255.255.0
isis enable 2
#

undo shutdown
ip address 10.1.20.1 255.255.255.0
isis enable 1
#
undo shutdown
ip address 192.168.1.1 255.255.255.0
isis enable 2
#
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 LoopBack2
ip address 3.3.3.3 255.255.255.255
isis enable 1
#
interface Nve1
source 3.3.3.3
#
bgp 100
#
ipv4-family unicast
peer 2.2.2.2 enable
#
auto-frr
peer 192.168.1.2 connect-interface GigabitEthernet1/0/2
#
l2vpn-family evpn
peer 2.2.2.2 enable
#
return
#
sysname PE2
#
evpn
bypass-vxlan enable
#
ipv4-family
vxlan vni 100
#
bridge-domain 10
#

isis 1
network-entity 10.0000.0000.0020.00
frr
#
isis 2 vpn-instance vpn1
network-entity 20.0000.0000.0020.00
#
interface Vbdif10
ip address 10.1.10.1 255.255.255.0
isis enable 2
#
undo shutdown
ip address 10.1.20.2 255.255.255.0
isis enable 1
#
undo shutdown
ip address 192.168.2.1 255.255.255.0
isis enable 2
#
undo shutdown
ip address 10.1.2.1 255.255.255.0
isis enable 1
#
interface LoopBack1
ip address 2.2.2.2 255.255.255.255
isis enable 1
#
interface LoopBack2
ip address 3.3.3.3 255.255.255.255
isis enable 1
#
interface Nve1
source 3.3.3.3
#
bgp 100
#
ipv4-family unicast
peer 1.1.1.1 enable
#
auto-frr
peer 192.168.2.2 connect-interface GigabitEthernet1/0/2
#
l2vpn-family evpn
peer 1.1.1.1 enable
#
return
#
sysname CE1
#

isis 2
network-entity 20.0000.0000.0030.00
#
undo shutdown
ip address 192.168.1.2 255.255.255.0
isis enable 2
#
undo shutdown
ip address 192.168.2.2 255.255.255.0
isis enable 2
#
interface LoopBack1
ip address 5.5.5.5 255.255.255.255
#
bgp 200
#
ipv4-family unicast
network 5.5.5.5 255.255.255.255
peer 1.1.1.1 enable
peer 2.2.2.2 enable
#
return
#
sysname CPE
#
bridge-domain 10
#
isis 1
network-entity 20.0000.0000.0001.00
frr
#
undo shutdown
ip address 10.1.1.2 255.255.255.0
isis enable 1
#
undo shutdown
ip address 10.1.2.2 255.255.255.0
isis enable 1
#
interface LoopBack1
ip address 4.4.4.4 255.255.255.255
isis enable 1
#
interface Nve1
source 4.4.4.4
#
return
4.2.12.9 Example for Configuring the VXLAN over IPSec Active-Active Scenario
homed to a VXLAN network, which enhances VXLAN access reliability and implements
rapid convergence in case of a fault. IPSec encapsulation implements encrypted packet
transmission, securing packet transmission.

As shown in Figure 4-94, CE1 is dual-homed to PE1 and PE2; PE1 and PE2 uses a virtual
address as the source VTEP address of an NVE interface. In this way, the CPE is aware of
only one remote NVE interface and establishes a static VXLAN tunnel with the Anycast
VTEP address. VXLAN packets are transmitted in plain text in the network, which is
insecure. IPSec encryption implements encrypted packet transmission, securing packet
transmission.
Figure 4-94 Networking diagram for configuring the VXLAN over IPSec active-active
scenario
NOTE
Interface 1, interface 2, and interface 3 stand for GigabitEthernet1/0/1, GigabitEthernet1/0/2, and

CPE
interface1
VXLAN Tunnel
VXLAN
over
IPSec
in
te
3
rfa
ce
rfa
ce
PE1 3
te
PE2
in
Anycast VTEP
Bypass VXLAN Tunnel
VLAN int 2
e rfa ce
ce r fa
2 i n te
Trunk
int 2
e rfa ce
ce t e rfa
1 in
CE2 CE1 CE3
Device Interface IP address

Device Interface IP address
CE1 GigabitEthernet 1/0/1 192.168.1.2/24
CPE GigabitEthernet1/0/1 10.1.1.2/24
1. Configure an IGP on the CEs, PEs, and CPE to implement Layer 2 network connectivity.
2. Configure service access points on PE1 and PE2 so that CE1 can be dual-homed to PE1
and PE2.
3. Establish static VXLAN tunnels between the PEs and CPE so that the PEs and CEP can
communicate.
4. Establish a bypass VXLAN tunnel between PE1 and PE2 so that PE1 and PE2 can
communicate.
5. (Optional) Configure a UDP port on the PEs to prevent the receiving of replicated
packets.
6. Configure IPSec on the PEs and CPE and establish IPSec tunnels.
Data Preparation

l EVPN instance names
l VPN targets of the received and sent routes in EVPN instances
l Preshared key
l Security protocol, encryption algorithm, and authentication algorithm to be adopted by
IPSec

l Encryption algorithm and authentication algorithm that an IKE proposal uses
Procedure
addresses.
Step 2 Configure an IGP at the AC side and on the backbone. In this example, IS-IS is adopted.
Configure PE1.
[~PE1] evpn
[*PE1-evpn] quit
[*PE1] commit
Step 4 Configure a BGP peer relationship between PE1 and PE2.
# Configure PE1.
[~PE1] bgp 100
[*PE1-bgp] ipv4-family unicast
[*PE1-bgp-af-ipv4] undo synchronization
[*PE1-bgp-af-ipv4] peer 2.2.2.2 enable
[*PE1-bgp-af-ipv4] quit
[*PE1-bgp] quit
[*PE1] commit
Step 5 Create a VXLAN tunnel.
1. Configure EVPN instances and bind them to BDs on the PEs.
# Configure PE1.
[*PE1-bd10] quit
[*PE1] commit
section.

2. Enable ingress replication on the PEs.

[~CPE] interface nve 1
[*CPE-Nve1] quit
[*CPE] commit
# Configure PE1.
[*PE1-Nve1] quit
[*PE1] commit
section.
Step 6 Configure CE1 to access the PEs.
Configure PE1.
[*PE1] e-trunk 1
[*PE1-Eth-Trunk1] esi 0000.0001.0001.0001.0001
[~PE1] commit
# Configure PE1.
[~PE1] evpn enhancement port 1345
[*PE1] commit
Step 8 Configure IPSec on PE1.

1. Enable IPSec.
[~PE1] license
[*PE1-license] active ipsec slot 2
[*PE1-license] quit
[*PE1] commit

2. Configure advanced ACL 3000.

[~PE1] acl 3000
[*PE1-acl-adv-3000] rule 5 permit ip source 3.3.3.3 0 destination 4.4.4.4 0
[*PE1acl-adv-3000] quit
[*PE1] commit
3. Configure an IPSec proposal named tran1.
[~PE1] ipsec proposal tran1
[*PE1-ipsec-proposal-tran1] encapsulation-mode tunnel
[*PE1-ipsec-proposal-tran1] transform esp
[*PE1-ipsec-proposal-tran1] esp authentication-algorithm sha2-256
[*PE1-ipsec-proposal-tran1] esp encryption-algorithm aes 256
[*PE1-ipsec-proposal-tran1] quit
[*PE1] commit
4. Configure an IKE proposal numbered 10.
[~PE1] ike proposal 10
[*PE1-ike-proposal-10] authentication-method pre-share
[*PE1-ike-proposal-10] authentication-algorithm sha2-256
[*PE1-ike-proposal-10] integrity-algorithm hmac-sha2-256
[*PE1-ike-proposal-10] dh group14
[*PE1-ike-proposal-10] quit
[*PE1] commit
5. Configure an IKE peer named b.
[~PE1] ike peer b
[*PE1-ike-peer-b] ike-proposal 10
[*PE1-ike-peer-b] remote-address 4.4.4.4
[*PE1-ike-peer-b] pre-shared-key abcde
[*PE1-ike-peer-b] quit
[*PE1] commit
NOTE
By default, both IKEv1 and IKEv2 are enabled on the NE40E, and IKEv2 takes precedence over
IKEv1. If the remote device does not support IKEv2, disable IKEv2 on the local device and use
IKEv1 to perform the IKE negotiation.
The pre-shared key configured on the local device must be the same as that configured on the IKE
peer.
6. Configure an IPSec policy named map1 and numbered 10.
[~PE1] ipsec policy map1 10 isakmp
[*PE1-ipsec-policy-isakmp-map1-10] security acl 3000
[*PE1-ipsec-policy-isakmp-map1-10] proposal tran1
[*PE1-ipsec-policy-isakmp-map1-10] ike-peer b
[~PE1-ipsec-policy-isakmp-map1-10] local-address 3.3.3.3
[*PE1-ipsec-policy-isakmp-map1-10] quit
[*PE1] commit
7. Configure an IPsec service instance group named group1.
– For the VSUF-80/VSUF-160, perform the following configurations:
[~PE1] service-location 1
[*PE1-service-location-1] location slot 2 card 0
[*PE1-service-location-1] commit
[~PE1-service-location-1] quit
– For the LPUF-51-E/LPUI-51-E/LPUI-51-S, perform the following configurations:
[~PE1] service-location 1
[*PE1-service-location-1] location slot 2
[*PE1-service-location-1] commit
[~PE1-service-location-1] quit
[~PE1] service-instance-group group1
[*PE1-service-instance-group-group1] service-location 1
[*PE1-service-instance-group-group1] quit
[*PE1] commit
8. Create and configure an IPSec tunnel.
[*PE1-Tunnel1] ip address 11.1.1.1 255.255.255.255

[*PE1-Tunnel1] tunnel-protocol ipsec

[*PE1-Tunnel1] ipsec policy map1 service-instance-group group1
[*PE1-Tunnel1] quit
[*PE1] commit
9. Configure static routes that import traffic into the tunnel.

[~PE1] ip route-static 6.6.6.6 255.255.255.255 GigabitEthernet1/0/3 10.1.1.2
[*PE1] ip route-static 4.4.4.4 255.255.255.255 Tunnel1 6.6.6.6
[*PE1] commit
section.
Step 9 Configure IPSec on the CPE.
1. Enable IPSec.
[~CPE] license
[*CPE-license] active ipsec slot 2
[*CPE-license] quit
[*CPE] commit
2. Configure advanced ACL 3000.

[~CPE] acl 3000
[*CPE-acl-adv-3000] rule 5 permit ip
[*CPE-acl-adv-3000] quit
[*CPE] commit
3. Configure an IPSec proposal named tran1.

[~CPE] ipsec proposal tran1
[*CPE-ipsec-proposal-tran1] encapsulation-mode tunnel
[*CPE-ipsec-proposal-tran1] transform esp
[*CPE-ipsec-proposal-tran1] esp authentication-algorithm sha2-256
[*CPE-ipsec-proposal-tran1] esp encryption-algorithm aes 256
[*CPE-ipsec-proposal-tran1] quit
[*CPE] commit
4. Configure an IKE proposal numbered 10.

[~CPE] ike proposal 10
[*CPE-ike-proposal-10] authentication-method pre-share
[*CPE-ike-proposal-10] authentication-algorithm sha2-256
[*CPE-ike-proposal-10] integrity-algorithm hmac-sha2-256
[*CPE-ike-proposal-10] dh group14
[*CPE-ike-proposal-10] quit
[*CPE] commit
5. Configure an IKE peer named 1.

[~CPE] ike peer 1
[*CPE-ike-peer-1] ike-proposal 10
[*CPE-ike-peer-1] remote-address 5.5.5.5
[*CPE-ike-peer-1] pre-shared-key abcde
[*CPE-ike-peer-1] quit
[*CPE] commit
NOTE
By default, both IKEv1 and IKEv2 are enabled on the NE40E, and IKEv2 takes precedence over
IKEv1. If the remote device does not support IKEv2, disable IKEv2 on the local device and use
IKEv1 to perform the IKE negotiation.
The pre-shared key configured on the local device must be the same as that configured on the IKE
peer.
6. Configure an IPSec policy template named temp1.
[~CPE] ipsec policy-template temp1 1
[*CPE-ipsec-policy-templet-temp1-1] security acl 3000
[*CPE-ipsec-policy-templet-temp1-1] proposal tran1
[*CPE-ipsec-policy-templet-temp1-1] ike-peer 1
[*CPE-ipsec-policy-templet-temp1-1] local-address 6.6.6.6
[*CPE-ipsec-policy-templet-temp1-1] quit
[*CPE] commit

7. Create a security policy based on the policy template.

[~CPE] ipsec policy 1 1 isakmp template temp1
[*CPE] commit
8. Configure an IPsec service instance group named group1.

– For the VSUF-80/VSUF-160, perform the following configurations:
[~CPE] service-location 1
[*CPE-service-location-1] location slot 2 card 0
[*CPE-service-location-1] commit
[~CPE-service-location-1] quit
– For the LPUF-51-E/LPUI-51-E/LPUI-51-S, perform the following configurations:

[~CPE] service-location 1
[*CPE-service-location-1] location slot 2
[*CPE-service-location-1] commit
[~CPE-service-location-1] quit
[~CPE] service-instance-group group1
[*CPE-service-instance-group-group1] service-location 1
[*CPE-service-instance-group-group1] quit
[*CPE] commit
9. Create and configure an IPSec tunnel.

[~CPE interface Tunnel 1
[*CPE-Tunnel1] ip address 22.2.2.2 255.255.255.255
[*CPE-Tunnel1] tunnel-protocol ipsec
[*CPE-Tunnel1] ipsec policy 1 service-instance-group group1
[*CPE-Tunnel1] quit
[*CPE] commit
10. Configure static routes that import traffic into the tunnel.
[~CPE] ip route-static 5.5.5.5 255.255.255.255 GigabitEthernet1/0/1
192.168.1.1
[*CPE] commit
----End
Configuration Files
#
sysname PE1
#
#
evpn
bypass-vxlan enable
#
#
bridge-domain 10
#
acl number 3000
rule 5 permit ip source 3.3.3.3 0 destination 4.4.4.4 0
#
e-trunk 1
priority 10
#

isis 1
network-entity 10.0000.0000.0001.00
frr
#
#
license
active ipsec slot 2
service-location
1
location slot 2 card 0//For the VSUF-80/VSUF-160
location slot 2 //For the LPUF-51-E/LPUI-51-E/LPUI-51-S
#
service-instance-group
group1
service-location
1
#
ike proposal 10
encryption-algorithm aes-cbc 256
dh group14
authentication-algorithm sha2-256
integrity-algorithm hmac-sha2-256
#
ike peer b
pre-shared-key %$%$THBGMJK2659z"C(T{J"-,.2n%$%$
ike-proposal 10
remote-address 6.6.6.6
#
ipsec proposal tran1
esp authentication-algorithm sha2-256
esp encryption-algorithm aes 256
#
ipsec policy map1 10 isakmp
security acl 3000
ike-peer b
proposal tran1
local-address 5.5.5.5
#
mode lacp-static
e-trunk 1
esi 0000.0001.0001.0001.0001
#
rewrite pop single
bridge-domain 10
#
undo shutdown
ip address 10.1.20.1 255.255.255.0
#
undo shutdown
eth-trunk 1
#
undo shutdown
ip address 10.1.1.1 255.255.255.0
#
interface LoopBack0

ip address 1.1.1.1 255.255.255.255

isis enable 1
#
interface LoopBack1
ip address 3.3.3.3 255.255.255.255
isis enable 1
#
interface LoopBack2
ip address 5.5.5.5 255.255.255.255
isis enable 1
#
interface Nve1
source 3.3.3.3
#
bgp 100
#
ipv4-family unicast
peer 2.2.2.2 enable
#
l2vpn-family evpn
peer 2.2.2.2 enable
#
interface Tunnel1
ip address 11.1.1.1
255.255.255.0
tunnel-protocol ipsec
ipsec policy map1 service-instance-group group1
#
ip route-static 6.6.6.6 255.255.255.255 GigabitEthernet1/0/3 10.1.1.2
ip route-static 4.4.4.4 255.255.255.255 Tunnel1 6.6.6.6
#
return
#
sysname PE2
#
#
evpn
bypass-vxlan enable
#
#
bridge-domain 10
#
acl number 3000
rule 5 permit ip source 3.3.3.3 0 destination 4.4.4.4 0
#
license
active ipsec slot 2

service-location
1
#
group1
service-location 1
#
ike proposal 10
dh group14
#
ike peer b
ike-proposal 10
#
#
ipsec policy map1 10 isakmp
security acl 3000
ike-peer b
proposal tran1
#
e-trunk 1
priority 10
#
isis 1
network-entity 10.0000.0000.0002.00
frr
#
mode lacp-static
e-trunk 1
esi 0000.0001.0001.0001.0001
#
rewrite pop single
bridge-domain 10
#
undo shutdown
ip address 10.1.20.2 255.255.255.0
#
undo shutdown
eth-trunk 1
#
undo shutdown
ip address 10.1.2.1 255.255.255.0
#
interface LoopBack0
ip address 2.2.2.2 255.255.255.255

isis enable 1
#
interface LoopBack1
ip address 3.3.3.3 255.255.255.255
isis enable 1
#
interface LoopBack2
ip address 5.5.5.5 255.255.255.255
isis enable 1
#
interface Nve1
source 3.3.3.3
#
bgp 100
#
ipv4-family unicast
peer 1.1.1.1 enable
#
l2vpn-family evpn
peer 1.1.1.1 enable
#
interface Tunnel1
ip address 11.1.1.1 255.255.255.0
ipsec policy map1 service-instance-group group1
#
ip route-static 4.4.4.4 255.255.255.255 Tunnel1 6.6.6.6
#
return
#
sysname CE
#
#
portswitch
#
undo shutdown
eth-trunk 1
#
undo shutdown
eth-trunk 1
#
return
#
sysname CPE
#
bridge-domain 10
#

acl number 3000

rule 5 permit ip
#
license
active ipsec slot 2
#
service-location
1
#
group1
service-location 1
#
ike proposal 10
dh group14
#
ike peer 1
ike-proposal 10
#
#
ipsec policy-template temp1 1
#
security acl 3000
ike-peer 1
proposal tran1
#
ipsec policy 1 1 isakmp template temp1
#
isis 1
network-entity 20.0000.0000.0001.00
frr
#
undo shutdown
ip address 10.1.1.2 255.255.255.0
isis enable 1
#
interface GigabitEthernet 1/0/1.1 mode l2
rewrite pop single
bridge-domain 10
#
interface LoopBack0
ip address 4.4.4.4 255.255.255.255
isis enable 1
#
interface LoopBack1
ip address 6.6.6.6 255.255.255.255
isis enable 1
#
interface Nve1
source 4.4.4.4
#

interface Tunnel1
ip address 22.2.2.2
255.255.255.255
ipsec policy 1 service-instance-group
group1
#
#
return
4.2.12.10 Example for Configuring the Static VXLAN Active-Active Scenario (in
VLAN-Aware Bundle Mode)
a fault. 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 4-95, CE1 is dual-homed to PE1 and PE2 through an Eth-
Trunk. PE1 and PE2 use a virtual address as the source virtual tunnel end point (VTEP)
address of a Network Virtualization Edge (NVE) interface, that is, anycast VTEP address. In
this way, the CPE only detects the remote NVE interface, and a static VXLAN tunnel is
established between the CPE and the anycast VTEP address.
Packets sent by the CPE are forwarded to CE1 through either PE1 or PE2. However, a CE
may be single-homed to a PE on the network, for example, CE2 and CE3. In this case, the
CPE sends packets to one PE, and the packets may be sent to another PE before being
forwarded to the single-homed CE. Therefore, a bypass VXLAN needs to be established
between PE1 and PE2 to forward packets.
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 4-95 Configuring the static VXLAN active-active scenario

NOTE
In this example, interface1, interface2, and interface3 refer to GE 1/0/1, GE 1/0/2, and GE 1/0/3,
respectively.

Enterprise
Site
interface3
CPE
VXLAN Tunnel
in
3
te
ce
rfa
rfa
ce
te
PE1 3
in
PE2
Anycast VTEP
Bypass VXLAN Tunnel
i nt e2
er f ac
ac er f
e2 i nt
int
e rfa e2
ac
ce erf
1 int
CE2 CE1 CE3

Name
GE 1/0/1 10.1.20.1/24
GE 1/0/2 -
PE1 GE 1/0/3 10.1.1.1/24
PE2 GE 1/0/1 10.1.20.2/24
GE 1/0/2 -
GE 1/0/3 10.1.2.1/24


Name
CE1 GE 1/0/1 -
GE 1/0/2 -
CPE GE 1/0/1 10.1.1.2/24
GE 1/0/2 10.1.2.2/24
GE 1/0/3 -
1. Configure an IGP on each PE and the CPE to ensure Layer 3 connectivity.
2. Configure fast traffic switching on PE1 and PE2. If a PE fails, this configuration allows
downstream traffic on the CPE to be switched to another PE, which then forwards the
traffic to a CE.
3. Establish a BGP EVPN peer relationship between PE1 and PE2 so that they can
exchange VXLAN EVPN routes.
4. 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 of PE1 and PE2.
5. Configure the same anycast VTEP address (virtual address) on PE1 and PE2 as the NVE
interface's source address, which is used to establish a VXLAN tunnel with the CPE.
Establish static VXLAN tunnels between PE1 and the CPE and between PE2 and the
CPE, allowing the PEs to communicate with the CPE.
6. Configure PE1 and PE2 as service access points, and manually configure the same ESI
on PE1 and PE2 for the access links connected to CE1, allowing CE1 to be dual-homed
to the PEs.
7. Enable inter-chassis VXLAN on PE1 and PE2, configure different bypass addresses for
the PEs, and establish a bypass VXLAN tunnel between the PEs, allowing
communication between PE1 and PE2.
Data Preparation
l VPN and EVPN instance names
l Import and export VPN targets for the VPN and EVPN instances
Procedure

Step 2 Configure an IGP on each PE and the CPE. IS-IS is used in this example.
Step 3 Configure fast traffic switching on each PE.
# Configure PE1.
[~PE1] evpn
[*PE1-evpn] quit
[*PE1] commit
Step 4 Establish a BGP EVPN peer relationship between PE1 and PE2 so that they can exchange
VXLAN EVPN routes.
# Configure PE1.
[~PE1] bgp 100
[*PE1-bgp] quit
[*PE1] commit
Step 5 Establish VXLAN tunnels.
1. Configure an EVI and bind the EVI to a BD on each PE.
# Configure PE1.
[*PE1-bd10] evpn binding vpn-instance evpn1 bd-tag 100
[*PE1-bd10] quit
[*PE1-bd20] evpn binding vpn-instance evpn1 bd-tag 200
[*PE1-bd20] quit
[*PE1] commit
section.
2. Configure an ingress replication list on each PE and the CPE.
[~CPE] bridge-domain 10
[*CPE-bd10] vxlan vni 10 split-horizon-mode
[*CPE-bd10] quit
[*CPE] bridge-domain 20
[*CPE-bd20] vxlan vni 20 split-horizon-mode

[*CPE-bd20] quit
[*CPE] interface nve 1
[*CPE-Nve1] quit
[*CPE] commit
# Configure PE1.
[*PE1-Nve1] quit
[*PE1] commit
section.
Step 6 Perform access-side configurations on each PE.
# Configure PE1.
[*PE1] e-trunk 1
[*PE1-Eth-Trunk1] esi 0000.0001.0001.0001.0001
[~PE1] commit
Run the display vxlan tunnel command on PE1 and check information about the VXLAN
tunnels. The following example uses the command output on PE1.
----------------------------------------------------------------------------------
-
4026531841 3.3.3.3 4.4.4.4 up static 00:30:12
4026531842 1.1.1.1 2.2.2.2 up dynamic 00:12:28
that EVPN routes carrying Ethernet tag IDs are received from PE2.



*> 0000.0001.0001.0001.0001:100 0.0.0.0
* i 3.3.3.3
*> 0000.0001.0001.0001.0001:200 0.0.0.0
* i 3.3.3.3
*> 0000.0001.0001.0001.0001:100 0.0.0.0
i 3.3.3.3
*> 0000.0001.0001.0001.0001:200 0.0.0.0
i 3.3.3.3

*> 100:32:3.3.3.3 0.0.0.0
* i 3.3.3.3
*> 200:32:3.3.3.3 0.0.0.0
* i 3.3.3.3
*> 100:32:3.3.3.3 0.0.0.0
* i 3.3.3.3
*> 200:32:3.3.3.3 0.0.0.0
* i 3.3.3.3
----End
Configuration Files
#
sysname PE1
#
evpn
bypass-vxlan enable
#
#
bridge-domain 10
evpn binding vpn-instance evpn1 bd-tag 100

#
bridge-domain 20
#
e-trunk 1
priority 10
#
isis 1
network-entity 10.0000.0000.0001.00
#
mode lacp-static
e-trunk 1
esi 0000.0001.0001.0001.0001
#
bridge-domain 10
#
bridge-domain 20
#
undo shutdown
ip address 10.1.20.1 255.255.255.0
isis enable 1
#
undo shutdown
eth-trunk 1
#
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 LoopBack2
ip address 3.3.3.3 255.255.255.255
isis enable 1
#
interface Nve1
source 3.3.3.3
#
bgp 100
#
ipv4-family unicast
peer 2.2.2.2 enable
#
l2vpn-family evpn

peer 2.2.2.2 enable

#
return
#
sysname PE2
#
evpn
bypass-vxlan enable
#
#
bridge-domain 10
#
bridge-domain 20
#
e-trunk 1
priority 10
#
isis 1
network-entity 10.0000.0000.0002.00
#
mode lacp-static
e-trunk 1
esi 0000.0001.0001.0001.0001
#
bridge-domain 10
#
bridge-domain 20
#
undo shutdown
ip address 10.1.20.2 255.255.255.0
isis enable 1
#
undo shutdown
eth-trunk 1
#
undo shutdown
ip address 10.1.2.1 255.255.255.0
isis enable 1
#
interface LoopBack1
ip address 2.2.2.2 255.255.255.255
isis enable 1
#
interface LoopBack2

ip address 3.3.3.3 255.255.255.255

isis enable 1
#
interface Nve1
source 3.3.3.3
#
bgp 100
#
ipv4-family unicast
peer 1.1.1.1 enable
#
l2vpn-family evpn
peer 1.1.1.1 enable
#
return
l CE configuration file
#
sysname CE
#
#
portswitch
port trunk allow-pass vlan 1 2
#
undo shutdown
eth-trunk 1
#
undo shutdown
eth-trunk 1
#
return
#
sysname CPE
#
bridge-domain 10
#
bridge-domain 20
#
isis 1
network-entity 20.0000.0000.0001.00
#
undo shutdown
ip address 10.1.1.2 255.255.255.0
isis enable 1
#
undo shutdown
ip address 10.1.2.2 255.255.255.0

isis enable 1
#
undo shutdown
esi 0000.0000.0000.0000.0017
#
bridge-domain 10
#
bridge-domain 10
#
interface LoopBack1
ip address 4.4.4.4 255.255.255.255
isis enable 1
#
interface Nve1
source 4.4.4.4
#
return
4.2.12.11 Example for Configuring IPv4 NFVI Distributed Gateway

This section provides an example for configuring IPv4 NFVI distributed gateway in a typical
usage scenario.
Data Center Interconnect (DCI) and data communication network (DCN) technologies.
Mobile phone IPv4 traffic enters the DCN and accesses its virtualized unified gateway
(vUGW) and virtual multiservice engine (vMSE). After being processed by these, the phone
traffic is forwarded over the Internet through the DCN to the destination devices. Equally,
response traffic sent over the Internet from the destination devices to the mobile phones also
undergoes this process. For this to take place and to ensure that the traffic is balanced within
the DCN, you need to deploy the NFVI distributed gateway function on the DCN.
Figure 4-96 Configuring IPv4 NFVI distributed gateway

NOTE
In this example, interfaces 1 through 5 refer to GE 1/0/1, GE 1/0/2, GE 1/0/3, GE 1/0/4, and GE 1/0/5,
respectively.

DCGW1 DCGW2
Bypass VXLAN Tunnel
Interface2 Anycast VTEP Interface2
VX
l
LA
nne
N
Interface2
Interface2
Tu
Tu
N
nn
LA el
VX
VXLAN Tunnel
L2GW/ L2GW/
L3GW1 Interface1 Interface1 L3GW2
Int
e rf Interface3 Interface4
Inter
Interface3 ac
e5
face4
VNF1 VNF2
Figure 4-96 shows the network on which the NFVI distributed gateway function is deployed.
DCGW1 and DCGW2 are the DCN's border gateways. The DCGWs exchange Internet routes
with the external network. L2GW/L3GW1 and L2GW/L3GW2 access the virtualized network
functions (VNFs). As virtualized NEs, VNF1 and VNF2 can be deployed separately to
implement the functions of the vUGW and vMSE. VNF1 and VNF2 are connected to L2GW/
L3GW1 and L2GW/L3GW2 through respective interface process units (IPUs).
This networking combines the distributed gateway function and the EVPN VXLAN active-
active gateway function:
l The EVPN VXLAN active-active gateway function is deployed on DCGW1 and
DCGW2. Specifically, a bypass VXLAN tunnel is set up between DCGW1 and
DCGW2. In addition, they use a virtual anycast VTEP address to establish VXLAN
tunnels with L2GW/L3GW1 and L2GW/L3GW2.
The NE40E can be deployed as a DCGW and L2GW/L3GW in this networking.
Table 4-20 Interface IP addresses and masks
GE 1/0/1 10.6.1.1/24
DCGW1
GE 1/0/2 10.6.2.1/24

Loopback 0 9.9.9.9/32
Loopback2 33.33.33.33/32
DCGW2 GE 1/0/1 10.6.1.2/24
GE 1/0/2 10.6.3.1/24
Loopback2 44.44.44.44/32
L2GW/ GE 1/0/1 10.6.4.1/24

L3GW1
GE 1/0/2 10.6.2.2/24
GE 1/0/3 -
GE 1/0/4 -
GE 1/0/5 -
L2GW/ GE 1/0/1 10.6.4.2/24

L3GW2
GE 1/0/2 10.6.3.2/24
GE 1/0/3 -
GE 1/0/4 -
1. Configure a routing protocol on each DCGW and each L2GW/L3GW to ensure Layer 3
communication. OSPF is used in this example.
2. Configure an EVPN instance and bind it to a BD on each DCGW and each L2GW/
L3GW.
3. Configure an L3VPN instance and bind it to a VBDIF interface on each DCGW and
each L2GW/L3GW.
4. Configure BGP EVPN on each DCGW and each L2GW/L3GW.
5. Configure a VXLAN tunnel on each DCGW and each L2GW/L3GW.
6. On each L2GW/L3GW, configure a Layer 2 sub-interface that connects to a VNF and
static VPN routes to the VNF.

7. On each L2GW/L3GW, configure BGP EVPN to import static VPN routes, and
configure a route policy for the L3VPN instance to keep the original next of the static
VPN routes.
8. On each DCGW, configure default static routes for the VPN instance and loopback
routes used to establish a VPN BGP peer relationship with a VNF. Then configure a
route policy for the L3VPN instance so that the DCGW can advertise only the default
static routes and loopback routes through BGP EVPN.
9. Configure each DCGW to establish a VPN BGP peer relationship with a VNF.
10. Configure load balancing on each DCGW and each L2GW/L3GW.
Procedure
Step 2 Configure a routing protocol on each DCGW and each L2GW/L3GW to ensure Layer 3
Step 3 Configure an EVPN instance and bind it to a BD on each DCGW and each L2GW/L3GW.
# Configure DCGW1.
[~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] vxlan vni 100 split-horizon-mode
[*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 DCGW2 and each L2GW/L3GW. For configuration details, see
Step 4 Configure an L3VPN instance on each DCGW and each L2GW/L3GW.

# Configure DCGW1.
[~DCGW1] ip vpn-instance vpn1
[*DCGW1-vpn-instance-vpn1] vxlan vni 200
[*DCGW1-vpn-instance-vpn1] ipv4-family
[*DCGW1-vpn-instance-vpn1-af-ipv4] route-distinguisher 11:11
[*DCGW1-vpn-instance-vpn1-af-ipv4] vpn-target 11:1 evpn
[*DCGW1-vpn-instance-vpn1-af-ipv4] quit
[*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] vxlan anycast-gateway enable
[*DCGW1-Vbdif10] mac-address 00e0-fc00-0002
[*DCGW1-Vbdif10] quit
[*DCGW1] commit
Step 5 Configure BGP EVPN on each DCGW and each L2GW/L3GW.
# Configure DCGW1.
[~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] peer 1.1.1.1 as-number 100
[*DCGW1-bgp] peer 1.1.1.1 connect-interface LoopBack 1
[*DCGW1-bgp] l2vpn-family evpn
[*DCGW1-bgp-af-evpn] peer 1.1.1.1 enable
[*DCGW1-bgp-af-evpn] peer 1.1.1.1 advertise encap-type vxlan
[*DCGW1-bgp-af-evpn] peer 4.4.4.4 route-policy stopuIP export
[*DCGW1-bgp-af-evpn] quit
[*DCGW1-bgp] quit

[*DCGW1] commit
Repeat this step for DCGW2. For configuration details, see Configuration Files in this
section.
# Configure L2GW/L3GW1.
[~L2GW/L3GW1] bgp 100
[*L2GW/L3GW1-bgp] peer 2.2.2.2 as-number 100
[*L2GW/L3GW1-bgp] peer 2.2.2.2 connect-interface LoopBack 1
[*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 encap-type vxlan
[*L2GW/L3GW1-bgp-af-evpn] peer 2.2.2.2 advertise arp
[*L2GW/L3GW1-bgp-af-evpn] quit
[*L2GW/L3GW1-bgp] quit
[*L2GW/L3GW1] commit
Repeat this step for L2GW/L3GW2. For configuration details, see Configuration Files in this
section.
Step 6 Configure a VXLAN tunnel on each DCGW and each L2GW/L3GW.
# Configure DCGW1.
[~DCGW1] evpn
[*DCGW1-evpn] bypass-vxlan enable
[*DCGW1-evpn] quit
[*DCGW1] interface nve 1
[*DCGW1-Nve1] source 9.9.9.9
[*DCGW1-Nve1] bypass source 3.3.3.3
[*DCGW1-Nve1] mac-address 00e0-fc00-0009
[*DCGW1-Nve1] vni 100 head-end peer-list protocol bgp
[*DCGW1-Nve1] quit
[*DCGW1] commit
section.
[~L2GW/L3GW1] interface nve 1
[*L2GW/L3GW1-Nve1] source 1.1.1.1
[*L2GW/L3GW1-Nve1] vni 100 head-end peer-list protocol bgp
[*L2GW/L3GW1-Nve1] quit
section.
Step 7 On each L2GW/L3GW, configure a Layer 2 sub-interface that connects to a VNF and static
VPN routes to the VNF.

[~L2GW/L3GW1] interface GigabitEthernet1/0/3.1 mode l2
[*L2GW/L3GW1-GigabitEthernet1/0/3.1] encapsulation dot1q vid 10
[*L2GW/L3GW1-GigabitEthernet1/0/3.1] rewrite pop single
[*L2GW/L3GW1-GigabitEthernet1/0/3.1] bridge-domain 10
[*L2GW/L3GW1-GigabitEthernet1/0/3.1] quit
[*L2GW/L3GW1] interface GigabitEthernet1/0/4.1 mode l2
[*L2GW/L3GW1] ip route-static vpn-instance vpn1 5.5.5.5 255.255.255.255 10.1.1.2
tag 1000
tag 1000
tag 1000
section.
Step 8 On each L2GW/L3GW, configure BGP EVPN to import static VPN routes, and configure a
route policy for the L3VPN instance to keep the original next of the static VPN routes.
[*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] ip vpn-instance vpn1
[*L2GW/L3GW1-vpn-instance-vpn1] export route-policy sp evpn
[*L2GW/L3GW1-vpn-instance-vpn1] quit
section.
Step 9 On each DCGW, configure default static routes for the VPN instance and loopback routes
used to establish a VPN BGP peer relationship with a VNF. Then configure a route policy for
the L3VPN instance so that the DCGW can advertise only the default static routes and
loopback routes through BGP EVPN.
# Configure DCGW1.
[~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] route-policy dp deny node 20
[*DCGW1] ip vpn-instance vpn1
[*DCGW1-vpn-instance-vpn1] export route-policy dp evpn
[*DCGW1] commit
section.
Step 10 Configure each DCGW to establish a VPN BGP peer relationship with a VNF.
# Configure DCGW1.
[~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 DCGW2.
[*DCGW2] bgp 100
[*DCGW2-bgp] quit
[*DCGW2] commit
Step 11 Configure load balancing on each DCGW and each L2GW/L3GW.

# Configure DCGW1.
[~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
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
section.
Run the display bgp vpnv4 vpn-instance vpn1 peer command on each DCGW. The
command output shows that the VPN BGP peer relationship between the DCGW and VNF is
in Established state. The following example uses the command output on DCGW1:
[~DCGW1] display bgp vpnv4 vpn-instance vpn1 peer

VPN-Instance vpn1, Router ID 10.6.1.1:


PrefRcv
5.5.5.5 4 100 8136 8135 0 0118h05m
Established 4
6.6.6.6 4 100 8140 8167 0 0118h07m
Established 0
Run the display bgp vpnv4 vpn-instance vpn1 routing-table command on each DCGW.
The command output shows that the DCGW has received the mobile phone route (destined
for 10.10.10.10 in this example) from the VNF and the next hop of the route is the VNF IP
address. The following example uses the command output on DCGW1:
[~DCGW1] display bgp vpnv4 vpn-instance vpn1 routing-table

RPKI validation codes: V - valid, I - invalid, N - not-found

Network NextHop MED LocPrf
PrefVal Path/Ogn

*>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 ?
Run the display ip routing-table vpn-instance vpn1 command on each DCGW. The
command output shows the mobile phone routes in the VPN routing table on the DCGW and
the outbound interfaces of the routes are VBDIF interfaces.
[~DCGW1] display ip routing-table vpn-instance vpn1
route
------------------------------------------------------------------------------
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
----End
Configuration Files
l DCGW1 configuration file
#
sysname DCGW1
#
evpn
bypass-vxlan enable
#
#
#
#
#
ipv4-family
export route-policy dp evpn
vxlan vni 200
#
bridge-domain 10
#
bridge-domain 20
#
bridge-domain 30
#
bridge-domain 40
#
interface Vbdif10
ip address 10.1.1.1 255.255.255.0

arp generate-rd-table enable

vxlan 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
#
undo shutdown
ip address 10.6.1.1 255.255.255.0
#
undo shutdown
ip address 10.6.2.1 255.255.255.0
#
interface LoopBack0
ip address 9.9.9.9 255.255.255.255
#
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 9.9.9.9
#
bgp 100
#
ipv4-family unicast
peer 1.1.1.1 enable
peer 2.2.2.2 enable
peer 4.4.4.4 enable
#
network 0.0.0.0 0
import-route direct

maximum load-balancing 16
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
peer 4.4.4.4 enable
peer 4.4.4.4 route-policy stopuIP export
#
ospf 1
area 0.0.0.0
network 3.3.3.3 0.0.0.0
network 9.9.9.9 0.0.0.0
network 10.6.1.0 0.0.0.255
network 10.6.2.0 0.0.0.255
#
route-policy dp permit node 10
if-match tag 2000
#
if-match ip-prefix lp
#
route-policy dp deny node 20
#
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 vpn-instance vpn1 0.0.0.0 0.0.0.0 NULL0 tag 2000
#
return
#
sysname DCGW2
#
evpn
bypass-vxlan enable
#
#
#

#
#
ipv4-family
vxlan vni 200
#
bridge-domain 10
#
bridge-domain 20
#
bridge-domain 30
#
bridge-domain 40
#
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
#
undo shutdown
ip address 10.6.1.2 255.255.255.0
#
undo shutdown
ip address 10.6.3.1 255.255.255.0
#

interface LoopBack0
ip address 9.9.9.9 255.255.255.255
#
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 Nve1
source 9.9.9.9
#
bgp 100
#
ipv4-family unicast
peer 1.1.1.1 enable
peer 2.2.2.2 enable
peer 3.3.3.3 enable
#
network 0.0.0.0 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 1
area 0.0.0.0
network 4.4.4.4 0.0.0.0
network 9.9.9.9 0.0.0.0
network 10.6.1.0 0.0.0.255
network 10.6.3.0 0.0.0.255
#
if-match tag 2000
#


#
#
#
#
#
#
#
return
l L2GW/L3GW1 configuration file
#
sysname L2GW/L3GW1
#
#
#
#
#
ipv4-family
export route-policy sp evpn
vxlan vni 200
#
bridge-domain 10
#
bridge-domain 20
#
bridge-domain 30
#
bridge-domain 40
#
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
#
undo shutdown
ip address 10.6.4.1 255.255.255.0
#
undo shutdown
ip address 10.6.2.2 255.255.255.0
#
rewrite pop single
bridge-domain 10
#
rewrite pop single
bridge-domain 20
#
rewrite pop single
bridge-domain 10
#
interface LoopBack1
ip address 1.1.1.1 255.255.255.255
#
interface Nve1
source 1.1.1.1
#
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 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
#
ospf 1
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
#
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 tag 1000
#
return
#
sysname L2GW/L3GW2
#
#
#
#

#
ipv4-family
vxlan vni 200
#
bridge-domain 10
#
bridge-domain 20
#
bridge-domain 30
#
bridge-domain 40
#
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
#
undo shutdown
ip address 10.6.4.2 255.255.255.0
#
undo shutdown
ip address 10.6.3.2 255.255.255.0
#
rewrite pop single
bridge-domain 30

#
rewrite pop single
bridge-domain 40
#
interface LoopBack1
ip address 2.2.2.2 255.255.255.255
#
interface Nve1
source 2.2.2.2
#
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 static
#
l2vpn-family evpn
peer 1.1.1.1 enable
peer 3.3.3.3 enable
peer 4.4.4.4 enable
#
ospf 1
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
#
if-match tag 1000
#
#
#
return
l VNF1 configuration file

For details, see the configuration file of a specific device model.

4.2.12.12 Example for Configuring IPv6 NFVI Distributed Gateway

This section provides an example for configuring IPv6 NFVI distributed gateway in a typical
usage scenario.
Data Center Interconnect (DCI) and data communication network (DCN) technologies.
Mobile phone IPv6 traffic enters the DCN and accesses its virtualized unified gateway
(vUGW) and virtual multiservice engine (vMSE). After being processed by these, the phone
traffic is forwarded over the Internet through the DCN to the destination devices. Equally,
response traffic sent over the Internet from the destination devices to the mobile phones also
undergoes this process. For this to take place and to ensure that the traffic is balanced within
the DCN, you need to deploy the NFVI distributed gateway function on the DCN.
Figure 4-97 Configuring IPv6 NFVI distributed gateway

NOTE
In this example, interfaces 1 through 5 refer to GE 1/0/1, GE 1/0/2, GE 1/0/3, GE 1/0/4, and GE 1/0/5,
respectively.
DCGW1 DCGW2
Bypass VXLAN Tunnel
Interface2 Anycast VTEP Interface2
VX
l
LA
nne
N
Interface2
Interface2
Tu
Tu
N
nn
LA
el
VX
VXLAN Tunnel
L2GW/ L2GW/
Int
Inter
Interface3 ac
e5
face4
VNF1 VNF2

Figure 4-97 shows the DCN on which the NFVI distributed gateway is deployed. DCGW1
and DCGW2 are the DCN's border gateways. The DCGWs exchange Internet routes with the
external network. L2GW/L3GW1 and L2GW/L3GW2 access the virtualized network
functions (VNFs). As virtualized NEs, VNF1 and VNF2 can be deployed separately to
implement the functions of the vUGW and vMSE. VNF1 and VNF2 are connected to L2GW/
L3GW1 and L2GW/L3GW2 through respective interface process units (IPUs).
This networking combines the distributed gateway function and the EVPN VXLAN active-
active gateway function:
l The EVPN VXLAN active-active gateway function is deployed on DCGW1 and
DCGW2. Specifically, a bypass VXLAN tunnel is set up between DCGW1 and
DCGW2. In addition, they use a virtual anycast VTEP address to establish VXLAN
tunnels with L2GW/L3GW1 and L2GW/L3GW2.
The NE40E can be deployed as a DCGW and L2GW/L3GW in this networking.
Table 4-21 Interface IP addresses and masks

GE 1/0/1 10.6.1.1/24
GE 1/0/2 10.6.2.1/24
DCGW1 Loopback 0 9.9.9.9/32
Loopback 1 3.3.3.3/32
Loopback 2 2001:db8:33::33/128
DCGW2 GE 1/0/1 10.6.1.2/24
GE 1/0/2 10.6.3.1/24
Loopback 0 9.9.9.9/32
Loopback 1 4.4.4.4/32
Loopback 2 2001:db8:44::44/128
L2GW/ GE 1/0/1 10.6.4.1/24

L3GW1
GE 1/0/2 10.6.2.2/24
GE 1/0/3 -
GE 1/0/4 -
GE 1/0/5 -
Loopback 1 1.1.1.1/32
L2GW/ GE 1/0/1 10.6.4.2/24

L3GW2
GE 1/0/2 10.6.3.2/24

GE 1/0/3 -
GE 1/0/4 -
Loopback 1 2.2.2.2/32
1. Configure a routing protocol on each DCGW and each L2GW/L3GW to ensure Layer 3
2. Configure an EVPN instance and bind it to a BD on each DCGW and each L2GW/
L3GW.
3. Configure an L3VPN instance and bind it to a VBDIF interface on each DCGW and
each L2GW/L3GW.
4. Configure BGP EVPN on each DCGW and each L2GW/L3GW.
5. Configure a VXLAN tunnel on each DCGW and each L2GW/L3GW.
6. On each L2GW/L3GW, configure a Layer 2 sub-interface that connects to a VNF and
static VPN routes to the VNF.
7. On each L2GW/L3GW, configure BGP EVPN to import static VPN routes, and
configure a route policy for the L3VPN instance to keep the original next of the static
VPN routes.
8. On each DCGW, configure default static routes for the VPN instance and loopback
routes used to establish a VPN BGP peer relationship with a VNF. Then configure a
route policy for the L3VPN instance so that the DCGW can advertise only the default
static routes and loopback routes through BGP EVPN.
9. Configure each DCGW to establish a VPN BGP peer relationship with a VNF.
10. Configure load balancing on each DCGW and each L2GW/L3GW.
Procedure
Step 2 Configure a routing protocol on each DCGW and each L2GW/L3GW to ensure Layer 3
Step 3 Configure an EVPN instance and bind it to a BD on each DCGW and each L2GW/L3GW.
# Configure DCGW1.


[*DCGW1-bd10] quit
[*DCGW1-bd20] quit
[*DCGW1-bd30] quit
[*DCGW1-bd40] quit
[*DCGW1] commit
Step 4 Configure an L3VPN instance on each DCGW and each L2GW/L3GW.
# Configure DCGW1.
[*DCGW1-Vbdif10] ipv6 enable
[*DCGW1-Vbdif10] ipv6 address 2001:db8:1::1 64
[*DCGW1-Vbdif10] ipv6 nd generate-rd-table enable


[*DCGW1] commit
Step 5 Configure BGP EVPN on DCGW1 and each L2GW/L3GW.
# Configure DCGW1.
[~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
section.
[*L2GW/L3GW1-bgp-af-evpn] peer 2.2.2.2 advertise nd
section.

Step 6 Configure a VXLAN tunnel on each DCGW and each L2GW/L3GW.

# Configure DCGW1.
[~DCGW1] evpn
[*DCGW1-evpn] quit
[*DCGW1-Nve1] quit
[*DCGW1] commit
section.
section.
Step 7 On each L2GW/L3GW, configure a Layer 2 sub-interface that connects to a VNF and static
VPN routes to the VNF.
[*L2GW/L3GW1] ipv6 route-static vpn-instance vpn1 2001:db8:5::5 128 2001:db8:1::2
tag 1000
tag 1000
tag 1000
section.
Step 8 On each L2GW/L3GW, configure BGP EVPN to import static VPN routes, and configure a
route policy for the L3VPN instance to keep the original next of the static VPN routes.

[*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] apply ipv6 gateway-ip origin-nexthop
[*L2GW/L3GW1-vpn-instance-vpn1] ipv6-family
[*L2GW/L3GW1-vpn-instance-vpn1-af-ipv6] export route-policy sp evpn
[*L2GW/L3GW1-vpn-instance-vpn1-af-ipv6] quit
section.
Step 9 On each DCGW, configure default static routes for the VPN instance and loopback routes
used to establish a VPN BGP peer relationship with a VNF. Then configure a route policy for
the L3VPN instance so that the DCGW can advertise only the default static routes and
loopback routes through BGP EVPN.
# Configure DCGW1.
[~DCGW1] ipv6 route-static vpn-instance vpn1 :: 0 NULL0 tag 2000
[*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 ipv6 address prefix-list lp
[*DCGW1] route-policy dp deny node 20
[*DCGW1-vpn-instance-vpn1-af-ipv6] export route-policy dp evpn
[*DCGW1] commit
section.
Step 10 Configure each DCGW to establish a VPN BGP peer relationship with a VNF.
# Configure DCGW1.

[*DCGW1] bgp 100
[*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 DCGW2.
[*DCGW2] bgp 100
[*DCGW2-bgp] quit
[*DCGW2] commit
Step 11 Configure load balancing on each DCGW and each L2GW/L3GW.
# Configure DCGW1.
[~DCGW1] bgp 100
[*DCGW1-bgp-6-vpn1] maximum load-balancing 16
[*DCGW1-bgp] quit
[*DCGW1] commit
section.
[*L2GW/L3GW1-bgp-6-vpn1] maximum load-balancing 16
section.


Run the display bgp vpnv6 vpn-instance vpn1 peer command on each DCGW. The
command output shows that the VPN BGP peer relationship between the DCGW and each
VNF is Established. The following example uses the command output on DCGW1:
[~DCGW1] display bgp vpnv6 vpn-instance vpn1 peer


PrefRcv
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
Run the display bgp vpnv6 vpn-instance vpn1 routing-table command on each DCGW.
The command output shows that the DCGW has received the mobile phone route (destined
for 2001:DB8:10::10 in this example) from the VNF and the next hop of the route is the VNF
IP address. The following example uses the command output on DCGW1:
[~DCGW] display bgp vpnv6 vpn-instance vpn1 routing-table

RPKI validation codes: V - valid, I - invalid, N - not-found

*> 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
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 : ?
Run the display ipv6 routing-table vpn-instance vpn1 command on each DCGW. The
command output shows the mobile phone routes in the VPN routing table on the DCGW and
the outbound interfaces of the routes are VBDIF interfaces.

[~DCGW] display ipv6 routing-table vpn-instance vpn1

Destination : :: PrefixLength : 0
NextHop : :: Preference : 60
Cost : 0 Protocol : Static
RelayNextHop : :: TunnelID : 0x0
Interface : NULL0 Flags : DB
Destination : 2001:DB8:1:: PrefixLength : 64

NextHop : 2001:DB8:1::1 Preference : 0
Cost : 0 Protocol : Direct
Interface : Vbdif10 Flags : D
Destination : 2001:DB8:1::1 PrefixLength : 128

NextHop : ::1 Preference : 0







Cost : 0 Protocol : IBGP
RelayNextHop : 2001:DB8:2::2 TunnelID : 0x0
Interface : Vbdif20 Flags : RD








Interface : LoopBack2 Flags : D

NextHop : ::FFFF:4.4.4.4 Preference : 255
RelayNextHop : :: TunnelID :
0x0000000027f0000001
Interface : VXLAN Flags : RD
Destination : FE80:: PrefixLength : 10

----End
Configuration Files
#
sysname DCGW1
#
evpn
bypass-vxlan enable
#
#


#
#
#
ipv6-family
vxlan vni 200
#
bridge-domain 10
#
bridge-domain 20
#
bridge-domain 30
#
bridge-domain 40
#
interface Vbdif10
ipv6 enable
ipv6 address 2001:db8:1::1/64
ipv6 nd generate-rd-table enable
#
interface Vbdif20
ipv6 enable
#
interface Vbdif30
ipv6 enable
#
interface Vbdif40
ipv6 enable
#

undo shutdown
ip address 10.6.1.1 255.255.255.0
#
undo shutdown
ip address 10.6.2.1 255.255.255.0
#
interface LoopBack0
ip address 9.9.9.9 255.255.255.255
#
interface LoopBack1
ip address 3.3.3.3 255.255.255.255
#
interface LoopBack2
ipv6 enable
ipv6 address 2001:db8:33::33/128
#
interface Nve1
source 9.9.9.9
#
bgp 100
#
ipv4-family unicast
peer 1.1.1.1 enable
peer 2.2.2.2 enable
peer 4.4.4.4 enable
#
network :: 0
import-route direct
peer 2001:db8:5::5 as-number 100
peer 2001:db8:5::5 connect-interface LoopBack2
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 1

area 0.0.0.0
network 3.3.3.3 0.0.0.0
network 9.9.9.9 0.0.0.0
network 10.6.1.0 0.0.0.255
network 10.6.2.0 0.0.0.255
#
if-match tag 2000
#
if-match ipv6 address prefix-list lp
#
#
#
if-match ipv6 address prefix-list uIP
#
#
ip ipv6-prefix lp index 10 permit 2001:db8:33::33 128
ip ipv6-prefix uIP index 10 permit 2001:DB8:10::10 128
#
ipv6 route-static vpn-instance vpn1 :: 0 NULL0 tag 2000
#
return
#
sysname DCGW2
#
evpn
bypass-vxlan enable
#
#
#
#
#
ipv6-family
vxlan vni 200
#
bridge-domain 10
#
bridge-domain 20

#
bridge-domain 30
#
bridge-domain 40
#
interface Vbdif10
ipv6 enable
#
interface Vbdif20
ipv6 enable
#
interface Vbdif30
ipv6 enable
#
interface Vbdif40
ipv6 enable
#
undo shutdown
ip address 10.6.1.2 255.255.255.0
#
undo shutdown
ip address 10.6.3.1 255.255.255.0
#
interface LoopBack0
ip address 9.9.9.9 255.255.255.255
#
interface LoopBack1
ip address 4.4.4.4 255.255.255.255
#
interface LoopBack2
ipv6 enable
ipv6 address 2001:db8:44::44 128
#
interface Nve1
source 9.9.9.9
#

bgp 100
#
ipv4-family unicast
peer 1.1.1.1 enable
peer 2.2.2.2 enable
peer 3.3.3.3 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 1
area 0.0.0.0
network 4.4.4.4 0.0.0.0
network 9.9.9.9 0.0.0.0
network 10.6.1.0 0.0.0.255
network 10.6.3.0 0.0.0.255
#
if-match tag 2000
#
if-match ipv6 address prefix-list lp
#
#
#
if-match ipv6 address prefix-list uIP
#
#
ip ipv6-prefix lp index 10 permit 2001:db8:44::44 128
ip ipv6-prefix uIP index 10 permit 2001:DB8:10::10 128
#
#
return


#
sysname L2GW/L3GW1
#
#
#
#
#
ipv6-family
vxlan vni 200
#
bridge-domain 10
#
bridge-domain 20
#
bridge-domain 30
#
bridge-domain 40
#
interface Vbdif10
ipv6 enable
ipv6 nd collect host enable
#
interface Vbdif20
ipv6 enable
#
interface Vbdif30
ipv6 enable


#
interface Vbdif40
ipv6 enable
#
undo shutdown
ip address 10.6.4.1 255.255.255.0
#
undo shutdown
ip address 10.6.2.2 255.255.255.0
#
rewrite pop single
bridge-domain 10
#
rewrite pop single
bridge-domain 20
#
rewrite pop single
bridge-domain 10
#
interface LoopBack1
ip address 1.1.1.1 255.255.255.255
#
interface Nve1
source 1.1.1.1
#
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 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 1
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
#
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 tag 1000
#
return
#
sysname L2GW/L3GW2
#
#
#
#
#
ipv6-family
vxlan vni 200
#
bridge-domain 10
#
bridge-domain 20


#
bridge-domain 30
#
bridge-domain 40
#
interface Vbdif10
ipv6 enable
#
interface Vbdif20
ipv6 enable
#
interface Vbdif30
ipv6 enable
#
interface Vbdif40
ipv6 enable
#
undo shutdown
ip address 10.6.4.2 255.255.255.0
#
undo shutdown
ip address 10.6.3.2 255.255.255.0
#
rewrite pop single
bridge-domain 30
#
rewrite pop single
bridge-domain 40
#
interface LoopBack1
ip address 2.2.2.2 255.255.255.255
#
interface Nve1

source 2.2.2.2
#
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 static
#
l2vpn-family evpn
peer 1.1.1.1 enable
peer 3.3.3.3 enable
peer 4.4.4.4 enable
#
ospf 1
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
#
if-match tag 1000
#
#
#
return


4.2.12.13 Example for Configuring the NFVI Distributed Gateway Function

(Quad-Active DC-GWs)
This section provides an example for configuring the NFVI distributed function when the
quad-active gateway function is deployed on DC-GWs.
The NFVI telco cloud solution uses the DCI+DCN networking. A large amount of IPv4 and
IPv6 mobile phone traffic is sent to vUGWs and vMSEs on the DCN. After being processed
by the vUGWs and vMSEs, the mobile phone traffic is forwarded over the DCN to
destination devices on the Internet. The destination devices send traffic to mobile phones in
similar ways. To achieve these functions and ensure traffic load balancing on the DCN, you
need to deploy the NFVI distributed gateway function.
Figure 4-98 shows the networking of an NFVI distributed gateway. DC-GWs, which are the
border gateways of the DCN, can exchange Internet routes with external devices. 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.
This networking can be considered a combination of the distributed gateway function and the
VXLAN quad-active gateway function.
l The VXLAN quad-active gateway function is deployed on DC-GWs. Specifically, a
bypass VXLAN tunnel is established between four DC-GWs, and the four DC-GWs use
the same virtual anycast VTEP address to establish a VXLAN tunnel with L2GW/
L3GW1 and L2GW/L3GW2, respectively.
and a VXLAN tunnel is established between L2GW/L3GW1 and L2GW/L3GW2.
NE40Es can be deployed as DC-GWs and L2GW/L3GWs in this networking.
Figure 4-98 Configuring the NFVI distributed gateway function (quad-active DC-GWs)
NOTE
In this example, interface 1, interface 2, interface 3, interface 4, interface 5, and interface 6 stand for GE
1/0/1, GE 1/0/2, GE 1/0/3, GE 1/0/3, GE 1/0/4, and GE 1/0/5, respectively.

DCGW3 DCGW4
Bypass VXLAN Tunnel
DCGW1 Interface1 Interface1 DCGW2
VX
l
LA
nne
N
Interface2
Interface2
Tu
Tu
N
nn
LA
e l
VX
VXLAN Tunnel
L2GW/ L2GW/
In t
Inter
Interface3 ac
e5
face4
VNF1 VNF2
Table 4-22 IP address planning
DCGW1 GigabitEthernet 1/0/1 10.6.1.1/24
LoopBack2 2001:db8:33::33/128
33.33.33.33/32

LoopBack2 2001:db8:44::44/128
44.44.44.44/32
LoopBack2 2001:db8:77::77/128
77.77.77.77/32
LoopBack2 2001:db8:88::88/128
88.88.88.88/32
L2GW/ GigabitEthernet 1/0/1 10.6.4.1/24

L3GW1
L2GW/ GigabitEthernet 1/0/1 10.6.4.2/24

L3GW2

1. Configure a routing protocol on DC-GWs and L2GW/L3GWs to ensure Layer 3
networking. OSPF is used in this example.
2. Configure EVPN instances on DC-GWs and L2GW/L3GWs and bind the EVPN
instances to BDs.
3. Configure L3VPN instances on DC-GWs and L2GW/L3GWs and bind the L3VPN
instances to VBDIF interfaces.
4. Configure the BGP EVPN function on DC-GWs and L2GW/L3GWs.
5. Configure VXLAN tunnels between DC-GWs, between L2GW/L3GWs, and between
DC-GWs and L2GW/L3GWs.
6. Configure Layer 2 sub-interfaces connecting L2GW/L3GWs to VNFs and the static
VPN routes destined for VNFs.
7. 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.
8. 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.
9. Establish BGP VPN peer relationships between DC-GWs and VNFs.
10. Configure the load balancing function on DC-GWs and L2GW/L3GWs.
Procedure
Step 1 Configure IP addresses for all interfaces, including loopback interfaces, on DC-GWs and
L2GW/L3GWs.
Step 2 Configure a routing protocol on DC-GWs and L2GW/L3GWs to ensure Layer 3 networking.
Step 3 Configure EVPN instances on DC-GWs and L2GW/L3GWs and bind the EVPN instances to
BDs.
# Configure DC-GW1.


[*DCGW1-bd10] quit
[*DCGW1-bd20] quit
[*DCGW1-bd30] quit
[*DCGW1-bd40] quit
[*DCGW1] commit
Repeat this step for DC-GW2, DC-GW3, DC-GW4, and L2GW/L3GWs. For configuration
Step 4 Configure L3VPN instances on DC-GWs and L2GW/L3GWs.
# Configure DC-GW1.


[*DCGW1] commit
Repeat this step for DC-GW2, DC-GW3, DC-GW4, and L2GW/L3GWs. For configuration
Step 5 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] ip ipv6-prefix uIPv6 index 10 permit 2001:DB8:10::10 128
[*DCGW1-route-policy] if-match ip-prefix uIP
[*DCGW1-route-policy] if-match ipv6 address prefix-list uIPv6
[*DCGW1] bgp 100
[*DCGW1-bgp] quit
[*DCGW1] commit
Repeat this step for DC-GW2, DC-GW3, and DC-GW4. For configuration details, see


section.
Step 6 Configure VXLAN tunnels between DC-GWs, between L2GW/L3GWs, and between DC-
GWs and L2GW/L3GWs.
# Configure DC-GW1.
[~DCGW1] evpn
[*DCGW1-evpn] quit
[*DCGW1-Nve1] quit
[*DCGW1] commit
section.
Step 7 Configure Layer 2 sub-interfaces connecting L2GW/L3GWs to VNFs and the static VPN
routes destined for VNFs.

[*L2GW/L3GW1] ip route-static vpn-instance vpn1 5.5.5.5 32 10.1.1.2 tag 1000
tag 1006
tag 1006
tag 1006
section.
Step 8 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.
[*L2GW/L3GW1-bgp-vpn1] import-route static
[*L2GW/L3GW1-bgp-vpn1] advertise l2vpn evpn import-route-multipath
[*L2GW/L3GW1-bgp-6-vpn1] import-route static
[*L2GW/L3GW1-bgp-6-vpn1] advertise l2vpn evpn import-route-multipath
[*L2GW/L3GW1-route-policy] apply gateway-ip origin-nexthop
[*L2GW/L3GW1] route-policy spv6 permit node 10
[*L2GW/L3GW1-route-policy] apply ipv6 gateway-ip origin-nexthop
[*L2GW/L3GW1] route-policy spv6 deny node 20
[*L2GW/L3GW1-vpn-instance-vpn1-af-ipv4] export route-policy sp evpn
[*L2GW/L3GW1-vpn-instance-vpn1-af-ipv6] export route-policy spv6 evpn

section.
Step 9 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] ip route-static vpn-instance vpn1 0.0.0.0 0.0.0.0 NULL0 tag 2000
[*DCGW1] ipv6 route-static vpn-instance vpn1 :: 0 NULL0 tag 2006
[*DCGW1-LoopBack2] ipv6 enable
[*DCGW1-LoopBack2] ipv6 address 2001:db8:33::33 128
[*DCGW1-LoopBack2] ip address 33.33.33.33 32
[*DCGW1] bgp 100
[*DCGW1-bgp-vpn1] advertise l2vpn evpn
[*DCGW1-bgp-vpn1] import-route direct
[*DCGW1-bgp-vpn1] import-route static
[*DCGW1-bgp-6-vpn1] advertise l2vpn evpn
[*DCGW1-bgp-6-vpn1] import-route direct
[*DCGW1-bgp-6-vpn1] import-route static
[*DCGW1-bgp] quit
[*DCGW1] ip ip-prefix lp index 10 permit 33.33.33.33 32
[*DCGW1] ip ipv6-prefix lpv6 index 10 permit 2001:DB8:33::33 128
[*DCGW1] route-policy dpv6 permit node 10
[*DCGW1] route-policy dpv6 permit node 15
[*DCGW1-vpn-instance-vpn1-af-ipv4] export route-policy dp evpn
[*DCGW1-vpn-instance-vpn1-af-ipv6] export route-policy dpv6 evpn
[*DCGW1] commit
Step 10 Establish BGP VPN peer relationships between DC-GWs and VNFs.
# Configure DC-GW1.
[*DCGW1] bgp 100


[*DCGW1-bgp] quit
[*DCGW1] commit
Step 11 Configure the load balancing function on DC-GWs and L2GW/L3GWs.
# Configure DC-GW1.
[~DCGW1] bgp 100
[*DCGW1-bgp-6-vpn1] maximum load-balancing 16
[*DCGW1-bgp] quit
[*DCGW1] commit
[*L2GW/L3GW1-bgp-6-vpn1] maximum load-balancing 16
section.
After completing the configurations, run the display ip routing-table vpn-instance vpn1 and
display ipv6 routing-table vpn-instance vpn1 commands on DC-GWs to check the VNF
route information and mobile phone route information (in this example, the destination IPv4
address and IPv6 address of mobile phone routes destined for VNFs are 10.10.10.10 and

2001:DB8:10::10, respectively) in the VPN routing tables of DC-GWs and specify the
VBDIF interface as the outbound interface.
[~DCGW1] display ip routing-table vpn-instance vpn1
route
------------------------------------------------------------------------------
0.0.0.0/0Static 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.4.1.2 Vbdif40
IBGP 255 0 RD 10.3.1.2 Vbdif30
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
77.77.77.77/32 IBGP 255 0 RD 7.7.7.7 VXLAN
88.88.88.88/32 IBGP 255 0 RD 8.8.8.8 VXLAN
[~DCGW1] display ipv6 routing-table vpn-instance vpn1
Destination : :: PrefixLength : 0
Cost : 0 Protocol : Static



















Interface : LoopBack2 Flags : D

0x0000000027f0000003

0x0000000027f0000001

0x0000000027f0000002
Destination : FE80:: PrefixLength : 10

----End
Configuration Files
l DC-GW1 configuration file
#
sysname DCGW1
#
evpn
bypass-vxlan enable
#
mac-duplication
#
#
#
#
#
ipv4-family

ipv6-family
export route-policy dpv6 evpn
vxlan vni 200
#
bridge-domain 10
#
bridge-domain 20
#
bridge-domain 30
#
bridge-domain 40
#
interface Vbdif10
ipv6 enable
ip address 10.1.1.1 255.255.255.0
ipv6 address 2001:DB8:1::1/64
#
interface Vbdif20
ipv6 enable
ip address 10.2.1.1 255.255.255.0
#
interface Vbdif30
ipv6 enable
ip address 10.3.1.1 255.255.255.0
#
interface Vbdif40
ipv6 enable
ip address 10.4.1.1 255.255.255.0
#
undo shutdown

ip address 10.6.1.1 255.255.255.0

#
undo shutdown
ip address 10.6.2.1 255.255.255.0
#
undo shutdown
ip address 10.6.5.1 255.255.255.0
#
interface LoopBack0
ip address 9.9.9.9 255.255.255.255
#
interface LoopBack1
ip address 3.3.3.3 255.255.255.255
#
interface LoopBack2
ipv6 enable
ip address 33.33.33.33 255.255.255.255
ipv6 address 2001:DB8:33::33/128
#
interface Nve1
source 9.9.9.9
#
bgp 100
#
ipv4-family unicast
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
import-route static
#
import-route direct
import-route static
peer 2001:DB8:5::5 as-number 100
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
peer 7.7.7.7 enable
peer 8.8.8.8 enable
#
ospf 1
area 0.0.0.0
network 3.3.3.3 0.0.0.0
network 9.9.9.9 0.0.0.0
network 10.6.1.0 0.0.0.255
network 10.6.2.0 0.0.0.255
network 10.6.5.0 0.0.0.255
#
if-match tag 2000
#
#
route-policy dpv6 permit node 10
if-match tag 2006
#
if-match ipv6 address prefix-list lpv6
#
#
#
if-match ipv6 address prefix-list uIPv6
#
#
#
#
#
ip ipv6-prefix lpv6 index 10 permit 2001:DB8:33::33 128
ip ipv6-prefix uIPv6 index 10 permit 2001:DB8:10::10 128
#
return
#
sysname DCGW2
#
evpn
bypass-vxlan enable
#
mac-duplication

#
#
#
#
#
ipv4-family
ipv6-family
vxlan vni 200
#
bridge-domain 10
#
bridge-domain 20
#
bridge-domain 30
#
bridge-domain 40
#
interface Vbdif10
ipv6 enable
ip address 10.1.1.1 255.255.255.0
#
interface Vbdif20
ipv6 enable
ip address 10.2.1.1 255.255.255.0

#
interface Vbdif30
ipv6 enable
ip address 10.3.1.1 255.255.255.0
#
interface Vbdif40
ipv6 enable
ip address 10.4.1.1 255.255.255.0
#
undo shutdown
ip address 10.6.1.2 255.255.255.0
#
undo shutdown
ip address 10.6.3.1 255.255.255.0
#
undo shutdown
ip address 10.6.6.1 255.255.255.0
#
interface LoopBack0
ip address 9.9.9.9 255.255.255.255
#
interface LoopBack1
ip address 4.4.4.4 255.255.255.255
#
interface LoopBack2
ipv6 enable
ip address 44.44.44.44 255.255.255.255
ipv6 address 2001:DB8:44::44/128
#
interface Nve1
source 9.9.9.9
#
bgp 100
#
ipv4-family unicast
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
import-route static
#
import-route direct
import-route static
#
l2vpn-family evpn
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
#
ospf 1
area 0.0.0.0
network 4.4.4.4 0.0.0.0
network 9.9.9.9 0.0.0.0
network 10.6.1.0 0.0.0.255
network 10.6.3.0 0.0.0.255
network 10.6.6.0 0.0.0.255
#
if-match tag 2000
#
#
if-match tag 2006
#
#
#
#


#
#
#
#
#
#
return
#
sysname DCGW3
#
evpn
bypass-vxlan enable
#
mac-duplication
#
#
#
#
#
ipv4-family
ipv6-family
vxlan vni 200
#
bridge-domain 10
#
bridge-domain 20
#
bridge-domain 30
#

bridge-domain 40
#
interface Vbdif10
ipv6 enable
ip address 10.1.1.1 255.255.255.0
#
interface Vbdif20
ipv6 enable
ip address 10.2.1.1 255.255.255.0
#
interface Vbdif30
ipv6 enable
ip address 10.3.1.1 255.255.255.0
#
interface Vbdif40
ipv6 enable
ip address 10.4.1.1 255.255.255.0
#
undo shutdown
ip address 10.6.7.1 255.255.255.0
#
undo shutdown
ip address 10.6.5.2 255.255.255.0
#
interface LoopBack0
ip address 9.9.9.9 255.255.255.255
#
interface LoopBack1
ip address 7.7.7.7 255.255.255.255
#
interface LoopBack2
ipv6 enable
ip address 77.77.77.77 255.255.255.255
ipv6 address 2001:DB8:77::77/128
#
interface Nve1
source 9.9.9.9


#
bgp 100
#
ipv4-family unicast
peer 1.1.1.1 enable
peer 2.2.2.2 enable
peer 3.3.3.3 enable
peer 4.4.4.4 enable
peer 8.8.8.8 enable
#
import-route direct
import-route static
#
import-route direct
import-route static
#
l2vpn-family evpn
peer 1.1.1.1 enable
peer 2.2.2.2 enable
peer 3.3.3.3 enable
peer 4.4.4.4 enable
peer 8.8.8.8 enable
#
ospf 1
area 0.0.0.0
network 7.7.7.7 0.0.0.0
network 9.9.9.9 0.0.0.0
network 10.6.5.0 0.0.0.255
network 10.6.7.0 0.0.0.255
#


if-match tag 2000
#
#
if-match tag 2006
#
#
#
#
#
#
#
#
#
#
return
#
sysname DCGW4
#
evpn
bypass-vxlan enable
#
mac-duplication
#
#
#
#
#
ipv4-family
ipv6-family

vxlan vni 200
#
bridge-domain 10
#
bridge-domain 20
#
bridge-domain 30
#
bridge-domain 40
#
interface Vbdif10
ipv6 enable
ip address 10.1.1.1 255.255.255.0
#
interface Vbdif20
ipv6 enable
ip address 10.2.1.1 255.255.255.0
#
interface Vbdif30
ipv6 enable
ip address 10.3.1.1 255.255.255.0
#
interface Vbdif40
ipv6 enable
ip address 10.4.1.1 255.255.255.0
#
undo shutdown
ip address 10.6.7.2 255.255.255.0
#
undo shutdown
ip address 10.6.6.2 255.255.255.0

#
interface LoopBack0
ip address 9.9.9.9 255.255.255.255
#
interface LoopBack1
ip address 8.8.8.8 255.255.255.255
#
interface LoopBack2
ipv6 enable
ip address 88.88.88.88 255.255.255.255
ipv6 address 2001:DB8:88::88/128
#
interface Nve1
source 9.9.9.9
#
bgp 100
#
ipv4-family unicast
peer 1.1.1.1 enable
peer 2.2.2.2 enable
peer 3.3.3.3 enable
peer 4.4.4.4 enable
peer 7.7.7.7 enable
#
import-route direct
import-route static
#
import-route direct
import-route static
#
l2vpn-family evpn
peer 1.1.1.1 enable
peer 2.2.2.2 enable


peer 3.3.3.3 enable
peer 4.4.4.4 enable
peer 7.7.7.7 enable
#
ospf 1
area 0.0.0.0
network 8.8.8.8 0.0.0.0
network 9.9.9.9 0.0.0.0
network 10.6.6.0 0.0.0.255
network 10.6.7.0 0.0.0.255
#
if-match tag 2000
#
#
if-match tag 2006
#
#
#
#
#
#
#
#
#
#
return
#
sysname L2L3GW1
#
#
#

#
#
ipv4-family
ipv6-family
export route-policy spv6 evpn
vxlan vni 200
#
bridge-domain 10
#
bridge-domain 20
#
bridge-domain 30
#
bridge-domain 40
#
interface Vbdif10
ipv6 enable
ip address 10.1.1.1 255.255.255.0
#
interface Vbdif20
ipv6 enable
ip address 10.2.1.1 255.255.255.0
#
interface Vbdif30
ipv6 enable
ip address 10.3.1.1 255.255.255.0


#
interface Vbdif40
ipv6 enable
ip address 10.4.1.1 255.255.255.0
#
undo shutdown
ip address 10.6.4.1 255.255.255.0
#
undo shutdown
ip address 10.6.2.2 255.255.255.0
#
undo shutdown
#
rewrite pop single
bridge-domain 10
#
undo shutdown
#
rewrite pop single
bridge-domain 20
#
undo shutdown
#
rewrite pop single
bridge-domain 10
#
interface LoopBack1
ip address 1.1.1.1 255.255.255.255
#
interface Nve1
source 1.1.1.1
#
bgp 100
#
ipv4-family unicast

import-route static
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 static
#
import-route static
#
l2vpn-family evpn
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
#
ospf 1
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
#
if-match tag 1000
#
#
route-policy spv6 permit node 10
if-match tag 1006
#
route-policy spv6 deny node 20
#


#
ipv6 route-static vpn-instance vpn1 2001:DB8:5::5 128 2001:DB8:1::2 tag 1006
#
return
#
sysname L2L3GW2
#
#
#
#
#
ipv4-family
ipv6-family
export route-policy spv6 evpn
vxlan vni 200
#
bridge-domain 10
#
bridge-domain 20
#
bridge-domain 30
#
bridge-domain 40
#
interface Vbdif10
ipv6 enable
ip address 10.1.1.1 255.255.255.0


#
interface Vbdif20
ipv6 enable
ip address 10.2.1.1 255.255.255.0
#
interface Vbdif30
ipv6 enable
ip address 10.3.1.1 255.255.255.0
#
interface Vbdif40
ipv6 enable
ip address 10.4.1.1 255.255.255.0
#
undo shutdown
ip address 10.6.4.2 255.255.255.0
#
undo shutdown
ip address 10.6.3.2 255.255.255.0
#
undo shutdown
#
rewrite pop single
bridge-domain 30
#
undo shutdown
#
rewrite pop single
bridge-domain 40
#
interface LoopBack1
ip address 2.2.2.2 255.255.255.255
#
interface Nve1
source 2.2.2.2


#
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
#
import-route static
#
l2vpn-family evpn
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
#
ospf 1
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
#
if-match tag 1000
#


#
route-policy spv6 permit node 10
if-match tag 1006
#
route-policy spv6 deny node 20
#
#
#
return

For details, see the configuration file of the corresponding product.
For details, see the configuration file of the corresponding product.
4.3 VXLAN Configuration Commands
4.3.1 active port-vxlan
Function
The active port-vxlan command activates VXLAN interface licenses for a CM board in
batches.
The undo active port-vxlan command deactivates VXLAN interface licenses for a CM board
in batches.
By default, VXLAN interface licenses are not activated for a CM board.
Format
active port-vxlan slot slot-id card card-id port port-list
undo active port-vxlan slot slot-id card card-id [ port port-list ]
Parameters
slot slot-id Specifies the slot ID of a CM board. -
card card-id Specifies a subcard ID. -
port port-list Specifies the interface list of a CM board, with the interfaces -
separated by commas (,) or hyphens (-).
Views
License view

Default Level

license write
Usage Guidelines
Usage Scenario
The VXLAN service can be configured on a CM board only after VXLAN interface licenses
are activated for the board.
In VS mode, this command applies only to the admin VSand cannot be configured in other
VSs.
Prerequisites
1. The license file on the master main control board has been activated by running the
license active file-name command.
2. Interface-specific basic hardware licenses have been activated by running the active
port-basic slot slot-id card card-id port port-list command.
Example
# Activate VXLAN interface licenses in a batch.
<HUAWEI>system-view
[~HUAWEI] license
[*HUAWEI-license] active port-vxlan slot 2 card 0 port 0-8
# Deactivate VXLAN interface licenses in a batch.

<HUAWEI>system-view
[~HUAWEI] license
[*HUAWEI-license] undo active port-vxlan slot 2 card 0 port 0-8
4.3.2 advertise l2vpn evpn

Function
The advertise l2vpn evpn command enables a device to advertise IP routes imported to a
VPN instance to its EVPN instance.
The undo advertise l2vpn evpn command restores the default configuration.
By default, a device is disabled from advertising IP routes imported to a VPN instance to its
EVPN instance.
Format
advertise l2vpn evpn [ valid-routes | best-route ] [ import-route-multipath ]

undo advertise l2vpn evpn [ valid-routes | best-route ] [ import-route-multipath ]
Parameters
import-route- Advertises all routes with the same destination address in a -
multipath VPN instance to an EVPN instance.
valid-routes Advertises only valid routes in a VPN instance to an EVPN -
instance.
best-route Advertises only optimal routes in a VPN instance to an -
EVPN instance.
Views
BGP-VPN instance IPv4 address family view, BGP-VPN instance IPv6 address family view
Default Level

bgp write
Usage Guidelines
Usage Scenario
After VTEPs establish VXLAN tunnels through IP prefix routes, run the advertise l2vpn
evpn command to enable a VTEP to advertise host routes imported to a VPN instance to its
EVPN instance. The VTEP then sends host routes to the remote VTEP through the BGP
If you run the advertise l2vpn evpn command without specifying the import-route-
multipath parameter, the VPN instance selects the optimal route among its routes with the
same destination address and advertises the route to the EVPN instance. On the network
shown in Figure 4-99, Device A establishes a BGP EVPN peer relationship with each of
Device B and Device C. Device B has two static IPv4 or IPv6 static routes to Device D
configured for its VPN instance, and Device C has one static IPv4 or IPv6 route to Device D
configured for its VPN instance. The advertise l2vpn evpn command can be run on Device B
and Device C to import the VPN routes into the EVPN instance. However, if the import-
route-multipath parameter is not specified, Device B can send only one VPN route to Device
A as Device C. If load balancing is configured on Device A, Device A divides the traffic
volume into two even copies and sends them to Device B and Device C. However, there are
two links between Device B and Device D. As a result, traffic is not evenly balanced. To
implement even load balancing, Device B must send both its VPN routes to Device A so that
Device A can detect that Device B has multiple paths reachable to Device D. For this to take
place, run the advertise l2vpn evpn command with the import-route-multipath parameter

specified on Device B. This configuration allows the VPN instance to advertise all the routes
with the same destination address to the EVPN instance.
Figure 4-99 Load balancing network
Device B
sta
N s ta ti c
E VP ti c
P
Device A BG Device D
BG
PE tic
VP
N s ta
Device C
Example
# Enable a device to advertise IP routes imported to VPN instance vpna to its EVPN instance.
[~HUAWEI] ip vpn-instance vpna
[*HUAWEI-vpn-instance-vpna] route-distinguisher 1:1
[*HUAWEI-vpn-instance-vpna] quit
[*HUAWEI] bgp 100
[*HUAWEI-bgp] ipv4-family vpn-instance vpna
[*HUAWEI-bgp-vpna] advertise l2vpn evpn
4.3.3 bridge-domain (System view)
Function
The bridge-domain command creates a bridge domain (BD) and displays the BD view, or
directly displays the BD view if the BD exists.
The undo bridge-domain command deletes a BD.
By default, no BD is created.
Format
bridge-domain bd-id
undo bridge-domain bd-id
Parameters

bd-id Specifies a BD ID. The value is an integer ranging from 1 to 32768.

Views
System view
Default Level

nvo3 write
Usage Guidelines
Usage Scenario
A virtual network (VN) on a VXLAN is a virtual broadcast domain. VXLAN network

identifiers (VNIs) identifying VNs must be mapped to BDs in 1:1 mode so that a BD can
function as a VXLAN network entity to transmit VXLAN traffic. To create a BD, run the
bridge-domain command.
Follow-up Procedure
Run the interface vbdif bd-id command to create a Layer 3 VBDIF interface for a BD. A BD
functions similar to a VLAN as a broadcast domain. A VBDIF interface, also similar to a
VLANIF interface, can be used for Layer 2 termination and Layer 3 access.
Example
# Create a BD with the ID of 10.
[~HUAWEI] bridge-domain 10
4.3.4 bridge-domain (Layer 2 sub-interface view)
Function
The bridge-domain command adds a Layer 2 sub-interface to a bridge domain (BD).
The undo bridge-domain command removes a Layer 2 sub-interface from a BD.
By default, no Layer 2 sub-interface is added to any BD.
Format
bridge-domain bd-id
undo bridge-domain

Parameters
Views
Layer 2 sub-interface view
Default Level

nvo3 write
Usage Guidelines
Usage Scenario
To allow service packets to be transmitted through a BD, run the bridge-domain command to
add a Layer 2 sub-interface to the BD.
Prerequisites
1. A BD has been created using the bridge-domain bd-id command in the system view.
2. A Layer 2 sub-interface has been created using the interface interface-type interface-
number.subnum mode l2 command in the system view.
Precautions
Each Layer 2 sub-interface belongs to only one BD.
Example
# Add GE1/0/1.1 to a BD with the ID of 10.
[*HUAWEI-bd10] quit
[*HUAWEI] interface gigabitethernet1/0/1.1 mode l2
[*HUAWEI-GigabitEthernet1/0/1.1] bridge-domain 10
4.3.5 bypass source

Function
The bypass source command configures a source VTEP address for a bypass VXLAN tunnel.
The undo bypass source command cancels the configuration.
By default, no source VTEP address is configured for a bypass VXLAN tunnel.

Format
bypass source ip-address
undo bypass source [ ip-address ]
Parameters
ip-address Specifies the IPv4 source VTEP address of a The value is in dotted decimal
bypass VXLAN tunnel. notation.
Views
NVE interface view
Default Level

nvo3 write
Usage Guidelines
Usage Scenario
In the DCI-PE all-active scenario, the PEs in the active state use the same address as the
source NVE address (namely, the default source VTEP address). Therefore, the PEs in the
active state cannot use this address to establish a VXLAN tunnel. To improve the DCI-PE all-
active solution, you can run the bypass source command to specify an independent source
VTEP address for each PE in the active state so that the PEs can establish a bypass VXLAN
tunnel with each other. The PEs establish a BGP EVPN peer relationship. BGP EVPN
advertises the source VTEP address of the local PE on the bypass VXLAN tunnel to the peer
PE. The peer PE establishes a bypass VXLAN tunnel based on its source VTEP address and
the received source VTEP address from the local PE.
Example
# Configure a source VTEP address for a bypass VXLAN tunnel.
[~HUAWEI] interface nve 1
[*HUAWEI-Nve1] bypass source 4.4.4.4
4.3.6 description (BD view)

Function
The description command configures a description for a bridge domain (BD).

The undo description command deletes the description of a BD.

By default, no description is configured for any BD.
Format
description description
undo description
Parameters
description Specifies a description. The value is a string of 1 to 80 case-sensitive
characters, spaces supported.
Views
BD view
Default Level

bdbase write
Usage Guidelines
If the bridge-domain bd-id command has been run several times to configure multiple BDs,
run the description command to configure a description for each BD. The description helps
rapidly understand the BD's function, which facilitates service management.
Example
# Configure the description VXLAN for the BD with the ID of 10.
[*HUAWEI-bd10] description VXLAN
4.3.7 display bridge-domain

Function
The display bridge-domain command displays bridge domain (BD) configurations.
Format
display bridge-domain [ binding-info | [ bd-id [ brief | verbose | binding-info ] ] ]

Parameters
bd-id Displays information about a BD with a specified The value is an integer
ID. ranging from 1 to 32768.
brief Displays brief BD information. -
verbose Displays detailed BD information. -
binding-info Displays the binding information between BDs -
and VNIs, VSIs, and EVPN instances.
Views
All views
Default Level
1: Monitoring level

bdbase read
Usage Guidelines
Usage Scenario
After BDs are configured on a device, to view BD information, run the display bridge-
domain command. The command output contains bridge domain configurations, including
which EVC Layer 2 sub-interfaces are added to a BD. The command output helps verify the
configuration and analyze faults.
Precautions
At least a BD has been configured using the bridge-domain bd-id command.
If a great number of BDs are configured on a device, configure bd-id in the display bridge-
domain command to view information about a specified BD.
Example
# Display the configurations of all BDs configured on a device.
<HUAWEI> display bridge-domain
The total number of bridge-domains is : 2
--------------------------------------------------------------------------------
MAC_LRN: MAC learning; STAT: Statistics; SPLIT: Split-horizon;
BC: Broadcast; MC: Unknown multicast; UC: Unknown unicast;
*down: Administratively down; FWD: Forward; DSD: Discard;
--------------------------------------------------------------------------------
BDID State MAC-LRN STAT BC MC UC SPLIT Description

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

10 up enable enable FWD FWD DSD disable VPLS

20 up enable disable FWD FWD FWD disable VLAN
# Display the configurations of BD 10 configured on a device.

<HUAWEI> display bridge-domain 10
--------------------------------------------------------------------------------
MAC_LRN: MAC learning; STAT: Statistics; SPLIT: Split-horizon;
BC: Broadcast; MC: Unknown multicast; UC: Unknown unicast;
*down: Administratively down; FWD: Forward; DSD: Discard;
U: Up; D: Down;
--------------------------------------------------------------------------------
BDID Ports
--------------------------------------------------------------------------------
10
BDID State MAC-LRN STAT BC MC UC SPLIT Description

--------------------------------------------------------------------------------
10 down enable disable FWD FWD FWD disable
Table 4-23 Description of the display bridge-domain command output

Item Description
The total number of Total number of BDs configured on a device.

bridge-domains is
BDID ID of each BD.

A BD can be configured using the bridge-domain bd-id
command in the system view.
State BD status:
l up: An EVC Layer 2 sub-interface is added to a BD, and the
EVC Layer 2 sub-interface status is Up.
l down: its meaning is as follows:
– No EVC Layer 2 sub-interface is added to a BD.
– An EVC Layer 2 sub-interface is added to a BD, and the
EVC Layer 2 sub-interface status is Down.
l *down: Administratively down. The shutdown command has
been run in the BD view.
A BD goes Up when at least one member interface in the BD is
Up.
MAC-LRN Whether the MAC address learning function is enabled in a BD:

l disable
l enable
To enable this function, run the undo mac-address learning
disable command. To disable this function, run the mac-address
learning disable command. This function is enabled by default.

Item Description
STAT Whether a device is enabled to collect statistics about packets

transmitted in a BD:
l disable
l enable
To enable the device to collect BD packet statistics, run the
statistic enable command.
BC Whether a device forwards broadcast packets in a BD:

l FWD: The device forwards broadcast packets in a BD.
l DSD: The device discards broadcast packets in a BD.
By default, the device forwards broadcast packets in a BD. To
enable the device to discard broadcast packets in a BD, run the
broadcast discard command.
MC Whether a device forwards multicast packets in a BD:

l FWD: The device forwards multicast packets in a BD.
l DSD: The device discards multicast packets in a BD.
To enable the device to discard unknown multicast packets in a
BD, run the unknown-multicast discard command.
UC Whether a device forwards unknown unicast packets in a BD:

l FWD: The device forwards unknown unicast packets in a BD.
l DSD: The device discards unknown unicast packets in a BD.
To enable the device to discard unknown unicast packets in a
BD, run the unknown-unicast discard command.
SPLIT Whether split horizon is enabled in a BD:

l disable
l enable
To enable split horizon in a BD, run the split-horizon enable
command.
Description Description of a BD.

To configure a bridge domain description, run the description
command in the BD view.
# Display the brief configurations of BD 10.

<HUAWEI> display bridge-domain 10 brief
--------------------------------------------------------------------------------
*down: Administratively down; U:Up; D:Down;
--------------------------------------------------------------------------------
BDID State Ports

--------------------------------------------------------------------------------
10 up gigabitethernet 1/0/1.1(D)

Table 4-24 Description of the display bridge-domain brief command output

Item Description
Ports Type, number, and status of each EVC Layer 2 sub-interface

added to a BD.
To add an EVC Layer 2 sub-interface to a BD, run the bridge-
domain bd-id command in a specific EVC Layer 2 sub-interface
view.
The status of an EVC Layer 2 sub-interface in a BD can be:
l UP: The data link layer protocol of the EVC Layer 2 sub-
interface starts properly.
l Down: The data link layer protocol of the EVC Layer 2 sub-
interface starts is abnormal.
# Display detailed configurations of BD 10.

<HUAWEI> display bridge-domain 10 verbose
Bridge-domain ID : 10
Description :
State : Up
MAC Learning : Enable
Statistics : Disable
Broadcast : Forward
Unknown-unicast : Forward
Unknown-multicast : Forward
Split-horizon : Disable
Vxlan Vni : 100
VSI :
EVPN : vpntest1
-----------------------------------------
Interface State
gigabitethernet 1/0/1.1 up
Table 4-25 Description of the display bridge-domain verbose command output

Item Description
Bridge-domain ID ID of each BD.

Description Description of a BD.

The description can be configured for a BD using the
description command.
State Status of an interface added to a BD.

l UP: The data link layer protocol of the EVC Layer 2 sub-
interface starts properly.
l Down: The data link layer protocol of the EVC Layer 2 sub-
interface starts is abnormal.

Item Description
MAC Learning Whether the MAC address learning function is enabled in a BD:
l disable
l enable
To enable this function, run the undo mac-address learning
disable command. To disable this function, run the mac-address
learning disable command. This function is enabled by default.
Statistics Whether a device is enabled to collect statistics about packets

transmitted in a BD:
l disable
l enable
To enable the device to collect BD packet statistics, run the
statistic enable command.
Broadcast Whether a device forwards broadcast packets in a BD:

l FWD: The device forwards broadcast packets in a BD.
l DSD: The device discards broadcast packets in a BD.
By default, the device forwards broadcast packets in a BD. To
enable the device to discard broadcast packets in a BD, run the
broadcast discard command.
Unknown-unicast Whether a device forwards unknown unicast packets in a BD:

l FWD: The device forwards unknown unicast packets in a BD.
l DSD: The device discards unknown unicast packets in a BD.
To enable the device to discard unknown unicast packets in a
BD, run the unknown-unicast discard command.
Unknown-multicast Whether a device forwards multicast packets in a BD:

l FWD: The device forwards multicast packets in a BD.
l DSD: The device discards multicast packets in a BD.
To enable the device to discard unknown multicast packets in a
BD, run the unknown-multicast discard command.
Split-horizon Whether split horizon is enabled in a BD:

l disable
l enable
To enable split horizon in a BD, run the split-horizon enable
command.
Vxlan Vni VNI bound to a BD.
VSI VSI bound to a BD.

A VSI can be bound to a BD using the l2 binding vsi vsi-name

Item Description
EVPN EVPN instance bound to a BD.

An EVPN instance can be bound to a BD using the evpn
binding vpn-instance evpn-name command in the BD view.
Interface Interface bound to the BD.

To add an EVC Layer 2 sub-interface to a BD, run the bridge-
domain bd-id command in a specific EVC Layer 2 sub-interface
view.
# Display the binding information between BDs and VNIs, VSIs, and EVPN instances.
<HUAWEI> display bridge-domain binding-info
--------------------------------------------------------------------------------
BDID VNI VSI EVPN
--------------------------------------------------------------------------------
1 1 vsitest1 vpntest1
Table 4-26 Description of the display bridge-domain binding-info command output

Item Description
BDID ID of a BD.
VNI VNI bound to a BD.

A VNI can be bound to a BD using the vxlan vni vni-id
VSI VSI bound to a BD.

A VSI can be bound to a BD using the l2 binding vsi vsi-name
EVPN EVPN instance bound to a BD.

An EVPN instance can be bound to a BD using the evpn
binding vpn-instance evpn-name command in the BD view.
4.3.8 display bridge-domain statistics

Function
The display bridge-domain statistics command displays traffic statistics of a bridge domain
(BD).

Format
display bridge-domain bd-id statistics
Parameters
Views
All views
Default Level
1: Monitoring level

bdbase read
Usage Guidelines
Usage Scenario
To check traffic statistics of a BD when monitoring it, run the display bridge-domain
statistics command. The command output helps locate faults.
Prerequisites
To ensure that the display bridge-domain statistics command displays valid statistics entries,
you must have performed the following operations before running the display bridge-
domain statistics command:
1. A BD has been created using the bridge-domain bd-id command in the system view.
2. Traffic statistics collection has been enabled for the BD using the statistics enable
Example
# Display traffic statistics of BD 10.
<HUAWEI> display bridge-domain 10 statistics
202306 packets input, 25895168 bytes
0 packets output, 0 bytes
Input:202306 unicasts, 0 multicasts
0 broadcasts
0 unknown-unicast-drops
0 unknown-multicast-drops
0 broadcasts-drops
Output:0 unicasts, 0 multicasts

0 broadcasts

Table 4-27 Description of the display bridge-domain statistics command output

Item Description
202306 packets input, Statistics about packets received in the BD

25895168 bytes Received packets can be:
l Correct packets, including unicast, broadcast, and
multicast packets
l Discarded packets
Input fields are as follows:
l packets, bytes: the number of packets and bytes
correctly received. The number of packets refers to the
total number of unicast, broadcast, and multicast
packets.
l unicasts, broadcasts, multicasts: the number of unicast,
broadcast, and multicast packets correctly received.
l unknown-unicast-drops: the number of unknown
unicast packets discarded.
l unknown-multicast-drops: the number of unknown
multicast packets discarded.
l broadcasts-drops: the number of broadcast packets
discarded.
0 packets output, 0 bytes Statistics about packets sent from the BD

Output fields are as follows:
l packets, bytes: the number of packets and bytes
correctly sent. The number of packets refers to the
total number of unicast, broadcast, and multicast
packets.
l unicasts, broadcasts, multicasts: the number of unicast,
broadcast, and multicast packets correctly sent.
4.3.9 display license resource usage port-vxlan

Function
The display license resource usage port-l3vpn command displays authorization information
about VXLAN interface licenses.
Format
display license resource usage port-vxlan { all | slot slot-id } [ active | deactive ]

Parameters
all Displays authorization information about VXLAN interface licenses. -
slot slot-id Specifies the slot ID on which authorization information about -

VXLAN interface licenses is to be displayed.
active Displays authorization information about VXLAN licenses for -

interfaces with the active port-vxlan command configured.
deactive Displays authorization information about VXLAN licenses for -

interfaces with the active port-vxlan command not configured.
Views
All views
Default Level
1: Monitoring level

license read
Usage Guidelines
Usage Scenario
To view authorization information about VXLAN interface licenses, run the display license
resource usage port-vxlan command.
Precautions
In VS mode, this command is supported only by the admin VS.
Example
# Display authorization information about VXLAN interface licenses.
<HUAWEI>system-view
[~HUAWEI] display license resource usage port-vxlan all
Global port license information:
==================================================================================
Port Type Offline Allocated Activated Available Total
--------------------------------------------------------------------------------
GE 0 0 0 0 0
10GE 0 2 3 0 3
100GE 0 0 0 0 0

Port license detailed information:

================================================================================
Physical Port Position Port Type Active Status
--------------------------------------------------------------------------------
2/0/0 10GE No allocated
2/0/4 10GE
Activated
2/0/5 10GE
Activated
2/0/6 10GE
Activated
2/0/7 10GE Allocated
# Display authorization information about VXLAN licenses for interfaces with the active
port-vxlan command configured in slot 1.
<HUAWEI>system-view
[~HUAWEI] display license resource usage port-vxlan slot 1 active
==================================================================================
--------------------------------------------------------------------------------
GE 0 0 0 0 0
10GE 0 2 3 0 3
100GE 0 0 0 0 0

================================================================================
--------------------------------------------------------------------------------
2/0/4 10GE
Activated
2/0/5 10GE
Activated
2/0/6 10GE
Activated
# Display authorization information about VXLAN licenses for interfaces with the active
port-vxlan command not configured in slot 1.
<HUAWEI>system-view
[~HUAWEI] display license resource usage port-vxlan slot 1 deactive
==================================================================================
--------------------------------------------------------------------------------
GE 0 0 0 0 0
10GE 0 2 3 0 3
100GE 0 0 0 0 0

================================================================================
--------------------------------------------------------------------------------

Table 4-28 Description of the display license resource usage port-vxlan all command
output
Item Description
Global port license information Global interface license information
Port Type Interface type
Offline Number of offline interfaces
Allocated Number of interfaces with the interface

license status being Allocated
Activated Number of interfaces with the interface

license status being Active
Available Number of interface licenses that can be

activated
Total Total number of interface license resources
Port license detailed information Interface license activation information
Physical Port Position Physical interface position
Active status Interface license status:

l Active: Interface licenses have been
activated for the interface.
l Allocated: The active port-vxlan
command has been run on the interface,
but interface license resources are
insufficient and these licenses cannot be
activated.
l No allocated: The active port-vxlan
command has not been run on the
interface.
4.3.10 display interface nve

Function
The display interface nve command displays information about network virtualization edge
(NVE) interfaces.
Format
display interface nve [ nve-number | main ]

Parameters
nve-number Specifies the number of an NVE interface. The number can
If nve-number is not specified, information about all only be 1.
NVE interfaces is displayed.
main Displays the running status of and traffic statistics on an -

interface.
Views
All views
Default Level
1: Monitoring level

interface-mgr read
Usage Guidelines
Usage Scenario
To monitor the status of an NVE interface or locate an NVE interface faults on a VXLAN, run
the display interface nve command to check information about the NVE interface.
Example
# Display information about NVE interface.
<HUAWEI> display interface nve 1
Nve1 current state : UP (ifindex: 711)
Line protocol current state : UP
Description:
Table 4-29 Description of the display interface nve command output

Item Description
Nve1 current state Physical status of NVE interface. The

physical status retains UP after NVE
interface is created.
Line protocol current state Link layer protocol status of NVE interface.
The link layer protocol status retains UP
after NVE interface is created.

Item Description
Description NVE interface description. The description

can be modified using the description
command. If no description is configured,
nothing is displayed for this field.
4.3.11 display interface vbdif

Function
The display interface vbdif command displays the status, configurations, and statistics about
a VBDIF interface.
Format
display interface vbdif [ bd-id ]
Parameters
bd-id Specifies the ID of the bridge domain (BD) of which the The value is an
status, configurations, and statistics about the VBDIF integer ranging
interface is displayed. from 1 to 32768.
If bd-id is not specified, statuses, configurations, and

statistics about all VBDIF interfaces are displayed.
Views
All views
Default Level
1: Monitoring level

bdbase read
Usage Guidelines
Usage Scenario
To monitor the status of an interface or locate an interface fault, run the display interface
vbdif command to view status, configurations and statistics about the interface. This
information provides a basis for fault location.

Prerequisites
A VBDIF interface has been created.
Example
# Displays information about VBDIF 20 interface.
<HUAWEI> display interface vbdif 20
Vbdif20 current state : UP (ifindex:
1120)
Line protocol current state :

UP
Last line protocol up time : 2015-07-08

11:25:34
Description:
Route Port,The Maximum Transmit Unit is

1500
Internet Address is
192.168.20.1/24
IP Sending Frames' Format is PKTFMT_ETHNT_2, Hardware address is 00e0-

fc00-0001
Current system time: 2015-07-08
14:09:59
Table 4-30 Description of the display interface vbdif command output

Item Description
Vbdif20 current state Indicates the physical status of the VBDIF interface:
l UP: indicates that the interface is Up.
l DOWN: indicates that the interface is Down.
l Administratively down: If the administrator uses the
shutdown command on the interface, the state is
Administratively Down.
Line protocol current Indicates the status of the link protocol of the VBDIF interface:
state l UP: indicates the normal enabled state.
l DOWN: indicates the abnormal state or the IP address is not
configured on the interface.
Last line protocol up Indicates the last time when the link layer protocol status of the
time interface is Up.
NOTE
This field is displayed only when the link layer protocol status of an
interface is Up.

Item Description
Description Indicates the description of an interface. The information allows

users to know about functions of the interface and is used to
identify the current interface.
The description command is used to configure or modify the
description of an interface.
If the description command is not used to configure the
interface description, the description is empty by default.
Route Port Indicates the Layer 3 interface.
The Maximum Indicates the MTU of the interface. By default, the MTU is 1500
Transmit Unit is bytes. Packets larger than the MTU are fragmented before being
sent. If fragmentation is disabled, packets will be discarded.
The mtu command is used to configure or modify the MTU of a
VBDIF interface.
Internet Address is Indicates the IP address of a VBDIF interface.

If no IP address is configured on the current VBDIF interface,
the system displays "Internet protocol processing: disabled".
IP Sending Frames' Format of the Ethernet frame sent by the VBDIF interface.
Format is The default frame format is PKTFMT_ETHNT_2. When
receiving frames, the Ethernet protocol can identify the
following formats:
l PKTFMT_ETHNT_2
l Ethernet_SNAP
l 802.2
l 802.3
Hardware address is Indicates the physical address.
Current system time Indicates the current system time.

If the system is configured with a time zone and is in the summer
time configured using the clock daylight-saving-time
command, the time is displayed in the format of YYYY/MM/DD
HH:MM:SS UTC±HH:MM DST.
4.3.12 display mac-address bridge-domain

Function
The display mac-address bridge-domain command displays MAC address entries in a
specified bridge domain (BD).
Format
# Display all MAC address entries in specified bridge domain.

display mac-address [ mac-address ] bridge-domain bd-id [ verbose ]

# Display static MAC address entries in a specified bridge domain.
display mac-address static bridge-domain bd-id [ verbose ]
Parameters
mac-address Displays an entry with a specified MAC The value is a 12-digit
address. hexadecimal number, in the
format of H-H-H. Each H is 4
digits. If an H contains fewer than
4 digits, the left-most digits are
padded with zeros. For example,
e0 is displayed as 00e0.
bd-id Displays MAC address entries in a BD The value is an integer ranging

with a specified ID. from 1 to 32768.
static Displays static MAC address entries in a -

BD.
The static parameter configured in this
command helps verify that a user device
is correctly bound to an interface so that
authorized user's communication can be
ensured.
verbose Displays detailed information about -

MAC address entries in a bridge domain.
Views
All views
Default Level
1: Monitoring level

mac read
Usage Guidelines
To adapt to a changing network, the MAC address table needs to be updated constantly. To
check MAC address entries in a BD, run the display mac-address bridge-domain command.

Example
# Display all MAC address entries in bridge domain 1019.
<HUAWEI> display mac-address bridge-domain 1019
Flags: * - Backup
# - forwarding logical interface, operations cannot be performed based
on the interface.
BD : bridge-domain
-------------------------------------------------------------------------------
MAC Address VLAN/VSI/BD Learned-From Type
-------------------------------------------------------------------------------
00e0-fc00-0001 -/-/1019 10GE4/0/46 dynamic
-------------------------------------------------------------------------------
Total items: 1
Table 4-31 Description of the display mac-address bridge-domain command output

Item Description
Backup Backup path
MAC Address Destination MAC address
VLAN/VSI/BD l VLAN: ID of a VLAN to which an interface belongs

l VSI: ID of a VSI associated with an interface
l BD: ID of a BD to which an interface belongs
Learned-From l Static MAC address configured for an interface if the MAC

address entry type is static
l MAC address dynamically learned by an interface if the MAC
address entry type is dynamic
Type MAC address entry type:

l static: static MAC address entries
l dynamic: dynamic MAC address entries.
Total items Total number of MAC address entries matching the configured
conditions.
4.3.13 display mac-limit bridge-domain

Function
The display mac-limit bridge-domain command displays rules for dynamically learning
MAC addresses in a bridge domain (BD).
Format
display mac-limit bridge-domain bd-id

Parameters
bridge-domain bd-id Displays rules for dynamically learning The value is an integer
MAC addresses in a bridge domain with ranging from 1 to 32768.
a specified ID.
Views
All views
Default Level
1: Monitoring level

mac read
Usage Guidelines
Usage Scenario
After MAC address learning limit rules are successfully configured, run the display mac-
limit bridge-domain command to view the configuration. The command output helps verify
the configuration and analyze faults.
Precautions
If a great number of bridge domains are configured on a device, configure bd-id in the display
mac-limit bridge-domain command to view information about a specified bridge domain.
Example
# Display MAC address learning limit rules in BD 10.
<HUAWEI> display mac-limit bridge-domain 10
Bridge-domain 10 MAC limit:
Maximum MAC count 100, used count 3
Action: forward, Alarm: enable
Table 4-32 Description of the display mac-limit bridge-domain command output

Item Description
Bridge-domain 10 MAC limit A BD with a specified ID is assigned an upper limit of

MAC addresses that an EVC Layer 2 sub-interface can
learn.
Maximum MAC count 100 Configured maximum number of MAC addresses that
the interface can learn.

Item Description
used count 3 Number of learned MAC addresses in a specified bridge

domain.
Action Action the interface takes to process packets after the

interface learns a maximum number of MAC addresses:
l discard
l forward
Alarm Whether the interface is enabled to send an alarm to the

NMS after the number of learned MAC addresses
reaches the upper limit:
l enable
l disable
4.3.14 display vxlan evpl
Function
The display vxlan evpl command displays the VXLAN tunnel information of EVPL
instances.
Format
display vxlan evpl [ evpl-id [ verbose ] ]
Parameters

evpl-id The value is an integer
Displays the VXLAN tunnel information of an
ranging from 1 to
EVPL instance with a specified ID.
32768.
verbose Displays more detailed VXLAN tunnel information -
of an EVPL instance with a specified ID.
Views
All views
Default Level
1: Monitoring level


nvo3 read
Usage Guidelines
Usage Scenario
After configuring P2P VXLAN, run the display vxlan evpl command to check the VXLAN
tunnel information of EVPL instances. The command output helps you determine whether the
P2P VXLAN configurations are correct.
Precautions
Before running the display vxlan evpl command, ensure that at least one EVPL instance has
been created. Otherwise, no useful information is displayed in the command output.
Example
# Display the VXLAN tunnel information of all EVPL instances.
<HUAWEI> display vxlan evpl
Total VXLAN Evpl : 2
Evpl Instace ID : 1000

Tunnel Source : 1.1.1.1
Primary Destination/VNI : 1.1.1.2/100
Standby Destination/VNI : -/-
Bypass Destination/VNI : -/-
Local Vni : 100

Local Vni : 100
# Display the VXLAN tunnel information of EVPL instance 1000.

<HUAWEI> display vxlan evpl 1000

Local Vni : 100
# Display the detailed VXLAN tunnel information of EVPL instance 1000.

<HUAWEI> display vxlan evpl 1000 verbose

Local Vni : 100

Table 4-33 Description of the display vxlan evpl command output

Item Description
Total VXLAN
Evpl Number of EVPL instances to which VXLAN tunnels are bound
Evpl Instace ID ID of an EVPL instance
Tunnel Source Source IP address of a VXLAN tunnel
Primary Destination IP address and outbound VNI ID of a primary VXLAN

Destination/VNI tunnel
Standby Destination IP address and outbound VNI ID of a backup VXLAN

Bypass Destination IP address and outbound VNI ID of a bypass VXLAN

Inbound VNI ID of a VXLAN tunnel, that is, the VNI ID of the

Local Vni VXLAN to which an EVPL instance is bound
4.3.15 display vxlan peer

Function
The display vxlan peer command displays ingress replication lists of a VNI or all VNIs.
Format
display vxlan peer [ vni vni-id ]
Parameters
vni vni-id Specifies a VNI. The value is an integer ranging from 1 to 16777215.
Views
All views
Default Level
1: Monitoring level


nvo3 read
Usage Guidelines
Usage Scenario
If you want to check the VNI and source and destination IP address in an ingress replication
list after a VXLAN is configured, run the display vxlan peer command. The command
output helps you determine whether the VXLAN is correctly configured.
Precautions
Before running the display vxlan peer command, ensure that the specified VNI exists.
Otherwise, the information obtained will be inapplicable.
Example
# Display ingress replication lists of the VNI with the ID of 1.
<HUAWEI> display vxlan peer vni 1
Number of peers : 1
-------------------------------------------------------------------------------
1 1.1.1.1 2.2.2.2 static 1
# Display ingress replication lists of all VNIs.

<HUAWEI> display vxlan peer
Number of peers : 2
-------------------------------------------------------------------------------
1 1.1.1.1 2.2.2.2 static 1
2 1.1.1.1 3.3.3.3 static 2
Table 4-34 Description of the display vxlan peer command output

Item Description
Number of peers Number of ingress replication lists
Vni ID VNI ID, which is configured using the vxlan vni vni-id command
Source VTEP's IP address, which can be configured using the source

Source ip-address command
IP address of the remote VTEP with the Type of static, which can be
configured using the vni vni-id head-end peer-list ip-address
Destination &<1-10> command
Method for configuring an ingress replication list

l static: The ingress replication list is configured using the vni vni-
id head-end peer-list ip-address &<1-10> command.
l dynamic: The ingress replication list is dynamically generated by
BGP after the vni vni-id head-end peer-list protocol bgp
Type command is run.

Item Description
Out Vni ID Outbound VNI ID identifying a segment VXLAN tunnel
4.3.16 display vxlan tunnel
Function
The display vxlan tunnel command displays VXLAN tunnel information.
Format
display vxlan tunnel [ tunnel-id ] [ verbose ]
display vxlan tunnel [ cu-mode | vpn-instance vpn-instance-name [ cu-mode ] ] [ verbose ]
display vxlan tunnel all
Parameters
tunnel-id Specifies a VXLAN tunnel ID. The value is an integer
ranging from 1 to
4294967295.
verbose Displays detailed VXLAN tunnel information. -
cu-mode Displays VXLAN tunnel information in a CU -
separation scenario.
In VS mode, this parameter is supported only
by the admin VS.
vpn-instance vpn- Displays the VXLAN tunnel information of a -

instance-name VPN instance with a specified ID.
In VS mode, this parameter is supported only
by the admin VS.
all Displays information about all VXLAN -

tunnels.
Views
All views
Default Level
1: Monitoring level


nvo3 read
Usage Guidelines
After VXLAN tunnels are established, run the display vxlan tunnel command to check
tunnel information. The command output helps verify configurations and locate faults.
After VXLAN tunnels are created in a CU separation scenario, you can specify the cu-mode
parameter in the display vxlan tunnel command to check information about VXLAN tunnels
between the vBRAS-CU and vBRAS-UP. To check the VXLAN tunnel information of a
specified VPN instance, specify the vpn-instance vpn-instance-name parameter in the
command.
Example
# Display VXLAN tunnel information.
<HUAWEI> display vxlan tunnel
Tunnel ID Source Destination State Type
Uptime
----------------------------------------------------------------------------------
------------------------
4026531844 1.1.1.1 2.2.2.2 up static
03:12:33
4026531846 1.1.1.1 3.3.3.3 up static
12:23:45
4026531847 1.1.1.1 4.4.4.4 down static -
# Display information about all VXLAN tunnels.

<HUAWEI> display vxlan tunnel all
Vpn Instance Name : _public_
Uptime
----------------------------------------------------------------------------------
------------------------
4026531844 1.1.1.1 4.4.4.4 down static -
4026531846 1.1.1.1 2.2.2.2 down static -
----------------------------------------------------------------------------------
------------------------
# Display VXLAN tunnel information in a CU separation scenario.

<HUAWEI> display vxlan tunnel cu-mode
Uptime
----------------------------------------------------------------------------------
------------------------
4026531846 1.1.1.1 3.3.3.3 up static
12:23:45
# Display detailed VXLAN tunnel information.

<HUAWEI> display vxlan tunnel 4026531844 verbose
Tunnel ID : 4026531844
Source : 1.1.1.1
Destination : 2.2.2.2
State : up
Type : static

LearnMac : disable
BypassVxlan : false
Uptime : 03:12:33
# Display detailed VXLAN tunnel information in a CU separation scenario.

<HUAWEI> display vxlan tunnel cu-mode verbose
Tunnel ID : 4026531846
Source : 1.1.1.1
Destination : 3.3.3.3
State : up
Type : static
LearnMac : disable
BypassVxlan : false
Uptime : 12:23:45
Table 4-35 Description of the display vxlan tunnel command output

Item Description
Vpn Instance Name of VPN instance which VXLAN tunnels belong to. The
Name _public_ indicates public instance.
Number of vxlan
tunnel Number of VXLAN tunnels that have been established.
VXLAN tunnel ID, which is automatically allocated after a VXLAN

Tunnel ID tunnel is established.
Source VXLAN tunnel's source IP address.
Destination VXLAN tunnel's destination IP address.
VXLAN tunnel status:

l up: The tunnel is reachable.
State l down: The tunnel is unreachable.
VXLAN tunnel type.

The VXLAN tunnel status is determined by how peer-list ip-address
is specified in the vni vni-id head-end peer-list ip-address &<1-10>
command:
l static: peer-list ip-address is statically configured.
l dynamic: peer-list ip-address is dynamically learned by a routing
Type protocol.
Indicates whether MAC address learning is enabled:

l enable
LearnMac l disable
Indicates whether the bypass VXLAN tunnel exists:

l true
BypassVxlan l false

Item Description
Period during which a VXLAN tunnel is Up.

l If the period is less than 24 hours, the displayed format is
hh:mm:ss, where hh, mm, and ss stand for hours, minutes, and
seconds, respectively.
l If the period is greater than 24 hours but less than 9999 hours, the
displayed format is xxxxhxxm. For example, a period of 30 hours
and 26 minutes is displayed as 0030h26m.
l If the period is greater than 9999 hours, the number of hours is
displayed as four asterisks (****). For example, a period of 10000
hours and 26 minutes is displayed as ****h26m.
Uptime If a hyphen (-) is displayed, the VXLAN tunnel is Down.
4.3.17 display vxlan vni
Function
The display vxlan vni command displays VXLAN configurations.
Format
display vxlan vni [ vni-id [ verbose ] ]
Parameters
vni-id Specifies a VNI ID. The value is an integer ranging
from 1 to 16777215.
verbose Displays detailed configurations of the -

VXLAN with a specified VNI ID.
Views
All views
Default Level
1: Monitoring level

nvo3 read

Usage Guidelines
Usage Scenario
After a VXLAN is configured, to check the VNI status and BD to which the VNI is mapped,
run the display vxlan vni command. The command output helps you determine whether the
VXLAN is correctly configured.
Precautions
l Before running the display vxlan vni command, ensure that the specified VNI exists.
Otherwise, the information obtained will be inapplicable.
l If both ingress replication and centralized or multicast replication are configured in a
VSI, the mode for forwarding BUM packets is displayed as centralized or multicast
replication in the command output.
Example
# Display VXLAN configurations.
<HUAWEI> display vxlan vni
VNI BD-ID State
---------------------------------------
5010 10 up
5020 20 up
# Display detailed configurations of the VXLAN with VNI 5010.

<HUAWEI> display vxlan vni 5010 verbose
BD ID : 10
State : up
NVE : 1610612739
Source Address : 1.1.1.1
Source IPv6 Address : -
UDP Port : 4789
BUM Mode : head-end
Group Address : -
Peer List : 2.2.2.2 2.2.2.3
IPv6 Peer List : -
Table 4-36 Description of the display vxlan vni command output

Item Description
Number of vxlan
vni Number of VNIs configured.
VNI VNI ID, which is configured using the vxlan vni vni-id command.
ID of the BD to which a VNI is mapped, which is configured using

BD-ID (BD ID) the bridge-domain bd-id command.

Item Description
VNI status:
l up
l down
The status of a VNI is up only when the VXLAN tunnel identified by
the VNI exists and is up.
If the VNI status is down, check whether the source and destination
IP addresses displayed in the Source and Peer List fields in the
display vxlan vni command output are consistent with those
displayed in the Source and Destination fields in the display vxlan
tunnel command output.
l If they are inconsistent, the VXLAN tunnel identified by the VNI
does not exist.
Run the source ip-address or vni vni-id head-end peer-list ip-
address &<1-10> command to change the source or destination IP
address of the VXLAN tunnel to ensure that the VXLAN tunnel
exists.
l If they are consistent, collect configuration information and
State contact technical support personnel.
NVE interface index, which is automatically generated when an NVE

interface is created using the interface nve command. This index is
NVE used only for internal query.
Source VTEP's IP address, which can be configured using the source

Source Address ip-address command.
Source IPv6
Address IPv6 address of the source VTEP
UDP Port Destination UDP port number, which is fixed at 4789.
Broadcast, unknown unicast, and multicast mode

head-end: A VXLAN tunnel forwards BUM packets using the ingress
BUM Mode replication mode.
Group address mode, which allows a VNI to use multicast replication

to forward BUM packets
This field displays as a hyphen (-) because multicast replication is not
Group Address supported.
Remote VTEPs' IP addresses, which can be configured using the vni

Peer List vni-id head-end peer-list ip-address &<1-10> command.
IPv6 Peer List IPv6 address of the remote VTEP

4.3.18 display vxlan statistics
Function
The display vxlan statistics command displays VXLAN packet statistics.
Format
# Display VXLAN packet statistics by VNI.
display vxlan statistics vni vni-id
# Display VXLAN packet statistics by VNI and VXLAN tunnel.
display vxlan statistics source source-ip peer peer-ip vni vni-id
Parameters
vni vni-id Displays VXLAN packets statistics The value is an integer
collected based on a specified VNI ID. ranging from 1 to 16777215.
source source-ip Displays VXLAN packets statistics The value is in dotted decimal
collected based on the source IP address. notation.
peer peer-ip Displays VXLAN packet statistics

The value is in dotted decimal
collected based on the IP address of the
notation.
peer virtualized edge node.
Views
All views
Default Level
1: Monitoring level

nvo3 read
Usage Guidelines
l After the statistic enable command is run in the VNI view to enable VXLAN packet
statistics collection, run the display vxlan statistics vni vni-id command to view
VXLAN packet statistics collected by VNI.
l After the vxlan statistics peer peer-ip vni vni-id enable command is run in the NVE
interface view to enable VXLAN packet statistics collection, run the display vxlan

statistics source source-ip peer peer-ip vni vni-id command to view VXLAN packet
statistics collected by VNI and VXLAN tunnel.
Precautions
l Packet statistics collection based on the VXLAN tunnel and VNI and packet statistics
collection based on the VXLAN tunnel are mutually exclusive.
l Only split-horizon mode of traffic statistics collection for a VNI are supported, non-split-
horizon mode is not supported.
l In the statistics on VNI, unknown-unicast-drops, unknown-multicast-drops, and
broadcasts-drops are pseudo counts with a displayed value 0.
Example
# Display VXLAN packet statistics collected based on the VNI with the ID of 1.
<HUAWEI> display vxlan statistics vni 1
Last 300 seconds input rate: 536 bits/sec, 0 packets/sec
Last 300 seconds output rate: 368 bits/sec, 0 packets/sec
Input:2432180 unicast packets, 0 multicast packets
0 broadcasts
0 broadcasts-drops
Output:2100692 unicast packets, 0 multicast packets

1 broadcasts
# Display VXLAN packet statistics collected based on the source IP address 1.1.1.1, VNI
with the ID of 1, and the IP address of the peer virtualized edge node as 1.1.1.2.
<HUAWEI> display vxlan statistics source 1.1.1.1 peer 1.1.1.2 vni 1
Input:1051720620 unicast packets, 0 multicast packets
375 broadcasts
0 broadcasts-drops
Output:909549097 unicast packets, 0 multicast packets

375 broadcasts
Table 4-37 Description of the display vxlan statistics command output
Item Description
Last 300 seconds x indicates the number of received bits per second in last 300
input rate: x bits/ seconds; y indicates the number of received packets per second in
sec, y packets/sec 300 seconds.
Last 300 seconds

output rate: x bits/ x indicates the number of sent bits per second in last 300 seconds; y
sec, y packets/sec indicates the number of sent packets per second in 300 seconds.
x packets input, y x indicates the number of received packets; y indicates the number of
bytes bytes of received packets.

Item Description
x packets output, y x indicates the number of sent packets; y indicates the number of
bytes bytes of sent packets.
Input:x unicast
packets, y x indicates the number of received unicast packets; y indicates the
multicast packets number of received multicast packets; z indicates the number of
z broadcasts received broadcast packets.
x unknown-
unicast-drops Number of discarded unknown unicast packets
x unknown-
multicast-drops Number of discarded unknown multicast packets
x broadcasts-drops Number of discarded broadcast packets
Output:x unicast
packets, y x indicates the number of sent unicast packets; y indicates the number
multicast packets of sent multicast packets; z indicates the number of sent broadcast
z broadcasts packets.
4.3.19 display vxlan statistics l3-mode
Function
The display vxlan statistics l3-mode command displays Layer 3 VXLAN traffic statistics.
Format
display vxlan statistics l3-mode source source-ip peer peer-ip local-vni vni-id
display vxlan statistics l3-mode source source-ip peer peer-ip remote-vni vni-id
Parameters

source source-ip Displays statistics about Layer 3
VXLAN traffic with a specified source
notation.
VTEP IP address.
peer peer-ip Displays statistics about Layer 3
VXLAN traffic with a specified peer
notation.
VTEP IP address.
local-vni vni-id Displays statistics about Layer 3 The value is an integer ranging
VXLAN traffic with a local VNI. from 1 to 16777215.


remote-vni vni-id Displays statistics about Layer 3 The value is an integer ranging
VXLAN traffic with a remote VNI. from 1 to 16777215.
Views
All views
Default Level
1: Monitoring level

nvo3 read
Usage Guidelines
After Layer 3 VXLAN statistics collection is enabled using the vxlan statistics l3-mode
enable command run in the NVE interface view, you can run the display vxlan statistics l3-
mode command to check the statistics collected by VNI and VXLAN tunnel.
If you want to check the upstream traffic statistics, specify local-vni vni-id. If you want to
check the downstream traffic statistics, specify remote-vni vni-id.
Example
# Display statistics about upstream VXLAN traffic, with source VTEP IP address 1.1.1.1,
peer VTEP IP address 2.2.2.2, and local VNI 1.
<HUAWEI> display vxlan statistics l3-mode source 1.1.1.1 peer 2.2.2.2 local-vni 1
Input:0 unicast, 0 multicast
1195 broadcast
0 broadcast-drops
# Display statistics about downstream VXLAN traffic, with source VTEP IP address 1.1.1.1,
peer VTEP IP address 2.2.2.2, and remote VNI 1.
<HUAWEI> display vxlan statistics l3-mode source 1.1.1.1 peer 1.1.1.2 remote-vni 1
Output:0 unicast, 0 multicast
6948 broadcast

Table 4-38 Description of the display vxlan statistics l3-mode command output
Item Description
Last 300 seconds

input rate: x bits/ Rate of bytes received in the last 300 seconds, with x indicating the
sec, y packets/sec total number of bytes and y indicating the total number of packets
Last 300 seconds

output rate: x bits/ Rate of bytes sent in the last 300 seconds, with x indicating the total
sec, y packets/sec number of bytes and y indicating the total number of packets
x packets input, y x and y indicate the number of received packets and bytes,
bytes respectively.
Input:x unicast, y
multicast x, y, and z indicate the number of received unicast, multicast, and
z broadcast broadcast packets, respectively.
x unknown-
unicast-drops Number of discarded unknown unicast packets.
x unknown-
multicast-drops Number of discarded unknown multicast packets.
x broadcast-drops Number of discarded broadcast packets.
x packets output, y
bytes x and y indicate the number of sent packets and bytes, respectively.
Output:x unicast, y
multicast x, y, and z indicate the number of sent unicast, multicast, and
z broadcast broadcast packets, respectively.
4.3.20 encapsulation (Layer 2 sub-interface view)
Function
The encapsulation command specifies an encapsulation type of packets allowed to pass
through a Layer 2 sub-interface.
The undo encapsulation command deletes an encapsulation type of packets allowed to pass
through a Layer 2 sub-interface.
By default, an encapsulation type of packets allowed to pass through a Layer 2 sub-interface

is not specified.
Format
encapsulation { dot1q [ vid vid ] | default | untag | qinq [ vid pe-vid ce-vid { low-ce-vid [ to
high-ce-vid ] } ] }
undo encapsulation { dot1q [ vid vid ] | default | untag | qinq }

Parameters
dot1q Indicates the dot1q encapsulation type, which allows a -
Layer 2 sub-interface to receive tagged packets.
vid vid Specifies a VLAN ID in the outer VLAN tag. The value is
an integer
ranging from
1 to 4094.
default Indicates the default encapsulation type, which allows a -
Layer 2 sub-interface to receive all packets, irrespective of
whether the packets carry VLAN tags.
NOTE
interface, the main interface cannot have other types of Layer
2 sub-interfaces configured.
interface, ensure that the main interface of the Layer 2 sub-
interface is not added to any VLAN.
untag Indicates the untag encapsulation type, which allows a -

Layer 2 sub-interface to receive only untagged packets.
qinq Indicates the QinQ encapsulation type, which allows a -
Layer 2 sub-interface to receive double-tagged packets.
vid pe-vid Specifies an outer VLAN ID for double-tagged packets to The value is
be received by an EVC Layer 2 sub-interface. an integer
ranging from
1 to 4094.
ce-vid low-ce- Specifies a range of inner VLAN IDs for double-tagged The value is
vid [ to high-ce- packets to be received by an EVC Layer 2 sub-interface. an integer
vid ] The parameters are as follows: ranging from
l low-ce-vid: specifies the start VLAN ID in an inner tag. 1 to 4094.
l high-pe-vid: specifies the end VLAN ID in an inner tag.
high-ce-vid must be greater than or equal to low-ce-vid.
high-ce-vid and low-ce-vid define a range of VLAN
IDs in an inner VLAN tag.
l If you do not specify to high-ce-vid, low-ce-vid
specifies the single VLAN ID in the inner VLAN tag
carried in packets.
l If the low-ce-vid [ to high-ce-vid ] parameters are run
more than once, all configurations take effect.
NOTE
If ce-vid and default are configured for an EVC Layer 2 sub-
interface, this sub-interface forwards packets only based on outer
VLAN tags, regardless of inner VLAN tags.

Views
Layer 2 sub-interface view
Default Level

nvo3 write
Usage Guidelines
Usage Scenario
Packets on a VXLAN either carry a VLAN tags or do not carry VLAN tags. To allow these
packets to be transmitted through different Layer 2 sub-interfaces, run the encapsulation
command to configure an encapsulation type for each Layer 2 sub-interface.
Prerequisites
A Layer 2 sub-interface has been created using the interface interface-type interface-
number.subnum mode l2 command in the system view.
Precautions
Each Layer 2 sub-interface can have only one encapsulation type configured. Before changing
an encapsulation type, run the undo encapsulation command to delete the existing
encapsulation type. Then run the encapsulation command to specify an encapsulation type.
The encapsulation qinq command specifies the QinQ encapsulation type for a Layer 2 sub-
interface but does not enable the sub-interface to identify double-tagged packets. Therefore, to
enable the sub-interface to forward double-tagged packets, you must set inner and outer
VLAN IDs of packets that the sub-interface permits.
Example
# Enable untagged encapsulation on Layer 2 sub-interface GE1/0/1.1.
[~HUAWEI] interface gigabitethernet1/0/1.1 mode l2
[*HUAWEI-GigabitEthernet1/0/1.1] encapsulation untag
4.3.21 evpl instance (PW-VE interface view)
Function
The evpl instance command binds a PW-VE interface to an EVPL instance.
The undo evpl instance command unbinds a PW-VE interface from an EVPL instance.
By default, a PW-VE interface is not bound to any EVPL instance.

Format
evpl instance evpl-id peer ip-address
undo evpl instance evpl-id peer ip-address
Parameters
evpl-id The value is an integer ranging
from 1 to 32768.
peer ip-address Specifies a peer VTEP IP address for The value is in dotted decimal
an EVPL instance. notation.
Views
PW-VE interface view
Default Level

evpl write
Usage Guidelines
Usage Scenario
In scenarios where VXLAN tunnels are used for user access, to allow a device to terminate
VXLAN tunnel information on its PW-VE interface, run the evpl instance command to bind
the PW-VE interface to the EVPL instance of the VXLAN tunnel.
Example
# Bind a PW-VE interface to an EVPL instance.
[*HUAWEI-evpl-vxlan1] local-vni 10
[*HUAWEI-evpl-vxlan1] vtep-src 1.1.1.2
[*HUAWEI-evpl-vxlan1] quit
[*HUAWEI] interface pw-ve 1
[*HUAWEI-PW-VE1] evpl instance 1 peer 2.2.2.2
4.3.22 evpn binding vpn-instance

Function
The evpn binding vpn-instance command binds an EVPN instance to a BD.

The undo evpn binding vpn-instance command unbinds an EVPN instance from a BD.
By default, an EVPN instance is not bound to any BD.
Format
evpn binding vpn-instance evpn-name [ bd-tag bd-tag ]
undo evpn binding vpn-instance evpn-name
Parameters
evpn-name Specifies the name of an The value is a string of 1 to 31 case-sensitive
EVPN instance. characters, spaces not supported. When double
bd-tag bd-tag Specifies a BD tag value. The value is an integer ranging from 1 to 4094.
Views
BD view
Default Level

BGP write
Usage Guidelines
Usage Scenario
An EVPN instance can be bound only to BDs. To bind an EVPN instance to a BD, run the
evpn binding vpn-instance command.
An EVPN instance can be bound to a BD in two ways: using a VXLAN Network Identifier
(VNI) and using MPLS. In VNI mode, an EVPN instance is bound to a BD after a VNI is
configured. In MPLS mode, an EVPN instance is bound to a BD directly in the BD view.
If you want to implement the VLAN-aware function that allows different VLANs to access
the same EVPN instance and isolate the BDs to which the VLANs belong, specify the bd-tag
bd-tag parameter when you bind the EVPN instance to the BDs.
Prerequisites
If you use the VNI mode, ensure that a VNI has been created and associated with a BD and
forwarding in split horizon mode has been enabled for a VXLAN tunnel using the vxlan vni
vni-id split-horizon-mode command.

Precautions
The ways for binding an EVPN instance to a BD are mutually exclusive. To switch a binding
way, remove the existing binding relationship and establish another binding relationship.
An EVPN instance has been bound in the BD view. Running the evpn binding vpn-instance
command in the BD view to bind another EVPN instance will overwrite the current binding
relationship.
If a VSI with a PW tag or a VSI with a Spoken PW configured has been bound to a BD using
the l2 binding (BD view) vsi vsi-name pw-tag pw-tag-value command in the BD view, the
evpn binding vpn-instance command cannot be run to bind an EVPN instance to the BD.
Example
# Bind an EVPN instance named vrf1 to a BD in VNI mode.
[~HUAWEI] evpn vpn-instance vrf1 bd-mode
[*HUAWEI-evpn-instance-vrf1] route-distinguisher 100:1
[*HUAWEI-evpn-instance-vrf1] vpn-target 1:1
[*HUAWEI-evpn-instance-vrf1] quit
[*HUAWEI-bd100] evpn binding vpn-instance vrf1
# Bind an EVPN instance named vrf1 to a BD in MPLS mode.

[*HUAWEI-evpn-instance-vrf1] route-distinguisher 100:1
[*HUAWEI-evpn-instance-vrf1] vpn-target 1:1
[*HUAWEI-evpn-instance-vrf1] quit
[*HUAWEI-bd100] evpn binding vpn-instance vrf1
4.3.23 evpn vpn-instance bd-mode

Function
The evpn vpn-instance bd-mode command creates a BD EVPN instance and displays the
BD EVPN instance view.
The undo evpn vpn-instance bd-mode command deletes a specified BD EVPN instance.
By default, no BD EVPN instance is created.
Format
evpn vpn-instance vpn-instance-name bd-mode
undo evpn vpn-instance vpn-instance-name [ bd-mode ]

Parameters
vpn-instance- Specifies the name of The value is a string of 1 to 31 case-sensitive
name an EVPN instance. characters, spaces not supported. In addition, the
VPN instance name must not be _public_. When
double quotation marks are used around the string,
Views
System view
Default Level

BGP write
Usage Guidelines
Usage Scenario
To create a BD EVPN instance, run the evpn vpn-instance bd-mode command.
An EVPN instance functions as a virtual routing table on a PE, and therefore consumes
resources on the PE.
After the undo evpn vpn-instance bd-mode command is run to delete a BD EVPN instance,
all configurations of the EVPN instance are deleted.
Precautions
A BD EVPN instance can be bound only to BDs. To bind a BD EVPN instance to a BD, run
the evpn binding vpn-instance command.
Follow-up Procedure
After creating a BD EVPN instance, perform the following configurations in the EVPN
instance view:
l Run the route-distinguisher command to configure an RD for the EVPN instance.
l Run the vpn-target command to configure VPN targets for the EVPN instance.
Example
# Create a BD EVPN instance named vrf1.

Related Topics
4.3.24 export route-policy (EVPN instance view)

Function
The export route-policy command associates an EVPN instance with an export routing
policy.
The undo export route-policy command disassociates an EVPN instance with an export
routing policy.
By default, an EVPN instance is not associated with any export routing policy.
Format
export route-policy policy-name
undo export route-policy
Parameters
policy-name Specifies the name of a The name is a string of 1 to 200 case-sensitive
routing policy. characters, with spaces not supported. When double
quotation marks are used around the string, spaces
Views
EVPN instance view
Default Level

bgp write
Usage Guidelines
Usage Scenario
By default, an EVPN instance adds all VPN targets in the export VPN target list to EVPN
routes to be advertised to its peers. To control route export more precisely, run the export

route-policy policy-name command to associate the EVPN instance with an export routing
policy and set attributes for eligible routes.
Prerequisites
An RD has been configured for the EVPN instance using the route-distinguisher route-
distinguisher command.
Precautions
If the specified routing policy does not exist, run the route-policy command to create the
routing policy.
Example
# Associate an EVPN instance with an export routing policy named rp2.
[~HUAWEI] route-policy rp2 permit node 10
[*HUAWEI-route-policy] quit
[*HUAWEI-evpn-instance-vrf] export route-policy rp2
4.3.25 export route-policy evpn
Function
The export route-policy evpn command associates the VPN instance IPv4/IPv6 address
family of a VPN instance with an export routing policy to filter routes to be advertised to the
EVPN.
The undo export route-policy evpn command disassociates the VPN instance IPv4/IPv6
address family of a VPN instance with an export routing policy.
By default, the VPN instance IPv4/IPv6 address family of a VPN instance is not associated
with any export routing policy.
Format
export route-policy policy-name evpn
undo export route-policy policy-name evpn
Parameters

Views
VPN instance view, VPN instance IPv4 address family view, VPN instance IPv6 address
family view
Default Level

l3vpn write
Usage Guidelines
Usage Scenario
By default, the VPN IPv4/IPv6 address family of a VPN instance adds all VPN targets in the
export VPN target list to routes to be advertised to the EVPN. To control route export more
precisely, run the export route-policy policy-name evpn command to associate the VPN
IPv4/IPv6 address family with an export routing policy and set attributes for eligible routes.
Prerequisites
An RD has been configured for the VPN instance IPv4/IPv6 address family using the route-
distinguisher route-distinguisher command.
The export routing policy configured using the export route-policy policy-name evpn
command does not affect the export routing policy applied to the VPN instance using the
export route-policy policy-name command.
Precautions
routing policy.
Example
# Associate the VPN instance IPv4 address family of a VPN instance named vrf1 with an
export routing policy named policy-2 to filter routes to be advertised to the EVPN.
[~HUAWEI] route-policy policy-2 permit node 10
[*HUAWEI] ip vpn-instance vrf1
[*HUAWEI-vpn-instance-vrf1] ipv4-family
[*HUAWEI-vpn-instance-vrf1-af-ipv4] route-distinguisher 100:1
[*HUAWEI-vpn-instance-vrf1-af-ipv4] export route-policy policy-2 evpn

4.3.26 interface mode l2

Function
The interface mode l2 command creates a Layer 2 sub-interface and displays the Layer 2
sub-interface view.
The undo interface command deletes a Layer 2 sub-interface.
By default, no Layer 2 sub-interface is created.
Format
interface interface-type interface-number.subnum mode l2
undo interface interface-type interface-number.subnum
Parameters
interface-type interface- Specifies the type and number of a Layer 2 sub- -
number.subnum interface.
Views
System view
Default Level

ifm write
Usage Guidelines
Usage Scenario
The Ethernet virtual connection (EVC) module defines Layer 2 sub-interfaces as service
access points. Only Layer 2 sub-interface provides access services. To create a Layer 2 sub-
interface, run the interface mode l2 command.
Precautions
Layer 2 sub-interfaces can only send access packets to bridge domains, not Layer 3 networks.
Each Layer 2 sub-interface can be added to only one BD.
Before running the interface mode l2 command, ensure that the port link-type dot1q-tunnel
command is not run on the Layer 2 interface. If the port link-type dot1q-tunnel command
has been run, run the undo port link-type command first to delete the configuration.

Run the bridge-domain bd-id command to add a created Layer 2 sub-interface to a bridge
domain (BD) so that services can be transmitted in the bridge domain.
Example
# Create a Layer 2 sub-interface GE 1/0/1.1.
[~HUAWEI] interface gigabitethernet 1/0/1.1 mode l2
4.3.27 interface nve
Function
The interface nve command creates a network virtualization edge (NVE) interface or
displays an NVE interface view.
The undo interface nve command deletes an NVE interface.
By default, no NVE interfaces are created.
Format
interface nve nve-number
undo interface nve nve-number
Parameters
nve-number Specifies the number of an NVE interface. The number can only be 1.
Views
System view
Default Level

interface-mgr write
Usage Guidelines
Usage Scenario
To exert server virtualization advantages, deploy a VXLAN on an NVE interface for multi-
tenant access. To create an NVE interface, run the interface nve command.

Precautions
After configuring a VXLAN tunnel, if you run the undo interface nve command, the
specified NVE interface and its configurations will be deleted.
The interface nve and virtual-access commands are mutually exclusive.
Example
# Create NVE interface.
4.3.28 interface vbdif
Function
The interface vbdif command creates a VBDIF interface and displays the VBDIF interface
view, or directly displays the VBDIF interface view if the VBDIF interface exists.
The undo interface vbdif command deletes a VBDIF interface.
By default, no VBDIF interface is created.
Format
interface vbdif bd-id
undo interface vbdif bd-id
Parameters
Views
System view
Default Level

nvo3 write
Usage Guidelines
Usage Scenario

IP routes are required for communication between VXLANs on different network segments
and between VXLANs and non-VXLANs.
To allow communication between these networks, run the vxlan vni command to map a VNI
to a BD, run the interface vbdif command to create a VBDIF interface for the BD, and
configure an IP address for the BD.
Prerequisites
A BD has been created using the bridge-domain command.
Follow-up Procedure
Run the ip address command to configure an IP address for a VBDIF interface.
Example
# Create VBDIF10.
[*HUAWEI-bd10] quit
[*HUAWEI] interface vbdif 10
4.3.29 import route-policy (EVPN instance view)

Function
The import route-policy command associates an EVPN instance with an import routing
policy.
The undo import route-policy command disassociates an EVPN instance with an import
routing policy.
By default, an EVPN instance is not associated with any import routing policy.
Format
import route-policy policy-name
undo import route-policy
Parameters
Views
EVPN instance view
Default Level


bgp write
Usage Guidelines
Usage Scenario
By default, an EVPN instance matches the export VPN targets of received routes against its
import VPN targets to determine whether to import these routes. To control route import more
precisely, run the import route-policy policy-name command to associate the EVPN instance
with an import routing policy and set attributes for eligible routes.
Prerequisites
An RD has been configured for the EVPN instance using the route-distinguisher route-
distinguisher command.
Precautions
routing policy.
Example
# Associate an EVPN instance with an import routing policy named rp1.
[~HUAWEI] route-policy rp1 permit node 10
[*HUAWEI-evpn-instance-vrf] import route-policy rp1
4.3.30 import route-policy evpn
Function
The import route-policy evpn command associates the VPN instance IPv4/IPv6 address
family of a VPN instance with an import routing policy to filter routes imported from the
EVPN.
The undo import route-policy evpn command dissociates the VPN instance IPv4/IPv6
address family of a VPN instance with an import routing policy.
By default, the VPN instance IPv4/IPv6 address family of a VPN instance is not associated
with any import routing policy.
Format
import route-policy policy-name evpn

undo import route-policy policy-name evpn
Parameters

Views
VPN instance view, VPN instance IPv4 address family view, VPN instance IPv6 address
family view
Default Level

l3vpn write
Usage Guidelines
Usage Scenario
By default, the VPN instance IPv4/IPv6 address family of a VPN instance matches the export
VPN targets of received routes against its import VPN targets to determine whether to import
these routes. To control route import more precisely, run the import route-policy policy-name
evpn command to associate the VPN IPv4/IPv6 address family with an import routing policy
and set attributes for eligible routes.
Prerequisites
An RD has been configured for the VPN instance IPv4/IPv6 address family using the route-
distinguisher route-distinguisher command.
The import routing policy configured using the import route-policy policy-name evpn
command does not affect the import routing policy applied to the VPN instance using the
import route-policy policy-name command.
Precautions
routing policy.

Example
# Associate the VPN instance IPv4 address family of a VPN instance named vrf1 with an
import routing policy named policy-1 to filter routes received from the EVPN.
[~HUAWEI] route-policy policy-1 permit node 10
[*HUAWEI] ip vpn-instance vrf1
[*HUAWEI-vpn-instance-vrf1] ipv4-family
[*HUAWEI-vpn-instance-vrf1-af-ipv4] route-distinguisher 100:1
[*HUAWEI-vpn-instance-vrf1-af-ipv4] import route-policy policy-1 evpn
4.3.31 irb asymmetric

Function
The irb asymmetric command enables the asymmetric mode for IRB routes.
The undo irb asymmetric command restores the default configuration.
By default, the asymmetric mode is disabled for IRB routes.
Format
irb asymmetric
undo irb asymmetric
Parameters
None
Views
BGP-VPN instance IPv4 address family view or BGP-VPN instance IPv6 address family
view
Default Level

bgp write
Usage Guidelines
By default, a device generates an IP prefix route based on the IP address in an IRB/IRBv6
route that it has received from a BGP EVPN peer. IP prefix routes can be used for Layer 3
traffic forwarding. If Layer 2 forwarding is required, run the irb asymmetric command to
enable the asymmetric mode for IRB/IRBv6 routes. Specifically, after this configuration is
performed, the device does not generate IP prefix routes after receiving IRB/IRBv6 routes.

Example
# Enable the asymmetric mode for IRB routes.
[*HUAWEI-vpn-instance-vpna] route-distinguisher 1:1
[*HUAWEI] bgp 100
[*HUAWEI-bgp-vpna] irb asymmetric
# Enable the asymmetric mode for IRBv6 routes.

[*HUAWEI-vpn-instance-vpna] ipv6-family
[*HUAWEI-vpn-instance-vpna-af-ipv6] route-distinguisher 2:2
[*HUAWEI-vpn-instance-vpna-af-ipv6] quit
[~HUAWEI] bgp 100
[*HUAWEI-bgp-6-vpna] irb asymmetric
4.3.32 local-vni
Function
The local-vni command binds an EVPL instance in VXLAN mode to a VNI.
The undo local-vni command unbinds an EVPL instance in VXLAN mode from a VNI.
By default, an EVPL instance in VXLAN mode is not bound to any VNI.
Format
local-vni vni-id
undo local-vni vni-id
Parameters

vni-id Specifies the ID of a VNI to be bound to The value is an integer ranging
an EVPL instance. from 1 to 16777215.
Views
EVPL instance VXLAN mode view
Default Level


nvo3 write
Usage Guidelines
Usage Scenario
To bind a P2P VXLAN tunnel to an EVPL instance, run the local-vni command to bind the
EVPL instance in VXLAN mode to the VNI of the P2P VXLAN tunnel.
Precautions
l An EVPL instance can be bound to one VNI. Likewise, a VNI can be bound to one
EVPL instance.
l The binding relationship between an EVPL instance and a VNI cannot be modified.
However, you can run the undo local-vni command to delete the binding relationship
and then run the local-vni command to re-create a binding relationship.
l When an EVPL instance is deleted, its binding relationship with a VNI is also deleted.
Example
# Bind an EVPL instance to VNI 20.
[*HUAWEI-evpl-vxlan1] local-vni 20
4.3.33 mac-address (VBDIF interface view)

Function
The mac-address command configures a MAC address for a VBDIF interface.
The undo mac-address command restores the default MAC address of a VBDIF interface.
By default, the MAC address of a VBDIF interface is the system MAC address.
Format
undo mac-address

Parameters
mac-address Specifies a MAC The value is a 12-digit hexadecimal number, in the
address for a format of H-H-H. Each H is 4 digits. If an H contains
VBDIF interface. fewer than 4 digits, the left-most digits are padded with
zeros. For example, e0 is displayed as 00e0. A MAC
address cannot be all 0s or 1s or a multicast MAC
address.
Views
VBDIF interface view
Default Level

interface-mgr write
Usage Guidelines
Usage Scenario

Figure 4-100 Default MAC address of VBDIF interface
By default
MAC
port
address
BDIF1 MAC1
BDIF2 MAC1
L3 Gateway
BDIF1 NVE BDIF2

VXLAN Tunnel
NVE
VSwitch
VM1 VM2
IP1 IP2
By default, VBDIF interfaces of VXLAN Layer 3 gateways use the same MAC address, that
is the system MAC address, as shown in Figure 4-100.
After you configure a MAC address for a VBDIF interface, the device will actively send
gratuitous ARP packets to update the mapping between MAC addresses and interfaces of
other devices.
Example
# Configure the MAC address 00e0-fc00-0009 for VBDIF 10.
[*HUAWEI-bd10] quit
[*HUAWEI-Vbdif10] mac-address 00e0-fc00-0009
4.3.34 MAC-Address (NVE Interface View)
Function
The mac-address command sets a VTEP MAC address.
The undo mac-address command deletes a VTEP MAC address.
By default, a VTEP address is a system MAC address.

Format
undo mac-address [ mac-address ]
Parameters

mac-address Specifies a VTEP The value is a 12-digit hexadecimal number, in the format
MAC address. of H-H-H. Each H is 4 digits. If an H contains fewer than
4 digits, the left-most digits are padded with zeros. For
example, e0 is displayed as 00e0.
A MAC address cannot be all 0s, all 1s, or a multicast
MAC address.
Views
NVE interface view
Default Level

nvo3 write
Usage Guidelines
In VTEP all-active access scenarios, the NVE interfaces on all-active devices must have the
same source VTEP MAC address. To set a VTEP MAC address to control the MAC extension
attribute carried in EVPN BGP routes, run the mac-address command.
If no VTEP MAC address is configured, the MAC address of an NVE interface on an all-
active device is the system MAC address. In this case, VTEP functions become unavailable.
Precautions
In the VXLAN dual-active scenario, the same Anycast MAC address must be configured for
the dual-active devices served by routers. Otherwise, traffic may fail to be forwarded.
Example
# Set the VTEP MAC address to 00e0-fc00-0009.
[~HUAWEI] interface Nve 1
[*HUAWEI-Nve1] mac-address 00e0-fc00-0009

4.3.35 mac-address static vni
Function
The mac-address static vni command configures a static MAC address entry for a VXLAN
tunnel.
The undo mac-address static vni command deletes a static MAC address entry of a VXLAN
tunnel.
By default, no static MAC address entry is configured for any VXLAN tunnel.
Format
mac-address static mac-address bridge-domain bd-id source source-ip-address peer peer-
ip vni vni-id
undo mac-address static mac-address bridge-domain bd-id [ source source-ip-address ]

[ peer peer-ip ] [ vni vni-id ]
Parameters

mac-address Specifies a destination The value is a 12-digit hexadecimal
MAC address. number, in the format of H-H-H. Each H
is 4 digits. If an H contains fewer than 4
digits, the left-most digits are padded with
zeros. For example, e0 is displayed as
00e0.
bridge-domain Specifies a BD to which a The value is an integer ranging from 1 to
bd-id VNI is to be mapped. 32768.
source source-ip- Specifies the IP address of
address a local VTEP.
peer peer-ip Specifies an IP address for
a remote VTEP.
vni-id Specifies a VNI ID. The value is an integer ranging from 1 to
16777215.
Views
System view
Default Level


nvo3 write
Usage Guidelines
Usage Scenario
the ingress replication list with the same VNI. To reduce the volume of broadcast traffic, run
the mac-address static vni command to configure a static MAC entry for forwarding traffic.
This configuration also prevents unauthorized data access, enhancing network security.
Prerequisites
VXLAN tunnels have been established.
Precautions
Before running the mac-address static vni command, the network administrator must know
the MAC addresses of network devices that need static MAC entries for communication. If
the configured static MAC entries are incorrect, communication may be interrupted for
authorized users.
Example
# Configure a static MAC entry with the destination MAC address of aa-fcc-12 for a VXLAN
tunnel.
[*HUAWEI-bd10] vxlan vni 5000
[*HUAWEI-bd10] quit
[*HUAWEI] interface nve 1
[*HUAWEI-Nve1] source 1.1.1.1
[*HUAWEI-Nve1] vni 5000 head-end peer-list 2.2.2.2
[*HUAWEI-Nve1] quit
[*HUAWEI] mac-address static aa-fcc-12 bridge-domain 10 source 1.1.1.1 peer
2.2.2.2 vni 5000
4.3.36 mtu (BDIF interface view)
Function
The mtu command sets the maximum transmission unit (MTU) for a VBDIF interface.
The undo mtu command restores the MTU of a VBDIF interface to the default setting.
By default, the MTU is 1500 bytes.
Format
mtu mtu
undo mtu

Parameters
mtu Specifies the MTU of a VBDIF interface. The value
is an
l When the line test between devices is required, and for integer
example, the line forwarding specification of a 10M Ethernet ranging
interface is 14880 pulse per second (14880 64-bytes Ethernet from 46 to
frames are forwarded in 1 second), you can set the MTU of 9600, in
the VBDIF interface to 46 bytes to improve the forwarding bytes.
rate.
l If video communications, which require a wider bandwidth,
are to be implemented, you can set the MTU of the VBDIF
interface to the maximum value 1500 bytes.
Generally, it is recommended that you adopt the default MTU
value of 1500 bytes. Some protocols have requirements for the
minimum packet size. If the MTU is set to a value smaller than
the minimum packet size, the neighbor relationship of a specified
protocol may fail to be established.
Views
Default Level

bdbase write
Usage Guidelines
Usage Scenario
Generally, the IP layer controls the maximum length of frames that are sent each time. Any
time the IP layer receives an IP packet to be sent, it checks which local interface the packet
needs to be sent to and queries the MTU of the interface. Then, the IP layer compares the
MTU with the packet length to be sent. If the packet length is greater than the MTU, the IP
layer fragments the packet to ensure that the length of each fragment is smaller or equal to the
MTU.
If forcible unfragmentation is configured, certain packets are lost during data transmission at
the IP layer. To ensure jumbo packets are not dropped during transmission, you need to
configure forcible fragmentation. In this case, you can run the mtu command to set the size of
a fragment.

If the MTU is set too small and the size of packets is quite large, packets are fragmented into
a great number of fragments, and therefore are discarded by QoS queues.
Precautions
After using the mtu command to change the MTU of a VBDIF interface, you need to change
the MTU of the peer VBDIF interface to ensure that the MTUs of both interfaces are the
same. Otherwise, services may be interrupted.
Example
# Set the MTU of a VBDIF interface to 1400.
[*HUAWEI-bd10] quit
[*HUAWEI-Vbdif10] mtu 1400
4.3.37 peer advertise encap-type vxlan

Function
The peer advertise encap-type vxlan command configures a device to advertise EVPN
routes that carry the VXLAN encapsulation attribute to its peers.
The undo peer advertise encap-type vxlan command restores the default configuration.
By default, a device advertises EVPN routes that carry the MPLS encapsulation attribute to its
peers.
Format
peer { ipv4-address | group-name } advertise encap-type vxlan
undo peer { ipv4-address | group-name } advertise encap-type vxlan
Parameters
ipv4-address Specifies the IPv4 address The value is in dotted decimal notation.
of a peer.
group-name Specifies the name of a peer The name is a string of 1 to 47 case-sensitive
group. characters, with spaces not supported. When
Views
Default Level


BGP write
Usage Guidelines
On a BGP EVPN, a device can advertise EVPN routes that carry the VXLAN or MPLS
encapsulation attribute to its peers. To enable a device to advertise EVPN routes that carry the
VXLAN encapsulation attribute to its peers in distributed or centralized VXLAN gateway
scenarios, run the peer advertise encap-type vxlan command.
Example
# Configure a device to advertise VXLAN-encapsulated EVPN routes to its peers.
[~HUAWEI] bgp 100
[*HUAWEI-bgp-af-evpn] peer 1.1.1.1 advertise encap-type vxlan
4.3.38 peer next-hop-invariable (BGP-EVPN address family view)
Function
The peer next-hop-invariable command provides the following functions:
l Allows a BGP EVPN speaker to keep the next hops of routes unchanged when the
speaker advertises these routes to EBGP EVPN peers.
l Allows a BGP EVPN speaker to apply the original next hops of locally imported routes
when the speaker advertises these routes to IBGP EVPN peers.
The undo peer next-hop-invariable command restores the default configuration.
By default:
l A BGP EVPN speaker changes the next hops of routes to the interface that it uses to
establish EBGP EVPN peer relationships before advertising these routes to EBGP EVPN
peers.
l A BGP EVPN speaker does not change the next hops of routes imported from EBGP
EVPN when advertising these routes to IBGP EVPN peers.
l An RR does not change the next hops of routes imported from IBGP EVPN when
advertising these routes to IBGP EVPN peers.
l A BGP EVPN speaker changes the next hops of routes to the interface that it uses to
establish IBGP EVPN peer relationships before advertising these routes to IBGP EVPN
peers.
Format
peer { ipv4-address | group-name } next-hop-invariable
undo peer { ipv4-address | group-name } next-hop-invariable

Parameters

ipv4-address Specifies the IPv4 address of a The value is in dotted decimal notation.
BGP EVPN peer.
EVPN peer group. characters, with spaces not supported. When
Views
Default Level

bgp evpn write
Usage Guidelines
When VTEPs are indirectly connected, run the peer next-hop-invariable command on a
VTEP to configure it not to change the next hops of routes when advertising these routes to its
BGP EVPN peers.
In an EVPN VPWS over SRv6 scenario, if two PEs (PE1 and PE2) transmit EVPN routes
over an RR and one of the PEs (taking PE1 as an example) establishes an EBGP EVPN peer
relationship with the RR, the RR by default changes the next hop to its own address and
reassigns the SID carried in routes. In this way, PE2 can select only the SRv6 tunnel to the
RR, instead of the tunnel to PE1. To address this problem, run the peer next-hop-invariable
command on the RR to keep the next hops of routes unchanged during route advertisement.
Example
# Configure a device not to change the next hops of routes when advertising these routes to its
BGP EVPN peers.
[~HUAWEI] bgp 100
[*HUAWEI-bgp-af-evpn] peer 1.1.1.1 next-hop-invariable

4.3.39 peer route-policy (BGP-EVPN address family view)
Function
The peer route-policy command specifies a routing policy for routes received from or to be
advertised to a BGP EVPN peer or peer group.
The undo peer route-policy command deletes a specified routing policy.
By default, no routing policy is specified for routes received from or to be advertised to a

specified BGP EVPN peer or peer group.
Format
peer { group-name | ipv4-address } route-policy route-policy-name { import | export }
undo peer { group-name | ipv4-address } route-policy route-policy-name { import |

export }
Parameters

group-name Specifies the name of a BGP The name is a string of 1 to 47 case-
EVPN peer group. sensitive characters, with spaces not
ipv4-address Specifies the IPv4 address of a The value is in dotted decimal
BGP EVPN peer. notation.
route-policy- Specifies the name of a route- The name is a string of 1 to 200 case-
name policy. sensitive characters, with spaces not
import Applies the routing policy to routes -
received from a BGP EVPN peer
or peer group.
export Applies the routing policy to routes -
to be advertised to a BGP EVPN
peer or peer group.
Views
Default Level


bgp write
Usage Guidelines
Usage Scenario
To use a route-policy to filter routes received from or to be advertised to a specified BGP
EVPN peer or peer group, run the peer route-policy command. This configuration helps
manage routes and reduce required routing entries and system resources.
Prerequisites
BGP EVPN peers or peer groups have been configured to exchange EVPN routes using the
peer { group-name | ipv4-address } enable command.
After a route-policy is specified for a BGP EVPN peer group, all members in the group use
the route-policy.
Precautions
If the command specifies a route-policy that does not exist, use the route-policy command to
create the routing policy.
Example
# Apply a route-policy named test-rp to routes received from the BGP EVPN peer at 1.1.1.9.
[~HUAWEI] route-policy test-rp permit node 10
[*HUAWEI] bgp 100
[*HUAWEI-bgp-af-evpn] peer 1.1.1.9 route-policy test-rp import
4.3.40 peer track admin-vrrp vrid

Function
The peer track admin-vrrp vrid command binds a service PW in a service VSI to an
mVRRP group.
The undo peer track admin-vrrp vrid command unbinds a service PW in a service VSI
from an mVRRP group.
By default, no service PW in a service VSI is bound to an mVRRP group.
Format
peer peer-address [ negotiation-vc-id vc-id ] track admin-vrrp interface interface-type
interface-number vrid virtual-router-id pw-redundancy backup-block-all

undo peer peer-address [ negotiation-vc-id vc-id ] track admin-vrrp [ interface interface-

type interface-number vrid virtual-router-id pw-redundancy backup-block-all ]
Parameters
peer-address Specifies a peer IP address. The value is in
dotted decimal
notation.
negotiation-vc-id Specifies a VC ID. A VC ID is used when two The value is an
negotiation-vc-id ends that have different VSI IDs need to integer ranging from
communicate. 1 to 4294967295.
l negotiation-vc-id must be different from local

VSI IDs or VSI IDs specified locally using
the negotiate-vc-id command. Specifically,
the specified negotiation-vc-id must be an
unused one.
l The local negotiation-vc-id must be the same
as the peer negotiation-vc-id or VSI ID.
interface Specifies an interface where an mVRRP group is -

interface-type configured.
interface-number
virtual-router-id Specifies the ID of an mVRRP group. The value is an
integer ranging from
1 to 255.
pw-redundancy Indicates a VPLS PW redundancy scenario. -
If pw-redundancy is configured, the PW

redundancy mechanism determines the active/
standby status of a PW based on the master/
backup status of the corresponding remote PE in
the mVRRP group.
backup-block-all Blocks multicast traffic forwarding. -
Views
VSI-LDP view
Default Level


l2vpn write
Usage Guidelines
Usage Scenario
In a VLL accessing VPLS+VXLAN scenario where independent PW redundancy is

configured, the PW redundancy mechanism determines the active/standby status of PWs
based on the master/backup status of the remote PEs in the mVRRP group.
l The initial status of each PW between the local and remote PEs is Active.
l The mVRRP group determines the master/backup status of the two remote PEs.
After the peer track admin-vrrp vrid command is configured, the PW redundancy
mechanism determines the active/standby status of a PW based on the master/backup status of
the corresponding remote PE in the mVRRP group.
Prerequisites
l Service VSI peers have been configured using the peer command.
l An mVRRP group has been configured.
Precautions
l The peer track admin-vrrp vrid command applies only to service VSIs.
l If the AC interface and the mVRRP group interface on the remote PE reside on different
interface boards, the mVRRP group may fail to reflect the actual status of the service
PW.
l One service VSI can be bound only to one mVRRP group.
Example
# Bind a service PW with VC ID 100 to an mVRRP group with VRRP ID 100 and virtual IP
address 192.168.10.100.
[~HUAWEI] interface gigabitethernet 1/0/0
[~HUAWEI-GigabitEthernet1/0/0] ip address 192.168.10.1 24
[*HUAWEI-GigabitEthernet1/0/0] vrrp vrid 100 virtual-ip 192.168.10.100
[*HUAWEI-GigabitEthernet1/0/0] admin-vrrp vrid 100
[*HUAWEI-GigabitEthernet1/0/0] quit
[*HUAWEI] mpls
[*HUAWEI-mpls] quit
[*HUAWEI] mpls l2vpn
[*HUAWEI-l2vpn] quit
[*HUAWEI] vsi v100 bd-mode
[*HUAWEI-v100] pwsignal ldp
[*HUAWEI-v100-ldp] vsi-id 100
[*HUAWEI-v100-ldp] peer 2.2.2.2 negotiation-vc-id 100 track admin-vrrp interface
gigabitethernet 1/0/0 vrid 100 pw-redundancy backup-block-all

4.3.41 reset bridge-domain statistics
Function
The reset bridge-domain statistics command clears traffic statistics of a BD.
Format
reset bridge-domain bd-id statistics
Parameters
bd-id Clears traffic statistics of a specified The value is an integer ranging from
bridge domain ID. 1 to 32768.
Views
User view
Default Level

bdbase execute
Usage Guidelines
Usage Scenario
Before you collect traffic statistics within a specified period for a BD, run the reset bridge-
domain statistics command to clear existing statistics so that traffic statistics can be collected
again, ensuring that the statistics are correct.
Prerequisites
A BD has been created using the bridge-domain bd-id command in the system view.
Precautions
Traffic statistics of a BD are cleared and cannot be restored. Exercise caution when running
the reset bridge-domain statistics command.
Example
# Clear traffic statistics of BD 10.
<HUAWEI> reset bridge-domain 10 statistics

4.3.42 reset mac-address bridge-domain

Function
The reset mac-address bridge-domain command deletes dynamically learned MAC address
entries in a bridge domain (BD).
Format
reset mac-address bridge-domain bd-id
Parameters
bd-id Deletes MAC address entries with a The value is an integer ranging
specified bridge domain ID. from 1 to 32768.
Views
User view
Default Level

mac execute
Usage Guidelines
Usage Scenario
To delete dynamically learned MAC address entries (entries to be deserted, for example) in a
BD, run the reset mac-address bridge-domain command.
Prerequisites
A BD has been created using the bridge-domain bd-id command in the system view.
Precautions
After the reset mac-address bridge-domain command is run, the dynamically learned MAC
address entries are deleted and cannot be restored. Exercise caution when running the
command.
Example
# Delete MAC address entries in a specified BD 10.
<HUAWEI> reset mac-address bridge-domain 10

4.3.43 reset vxlan statistics
Function
The reset vxlan statistics command clears VXLAN packet statistics.
Format
# Clear VXLAN packet statistics by VNI.
reset vxlan statistics vni vni-id
# Clear VXLAN packet statistics by VNI and VXLAN tunnel.
reset vxlan statistics source source-ip peer peer-ip vni vni-id
reset vxlan statistics source source-ip peer peer-ip local-vni local-vni-id
reset vxlan statistics source source-ip peer peer-ip remote-vni remote-vni-id
Parameters

vni vni-id Clears VXLAN packets statistics The value is an integer
collected based on a specified VNI ID. ranging from 1 to 16777215.
source source-ip Clears VXLAN packets statistics

The value is in dotted
collected based on the source IP
decimal notation.
address.
peer peer-ip Clears VXLAN packet statistics
collected based on the IP address of
decimal notation.
the peer virtualized edge node.
local-vni local-vni- Specifies the local VNI ID based on
The value is an integer
id which upstream VXLAN packet
statistics are to be cleared.
remote-vni remote- Specifies the remote VNI ID based on
vni-id which downstream VXLAN packet
statistics are to be cleared.
Views
User view
Default Level


nvo3 execute
Usage Guidelines
Usage Scenario
In cloud VPN scenarios, cloud GWs support VXLAN packet statistics collection. To clear
VXLAN packet statistics, run the reset vxlan statistics command.
Precautions
After the reset vxlan statistics command is run, VXLAN packet statistics on a device are
cleared and cannot be restored. Exercise caution when you run this command.
Example
# Clear VXLAN packet statistics collected based on the VNI with the ID of 1.
<HUAWEI> reset vxlan statistics vni 1
# Clear VXLAN packet statistics collected based on the source IP address 1.1.1.1, VNI with
the ID of 1, and the IP address of the peer virtualized edge node as 1.1.1.2.
<HUAWEI> reset vxlan statistics source 1.1.1.1 peer 1.1.1.2 vni 1
# Clear upstream VXLAN packet statistics collected based on the source IP address 10.1.1.1,
remote VTEP IP address 10.2.2.2, and local VNI ID 1.
<HUAWEI> reset vxlan statistics source 10.1.1.1 peer 10.2.2.2 local-vni 1
# Clear downstream VXLAN packet statistics collected based on the source IP address
10.1.1.1, remote VTEP IP address 10.2.2.2, and remote VNI ID 2.
<HUAWEI> reset vxlan statistics source 10.1.1.1 peer 10.2.2.2 remote-vni 2
4.3.44 reset vxlan statistics l3-mode
Function
The reset vxlan statistics l3-mode command clears Layer 3 VXLAN traffic statistics.
Format
reset vxlan statistics l3-mode source source-ip peer peer-ip local-vni vni-id
reset vxlan statistics l3-mode source source-ip peer peer-ip remote-vni vni-id
Parameters
source source-ip Clears statistics about Layer 3 VXLAN
traffic with a specified source VTEP IP
notation.
address.


peer peer-ip Clears statistics about Layer 3 VXLAN
traffic with a specified peer VTEP IP
notation.
address.
local-vni vni-id Clears statistics about upstream Layer 3 The value is an integer
VXLAN traffic with a local VNI. ranging from 1 to 16777215.
remote-vni vni-id Clears statistics about downstream

Layer 3 VXLAN traffic with a remote
VNI.
Views
User view
Default Level

nvo3 execute
Usage Guidelines
Usage Scenarios
Layer 3 VXLAN statistics can be collected. To clear the existing Layer 3 VXLAN statistics
before collecting new statistics, run the reset vxlan statistics l3-mode command.
Precautions
Layer 3 VXLAN statistics will all be cleared and cannot restore in the following situations:
l The reset vxlan statistics l3-mode command is run.
l The device is restarted, and VXLAN tunnels are deleted.
Example
# Clear statistics about upstream Layer 3 VXLAN traffic with source VTEP IP address
1.1.1.1, peer VTEP IP address 1.1.1.2, and local VNI 1.
<HUAWEI> reset vxlan statistics l3-mode source 1.1.1.1 peer 1.1.1.2 local-vni 1
4.3.45 route-distinguisher (EVPN instance view)

Function
The route-distinguisher command configures an RD for an EVPN instance.
The undo route-distinguisher command deletes the RD of an EVPN instance.

By default, no RD is configured for an EVPN instance.
Format
route-distinguisher route-distinguisher
undo route-distinguisher route-distinguisher
Parameters
route- Specifies an RD. An RD can be in either of the following formats: -
distinguisher l 2-byte AS number:4-byte user-defined number, such as 1:3. The
AS number ranges from 0 to 65535, and the user-defined
number ranges from 0 to 4294967295. The AS number and
user-defined number cannot be both 0s. Specifically, an RD
cannot be 0:0.
number, such as 0.0:3 or 0.1:0. The AS number is in the format
of x.y, where x and y are integers ranging from 0 to 65535. The
user-defined number also ranges from 0 to 65535. The AS
Specifically, an RD cannot be 0.0:0.
255.255.255.255, and the user-defined number ranges from 0 to
65535.
Views
Default Level

bgp write
Usage Guidelines
Usage Scenario
An RD must be configured for an EVPN instance after the EVPN instance is created. To
configure an RD for an EVPN instance, run the route-distinguisher command.

Different EVPN instances may have the same route prefix. To allow a PE to determine to
which EVPN instance a route belongs, run the route-distinguisher command to configure an
RD for each EVPN instance on the PE. After the configuration, a route sent from an EVPN
instance will carry an RD, making the route a globally unique EVPN route.
Precautions
Running the undo route-distinguisher command in the B-EVPN instance view causes
EVPN-related configurations to be deleted.
Example
# Configure an RD for EVPN instance evpn1.
Related Topics
4.3.46 source (NVE interface view)
Function
The source command configures an IP address for a source VXLAN tunnel endpoint (VTEP).
The undo source command deletes the IP address of a source VTEP.
By default, no IP address is configured for any source VTEP.
Format
source ip-address
undo source [ ip-address ]
Parameters

ip-address Specifies an IP address for a source The value is in dotted decimal
VTEP. notation.
Views
NVE interface view
Default Level


nvo3 write
Usage Guidelines
Usage Scenario
A VTEP is a VXLAN tunnel endpoint that encapsulates or decapsulates VXLAN packets. It

is represented by a network virtualization edge (NVE).
To configure an IP address for a source VTEP, run the source command. In VXLAN packets,
the source IP address is the source VTEP's IP address, and the destination IP address is a
remote VTEP's IP address. This pair of VTEP addresses corresponds to a VXLAN tunnel.
Precautions
Either a physical interface's IP address or loopback interface address can be specified for a
source VTEP. Using the loopback interface address as the source VTEP's IP address is
recommended.
Generally, you need to configure different VTEP IP addresses for the NVE interfaces of
different devices; otherwise, traffic forwarding error may occur. However, in some special
scenarios (for example, an M-LAG-enabled dual-active VXLAN access scenario or a multi-
active VXLAN gateways scenario), you need to configure the same VTEP IP address for the
gateways' NVE interfaces.
The IP address configured for a source VXLAN tunnel endpoint (VTEP) using the source
command cannot be the same as the EVPN source address configured for PE identification
using the evpn source-address ip-address command.
Example
# Configure the IP address 1.1.1.1 for a source VTEP.
4.3.47 statistic enable (BD view)
Function
The statistic enable command enables traffic statistics collection for a bridge domain (BD).
The undo statistic enable command disables traffic statistics collection in a BD.
By default, traffic statistics collection is disabled in BDs.
Format
statistic enable

Parameters
None
Views
BD view
Default Level

bdbase write
Usage Guidelines
Usage Scenario
By default, traffic statistics collection is disabled in BDs. Before you run the display bridge-
domain statistics command to view traffic statistics for fault locating, run the statistics
enable command in the BD view to enable traffic statistics collection. If traffic statistics
collection is not enabled for a BD, you cannot obtain the traffic statistics in the BD.
Precautions
l After traffic statistics collection is enabled for a BD, the device counts every packet
received in the BD. If a large number of packets pass through the BD, the device counts
all these packets and subsequently stores large amounts of statistics, causing device
operation performance to deteriorate.
l If traffic statistics collection is not needed in a BD, run the undo statistic enable
command to disable the function.
Follow-up Procedure
Run the display bridge-domain statistics command to view traffic statistics in the BD. The
command output helps locate faults.
Example
# Enable traffic statistics collection for BD 10.
[*HUAWEI-bd10] statistic enable
4.3.48 statistic enable (VNI view)

Function
The statistic enable command enables VXLAN traffic statistics collection.
The undo statistic enable command disables VXLAN traffic statistics collection.

By default, VXLAN traffic statistics collection is disabled.
Format
statistic enable
Parameters
None
Views
VNI view
Default Level

nvo3 write
Usage Guidelines
Usage Scenario
By default, VXLAN traffic statistics collection is disabled. Before you check VXLAN traffic
statistics of a VNI for fault locating, run the statistic enable command in the VNI view to
enable VXLAN traffic statistics collection. If traffic statistics collection is not enabled for a
VNI, you cannot obtain the VXLAN traffic statistics of the VNI.
If a large number of VXLAN packets exist, the device counts all these packets and
subsequently stores large amounts of statistics, causing device operation performance to
deteriorate. If VXLAN traffic statistics collection is not needed, run the undo statistic enable
command to disable the function.
Example
# Enable VXLAN traffic statistics collection.
[~HUAWEI] vni 10
[*HUAWEI-vni10] statistic enable
4.3.49 vni
Function
The vni command creates a VXLAN network identifier (VNI) and displays the VNI view. If a
VNI has been created, the VNI view is directly displayed.

The undo vni command deletes a configured VNI.

By default, no VNI is created.
Format
vni vni-id
undo vni vni-id
Parameters
vni-id Specifies a VNI ID. The value is an integer ranging from 1 to 16777215.
Views
System view
Default Level

nvo3 write
Usage Guidelines
VNIs are similar to VLAN IDs. VXLAN uses VNIs to differentiate VXLAN segments and
identify tenants. A VNI identifies only one tenant. Even if multiple terminal users belong to
the same VNI, they are considered one tenant.
The vni and virtual-access commands are mutually exclusive.
Example
# Create a VNI with the VNI ID of 4096.
[~HUAWEI] vni 4096
4.3.50 vni evpl peer

Function
The vni evpl peer command creates a P2P VXLAN tunnel.
The undo vni evpl peer command deletes a P2P VXLAN tunnel.
By default, no P2P VXLAN tunnel is created.

Format
vni vni-id evpl peer ip-address
undo vni vni-id evpl peer ip-address
Parameters
vni-id Specifies the ID of a VNI to which a local The value is an integer ranging
EVPL instance is to be bound. from 1 to 16777215.
ip-address Specifies a peer VTEP IP address for an The value is in dotted decimal
EVPL instance. notation.
Views
NVE interface view
Default Level

nvo3 write
Usage Guidelines
Usage Scenario
In scenarios where VXLAN tunnels are used for user access, run the vni evpl peer command
to create a P2P VXLAN tunnel to transmit user packets. Then, bind the VXLAN tunnel's VNI
to an EVPL instance, and bind a PW-VE interface to the EVPL instance. These binding
operations associate the P2P VXLAN tunnel with the PW-VE interface and then allow
VXLAN tunnel information to be terminated on the PW-VE interface.
Example
# Create a P2P VXLAN tunnel.
[*HUAWEI-Nve1] vni 1 evpl peer 2.2.2.2
4.3.51 vni head-end peer-list

Function
The vni head-end peer-list command configures an ingress replication list that contains the
IP addresses of those remote VTEPs for a VXLAN network identifier (VNI).

The undo vni head-end peer-list command deletes the ingress replication list of a VNI.
By default, no ingress replication list is configured for any VNI.
Format
vni vni-id head-end peer-list ip-address &<1-10>
undo vni vni-id [ head-end peer-list ip-address &<1-10> ]
vni vni-id head-end peer-list protocol bgp
undo vni vni-id head-end peer-list protocol bgp
Parameters
vni-id Specifies a VNI ID. The value is an integer ranging
from 1 to 16777215.
ip-address Specifies the IP address of a remote The value is in dotted decimal

VXLAN tunnel endpoint (VTEP). notation.
protocol bgp Specifies BGP for establishing Layer 2 -

VXLAN tunnels.
Views
NVE interface view
Default Level

nvo3 write
Usage Guidelines
Usage Scenario
replication list. The ingress replication list is a collection of remote VTEP IP addresses to
which the ingress of a VXLAN tunnel should send replicated BUM packets.
If a source VTEP on a VXLAN connects to multiple remote VTEPs on the same VXLAN
segment, run the vni head-end peer-list command to configure an ingress replication list that
contains the IP addresses of those remote VTEPs. After the source NVE receives BUM
packets, the local VTEP sends a copy of the BUM packets to every VTEP in the list.

To use BGP to dynamically establish Layer 2 VXLAN tunnels, run the vni vni-id head-end
peer-list protocol bgp command.
Ingress replication allows BUM packets to be transmitted in broadcast mode, independent of
multicast routing protocols.
Precautions
Even if a source VTEP connects only to one remote VTEP, you still need to run the vni head-
end peer-list command to configure an ingress replication list with the remote VTEP's IP
address specified.
BUM packet forwarding is implemented only using ingress replication. To establish a
VXLAN tunnel between a Huawei device and a non-Huawei device, ensure that the non-
Huawei device also has ingress replication configured. Otherwise, communication fails.
Example
# Configure an ingress replication list for VNI 5010, with the remote VTEPs' IP addresses
being 2.2.2.2 and 3.3.3.3.
[*HUAWEI-Nve1] vni 5010 head-end peer-list 2.2.2.2 3.3.3.3
# Configure BGP to dynamically establish Layer 2 VXLAN tunnels.

[*HUAWEI-Nve1] vni 5010 head-end peer-list protocol bgp
4.3.52 vni (NVE interface view)

Function
The vni command configures a VXLAN network identifier (VNI) for an NVE interface.
The undo vni command deletes the VNI for an NVE interface, and deletes all configurations
for the same VNI on the current NVE interface.
By default, no VNI is configured for an NVE interface.
Format
vni vni-id
undo vni vni-id
Parameters
Views
NVE interface view

Default Level

nvo3 write
Usage Guidelines
Usage Scenario
VNIs are similar to VLAN IDs. VXLAN uses VNIs to differentiate VXLAN segments and
identify tenants. A VNI identifies only one tenant. Even if multiple terminal users belong to
the same VNI, they are considered one tenant. Run this command to configure a VNI for an
NVE interface
Precautions
If other configurations are performed for the same VNI on the current NVE interface, the
command configuration will be overwritten.
Example
# Configures a VNI for an NVE interface.
[*HUAWEI-Nve1] vni 10
4.3.53 vpn-target (EVPN instance view)

Function
The vpn-target command configures VPN targets for an EVPN instance.
The undo vpn-target command deletes the VPN targets configured for an EVPN instance.
By default, no VPN targets are configured for an EVPN instance.
Format
vpn-target vpn-target &<1-8> [ both | export-extcommunity | import-extcommunity ]
undo vpn-target { all | vpn-target &<1-8> [ both | export-extcommunity | import-
extcommunity ] }

Parameters
vpn-target Specifies the VPN targets to be added to the VPN target list of -
the EVPN instance address family. The value can be in either of
the following formats:
l 2-byte AS number:4-byte user-defined number, such as 1:3.
The AS number ranges from 0 to 65535, and the user-
defined number ranges from 0 to 4294967295. The AS
Specifically, a VPN target cannot be 0:0.
number, such as 0.0:3 or 0.1:0. The AS number is in the
format of x.y, where x and y are integers ranging from 0 to
65535. The user-defined number also ranges from 0 to
65535. The AS number and user-defined number cannot be
both 0s. Specifically, a VPN target cannot be 0.0:0.
255.255.255.255, and the user-defined number ranges from 0
to 65535.
both Adds VPN targets to both the import and export VPN target lists -
of the EVPN instance address family. If you do not specify
both, export-extcommunity, or import-extcommunity, VPN
targets will be added to both the import and export VPN target
lists.
export- Adds VPN targets to the export VPN target list of the EVPN -
import- Adds VPN targets to the import VPN target list of the EVPN -
all Deletes all the VPN targets of the current EVPN instance -
address family.
Views
Default Level


evpn write
Usage Guidelines
Usage Scenario
When a PE advertises EVPN routes to other PEs, the PE attaches all the local export VPN
targets to these routes. After a PE receives EVPN routes, the PE matches export VPN targets
carried in these routes against the local import VPN target list and imports these routes to the
local EVPN instance routing table only if at least one export VPN target matches one import
VPN target.
NOTE
One vpn-target command configures a maximum of eight VPN targets. To configure more VPN targets,
Prerequisites
An RD has been configured for the EVPN instance using the route-distinguisher command.
If you do not configure this command, a PE cannot import received EVPN routes to its local
EVPN instance routing table.
After all the VPN targets of an EVPN instance are deleted using the undo vpn-target
command, all EVPN routes learned by the EVPN instance from other EVPN instances will be
deleted.
Example
# Configure both the import and export VPN targets as 5:5 for an EVPN instance.
[*HUAWEI-evpn-instance-evpn1] vpn-target 5:5 both
Related Topics
4.3.45 route-distinguisher (EVPN instance view)
4.3.54 vtep-src (EVPL instance in VXLAN mode view)
Function
The vtep-src command configures an IP address for the source VXLAN tunnel end point
(VTEP) of the VXLAN tunnel bound to an EVPL instance.
The undo vtep-src command restores the default configuration.

By default, the VXLAN tunnel bound to an EVPL instance uses the source IP address of the
NVE interface as the IP address of the source VTEP.
Format
vtep-src ip-address
undo vtep-src ip-address
Parameters

ip-address Configures an IP address for the source VTEP of The value is in dotted
the VXLAN tunnel bound to an EVPL instance. decimal notation.
Views
EVPL instance VXLAN mode view
Default Level

nvo3 write
Usage Guidelines
Usage Scenario
When configuring a VXLAN tunnel, first configure an IP address for the source VTEP. This
IP address serves as the source IP address of VXLAN packets. Because a VXLAN tunnel is
established between a source VTEP and a peer VTEP, a different IP address also needs to be
configured for the peer VTEP. This IP address serves as the destination IP address in VXLAN
packets.
During P2P VXLAN configuration, run the vtep-src command to configure an IP address for
the source VTEP of the VXLAN tunnel bound to an EVPL instance.
Precautions
If the vtep-src command is not run for an EVPL instance, a VXLAN tunnel of the EVPL
instance uses the NVE interface's source address as the source VTEP address. If the vtep-src
command is run for an EVPL instance, a VXLAN tunnel of the EVPL instance uses the
address specified in the command by preference.

Example
# Configure 10.1.1.1 as the IP address of the source VTEP of the VXLAN tunnel bound to an
EVPL instance.
[*HUAWEI-evpl-vxlan1] vtep-src 10.1.1.1
4.3.55 vxlan anycast-gateway enable
Function
The vxlan anycast-gateway enable command enables distributed gateway.
The undo vxlan anycast-gateway enable command disables distributed gateway.
By default, distributed gateway is disabled.
Format
undo vxlan anycast-gateway enable
Parameters
None
Views
Default Level

nvo3 write
Usage Guidelines
Usage Scenario
To enable distributed gateway on a VBDIF interface and allow the gateway to learn only user-
side ARP, ND, or DHCP packets, run the vxlan anycast-gateway enable command. After
distributed gateway is enabled, the gateway:
l Processes only received user-side ARP, ND, or DHCP packets and generates host routes
accordingly.
l Deletes network-side ARP, ND, or DHCP entries already learned and deletes the
corresponding host routes.

After distributed gateway is enabled:
l VXLAN tunnel-side static ARP, ND, or DHCP entries cannot be configured on the
gateway.
l If distributed gateways have the same IP address, they do not report ARP, ND, or DHCP
conflicts.
l If ARP proxy is not enabled but the network-side devices and user-side hosts have the
same IP address, the gateways do not report IP address conflict alarms.
Example
# Enable distributed gateway on VBDIF 10.
[*HUAWEI-bd10] quit
[*HUAWEI-Vbdif10] vxlan anycast-gateway enable
4.3.56 vxlan central-reassemble enable
Function
The vxlan central-reassemble enable command enables centralized inter-board reassembly
on VXLAN tunnels.
The undo vxlan central-reassemble enable command disables centralized inter-board
reassembly on VXLAN tunnels.
By default, centralized inter-board reassembly is disabled on VXLAN tunnels.
Format
vxlan central-reassemble enable
undo vxlan central-reassemble [ enable ]
Parameters
None
Views
System view
Default Level

forwarding write

Usage Guidelines
If a VXLAN tunnel is established over a trunk that uses per-packet load balancing, two
fragments of a packet may be transmitted through different boards. Therefore, the peer device
will receive the two fragments through different boards and reassemble the fragments
separately. If reassembly times out on one board, packet reassembly fails. To prevent
reassembly failures caused by reassembly timeout on a board, run the vxlan central-
reassemble enable command to enable centralized inter-board reassembly on VXLAN
tunnels. This allows the receive device to select a board in the Up state for each VXLAN
tunnel to reassemble fragments received from different boards.
After this command is run, all VXLAN tunnels use centralized inter-board reassembly.
Example
# Enable centralized inter-board reassembly on VXLAN tunnels.
[~HUAWEI] vxlan central-reassemble enable
4.3.57 vxlan statistics enable
Function
The vxlan statistics enable command enables the function of collecting VXLAN packet
statistics based on the VNI and VXLAN tunnel.
The undo vxlan statistics enable command disables the function of collecting VXLAN
packet statistics based on the VNI and VXLAN tunnel.
By default, the function of collecting VXLAN packet statistics based on the VNI and
VXLAN tunnel is disabled.
Format
vxlan statistics peer peer-ip vni vni-id [ inbound | outbound ] enable
undo vxlan statistics peer peer-ip vni vni-id [ inbound | outbound ] enable
Parameters

vni vni-id Enables VXLAN packets statistics collection The value is an integer
based on a specified VNI ID. ranging from 1 to 16777215.
peer peer-ip Enables VXLAN packet statistics collection The value is in dotted
based on the IP address of the peer VTEP. decimal notation.
inbound Collects VXLAN packet statistics for -

upstream traffic.


outbound Collects VXLAN packet statistics for -
downstream traffic.
Views
NVE interface view
Default Level

nvo3 write
Usage Guidelines
Usage Scenario
By default, VXLAN traffic statistics collection is disabled. To enable the VXLAN traffic
statistics collection function based on a VNI ID and VXLAN tunnel, run the vxlan statistics
enable command. If the function of collecting VXLAN packet statistics is disabled, you
cannot obtain the statistics.
Example
# Enable the VXLAN packet statistics collection function based on the VNI with the ID of 1
and the IP address of the peer VTEP as 1.1.1.2.
[*HUAWEI-Nve1] vxlan statistics peer 1.1.1.2 vni 1 enable
4.3.58 vxlan statistics l3-mode enable

Function
The vxlan statistics l3-mode enable command enables Layer 3 traffic statistics collection by
VNI and VXLAN tunnel.
The undo vxlan statistics l3-mode enable command disables Layer 3 traffic statistics
collection by VNI and VXLAN tunnel.
By default, Layer 3 traffic statistics collection by VNI and VXLAN tunnel is disabled.
Format
vxlan statistics l3-mode peer peer-ip vni vni-id inbound enable

vxlan statistics l3-mode peer peer-ip [ vni vni-id ] outbound enable
undo vxlan statistics l3-mode peer peer-ip vni vni-id inbound enable
undo vxlan statistics l3-mode peer peer-ip [ vni vni-id ] outbound enable
Parameters

peer peer-ip Specifies the IP address of a peer VTEP for which
Layer 3 VXLAN traffic statistics collection is
decimal notation.
enabled or disabled.
vni vni-id Specifies a VNI for which Layer 3 VXLAN traffic The value is an integer
statistics collection is enabled or disabled. ranging from 1 to
16777215.
inbound Enables or disables Layer 3 upstream traffic -

statistics collection by VNI and VXLAN tunnel.
outbound Enables or disables Layer 3 downstream traffic -
statistics collection by VNI and VXLAN tunnel.
Views
NVE interface view
Default Level

nvo3 write
Usage Guidelines
Usage Scenarios
Before checking the statistics about sent or received Layer 3 traffic collected by VNI and
VXLAN tunnel for problem locating, run the vxlan statistics l3-mode enable command in
the NVE interface view to enable upstream and downstream Layer 3 traffic statistics
collection by VNI and VXLAN tunnel. If you do not run the vxlan statistics l3-mode enable
command, VXLAN statistics cannot be obtained.
Precautions
The vxlan statistics l3-mode enable and statistic enable (VNI view) commands are
mutually exclusive.

If you run the undo vxlan statistics l3-mode enable command, Layer 3 VXLAN traffic
statistics will be cleared and cannot restore. Therefore, exercise caution when running this
command.
Example
# Enable upstream Layer 3 traffic statistics collection by VNI 1 and peer VTEP IP address
1.1.1.2.
[*HUAWEI-Nve1] vxlan statistics l3-mode peer 1.1.1.2 vni 1 inbound enable
# Enable downstream Layer 3 traffic statistics collection by VNI 1 and peer VTEP IP address
2.2.2.2.
[*HUAWEI-Nve1] vxlan statistics l3-mode peer 2.2.2.2 outbound enable
4.3.59 vxlan vni
Function
The vxlan vni command creates a VXLAN network identifier (VNI) and maps a VNI to a
bridge domain (BD) in 1:1 mode.
The undo vxlan vni command deletes the mapping between a VNI and a BD.
Format
vxlan vni vni-id
undo vxlan vni vni-id
Parameters

Views
BD view
Default Level


nvo3 write
Usage Guidelines
A virtual network (VN) on a VXLAN is a virtual broadcast domain. To allow a BD to
function as a VXLAN network entity to transmit VXLAN traffic, run the vxlan vni command
to map a VNI to a BD in 1:1 mode.
The VNI bound to a VPN instance cannot be bound to a BD.
The vxlan vni and virtual-access commands are mutually exclusive.
Precautions
Restrictions for connection between the VXLAN and EVPN MPLS are as follows:
l In a BD, the BD can be bound to the VNI and BD EVPN at the same time.
l Each VNI can be added to only one BD, and each BD can be added to only one VNI.
l Only 1:1 mode is supported to access the VSI.
l EVC sub-interfaces are not supported to access the VXLAN or EVPN.
l VXLAN tunnels and EVPNs do not support dynamic MAC address learning. They
advertise and receive MAC address routes through BGP.
l Tunnel-side broadcast, multicast, and unknown unicast are supported for VXLANs. The
device replicates packets based on VNI+peer statistics.
Example
# Map VNI5000 to BD10.
[*HUAWEI-bd10] vxlan vni 5000
4.3.60 vxlan vni (VPN instance view)
Function
The vxlan vni command binds a VXLAN network identifier (VNI) to a virtual private
network (VPN) instance.
The undo vxlan vni command unbinds a VNI from a VPN instance.
By default, a VNI is not bound to any VPN instance.
Format
vxlan vni vni-id
undo vxlan vni vni-id

Parameters
Views
VPN instance view
Default Level

nvo3 write
Usage Guidelines
Usage Scenario
To isolate tenants at Layer 3, VPN is generally used. In a distributed VXLAN gateway
scenario, to implement Layer 3 communication through a Layer 3 gateway, the Layer 3
gateway must be bound to a VPN instance.
The Layer 3 gateway assigns a Layer 2 VNI to each tenants and a Layer 3 VNI to each tenant
identified by a VPN instance. To bind a VNI to a VPN instance, run the vxlan vni command.
During Layer 3 communication through the Layer 3 gateway, the VNI ID bound to the VPN
instance is transmitted to the remote Layer 3 gateway through the VXLAN tunnel. The remote
Layer 3 gateway identifies VPNs based on tenants' VNI IDs to determine whether tenants
belong to the same VPN for communication or isolation purposes.
Precautions
A VNI can be bound only to one VPN instance.
The VNI bound to a VPN instance cannot be bound to a BD.
Example
# Bind VNI 5000 to a VPN instance named huawei.
[~HUAWEI] ip vpn-instance huawei
[*HUAWEI-vpn-instance-huawei] vxlan vni 5000
4.3.61 vxlan vni split-horizon-mode

Function
The vxlan vni split-horizon-mode command creates a VXLAN network identifier (VNI) and
binds it to a BD, and configures split horizon for packet forwarding.

The undo vxlan vni command unbinds a VNI from a BD.
Format
vxlan vni vni-id split-horizon-mode
undo vxlan vni vni-id split-horizon-mode
Parameters

Views
BD view
Default Level

nvo3 write
Usage Guidelines
A virtual network (VN) on a VXLAN is a virtual broadcast domain. To allow a BD to
function as a VXLAN network entity to transmit VXLAN traffic, run the vxlan vni command
to map a VNI to a BD in 1:1 mode.
When a VXLAN network and a VPLS network intersect, to allow internetworking, run the
vxlan vni vni-id split-horizon-mode command on the edge devices at the intersection of the
two networks to create a VNI and bind it to a BD, and configure split horizon for packet
forwarding.
Example
# Bind VNI 5000 to BD 10 and configure split horizon for packet forwarding.

New IP Technologies 5 NG MVPN
5 NG MVPN
5.1 Multicast VPN in NG MVPN Mode
5.1.1 Overview of NG MVPN
Purpose
BGP/MPLS IP VPNs are widely deployed as they provide excellent reliability and security.
Meanwhile, IP multicast is gaining increasing popularity among service providers as it
provides highly efficient point-to-multipoint (P2MP) traffic transmission. Rapidly developing
multicast applications, such as IPTV, video conference, and distance education, impose
increasing requirements on network reliability, security, and efficiency. As a result, service
providers' demand for delivering multicast services over BGP/MPLS IP VPNs is also
increasing. In this context, the multicast virtual private network (MVPN) solution is
developed. The MVPN technology, when applied to a BGP/MPLS IP VPN, can transmit VPN
multicast traffic to remote VPN sites across the public network.
Rosen MVPNs establish multicast distribution trees (MDTs) using Protocol Independent
Multicast (PIM) to transmit VPN multicast protocol and data packets, and have the following
limitations:
l VPN multicast protocol and data packets must be transmitted using the MDT, which
complicates network deployment because the multicast function must be enabled on the
public network.
l The public network uses GRE for multicast packet encapsulation and cannot leverage the
MPLS advantages, such as high reliability, QoS guarantee, and TE bandwidth
reservation, of existing BGP/MPLS IP VPNs.
Next-generation (NG) MVPNs, which have made improvements over Rosen MVPNs, have
the following characteristics:
l The public network uses BGP to transmit VPN multicast protocol packets and routing
information. Multicast protocols do not need to be deployed on the public network,
simplifying network deployment and maintenance.
l The public network uses the mature label-based forwarding and tunnel protection
techniques of MPLS, improving multicast service quality and reliability.

Definition
The NG MVPN is a new framework designed to transmit IP multicast traffic across a BGP/
MPLS IP VPN. An NG MVPN uses BGP to transmit multicast protocol packets, and uses
PIM-SM, PIM-SSM, P2MP TE, or mLDP to transmit multicast data packets. The NG MVPN
enables unicast and multicast services to be delivered using the same VPN architecture.
NG MVPN uses BGP to exchange messages on public networks to construct MPLS P2MP-
based multicast tunnels. These tunnels connect the private networks that contain multicast
sources and multicast users at both ends. In addition, NG MVPN uses BGP to transmit VPN
multicast routes, so that multicast traffic can be transmitted from the multicast sources to the
multicast user side.
Figure 5-1 shows a typical NG MVPN networking scenario, and Table 5-1 lists the roles of
different entities on an NG MVPN.
Figure 5-1 Typical NG MVPN networking scenario

P u b lic N e t w o r k
P r iv a t e N e t w o r k S e r v ic e P r iv a t e N e t w o r k
p r o v id e r 's R e c e iv e r
VPNA backbone
PE2 CE VPNA
S o u rc e CE1 PE1 2 R e c e iv e r
z
Sender s ite
s ite
PE3 R e c e iv e r
P 2 M P tu n n e l
P r iv a t e P IM J o in m e s s a g e
N e tw o rk M u ltic a s t tr a ffic
CE3 R e c e iv e r M P - B G P p e e r s e s s io n
VPNA s ite
P u b lic n e tw o r k
R e c e iv e r
P r iv a te n e tw o r k
Table 5-1 Roles on an NG MVPN

Role Description Example
Customer edge (CE) A CE directly connects to a CE1, CE2, and CE3 in

service provider network. Figure 5-1
Usually, a CE is unaware of
the VPN and does not need
to support MPLS.
Provider edge (PE) A PE directly connects to PE1, PE2, and PE3 in

CEs. On an MPLS network, Figure 5-1
PEs process all VPN
services. Therefore, the
requirements for PE
performance are high.
Provider device (P) A P does not directly P in Figure 5-1

connect to CEs. Ps only
need to possess basic MPLS
forwarding capabilities and
do not need to maintain
VPN information.

Role Description Example
Receiver site A receiver site is a site Site where multicast

where multicast receivers receivers reside in Figure
reside. 5-1
Receiver PE A receiver PE is a PE that PE2 and PE3 in Figure 5-1

connects to a receiver site.
Sender site A sender site is a site where Site where the multicast
the multicast source resides. source resides in Figure 5-1
Sender PE A sender PE is a PE that PE1 in Figure 5-1

connects to a sender site.
Benefits
NG MVPNs, which implement hierarchical forwarding of multicast data and control packets
on BGP/MPLS IP VPNs, offer the following benefits:
l Better security by transmitting VPN multicast data over BGP/MPLS IP VPNs.

l Better network maintainability by reducing network deployment complexity.
l Better service quality and reliability by using mature label-based forwarding and tunnel
protection techniques of MPLS.
5.1.2 Understanding NG MVPN
An NG MVPN is a new framework designed to transmit IP multicast traffic across a BGP/

MPLS VPN. To exchange control messages and create VPN multicast data channels, each PE
on an NG MVPN must be able to discover other PEs on the MVPN. The discovery process is
called MVPN membership autodiscovery. An NG MVPN uses BGP to implement this
process. To support MVPN membership autodiscovery, BGP defines a new BGP-MVPN
address family.
An NG MVPN transmits VPN multicast routes and establishes public network tunnels
through control messages defined by BGP-MVPN. BGP-MVPN defines seven types of
control messages, which represent seven types of MVPN routes. Type 6 and Type 7 routes are
used for VPN multicast joining and VPN multicast traffic forwarding. Type 1-5 routes are
used for MVPN membership autodiscovery and P2MP tunnel establishment. Type 6 and Type
7 routes are called C-multicast routes, and Type 1-5 routes are called A-D routes.
NG MVPN routing information is carried in BGP Update messages. The seven types of
control messages are not enough to complete multicast joining/leaving control and P2MP
tunnel establishment. MVPN extended community and PMSI attributes are introduced for
BGP.
After BGP peer relationships are established between PEs in the BGP-MVPN address family,
the MVPN extended community attributes control the sending and receiving of C-multicast
routes to transmit multicast users' Join/Leave messages. A-D routes help MPLS establish
P2MP tunnels. The information used to create a public network tunnel is carried by the PMSI,
which is a logical channel used by the public network to carry VPN multicast traffic.

5.1.2.1 NG MVPN Control Messages
The key mechanisms of NG MVPN are VPN multicast route transmission and public network
tunnel establishment. The two mechanisms are implemented by transmitting BGP messages
on the public network. These messages are NG MVPN control messages.
PEs on an NG MVPN exchange control messages to implement functions such as MVPN
membership autodiscovery, PMSI tunnel establishment, and VPN multicast joining and
leaving. The following describes these NG MVPN control messages. All examples in this
section are based on the network shown in Figure 5-2. On this network:
l The service provider's backbone network provides both unicast and multicast VPN
services for vpn1. The AS number of the backbone network is 65001.
l The multicast source resides at Site1 and accesses PE1 by means of CE1. This multicast
source sends multicast traffic to multicast group 232.1.1.1.
l Multicast receivers reside at Site2 and Site3.
l The backbone network provides MVPN services for vpn1 over RSVP-TE or mLDP
P2MP tunnels.
Figure 5-2 NG MVPN

R e c e iv e r P E
M VPN RT:
Sender PE 2 .2 .2 .9 :0
S o u rc e M VPN RT: M V P N ID :
C -S : 1 .1 .1 .9 :0 2 .2 .2 .9
1 9 2 .1 6 8 .1 .2 M V P N ID : R D : 2 0 0 :1
C -G : 1 .1 .1 .9
2 3 2 .1 .1 .1 R D : 1 0 0 :1 vpn1
S e r v ic e p r o v id e r 's PE2 CE2 R e c e iv e r
backbone
vpn1 p o r t1 p o r t1
A S 6 5 0 0 1 p o r t2
S o u rc e CE1 PE1 P p o r t2 p o r t2 S ite 2
p o r t1 p o r t2 p o r t2
( 1 9 2 .1 6 8 .1 .2 , 2 3 2 .1 .1 .1 )
p o r t1 p o r t1
S ite 1 p o r t3 vpn1
p o r t1 p o r t1
p o r t2
p o r t2
PE3 CE3 R e c e iv e r
S ite 3
R e c e iv e r P E
M VPN RT:
3 .3 .3 .9 :0
M V P N ID :
3 .3 .3 .9
R D : 3 0 0 :1
MVPN NLRI
A PE that participates in an NG MVPN is required to send a BGP Update message containing
the MVPN NLRI. The SAFI of the MVPN NLRI is 5. Figure 5-3 shows the MVPN NLRI
format.

Figure 5-3 MVPN NLRI format
Route type (1 octet)
Length (1 octet)
Route type specific (variable)
Table 5-2 Description of the fields in the MVPN NLRI

Field Description
Route type Type of an MVPN route. Seven types of MVPN routes are specified. For
more information, see Table 5-3.
Length Length of the Route type specific field in the MVPN NLRI.
Route type MVPN route information. The value of this field depends on the Route
specific type field. For more information, see Table 5-3.
Table 5-3 describes the types and functions of MVPN routes. Type 1-5 routes are called
MVPN A-D routes. These routes are used for MVPN membership autodiscovery and P2MP
tunnel establishment. Type 6 and Type 7 routes are called C-multicast routes (C is short for
Customer. C-multicast routes refer to multicast routes from the private network). These routes
are used for VPN multicast joining and VPN multicast traffic forwarding.

Table 5-3 Types and functions of MVPN routes

R Name Function Route Type Specific Parameter
o Field Format Description
u
t
e
T
y
p
e
1 Intra-AS Used for MVPN R D ( 8 o c te ts ) l RD: route

I-PMSI membership O r ig in a tin g r o u te r ’s IP distinguisher, an
a d d re s s
A-D route autodiscovery in intra- (a )
8-byte field in a
AS scenarios. MVPN- VPNv4 address.
1 0 0 :1
capable PEs use Intra- An RD and a 4-
1 .1 .1 .9
AS I-PMSI A-D routes byte IPv4
(b )
to advertise and learn address prefix
intra-AS MVPN form a VPNv4
membership address, which
information. is used to
differentiate
IPv4 prefixes
using the same
address space.
l Originating
router's IP
address: IP
address of the
device that
originates Intra-
AS A-D routes.
In NE40E
implementation,
the value is the
MVPN ID of the
device that
originates BGP
A-D routes.


u
t
e
T
y
p
e
2 Inter-AS Used for MVPN R D ( 8 o c te ts ) l RD: route

I-PMSI membership S o u r c e A S ( 4 o c te ts ) distinguisher, an
A-D route autodiscovery in inter- (a )
8-byte field in a
AS scenarios. MVPN- 1 0 0 :1
VPNv4 address.
capable ASBRs use 650001
An RD and a 4-
Inter-AS I-PMSI A-D byte IPv4
(b )
routes to advertise and address prefix
learn inter-AS MVPN form a VPNv4
membership address, which
information. is used to
differentiate
IPv4 prefixes
using the same
address space.
l Source AS: AS
where the source
device that
sends Inter-AS
A-D routes
resides.


u
t
e
T
y
p
e
3 S-PMSI Used by a sender PE to R o u te ty p e l RD: route

A-D route initiate a selective P- R D ( 8 o c te ts )
M u ltic a s t s o u r c e le n g th ( 1 o c te t)
distinguisher, an
tunnel for a particular M u ltic a s t s o u r c e ( v a r ia b le )
M u ltic a s t g r o u p le n g th ( 1 o c te t)
8-byte field in a
(C-S, C-G). M u ltic a s t g r o u p ( v a r ia b le )
O r ig in a tin g r o u te r 's IP a d d r e s s
VPNv4 address.
(a )
An RD and a 4-
3 byte IPv4
1 0 0 :1 address prefix
32
1 9 2 .1 6 8 .1 .2 form a VPNv4
32
2 3 2 .1 .1 .1 address, which
1 .1 .1 .9
is used to
(b )
differentiate
IPv4 prefixes
using the same
address space.
l Multicast source
length: length of
a multicast
source address.
The value is 32
if the multicast
group address is
an IPv4 address
or 128 if the
multicast group
address is an
IPv6 address.
l Multicast
source: address
of a multicast
source.
l Multicast group
length: length of
a multicast
group address.
The value is 32
if the multicast
group address is
an IPv4 address
or 128 if the
multicast group


u
t
e
T
y
p
e
address is an
IPv6 address.
l Multicast group:
address of a
multicast group.
l Originating
router's IP
address: IP
address of the
device that
originates A-D
routes. In
NE40E
implementation,
the value is the
MVPN ID of the
device that
originates BGP
A-D routes.
4 Leaf A-D Originated by a l Route key: set to

route receiver PE in R o u te k e y ( v a r a ib le ) the MVPN
response to receiving a NLRI of the S-
Type 3 route. A sender O r ig in a tin g r o u te r ’s IP a d d r e s s
PMSI A-D route
PE uses Leaf A-D (a ) received.
routes to discover the 1 0 0 :1
32 l Originating
leaf nodes of an S- 1 9 2 .1 6 8 .1 .2
32
router's IP
2 3 2 .1 .1 .1
PMSI tunnel. 1 .1 .1 .9
address: IP
2 .2 .2 .9
address of the
(b )
device that
NOTE originates A-D
The Route key is set to the routes. In
MVPN NLRI of the S- NE40E
PMSI A-D route received.
implementation,
the value is the
MVPN ID of the
device that
originates BGP
A-D routes.


u
t
e
T
y
p
e
5 Source Used by PEs to learn R D ( 8 o c te ts ) l RD: RD of the

Active A- the identity of active M u ltic a s t s o u r c e le n g th ( 1 o c te t) sender PE
D route VPN multicast M u ltic a s t s o u r c e ( v a r ia b le )
connected to the
sources. M u ltic a s t g r o u p le n g th ( 1 o c te t)
multicast source.
M u ltic a s t g r o u p ( v a r ia b le ) l Multicast source
(a ) length: length of
1 0 0 :1
a multicast
32
source address.
1 9 2 .1 6 8 .1 .2
The value is 32
if the multicast
32
group address is
2 2 5 .1 .1 .1
an IPv4 address
(b )
or 128 if the
multicast group
address is an
IPv6 address.
l Multicast
source: address
of a multicast
source.
l Multicast group
length: length of
a multicast
group address.
The value is 32
if the multicast
group address is
an IPv4 address
or 128 if the
multicast group
address is an
IPv6 address.
l Multicast group:
address of a
multicast group.


u
t
e
T
y
p
e
6 Shared Used in (*, G) R o u te ty p e l Route type:

Tree Join scenarios. R t- im p o r t MVPN route
N ext hop
route A Shared Tree Join RD type. The value
route is originated
S o u rc e A S
M u ltic a s t s o u r c e le n g th
6 indicates that
when a receiver PE
R P a d d re s s
M u ltic a s t g r o u p le n g th
the route is a
receives a (C-*, C-G) M u ltic a s t g r o u p Type 6 route
PIM Join message. A
(a )
(Shared Tree
receiver PE sends the
6
Join route).
1 .1 .1 .9 :0
Shared Tree Join route 2 .2 .2 .9 l Rt-import: VRF
1 0 0 :1
to sender PEs with 65001 Route Import
which it has 32
1 9 2 .1 6 8 .1 .2
Extended
established BGP peer 32 Community of
2 3 2 .1 .1 .1
relationships. (b ) the unicast route
NOTE to the multicast
NOTE
The (*, G) PIM-SM join source. For more
Shared Tree Join routes
initiated by a VPN is
and Source Tree Join information
called a (C-*, C-G) PIM about the VRF
routes have the same
join.
NLRI format. The Route Import
multicast source address is Extended
the RP address for (C-*, Community, see
C-G) joins.
MVPN
Extended
Communities.
The VRF Route
Import Extended
Community is
used by sender
PEs to
determine
whether to
process the BGP
C-multicast
route sent by a
receiver PE.
This attribute
also helps a
sender PE to
determine to
which VPN
instance routing
table a BGP C-


u
t
e
T
y
p
e
multicast route
should be added.
l Next hop: next
hop address.
l RD: RD of the
sender PE
connected to the
multicast source.
l Source AS:
Source AS
Extended
Community of
the unicast route
to the multicast
source. For more
information
about the Source
AS Extended
Community, see
MVPN
Extended
Communities.
l Multicast source
length: length of
a multicast
source address.
The value is 32
if the multicast
group address is
an IPv4 address
or 128 if the
multicast group
address is an
IPv6 address.
l RP address:
rendezvous
point address.
l Multicast group
length: length of
a multicast


u
t
e
T
y
p
e
group address.
The value is 32
if the multicast
group address is
an IPv4 address
or 128 if the
multicast group
address is an
IPv6 address.
l Multicast group:
address of a
multicast group.


u
t
e
T
y
p
e
7 Source Used in (S, G) R D ( 8 o c te ts ) l RD: RD of the

Tree Join scenarios. S o u r c e A S ( 4 o c te ts ) sender PE
route A Source Tree Join M u ltic a s t s o u r c e le n g th ( 1 connected to the
o c te t)
route is originated M u ltic a s t s o u r c e ( v a r ia b le )
multicast source.
when a receiver PE M u ltic a s t g r o u p le n g th ( 1
o c te t)
l Source AS:
receives a (C-S, C-G) M u ltic a s t g r o u p ( v a r ia b le ) Source AS
PIM Join message. A (a ) Extended
receiver PE sends the 1 0 0 :1
Community of
Source Tree Join route 65001
the unicast route
to sender PEs with to the multicast
32
which it has source. For more
1 9 2 .1 6 8 .1 .2
established BGP peer information
32
relationships. about the Source
NOTE
2 3 2 .1 .1 .1
AS Extended
The (S, G) PIM-SSM (b )
Community, see
join initiated by a VPN MVPN
is called a (C-S, C-G) Extended
PIM join.
Communities.
l Multicast source
length: length of
a multicast
source address.
The value is 32
if the multicast
group address is
an IPv4 address
or 128 if the
multicast group
address is an
IPv6 address.
l Multicast
source: address
of a multicast
source.
l Multicast group
length: length of
a multicast
group address.
The value is 32
if the multicast
group address is


u
t
e
T
y
p
e
an IPv4 address
or 128 if the
multicast group
address is an
IPv6 address.
l Multicast group:
address of a
multicast group.
PMSI Tunnel Attribute

The PMSI Tunnel attribute carries P-tunnel information used for P-tunnel establishment. The
following figure shows the PMSI Tunnel attribute format.
Table 5-4 Description of fields for the PMSI Tunnel attribute

Format Field Description
F la g s ( 1 o c te t) Flags Flags bits. Currently, only one flag

T u n n e l ty p e ( 1 o c te t)
indicating whether leaf information is
M P L S la b e l ( 3 o c te ts )
required is specified:
T u n n e l id e n tifie r ( v a r ia b le ) l If the PMSI Tunnel attribute
carried with a Type 3 route has its
Flags bit set to Leaf Information
Not Required, the receiver PE that
receives the Type 3 route does not
need to respond.
l If the PMSI Tunnel attribute
carried with a Type 3 route has its
Flags bit set to Leaf Information
Required, the receiver PE that
receives the Type 3 route needs to
send a Leaf A-D route in
response.

Format Field Description
Tunnel type Tunnel type, which can be:

l 0: No tunnel information present
l 1: RSVP-TE P2MP LSP
l 2: mLDP P2MP LSP
l 3: PIM-SSM Tree
l 4: PIM-SM Tree
l 5: BIDIR-PIM Tree
l 6: Ingress Replication
l 7: mLDP MP2MP LSP
Currently, NE40Es support only
RSVP-TE P2MP LSPs and mLDP
P2MP LSPs.
MPLS label MPLS labels are used for VPN tunnel

multiplexing. Currently, tunnel
multiplexing is not supported.
Tunnel identifier Tunnel identifier. Its value depends

on the value set in the Tunnel type
field: NE40Es support only the
following two types of tunnels:
l If the tunnel type is RSVP-TE
P2MP LSP, its value is <P2MP
ID, Tunnel ID, Extended Tunnel
ID>.
l If the tunnel type is mLDP P2MP
LSP, its value is <Root node
address, Opaque value>.
On an NG MVPN, the sender PE sets up the P-tunnel, and therefore is responsible for
originating the PMSI Tunnel attribute. The PMSI Tunnel attribute can be attached to Type 1-3
routes and sent to receiver PEs. Figure 5-4 is an example shows the format of an Intra-AS I-
PMSI A-D route carrying the PMSI Tunnel attribute.
Figure 5-4 Intra-AS I-PMSI A-D route carrying the PMSI Tunnel attribute
Next hop
RD
Originating router's IP address
5.1.2.2 NG MVPN Private Multicast Routing

The networks on the two sides of NG MVPN are one for the multicast source while the other
for multicast users, namely, the VPN on the multicast source side and the VPN on the user
side. The two networks connect to the public network separately through the sender PE and
receiver PE.
l The multicast source can be registered by the directly connected multicast source DR to
the RP, or receive the Join message sent by the receiver DR, so as to send multicast data
to the receiver. For details about multicast source registration, see PIM-SM and PIM-
SSM.
l A multicast user joins a multicast group through IGMP/MLD, and then the multicast
device to which the multicast group belongs sends a Join message to the multicast source
through PIM. In this manner, the multicast user can receive multicast data. For details
about how multicast users join multicast groups on VPNs, see IGMP and MLD.
On an NG MVPN, after a BGP peer relationship is established between PEs in the BGP
MVPN address family, the BGP MVPN extended community attribute can be used to carry
the VPN multicast route (C-multicast route) to transmit the join/leave information of multicast
users.
MVPN Extended Community Attributes

MVPN extended community attributes, which are used to control the advertisement and
receiving of BGP C-multicast routes, can be:
l Source AS Extended Community: carried in VPNv4 routes advertised by PEs. This
attribute is an AS extended community attribute and is mainly used in inter-AS
scenarios.
l VRF Route Import Extended Community: carried in VPNv4 routes advertised by sender
PEs to receiver PEs. When a receiver PE sends a BGP C-multicast route to a sender PE,
the receiver PE attaches this attribute to the route. In a scenario in which many sender
PEs exist, this attribute helps a sender PE that receives the BGP C-multicast route to
determine whether to process the route and to which VPN instance routing table the BGP
C-multicast route should be added.
The value of the VRF Route Import Extended Community is in the format of
"Administrator field value:Local Administrator field value". The Administrator field is
set to the local MVPN ID, whereas the Local Administrator field is set to the local VPN
instance ID of the sender PE.
On the network shown in Figure 5-5, PE1 and PE2 are both sender PEs, and PE3 is a
receiver PE. PE1 and PE2 connect to both vpn1 and vpn2. On PE1, the VRF Route
Import Extended Community is 1.1.1.9:1 for vpn1 and 1.1.1.9:2 for vpn2; on PE2, the
VRF Route Import Extended Community is 2.2.2.9:1 for vpn1 and 2.2.2.9:2 for vpn2.
After PE1 and PE2 both establish BGP MVPN peer relationships with PE3, PE1 and
PE2 both send to PE3 a VPNv4 route destined for the multicast source 192.168.1.2. The
VRF Route Import Extended Community carried in the VPNv4 route sent by PE1 is
1.1.1.9:1 and that carried in the VPNv4 route sent by PE2 is 2.2.2.9:1. After PE3
receives the two VPNv4 routes, PE3 adds the preferred route (VPNv4 route sent by PE1
in this example) to the vpn1 routing table and stores the VRF Route Import Extended
Community value carried in the preferred route locally for later BGP C-multicast route
generation.
Upon receipt of a PIM Join message from CE3, PE3 generates a BGP C-multicast route
with the RT-import attribute and sends this route to PE1 and PE2. The RT-import
attribute value of this route is the same as the locally stored VRF Route Import Extended
Community value, 1.1.1.9:1. Then,

– Upon receipt of the BGP C-multicast route, PE1 checks the RT-import attribute of
this route. After PE1 finds that the Administrator field value is 1.1.1.9, which is the
same as its local MVPN ID, PE1 accepts this route and adds it to the vpn1 routing
table based on the Local Administrator field value, 1.
– Upon receipt of the BGP C-multicast route, PE2 also checks the RT-import attribute
of this route. After PE2 finds that the Administrator field value is 1.1.1.9, a value
different from its local MVPN ID 2.2.2.9, PE2 drops this route.
Figure 5-5 Application of the VRF Route Import Extended Community
Source VRF Route Import Extended Community

C-S: 192.168.1.2 vpn1: 1.1.1.9:1 vpn2: 1.1.1.9:2 vpn1
C-G: 232.1.1.1
CE3 Receiver
Receiver
Source CE1 site
Sender site
vpn1 vpn2
Service CE4 Receiver
Source CE2 provider’s
backbone
Receiver site
Sender site VRF Route Import Extended Community
vpn2
vpn1: 2.2.2.9:1 vpn2: 2.2.2.9:2
PIM Join message BGP C-multicast route
This section describes the process of transmitting VPN multicast routes through the (S, G)
and (*, G) Join/Leave processes of multicast members.
5.1.2.2.1 PIM (S, G) Join/Prune

Multicast receiver joins/leaves a multicast group in PIM (S, G) modes.
On the network shown in Figure 5-6, CE1 connects to the multicast source, and CE2 connects
multicast receivers. CE2 sends PIM (S, G) Join/Prune messages to CE1. This process shows
how a multicast member joins and leaves a multicast group.
Figure 5-6 NG MVPN

S e r v ic e
R e c e iv e r
p r o v id e r 's
vpn1 PE1 backbone vpn1
S o u rc e CE1 PE2 CE2
R e c e iv e r
Sender s ite
s ite
PE3
R e c e iv e r
P 2 M P tu n n e l
R e c e iv e r
CE3 P IM J o in m e s s a g e
s ite
M u ltic a s t tr a ffic
vpn1
M P - IB G P p e e r s e s s io n
R e c e iv e r

Figure 5-7 Time sequences for joining a multicast group
1 B G P V P N v 4 r o u te
R e c e iv e r o u te a n d r e c o r d
2
E x te n d e d C o m m u n ity
3 P IM S S M J o in m e s s a g e
G e n e r a te m u ltic a s t e n tr y
4
T
im
a n d C - m u ltic a s t r o u te
5 C - m u ltic a s t r o u te
e
P r o c e s s C - m u ltic a s t r o u te , g e n e r a te
6 m u ltic a s t e n tr y , a n d c o n v e r t r o u te to
P IM S S M J o in m e s s a g e
7 P IM S S M J o in m e s s a g e
8 P r o c e s s P IM S S M
J o in m e s s a g e
Figure 5-7 shows the procedure for joining a multicast group, and Table 5-5 describes this
procedure.
Table 5-5 Procedure for joining a multicast group

Step Dev Key Action
ice
1 PE1 After PE1 receives a unicast route destined for the multicast source from
CE1, PE1 converts this route to a VPNv4 route, adds the Source AS
Extended Community and VRF Route Import Extended Community to this
route, and advertises this route to PE2.
For more information about the Source AS Extended Community and VRF
Route Import Extended Community, see MVPN Extended Community
Attributes.
2 PE2 After PE2 receives the VPNv4 route from PE1, PE2 matches the export
VPN target of the route against its local import VPN target:
l If the two targets match, PE2 accepts the VPNv4 route and stores the
Source AS Extended Community and VRF Route Import Extended
Community values carried in this route locally for later generation of the
BGP C-multicast route.
l If the two targets do not match, PE2 drops the VPNv4 route.
3 CE2 After CE2 receives an IGMP join request, CE2 sends a PIM-SSM Join
message to PE2.

Step Dev Key Action

ice
4 PE2 After PE2 receives the PIM-SSM Join message:

l PE2 generates a multicast entry. In this entry, the downstream interface
is the interface that receives the PIM-SSM Join message and the
upstream interface is the P2MP tunnel interface on the path to the
multicast source.
l PE2 generates a BGP C-multicast route based on the locally stored
Community values. The RT-import attribute of this route is set to the
locally stored VRF Route Import Extended Community value.
NOTE
In the BGP route with MVPN information, the NLRI field is called MVPN NLRI.
The routes whose Route type value is 6 or 7 are C-multicast routes. For more
information about C-multicast route structure, see MVPN NLRI.
5 PE2 PE2 sends the BGP C-multicast route to PE1.
6 PE1 After PE1 receives the BGP C-multicast route:

1. PE1 checks the Administrator field and Local Administrator field values
in the RT-import attribute of the BGP C-multicast route. After PE1
confirms that the Administrator field value is its MVPN ID, PE1 accepts
the BGP C-multicast route.
2. PE1 determines to which VPN instance routing table should the BGP C-
multicast route be added based on the Local Administrator field value in
the RT-import attribute of the route.
3. PE1 adds the BGP C-multicast route to the corresponding VPN instance
routing table and creates a VPN multicast entry to guide multicast traffic
forwarding. In the multicast entry, the downstream interface is PE1's
P2MP tunnel interface.
4. PE1 converts the BGP C-multicast route to a PIM-SSM Join message.
7 PE1 PE1 sends the PIM-SSM Join message to CE1.
8 CE1 After CE1 receives the PIM-SSM Join message, CE1 generates a multicast
entry. In this entry, the downstream interface is the interface that receives
the PIM-SSM Join message. After that, the multicast receiver successfully
joins the multicast group, and CE1 can send multicast traffic to CE2.

Figure 5-8 Time sequence for leaving a multicast group
G e n e r a te B G P W ith d r a w m e s s a g e 1 R e c e iv e r le a v e
T 2
im a fte r m u ltic a s t e n tr y a g e s m u ltic a s t g r o u p
e 3 G P W ith d r a w m e s s a g e
B
4 P r o c e s s B G P W ith d r a w m e s s a g e a n d
g e n e r a te P IM - S S M P r u n e m e s s a g e
P IM - S S M
5
P ru n e m e s s a g e
6 P r o c e s s P IM - S S M
P ru n e m e s s a g e
Figure 5-8 shows the procedure for leaving a multicast group, and Table 5-6 describes this
procedure.
Table 5-6 Procedure for leaving a multicast group

Step Dev Key Action
ice
1 CE2 CE2 detects that a multicast receiver attached to itself leaves the multicast
group.
2 PE2 PE2 deletes the corresponding multicast entry after this entry ages out.
Then, PE2 generates a BGP Withdraw message.
3 PE2 PE2 sends the BGP Withdraw message to PE1.
4 PE1 After PE1 receives the BGP Withdraw message, PE1 deletes the
corresponding multicast entry and generates a PIM-SSM Prune message.
5 PE1 PE1 sends the PIM-SSM Prune message to CE1.
6 CE1 After CE1 receives the PIM-SSM Prune message, CE1 stops sending
multicast traffic to CE2.
5.1.2.2.2 PIM (*, G) Join/Prune

Multicast receiver joins/leaves a multicast group in PIM (*, G) modes.
Table 5-7 lists the implementation modes of PIM (*, G) multicast joining and leaving.

Table 5-7 Implementation modes of PIM (*, G) multicast joining and leaving
Implementation Principle Advantage Disadvantage
Mode
Across the public PIM (*, G) entries The private l The RPT-to-
network are transmitted network SPT switching
across the public rendezvous point may occur on
network to remote (RP) can be the public
PEs. The multicast deployed at either network, so
joining process a CE or a PE. PEs need to
includes: maintain a lot
l Rendezvous of route state
point tree (RPT) information.
construction (see l Currently, a
Table 5-8 for private network
more RP must be a
information) static RP.
l Switching from
an RPT to a
shortest path
tree (SPT) (see
Table 5-9 for
more
information)
Not across the public PIM (*, G) entries l PIM (*, G) The private
network are converted to entries are not network RP can be
PIM (S, G) entries transmitted deployed on either
before being across the a PE or a CE. If a
transmitted to public network, CE serves as the
remote PEs across lowering the private network
the public network. performance RP, the CE must
requirements establish an MSDP
for PEs. peer relationship
l The private with the
network RP corresponding PE.
can be either a
static RP or a
dynamic RP.
PIM (*, G) multicast joining and leaving across the public network
On the network show in Figure 5-9, CE3 serves as the RP. Figure 5-10 shows the time
sequence for establishing an RPT.

Figure 5-9 Networking for PIM (*, G) multicast joining and leaving
Figure 5-10 Time sequence for establishing an RPT
Table 5-8 describes the procedure for establishing an RPT.
Table 5-8 Procedure for establishing an RPT

Step Dev Key Action
ice
1 CE2 After CE2 receives an IGMP join request, CE2 sends a PIM (*, G) Join
message to PE2.

Step Dev Key Action

ice
2 PE2 After PE2 receives the PIM (*, G) Join message: PE2 generates a PIM (*,
G) entry. In this entry, the downstream interface is the interface that
receives the PIM (*, G) Join message and the upstream interface is the
P2MP tunnel interface on the path to the RP. In this case, the upstream
interface is the interface used by PE3 to connect to PE2. PE2 generates a
BGP C-multicast route (Shared Tree Join route) based on the locally stored
Community values. The RT-import attribute of this route is set to the locally
stored VRF Route Import Extended Community value. PE2 sends the BGP
C-multicast route to PE3, its BGP peer.
NOTE
For more information about BGP C-multicast route generation, see MVPN NLRI.
3 PE3 After PE3 receives the BGP C-multicast route (Shared Tree Join route):
1. PE3 checks the Administrator field and Local Administrator field values
in the RT-import attribute of the BGP C-multicast route. After PE3
confirms that the Administrator field value is the same as its local
MVPN ID, PE3 accepts the BGP C-multicast route.
2. PE3 determines to which VPN instance routing table should the BGP C-
multicast route be added based on the Local Administrator field value in
the RT-import attribute of the route.
3. PE3 adds the BGP C-multicast route to the corresponding VPN instance
routing table and creates a VPN multicast entry to guide multicast traffic
forwarding. In the multicast entry, the downstream interface is PE3's
P2MP tunnel interface.
4. PE3 converts the BGP C-multicast route to a PIM (*, G) Join message
and sends this message to CE3.
4 CE3 Upon receipt of the PIM (*, G) Join message, CE3 generates a PIM (*, G)
entry. In this entry, the downstream interface is the interface that receives
the PIM (*, G) Join message. Then, an RPT rooted at CE3 and with CE2 as
the leaf node is established.
5 CE1 After CE1 receives multicast traffic from the multicast source, CE1 sends a
PIM Register message to CE3.
6 CE3 Upon receipt of the PIM Register message, CE3 generates a PIM (S, G)
entry, which inherits the outbound interface of the previously generated
PIM (*, G) entry. Meanwhile, CE3 sends multicast traffic to PE3.
7 PE3 Upon receipt of the multicast traffic, PE3 generates a PIM (S, G) entry,
which inherits the outbound interface of the previously generated PIM (*,
G) entry. Because the outbound interface of the PIM (*, G) entry is a P2MP
tunnel interface, multicast traffic is imported to the I-PMSI tunnel.
8 PE2 Upon receipt of the multicast traffic, PE2 generates a PIM (S, G) entry,
which inherits the outbound interface of the previously generated PIM (*,
G) entry.

Step Dev Key Action

ice
CE2 Upon receipt of the multicast traffic, CE2 sends the multicast traffic to
multicast receivers.
When the multicast traffic sent by the multicast source exceeds the threshold set on set, CE2
initiates RPT-to-SPT switching. Figure 5-11 shows the time sequence for switching an RPT
to an SPT.
NOTE
When the receiver PE receives multicast traffic transmitted along the RPT, the receiver PE immediately
initiates RPT-to-SPT switching. The RPT-to-SPT switching process on the receiver PE is similar to that
on CE2.
Figure 5-11 Time sequence for RPT-to-SPT switching
Table 5-9 describes the procedure for switching an RPT to an SPT.
Table 5-9 Procedure for RPT-to-SPT switching

Step Dev Key Action
ice
1 CE2 After the received multicast traffic exceeds the set threshold, CE2 initiates
RPT-to-SPT switching by sending a PIM (S, G) Join message to PE2.
2 PE2 Upon receipt of the PIM (S, G) Join message, PE2 updates the outbound
interface status in its PIM (S, G) entry, and switches the PIM (S, G) entry to
the SPT. Then, PE2 searches its multicast routing table for a route to the
multicast source. After PE2 finds that the upstream device on the path to
the multicast source is PE1, PE2 sends a BGP C-multicast route (Source
Tree Join route) to PE1.
3 PE1 Upon receipt of the BGP C-multicast route (Source Tree Join route), PE1
generates a PIM (S, G) entry, and sends a PIM (S, G) Join message to CE1.

Step Dev Key Action

ice
4 CE1 Upon receipt of the PIM (S, G) Join message, CE1 generates a PIM (S, G)
entry. Then, the RPT-to-SPT switching is complete and CE1 can send
multicast traffic to PE1.
5 PE1 To prevent duplicate multicast traffic, PE1 carries the PIM (S, G) entry
information in a Source Active AD route and sends the route to all its BGP
peers.
6 PE3 Upon receipt of the Source Active AD route, PE3 records the route. After
RPT-to-SPT switching, PE3, the ingress of the P2MP tunnel for the RPT,
deletes received multicast traffic, generates the (S, G, RPT) state, and sends
a PIM (S, G, RPT) Prune to its upstream. Meanwhile, PE3 updates its VPN
multicast routing entries and stops forwarding multicast traffic.
NOTE
To prevent packet loss during RPT-to-SPT switching, the PIM (S, G, RPT) Prune
operation is performed after a short delay.
7 PE2 Upon receipt of the Source Active AD route, PE2 records the route.
Because the Source Active AD route carries information about the PIM (S,
G) entry for the RPT, PE2 initiates RPT-to-SPT switching. After PE2 sends
a BGP C-multicast route (Source Tree Join route) to PE1, PE2 can receive
multicast traffic from PE1.
Figure 5-12 shows the time sequence for leaving a multicast group in PIM (*, G) mode.
Figure 5-12 Time sequence for leaving a multicast group in PIM (*, G) mode
Table 5-10 describes the procedure for leaving a multicast group in PIM (*, G) mode.

Table 5-10 Procedure for leaving a multicast group in PIM (*, G) mode
Step Dev Key Action
ice
1 CE2 After CE2 detects that a multicast receiver attached to itself leaves the
multicast group, CE2 sends a PIM (*, G) Prune message to PE2. If CE2 has
switched to the SPT, CE2 also sends a PIM (S, G) Prune message to PE2.
2 PE2 Upon receipt of the PIM (*, G) Prune message, PE2 deletes the
corresponding PIM (*, G) entry. Upon receipt of the PIM (S, G) Prune
message, PE2 deletes the corresponding PIM (S, G) entry.
3 PE2 PE2 sends a BGP Withdraw message (Shared Tree Join route) to PE3 and a
BGP Withdraw message (Source Tree Join route) to PE1.
4 PE1 Upon receipt of the BGP Withdraw message (Source Tree Join route), PE1
deletes the previously recorded BGP C-multicast route (Source Tree Join
route) as well as the outbound interface in the PIM (S, G) entry.
5 PE3 Upon receipt of the BGP Withdraw message (Shared Tree Join route), PE3
deletes the previously recorded BGP C-multicast route (Shared Tree Join
PIM (*, G) multicast joining and leaving not across the public network
On the network show in Figure 5-9, each site of the MVPN is a PIM-SM BSR domain. A PE
serves as the RP. Figure 5-13 shows the time sequence for joining a multicast group when a
PE serves as the RP.
Figure 5-13 Time sequence for joining a multicast group when a PE serves as the RP
Table 5-11 describes the procedure for joining a multicast group when a PE serves as the RP.

Table 5-11 Procedure for joining a multicast group when a PE serves as the RP
Ste Dev Key Action
p ice
1 CE2 After CE2 receives an IGMP join request, CE2 sends a PIM (*, G) Join
message to PE2.
2 PE2 Upon receipt of the PIM (*, G) Join message, PE2 generates a PIM (*, G)
entry. Because PE2 is the RP, PE2 does not send the BGP C-multicast route
(Shared Tree Join route) to other devices. Then, an RPT rooted at PE2 and
with CE2 as the leaf node is established.
3 CE1 After CE1 receives multicast traffic from the multicast server, CE1 sends a
PIM Register message to PE1.
4 PE1 Upon receipt of the PIM Register message, PE1 generates a PIM (S, G)
entry.
5 PE1 PE1 sends a Source Active AD route to all its BGP peers.
6 PE2 Upon receipt of the Source Active AD route, PE2 generates a PIM (S, G)
entry, which inherits the outbound interface of the previously generated PIM
(*, G) entry.
7 PE2 PE2 initiates RPT-to-SPT switching and sends a BGP C-multicast route
(Source Tree Join route) to PE1.
8 PE1 Upon receipt of the BGP C-multicast route (Source Tree Join route), PE1
imports multicast traffic to the I-PMSI tunnel based on the corresponding
VPN multicast forwarding entry. Then, multicast traffic is transmitted over
the I-PMSI tunnel to CE2.
Figure 5-14 shows the time sequence for leaving a multicast group when a PE serves as the
RP.
Figure 5-14 Time sequence for leaving a multicast group when a PE serves as the RP

Table 5-12 describes the procedure for leaving a multicast group when a PE serves as the RP.
Table 5-12 Procedure for leaving a multicast group when a PE serves as the RP
Step Dev Key Action

ice
multicast group, CE2 sends a PIM (*, G) Prune message to PE2.
2 PE2 Upon receipt of the PIM (*, G) Prune message, PE2 deletes the
corresponding PIM (*, G) entry.
3 CE2 CE2 sends a PIM (S, G) Prune message to PE2.
4 PE2 Upon receipt of the PIM (S, G) Prune message, PE2 deletes the
corresponding PIM (S, G) entry. PE2 sends a BGP Withdraw message
(Source Tree Join route) to PE1.
Meanwhile, PE1 sends a PIM (S, G) Prune message to CE1.
6 CE1 Upon receipt of the PIM (S, G) Prune message, CE1 stops sending
On the network show in Figure 5-9, each site of the MVPN is a PIM-SM BSR domain. A CE
serves as the RP. CE3 has established an MSDP peer relationship with PE3, and PE2 has
established an MSDP peer relationship with CE2. Figure 5-15 shows the time sequence for
joining a multicast group when a CE serves as the RP.
Figure 5-15 Time sequence for joining a multicast group when a CE serves as the RP
Table 5-13 describes the procedure for joining a multicast group when a CE serves as the RP.

Table 5-13 Procedure for joining a multicast group when a CE serves as the RP
Step Dev Key Action

ice
1 CE2 After CE2 receives an IGMP join request, CE2 generates a PIM (*, G) Join
message. Because CE2 is the RP, CE2 does not send the PIM (*, G) Join
message to its upstream.
2 CE1 After CE1 receives multicast traffic from the multicast server, CE1 sends a
PIM Register message to CE3.
3 CE3 Upon receipt of the PIM Register message, CE3 generates a PIM (S, G)
entry.
4 CE3 CE3 carries the PIM (S, G) entry information in an MSDP Source Active
(SA) message and sends the message to its MSDP peer, PE3.
5 PE3 Upon receipt of the MSDP SA message, PE3 generates a PIM (S, G) entry.
6 PE3 PE3 carries the PIM (S, G) entry information in a Source Active AD route
and sends the route to other PEs.
7 PE2 Upon receipt of the Source Active AD route, PE2 learns the PIM (S, G)
entry information carried in the route. Then, PE2 sends an MSDP SA
message to transmit the PIM (S, G) entry information to its MSDP peer,
CE2.
8 CE2 Upon receipt of the MSDP SA message, CE2 learns the PIM (S, G) entry
information carried in the message and generates a PIM (S, G) entry. Then,
CE2 initiates a PIM (S, G) join request to the multicast source. Finally, CE2
forwards the multicast traffic to multicast receivers.
Figure 5-16 shows the time sequence for leaving a multicast group when a CE serves as the
RP.
Figure 5-16 Time sequence for leaving a multicast group when a CE serves as the RP

Table 5-14 describes the procedure for leaving a multicast group when a CE serves as the RP.
Table 5-14 Procedure for leaving a multicast group when a CE serves as the RP
Step Dev Key Action
ice
multicast group, CE2 generates a PIM (*, G) Prune message. Because CE2
is the RP, CE2 does not send the PIM (*, G) Prune message to its upstream.
2 CE2 CE2 sends a PIM (S, G) Prune message to PE2.
3 PE2 Upon receipt of the PIM (S, G) Prune message, PE2 deletes the
corresponding PIM (S, G) entry. Then, PE2 sends a BGP Withdraw
message (Shared Tree Join route) to PE1.
Meanwhile, PE1 sends a PIM (S, G) Prune message to CE1.
5 CE1 Upon receipt of the PIM (S, G) Prune message, CE1 stops sending
5.1.2.3 NG MVPN Public Network Tunnel Principle
NG MVPN devices exchange routing information through BGP and establishes an MVPN
tunnel based on MPLS P2MP to carry multicast traffic.
The establishment of NG MVPN tunnels is affected by the network deployed on the public
network, including whether the public network contains multiple ASs and whether different
MPLS protocols are deployed in different areas. According to the two factors, NG MVPN
deployment scenarios can be classified into the following types:
l Intra-AS non-segmented NG MVPN: The public network contains only one AS, and
only one MPLS protocol is deployed.
l Intra-AS segmented NG MVPN: The public network contains only one AS but contains
multiple areas. Different MPLS protocols are deployed in adjacent areas.
l Inter-AS non-segmented NG MVPN: The public network contains multiple ASs, and
only one MPLS protocol is deployed in the ASs.
For details about the NG MVPN deployment scenarios, see NG MVPN Typical Deployment
Scenarios on the Public Network.
Tunnel establishment includes the following basic steps and slightly differs in different
scenarios:
1. MVPN membership autodiscovery
MVPN membership autodiscovery is a process that automatically discovers MVPN peers
and establishes MVPN peer relationships. A sender PE and a receiver PE on the same
MVPN can exchange control messages that carry MVPN NLRI to establish a PMSI

tunnel only after they establish an MVPN peer relationship. In NE40E, PEs use BGP as
the signaling protocol to exchange control messages.
2. I-PMSI tunnel establishment
PMSI tunnels are logical tunnels used by a public network to transmit VPN multicast
traffic.
3. Switching between I-PMSI and S-PMSI tunnels
After switching between I-PMSI and S-PMSI tunnels is configured, if the multicast data
forwarding rate exceeds the switching threshold, multicast data is switched from the I-
PMSI tunnel to an S-PMSI tunnel. Unlike the I-PMSI tunnel that sends multicast data to
all PEs on an NG MVPN, an S-PMSI tunnel sends multicast data only to PEs interested
in the data, reducing bandwidth consumption and PEs' burdens.
4. Transmitting multicast traffic on an NG MVPN
After a public network PMSI tunnel is created, multicast users can join the multicast
group and apply for multicast services from the multicast source. The multicast source
can send multicast traffic to multicast users through the PMSI tunnel.
The concepts and protocols related to the multicast traffic carried by the public network
tunnel are as follows:
l PMSI Tunnel
l MVPN Targets
PMSI Tunnel
Public tunnels (P-tunnels) are transport mechanisms used to forward VPN multicast traffic
across service provider networks. In NE40E, PMSI tunnels can be carried over RSVP-TE
P2MP or mLDP P2MP tunnels. Table 5-15 lists the differences between RSVP-TE P2MP
tunnels and mLDP P2MP tunnels.
Table 5-15 Differences between RSVP-TE P2MP tunnels and mLDP P2MP tunnels
Tunnel Type Tunnel Establishment Characteristic
Method
RSVP-TE P2MP tunnel Established from the root RSVP-TE P2MP tunnels
node. support bandwidth
reservation and can ensure
service quality during
network congestion. Use
RSVP-TE P2MP tunnels to
carry PMSI tunnels if high
service quality is required.

Tunnel Type Tunnel Establishment Characteristic

Method
mLDP P2MP tunnel Established from a leaf mLDP P2MP tunnels do not
node. support bandwidth
reservation and cannot
ensure service quality
during network congestion.
Configuring an mLDP
P2MP tunnel, however, is
easier than configuring an
RSVP-TE P2MP tunnel.
Use mLDP P2MP tunnels to
carry PMSI tunnels if high
service quality is not
required.
Theoretically, a P-tunnel can carry the traffic of one or multiple MVPNs. However, in NE40E,
a P-tunnel can carry the traffic of only one MVPN.
On an MVPN that uses BGP as the signaling protocol, a sender PE distributes information
about the P-tunnel in a new BGP attribute called PMSI. PMSI tunnels are the logical tunnels
used by the public network to transmit VPN multicast data, and P-tunnels are the actual
tunnels used by the public network to transmit VPN multicast data. A sender PE uses PMSI
tunnels to send specific VPN multicast data to receiver PEs. A receiver PE uses PMSI tunnel
information to determine which multicast data is sent by the multicast source on the same
MVPN as itself. There are two types of PMSI tunnels: I-PMSI tunnels and S-PMSI
tunnels.Table 5-16 lists the differences between I-PMSI and S-PMSI tunnels.
Table 5-16 I-PMSI and S-PMSI
PMSI Tunnel Type Description Characteristic
I-PMSI tunnel An I-PMSI tunnel connects Multicast data sent over an

to all PEs on an MVPN. I-PMSI tunnel can be
received by all PEs on the
MVPN. In a VPN instance,
one PE corresponds to only
one I-PMSI tunnel.
S-PMSI tunnel An S-PMSI tunnel connects Multicast data sent over an

to the sender and receiver S-PMSI tunnel is received
PEs of specific sources and by only PEs interested in the
multicast groups. data. In a VPN instance, one
PE can correspond to
multiple S-PMSI tunnels.
A public network tunnel can consist of one PMSI logical tunnel or multiple interconnected
PMSI tunnels. The former is a non-segmented tunnel, and the latter forms a segmented tunnel.

l For a non-segment tunnel, the public network between the sender PE and receiver PE
uses the same MPLS protocol. Therefore, an MPLS P2MP tunnel can be used to set up a
PSMI logical tunnel to carry multicast traffic.
l For a segmented tunnel, different areas on the public network between the sender PE and
receiver PE use different MPLS protocols. Therefore, PMSI tunnels need to be
established in each area based on the MPLS protocol type and MPLS P2MP tunnel type.
In addition, tunnel stitching must be configured on area connection nodes to stitch PMSI
tunnels in different areas into one tunnel to carry the data traffic of the MVPN. Currently,
the NE40E supports intra-AS segmented tunnels, not inter-AS segmented tunnels.
MVPN Targets
MVPN targets are used to control MVPN A-D route advertisement. MVPN targets function in
a similar way as VPN targets used on unicast VPNs and are also classified into two types:
l Export MVPN target: A PE adds the export MVPN target to an MVPN instance before
advertising this route.
l Import MVPN target: After receiving an MVPN A-D route from another PE, a PE
matches the export MVPN target of the route against the import MVPN targets of its
VPN instances. If the export MVPN target matches the import MVPN target of a VPN
instance, the PE accepts the MVPN A-D route and records the sender PE as an MVPN
member. If the export MVPN target does not match the import MVPN target of any VPN
instance, the PE drops the MVPN A-D route.
NOTE
By default, if you do not configure MVPN targets for an MVPN, MVPN A-D routes carry the VPN
target communities that are attached to unicast VPN-IPv4 routes. If the unicast and multicast network
topologies are congruent, you do not need to configure MVPN targets for MVPN A-D routes. If they are
not congruent, configure MVPN targets for MVPN A-D routes.
5.1.2.3.1 MVPN Membership Autodiscovery
To exchange control messages and establish PMSI tunnels, a PE on an MVPN must be

capable of discovering other PEs on the MVPN. The discovery process is called MVPN
membership autodiscovery. An NG MVPN uses BGP to implement this process. To support
MVPN membership autodiscovery, BGP defines a new address family, the BGP-MVPN
address family.
On the network shown in Figure 5-17, BGP and MVPN are configured on PE1, PE2, and PE3
in a way that PE1 can negotiate with PE2 and PE3 to establish BGP MVPN peer
relationships. A PE newly added to the service provider's backbone network can join the
MVPN so long as this PE can establish BGP MVPN peer relationships with existing PEs on
the MVPN.

Receiver
Receiver
site
vpn1 CE5 vpn2

Source CE1
Service provider's Receiver

Sender Site backbone
vpn1
PE1 P PE2 CE2
Receiver
site
vpn2
Source CE4 PE3
Receiver
Sender site
Receiver
site
CE3
vpn1 Receiver
MP-IBGP peer session
To transmit multicast traffic from multicast sources to multicast receivers, sender PEs must
establish BGP MVPN peer relationships with receiver PEs. On the network shown in Figure
5-17, PE1 serves as a sender PE, and PE2 and PE3 serve as receiver PEs. Therefore, PE1
establishes BGP MVPN peer relationships with PE2 and PE3.
PEs on an NG MVPN use BGP Update messages to exchange MVPN information. MVPN
information is carried in the network layer reachability information (NLRI) field of a BGP
Update message. The NLRI containing MVPN information is also called the MVPN NLRI.
For more information about the MVPN NLRI, see MVPN NLRI.
5.1.2.3.2 I-PMSI Tunnel Establishment
When establishing an I-PMSI tunnel, you must specify the P-tunnel type. The process of
establishing an I-PMSI tunnel varies according to the P-tunnel type. In NE40E, PEs can use
only the following types of P-tunnels to carry I-PMSI tunnels:
l RSVP-TE P2MP tunnels: A sender PE sends an intra-AS PMSI A-D route to each
receiver PE. Upon receipt, each receiver PE sends a reply message. Then, the sender PE
collects P2MP tunnel leaf information from received reply messages and establishes an
RSVP-TE P2MP tunnel for each MVPN based on the leaf information of the MVPN. For
more information about RSVP-TE P2MP tunnel establishment, see "P2MP TE" in
NE40E Feature Description - MPLS.
l mLDP P2MP tunnels: Receiver PEs directly send Label Mapping messages based on the
root node address (sender PE address) and opaque value information carried in the Intra-
AS PMSI A-D route sent by the sender PE to establish an mLDP P2MP tunnel. For more
information about mLDP P2MP tunnel establishment, see "mLDP" in NE40E Feature
Description - MPLS.

NOTE
For comparison between RSVP-TE and mLDP P2MP tunnels, see Table 5-15 in 5.1.2.3 NG MVPN
Public Network Tunnel Principle.
The following example uses the network shown in Figure 5-18 to describe how to establish
PMSI tunnels. Because RSVP-TE P2MP tunnels and mLDP P2MP tunnels are established
differently, the following uses two scenarios, RSVP-TE P2MP Tunnel and mLDP P2MP
Tunnel, to describe how to establish PMSI tunnels.
This example presumes that:
l PE1 has established BGP MVPN peer relationships with PE2 and PE3, but no BGP
MVPN peer relationship is established between PE2 and PE3.
l The network administrator has configured MVPN on PE1, PE2, and PE3 in turn.

S e r v ic e
R e c e iv e r
p r o v id e r 's
vpn1 PE1 backbone vpn1
S o u rc e CE1 PE2 CE2
R e c e iv e r
Sender s ite
s ite
PE3
R e c e iv e r
P 2 M P tu n n e l
R e c e iv e r
CE3 P IM J o in m e s s a g e
s ite
vpn1
M P - IB G P p e e r s e s s io n
R e c e iv e r
RSVP-TE P2MP Tunnel

Figure 5-19 shows the time sequence for establishing an I-PMSI tunnel with the P-tunnel
type as RSVP-TE P2MP LSP.

Figure 5-19 Time sequence for establishing an I-PMSI tunnel with the P-tunnel type as
RSVP-TE P2MP LSP
Table 5-17 briefs the procedure for establishing an I-PMSI tunnel with the P-tunnel type as
RSVP-TE P2MP LSP.

Table 5-17 Procedure for establishing an I-PMSI tunnel with the P-tunnel type as RSVP-TE
P2MP LSP
Ste De Prerequisites Key Action
p vice
1 PE1 BGP and MVPN have As a sender PE, PE1 initiates the I-PMSI tunnel
been configured on establishment process. The MPLS module on PE1
PE1. reserves resources for the corresponding RSVP-
PE1 has been TE P2MP tunnel. Because PE1 does not know
configured as a sender RSVP-TE P2MP tunnel leaf information, the
PE. RSVP-TE P2MP tunnel is not established in a real
sense.
The P-tunnel type for I-
PMSI tunnel
establishment has been
specified as RSVP-TE
P2MP LSP.
2 PE1 BGP and MVPN have PE1 sends a Type 1 BGP A-D route to PE2. This
been configured on route carries the following information:
PE2. l MVPN Targets: used to control A-D route
PE1 has established a advertisement. The Type 1 BGP A-D route
BGP MVPN peer carries the export MVPN target information
relationship with PE2. configured on PE1.
l PMSI Tunnel Attribute: specifies the P-
tunnel type (RSVP-TE P2MP LSP in this case)
used for PMSI tunnel establishment. This
attribute carries information about resources
reserved for the RSVP-TE P2MP tunnel in
Step 1 .
3 PE2 - 1. PE2 sends a BGP A-D route that carries the

export MVPN target to PE1. Because PE2 is
not a sender PE configured with PMSI tunnel
information, the BGP A-D route sent by PE2
does not carry the PMSI Tunnel attribute.
2. After PE2 receives the BGP A-D route from
PE1, PE2 matches the export MVPN target of
the route against its local import MVPN target.
If the two targets match, PE2 accepts this
route, records PE1 as an MVPN member, and
joins the P2MP tunnel that is specified in the
PMSI Tunnel attribute carried in this route (at
the moment, the P2MP tunnel has not been
established yet).

Ste De Prerequisites Key Action

p vice
4 PE1 - After PE1 receives the BGP A-D route from PE2,
PE1 matches the export MVPN target of the route
against its local import MVPN target. If the two
targets match, PE1 accepts this route, records PE2
as an MVPN member, and instructs the MPLS
module to send an MPLS message to PE2 and add
PE2 as a leaf node of the RSVP-TE P2MP tunnel
to be established.
5 PE1 - After PE1 receives a reply from PE2, the MPLS

module on PE1 completes the process of
establishing an RSVP-TE P2MP tunnel with PE1
as the root node and PE2 as a leaf node. For more
information about RSVP-TE P2MP tunnel
establishment, see "P2MP TE" in NE40E Feature
Description - MPLS.
6 PE2 - After PE2 receives the MPLS message from PE1,

PE2 joins the established RSVP-TE P2MP tunnel.
PE3 joins the RSVP-TE P2MP tunnel rooted at PE1 in a similar way as PE2. After PE2 and
PE3 both join the RSVP-TE P2MP tunnel rooted at PE1, the I-PMSI tunnel is established and
the MVPN service becomes available.
mLDP P2MP Tunnel

Figure 5-20 shows the time sequence for establishing an I-PMSI tunnel with the P-tunnel
type as mLDP LSP.

Figure 5-20 Time sequence for establishing an I-PMSI tunnel with the P-tunnel type as
mLDP P2MP LSP
Service provider PE1 PE2 PE3
Configure BGP
and MVPN
Create
1
Configure BGP tunnel
and MVPN
2 BGP A-D route with PMSI

Tunnel attribute
3 Receive BGP A-D route
and add leaf node
4 Join tunnel
Time
5 BGP A-D route without

Configure BGP PMSI Tunnel attribute
and MVPN
BGP A-D route with PMSI

Tunnel attribute
Receive BGP A-D route
and add leaf node
BGP A-D route without
PMSI Tunnel attribute
Join tunnel
Table 5-18 briefs the procedure for establishing an I-PMSI tunnel with the P-tunnel type as
mLDP P2MP LSP.
Table 5-18 Procedure for establishing an I-PMSI tunnel with the P-tunnel type as mLDP
P2MP LSP
Step Dev Prerequisites Key Action
ice
1 PE1 BGP and MVPN have As a sender PE, PE1 initiates the I-PMSI tunnel
been configured on establishment process. The MPLS module on
PE1. PE1 reserves resources (FEC information such as
PE1 has been the opaque value and root node address) for the
configured as a sender corresponding mLDP P2MP tunnel. Because PE1
PE. does not know leaf information of the mLDP
P2MP tunnel, the mLDP P2MP tunnel is not
The P-tunnel type for established in a real sense.
I-PMSI tunnel
establishment has been
specified as mLDP
P2MP LSP.

Step Dev Prerequisites Key Action

ice
2 PE1 BGP and MVPN have PE1 sends a Type 1 BGP A-D route to PE2. This
been configured on route carries the following information:
PE2. l MVPN Targets: used to control A-D route
PE1 has established a advertisement. The Type 1 BGP A-D route
BGP MVPN peer carries the export MVPN target configured on
relationship with PE2. PE1.
l PMSI Tunnel Attribute: specifies the P-
tunnel type (mLDP P2MP in this case) used
for PMSI tunnel establishment. This attribute
carries information about resources reserved
by MPLS for the mLDP P2MP tunnel in Step
1 .
3 PE2 - After PE2 receives the BGP A-D route from PE1,
the MPLS module on PE2 sends a Label
Mapping message to PE1. This is because the
PMSI Tunnel attribute carried in the received
route specifies the P-tunnel type as mLDP,
meaning that the P2MP tunnel must be
established from leaves.
After PE2 receives the MPLS message replied by
PE1, PE2 becomes aware that the P2MP tunnel
has been established. For more information about
mLDP P2MP tunnel establishment, see "mLDP"
in NE40E Feature Description - MPLS.
4 PE2 - PE2 creates an mLDP P2MP tunnel rooted at

PE1.
5 PE2 - PE2 sends a BGP A-D route that carries the

export MVPN target to PE1. Because PE2 is not
a sender PE configured with PMSI tunnel
information, the BGP A-D route sent by PE2
does not carry the PMSI Tunnel attribute.
After PE1 receives the BGP A-D route from PE2,
PE1 matches the export MVPN target of the route
against its local import MVPN target. If the two
targets match, PE1 accepts this route and records
PE2 as an MVPN member.
PE3 joins the mLDP P2MP tunnel and MVPN in a similar way as PE2. After PE2 and PE3
both join the mLDP P2MP tunnel rooted at PE1, the I-PMSI tunnel is established and the
MVPN service becomes available.
5.1.2.3.3 Switching Between I-PMSI and S-PMSI Tunnels

Background
An NG MVPN uses the I-PMSI tunnel to send multicast data to receivers. The I-PMSI tunnel
connects to all PEs on the MVPN and sends multicast data to these PEs regardless of whether
these PEs have receivers. If some PEs do not have receivers, this implementation will cause
redundant traffic, wasting bandwidth resources and increasing PEs' burdens.
To solve this problem, S-PMSI tunnels are introduced. An S-PMSI tunnel connects to the
sender and receiver PEs of specific multicast sources and groups on an NG MVPN.
Compared with the I-PMSI tunnel, an S-PMSI tunnel sends multicast data only to PEs
interested in the data, reducing bandwidth consumption and PEs' burdens.
NOTE
For comparison between I-PMSI and S-PMSI tunnels, see 5.1.2.3 NG MVPN Public Network Tunnel
Principle in Table 5-16.
Implementation
The following example uses the network shown in Figure 5-21 to describe switching between
I-PMSI and S-PMSI tunnels on an NG MVPN.
Figure 5-21 Typical NG MVPN networking

Table 5-19 Switching between I-PMSI and S-PMSI tunnels

Item Occurring Condition Description
Switching from the I- The multicast data S-PMSI tunnels are

PMSI tunnel to an S- forwarding rate is classified as RSVP-TE S-
PMSI tunnel consistently above the PMSI tunnels or mLDP S-
specified switching PMSI tunnels, depending on
threshold. the bearer tunnel type. For
details about switching from
the I-PMSI tunnel to an S-
PMSI tunnel, see:
l Switching from the I-
PMSI Tunnel to an
RSVP-TE S-PMSI
Tunnel
l Switching from the I-
PMSI Tunnel to an
mLDP S-PMSI Tunnel
Switching from an S- The multicast data -

PMSI tunnel to the I- forwarding rate is
PMSI tunnel consistently below the
specified switching
threshold.
NOTE
l After multicast data is switched from the I-PMSI tunnel to an S-PMSI tunnel, if the S-PMSI tunnel
fails but the I-PMSI tunnel is still available, multicast data will be switched back to the I-PMSI
tunnel.
l After multicast data is switched from the I-PMSI tunnel to an S-PMSI tunnel, if the multicast data
forwarding rate is consistently below the specified switching threshold but the I-PMSI tunnel is
unavailable, multicast data still travels along the S-PMSI tunnel.
Switching from the I-PMSI Tunnel to an S-PMSI Tunnel

l Switching from the I-PMSI Tunnel to an RSVP-TE S-PMSI Tunnel
Figure 5-22 shows the time sequence for switching from the I-PMSI tunnel to an RSVP-
TE S-PMSI tunnel. Table 5-20 describes the specific switching procedure.

Figure 5-22 Time sequence for switching from the I-PMSI tunnel to an RSVP-TE S-
PMSI tunnel
PE1 PE2 PE3
Multicast data
Traffic rate exceeds the

threshold
1 BGP S-PMSI A-D route
2 BGP Leaf A-D route
3 Record the BGP

Receive the BGP Leaf A-D
S-PMSI A-D route
route and create a P2MP
4 tunnel
Time
5 Join the tunnel
BGP Leaf A-D route
Receive the BGP Leaf A-D route

Add a leaf node
Join the
tunnel
Table 5-20 Procedure for switching from the I-PMSI tunnel to an RSVP-TE S-PMSI
tunnel
Step Devic Key Action
e
1 PE1 After PE1 detects that the multicast data forwarding rate exceeds
the specified switching threshold, PE1 initiates switching from the
I-PMSI tunnel to an S-PMSI tunnel by sending a BGP S-PMSI A-
D route to its BGP peers. In the BGP S-PMSI A-D route, the Leaf
Information Require flag is set to 1, indicating that a PE that
receives this route needs to send a BGP Leaf A-D route in
response if the PE wants to join the S-PMSI tunnel to be
established.
2 PE2 Upon receipt of the BGP S-PMSI A-D route, PE2, which has
downstream receivers, sends a BGP Leaf A-D route to PE1.
3 PE3 Upon receipt of the BGP S-PMSI A-D route, PE3, which does not
have downstream receivers, does not send a BGP Leaf A-D route
to PE1 but records the BGP S-PMSI A-D route information.
4 PE1 Upon receipt of the BGP Leaf A-D route from PE2, PE1
establishes an S-PMSI tunnel with itself as the root node and PE2
as a leaf node.


e
5 PE2 After PE2 detects that the RSVP-TE S-PMSI tunnel has been
established, PE2 joins this tunnel.
After PE3 has downstream receivers, PE3 will send a BGP Leaf A-D route to PE1. Upon
receipt of the route, PE1 adds PE3 as a leaf node of the RSVE-TE S-PMSI tunnel. After
PE3 joins the tunnel, PE3's downstream receivers will also be able to receive multicast
data.
l Switching from the I-PMSI Tunnel to an mLDP S-PMSI Tunnel
Figure 5-23 shows the time sequence for switching from the I-PMSI tunnel to an mLDP
S-PMSI tunnel. Table 5-21 describes the specific switching procedure.
Figure 5-23 Time sequence for switching from the I-PMSI tunnel to an mLDP S-PMSI
tunnel
PE1 PE2 PE3
Multicast data
Traffic rate exceeds the

threshold
1 BGP S-PMSI A-D route
2 Create a P2MP tunnel

Time
Join the tunnel

3 Not join the tunnel
Create a P2MP tunnel
Join the
tunnel
Table 5-21 Procedure for switching from the I-PMSI tunnel to an mLDP S-PMSI tunnel
e
1 PE1 After PE1 detects that the multicast data forwarding rate exceeds
the specified switching threshold, PE1 initiates switching from
the I-PMSI tunnel to an S-PMSI tunnel by sending a BGP S-
PMSI A-D route to its BGP peers. In the BGP S-PMSI A-D
route, the Leaf Information Require flag is set to 0.


e
2 PE2 Upon receipt of the BGP S-PMSI A-D route, PE2, which has
downstream receivers, directly joins the mLDP S-PMSI tunnel
specified in the BGP S-PMSI A-D route.
3 PE3 Upon receipt of the BGP S-PMSI A-D route, PE3, which does not
have downstream receivers, does not join the mLDP S-PMSI
tunnel specified in the BGP S-PMSI A-D route, but records the
BGP S-PMSI A-D route information.
After PE3 has downstream receivers, PE3 will also directly join the mLDP S-PMSI
tunnel. Then, PE3's downstream receivers will also be able to receive multicast data.
NOTE
PE1 starts a switch-delay timer upon the completion of S-PMSI tunnel establishment and determines
whether to switch multicast data to the S-PMSI tunnel as follows: If the S-PMSI tunnel fails to be
established, PE1 still uses the I-PMSI tunnel to send multicast data. If the multicast data forwarding rate
is consistently below the specified switching threshold throughout the timer lifecycle, PE1 still uses the
I-PMSI tunnel to transmit multicast data. If the multicast data forwarding rate is consistently above the
specified switching threshold throughout the timer lifecycle, PE1 switches data to the S-PMSI tunnel for
transmission.
Switching from an S-PMSI Tunnel to the I-PMSI Tunnel

Figure 5-24 shows the time sequence for switching from an S-PMSI tunnel to the I-PMSI
tunnel. Table 5-22 describes the specific switching procedure.
Figure 5-24 Time sequence for switching from an S-PMSI tunnel to the I-PMSI tunnel
PE1 PE2
Multicast data
Traffic rate is below the

threshold
Send the BGP Withdraw
1 S-PMSI A-D route
Time
Send the BGP Withdraw

2 Leaf A-D route
3 Leave the S-PMSI

tunnel
4 Delete the
S-PMSI tunnel

Table 5-22 Procedure for switching from an S-PMSI tunnel to the I-PMSI tunnel
Step Device Key Action
1 PE1 After PE1 detects that the multicast data forwarding rate is
consistently below the specified switching threshold, PE1 starts a
switchback hold timer:
l If the multicast data forwarding rate is consistently above the
specified switching threshold throughout the timer lifecycle, PE1
still uses the S-PMSI tunnel to send traffic.
l If the multicast data forwarding rate is consistently below the
specified switching threshold throughout the timer lifecycle, PE1
switches multicast data to the I-PMSI tunnel for transmission.
Meanwhile, PE1 sends a BGP Withdraw S-PMSI A-D route to
PE2, instructing PE2 to withdraw bindings between multicast
entries and the S-PMSI tunnel.
2 PE2 Upon receipt of the BGP Withdraw S-PMSI A-D route, PE2
withdraws the bindings between its multicast entries and the S-
PMSI tunnel. If PE2 has sent a BGP Leaf A-D route to PE1, PE2
will send a BGP Withdraw Leaf A-D route to PE1 in this step.
3 PE2 After PE2 detects that none of its multicast entries is bound to the S-
PMSI tunnel, PE2 leaves the S-PMSI tunnel.
4 PE1 PE1 deletes the S-PMSI tunnel after waiting for a specified period
of time.
NOTE
In an RSVP-TE P2MP tunnel dual-root 1+1 protection scenario, S-PMSI tunnels must be carried over
RSVP-TE P2MP tunnels. The I-PMSI/S-PMSI switching processes in this scenario are similar to those
described above except that the leaf PEs need to start a tunnel status check delay timer:
l Before the timer expires, leaf PEs delete tunnel protection groups to skip the status check of the
primary I-PMSI or S-PMSI tunnel. The leaf PEs select the multicast data received from the
primary tunnel and discard the multicast data received from the backup tunnel.
l After the timer expires, leaf PEs start to check the primary I-PMSI or S-PMSI tunnel status again.
Leaf PEs select the multicast data received from the primary tunnel only if the primary tunnel is
Up. If the primary tunnel is Down, Leaf PEs select the multicast data received from the backup
tunnel.
5.1.2.3.4 Transmitting multicast traffic on an NG MVPN
After a multicast receiver joins a multicast group, the multicast source can send multicast
traffic to the multicast receiver over a BGP/MPLS IP VPN if the corresponding P-tunnel has
been established. Figure 5-25 shows a typical NG MVPN networking scenario, and Figure
5-26 shows how an IP multicast packet is encapsulated and transmitted on the network shown
in Figure 5-25.

vpn1
PE2 CE2 Receiver

Service provider's
vpn1 port1 port1
backbone
Source port2
CE1 PE1 P
port1 port2
port1
vpn1
port1 port1
(192.168.1.2, 232.1.1.1) port2
PE3 CE3 Receiver
RSVP-TE or mLDP P2MP tunnel
Figure 5-26 IP multicast packet transmission on an NG MVPN

data
PE2 CE2 Receiver
L21
Source CE1 PE1 P data data
data data data

L10
data
L31 data data
PE3 CE3 Receiver
data IP data packet
MPLS label
RSVP-TE P2MP tunnel

or mLDP P2MP tunnel
Table 5-23 describes how an IP multicast packet is transmitted on an NG MVPN.
Table 5-23 IP multicast packet transmission on an NG MVPN

Step Devi Action Multicast Forwarding Table
ce Information
1 CE1 After CE1 receives an IP

Multicast forwarding-table
multicast packet from the
multicast source, CE1 (S, G): (192.168.1.2, 232.1.1.1)
searches its multicast
Upstream interface: port 1
forwarding table to forward
the packet to PE1. Downstream interface: port 2

Step Devi Action Multicast Forwarding Table

ce Information
2 PE1 After PE1 receives the IP

Multicast forwarding-table of vpn1
multicast packet, PE1
searches its VPN instance VPN instance name: vpn1
multicast forwarding table
for the corresponding (C-S, (C-S, C-G): (192.168.1.2, 232.1.1.1)
C-G) entry, adds an MPLS Upstream interface: port 1
label to the packet, and
Downstream interface:
sends the packet over a
pseudo
P2MP tunnel to the P.
Protocol: BGP
3 P After the P receives the -

MPLS packet, the P
duplicates the packet after
removing the MPLS label
of the packet. Then, the P
adds a new MPLS label to
each copy and sends one
copy to PE2 and one copy
to PE3.
4 PE2/ After PE2 and PE3 receive

Multicast forwarding-table of vpn1
PE3 the MPLS packet, PE2 and
PE3 remove the MPLS VPN instance name: vpn1
label, search their VPN
instance multicast (C-S, C-G): (192.168.1.2, 232.1.1.1)
forwarding tables for the Upstream interface: pseudo
corresponding (C-S, C-G)
entries, and forward the IP Downstream interface: port 1
multicast packet to CE2 and
CE3 respectively.
5 CE2/ After CE2 and CE3 receive

Multicast forwarding-table
CE3 the IP multicast packet,
CE2 and CE3 search their (S, G): (192.168.1.2, 232.1.1.1)
multicast forwarding tables
Upstream interface: port 2
to forward the IP multicast
packet to all receivers in the Downstream interface: port 1
multicast group.
5.1.2.3.5 NG MVPN Typical Deployment Scenarios on the Public Network
An NG MVPN uses a PMSI tunnel established on the public network BGP/MPLS VPN
network to transmit multicast traffic. The NG MVPN deployment mode varies according to
the public network architecture. According to whether the public network crosses ASs and
whether the tunnel is segmented, there are the following scenarios:
l Intra-AS non-segmented NG MVPN: The public network contains only one AS, and
only one MPLS protocol is deployed.

l Inter-AS non-segmented NG MVPN: The public network contains multiple ASs, and
only one MPLS protocol is deployed in the ASs.
l Intra-AS segmented NG MVPN: The public network contains only one AS but multiple
areas, and different MPLS protocols are deployed in adjacent areas.
Intra-AS Non-segmented NG MVPN

The public network that the multicast service traverses contains only one AS, and only one
MPLS protocol is used between PE1 on the multicast source side and PE2 on the multicast
user side, as shown in Figure 5-27.
Figure 5-27 Intra-AS non-segmented NG MVPN
S e r v ic e
P r o v id e r 's R e c e iv e r
VPNA B ackbone VPNA
S o u rc e CE1 PE1 PE2 CE2
R e c e iv e r
s ite
S e n d e r s ite P2M P Tunnel
AS1 R e c e iv e r
P IM J o in p a c k e t
M P - IB G P P e e r M u ltic a s t tr a ffic
The NG MVPN is established as follows:

l Establish an I-BGP peer relationship between PEs.
l Deploy MVPN on the PEs, so that the PEs in the same MVPN can automatically
discover each other and use BGP to transmit BGP C-multicast routes.
l Configure a P2MP tunnel and use BGP to transmit BGP A-D routes to each other, so that
PE1 and PE2 can establish a PMSI tunnel based on the P2MP tunnel to transmit
multicast traffic.
Inter-AS Non-segmented NG MVPN

The public network that the multicast service traverses contains multiple ASs, and only one
MPLS protocol is used between PE1 on the multicast source side and PE2 on the multicast
user side, as shown in Figure 5-28.
Figure 5-28 Inter-AS non-segmented NG MVPN

S e r v ic e P r o v id e r 's R e c e iv e r
VPNA
N e tw o r k VPNA
S o u rc e CE1 P2M P Tunnel CE2
R e c e iv e r
Sender s ite
AS1 AS2
s ite PE1 ASBR1ASBR2 PE2
M u ltic a s t R e c e iv e r
tr a ffic
This scenario supports three VPN modes: Option A, Option B, and Option C. In Option A
mode, ASBRs use each other as CEs. The establishment process is similar to that in the intra-
AS non-segment scenario.
In Option B mode, the NG MVPN is established as follows:
l Establish an IBGP peer relationship between a PE and an ASBR in the same AS.
Establish an EBGP peer relationship between ASBRs in different ASs.

discover each other and use BGP to transmit BGP C-multicast routes through ASBRs.
l Configure a P2MP tunnel and use BGP to transmit BGP A-D routes to each other
through ASBRs, so that PE1 and PE2 can establish a PMSI tunnel based on the P2MP
tunnel to transmit multicast traffic.
In Option C mode, the NG MVPN is established as follows:

l Establish an IBGP peer relationship between a PE and an ASBR in the same AS.
Establish an EBGP peer relationship between ASBRs in different ASs. Establish an MP-
EBGP peer relationship between PE1 and PE2.
discover each other and use BGP to directly transmit BGP C-multicast routes over
ASBRs.
l Configure a P2MP tunnel and use BGP to directly transmit BGP A-D routes to each
other over ASBRs, so that PE1 and PE2 can establish a PMSI tunnel based on the P2MP
tunnel to transmit multicast traffic.
Intra-AS Segmented NG MVPN

The public network that the multicast service traverses contains only one AS, and MPLS
areas of different types are used between PE1 on the multicast source side and PE2 on the
multicast user side, as shown in Figure 5-29.
Figure 5-29 Intra-AS segmented NG MVPN
S e r v ic e R e c e iv e r
P r o v id e r 's B a c k b o n e
VPNA VPNA
S o u rc e CE1 PE PE2 CE2
1 A re a 1 A re a 2
R e c e iv e r
s ite
S e n d e r s ite P2M P Tunnel P2M P Tunnel
AS1 R e c e iv e r
M P - IB G P p e e r M u ltic a s t tr a ffic
The NG MVPN is established as follows:

l Establish an I-BGP peer relationship between the PE and ABR.
discover each other and use BGP to transmit BGP C-multicast routes.
l Configure a P2MP tunnel and use BGP to transmit BGP A-D routes to each other so that
PE1 and the ABR can establish a PMSI tunnel based on the P2MP tunnel. The ABR and
PE2 establish a PMSI tunnel based on the P2MP tunnel. The two tunnels are stitched on
the ABR to carry the multicast traffic transmitted from PE1 to PE2.
5.1.2.4 NG MVPN Extranet
Background
NG MVPN supports inter-VPN multicast service distribution. To enable a service provider on
a VPN to provide multicast services for users on other VPNs, configure NG MVPN extranet.

Implementation
Table 5-24 describes the usage scenarios of NG MVPN extranet.
Table 5-24 Usage scenarios of NG MVPN extranet

Usage Scenario Description
Remote cross A multicast receiver and multicast source are

connected to different PEs and belong to different VPN
instances.
Local cross A multicast receiver and multicast source are

connected to the same PE and belong to different VPN
instances.
NOTE
l The address range of multicast groups using the NG MVPN extranet service cannot overlap that of
multicast groups using the intra-VPN service.
l Only a static RP can be used in an NG MVPN extranet scenario, the same static RP address must be
configured on the source and receiver VPN sides, and the static RP address must belong to the
source VPN. If different RP addresses are configured, inconsistent multicast routing entries will be
created on the two instances, causing service forwarding failures.
l To provide an SSM service using NG MVPN extranet, the same SSM group address must be
configured on the source and receiver VPN sides.
Remote Cross
On the network shown in Figure 5-30, VPN GREEN is configured on PE1. CE1 connects to
the multicast source in VPN GREEN. VPN BLUE is configured on PE2. CE2 connects to the
multicast source in VPN BLUE. VPN GREEN and VPN BLUE are configured on PE3. Users
connecting to CE3 need to receive multicast data from both VPN BLUE and VPN GREEN.
Figure 5-30 Networking for configuring a source VPN instance on a receiver PE in the
remote cross scenario of NG MVPN extranet
C o n fig u r e
S o u rc e s o u rc e V P N
CE1 G R EEN and a
m u ltic a s t
VPN r o u tin g p o lic y .
GREEN
VPN
PE1 P PE3 CE3 BLUE
R e c e iv e r
PE2
VPN VPN GREEN

BLUE VPN BLUE
CE2
S o u rc e
P IM J o in m e s s a g e
C - m u ltic a s t r o u te tr a n s m itte d b y B G P
M u ltic a s t tr a ffic tr a n s m itte d th r o u g h N G M V P N

Configure source VPN GREEN on PE3 and a multicast routing policy for receiver VPN
BLUE. Table 5-25 describes the implementation process.
Table 5-25 Process of configuring a source VPN instance on a receiver PE in the remote cross
scenario of NG MVPN extranet
St Devi Description
ep ce
1 CE3 CE3 receives an IGMP Report message from the receiver that requires data
from the multicast source in VPN GREEN and forwards a PIM Join
message to PE3.
2 PE3 After PE3 receives the PIM Join message from CE3 in VPN BLUE, it
creates a multicast routing entry. Through the RPF check, PE3 determines
that the upstream interface of the RPF route belongs to VPN GREEN. Then,
PE3 adds the upstream interface (serving as an extranet inbound interface)
to the multicast routing table.
3 PE3 PE3 sends the C-multicast route of VPN GREEN to PE1 in VPN GREEN
through BGP.
4 PE1 After PE1 receives the multicast data from the multicast source in VPN
GREEN, PE1 sends the multicast traffic of VPN GREEN to PE3 in VPN
GREEN over the public network.
5 PE3 PE3 decapsulates and imports the received multicast data to receiver VPN
BLUE and sends the data to CE3. Then, CE3 forwards the data to the
receiver in VPN BLUE.
Local Cross
On the network shown in Figure 5-31, PE1 is the source PE of VPN BLUE, and PE3 is the
source PE of VPN GREEN. CE4 connects to the multicast source in VPN GREEN. Both CE3
and CE4 reside on the same side of PE3. Users connecting to CE3 need to receive multicast
data from both VPN BLUE and VPN GREEN.
Figure 5-31 Local cross networking for NG MVPN extranet
S o u rc e
CE1 R e c e iv e r
VPN CE3
BLUE VPN
BLUE
PE1 P PE3
PE2
VPN CE4
GREEN S o u rc e
CE2 P IM J o in m e s s a g e VPN
GREEN
R e c e iv e r M u ltic a s t tr a ffic

Table 5-26 describes how NG MVPN extranet is implemented in the local cross scenario.
Table 5-26 NG MVPN extranet implemented in the local cross scenario

St Devi Description
ep ce
1 CE3 CE3 receives an IGMP Report message from the receiver that requires data
from the multicast source in VPN GREEN and forwards a PIM Join
message to PE3.
2 PE3 After PE3 receives the PIM Join message, it creates a multicast routing
entry of VPN BLUE. Through the RPF check, PE3 determines that the
upstream interface of the RPF route belongs to VPN GREEN. PE3 then
imports the PIM Join message to VPN GREEN.
3 PE3 PE3 creates a multicast routing entry in VPN GREEN, records receiver
VPN BLUE in the entry, and sends the PIM Join message to CE4 in VPN
GREEN.
4 PE3 After CE4 receives the PIM Join message, it sends the multicast data from
VPN GREEN to PE3, and PE3 imports the multicast data to receiver VPN
BLUE based on the multicast routing entries of VPN GREEN.
5 PE3 PE3 sends the multicast data to CE3 based on the multicast routing entries
of VPN BLUE. Then, CE3 forwards the data to the receiver in VPN BLUE.
5.1.2.5 NG MVPN Reliability

In the NG MVPN solution, MDT protection must be deployed to prevent network node or
link failures from causing long-term multicast service interruptions. A general protection
mechanism is node or link redundancy, which can immediately switch traffic to a backup
device or link if the master device or primary link fails. Table 5-27 describes several NG
MVPN protection solutions.

Table 5-27 NG MVPN protection solutions

Protection Protection Position Characteristic
Solution
Single-MVPN Sender CEs, receiver PEs, and Advantage: The network does not
networking nodes and links between sender have redundant multicast traffic.
protection CEs and receiver PEs Disadvantages:
l This solution enhances
network reliability by means
of networking redundancy. If
a network fault occurs, traffic
depends on unicast route
convergence to switch
between links. A longer route
convergence time results in
lower network reliability.
l Receiver CEs cannot be
protected.
Dual-MVPN Entire network Advantage: The entire network

networking can be protected.
protection Disadvantages:
l This solution also enhances
network reliability by means
of networking redundancy. If
a network fault occurs, traffic
depends on unicast route
convergence to switch
between links. A longer route
convergence time results in
lower network reliability.
l Redundant multicast traffic
exists on the network, wasting
bandwidth resources.
Dual-root 1+1 Sender PEs (P-tunnels can also Advantage: The network uses
protection be protected after this solution is BFD or flow based detection to
deployed) detect link faults, implementing
fast route convergence and high
network reliability.
Disadvantages:
l Redundant multicast traffic
exists on the network, wasting
bandwidth resources.
l Only sender PEs and P-
tunnels can be protected.
Receiver PEs and CEs cannot
be protected.

Protection Protection Position Characteristic

Solution
MPLS tunnel P-tunnels Advantage: MPLS tunnel

protection, such as protection technologies are
P2MP TE FRR mature and highly reliable.
NOTE Disadvantage: Only link
For more protection is supported.
information about
P2MP TE FRR,
see P2MP TE.
Single-MVPN Networking Protection

Appropriate NG MVPN networking can protect traffic transmitted over the NG MVPN
without using any reliability mechanisms. Single-MVPN networking protection is such an NG
MVPN protection solution. In single-MVPN networking protection, only one sender PE sends
multicast traffic to receiver PEs.
Scenario in Which No Fault Occurs
For example, on the network shown in Figure 5-32, unicast routing, VPN, BGP, MPLS, and
multicast routing are deployed properly. Figure 5-32 shows how a multicast receiver joins a
multicast group and how the multicast traffic is transmitted in a scenario in which no fault
occurs:
l Multicast joining process: After CE3 receives an IGMP join request, CE3 sends a PIM
Join message to PE3. Upon receipt, PE3 converts the message to a BGP C-multicast
route and sends the route to PE1, its BGP MVPN peer. Upon receipt, PE1 converts the
route to a PIM Join message and sends the message to the multicast source. Then, the
multicast receiver joins the multicast group.
l Multicast forwarding process: After PE1 receives multicast traffic from the multicast
source, PE1 sends the multicast traffic to PE3 over the P2MP tunnel. Upon receipt, PE3
sends the traffic to CE3, which in turn sends the traffic to the multicast receiver.

Figure 5-32 Single-MVPN networking protection

PE3 to PE1 and PE2
P1
PE1 PE3
CE1
vpn1
Source CE3 Receiver
vpn1
Sender Site Receiver Site
CE2
PE2 PE4
P2
PE4 to PE1 and PE2
PIM Join
BGP C-multicast route
P2MP tunnel with PE1 as ingress
P2MP tunnel with PE2 as ingress
Scenario in Which a Fault Occurs

Table 5-28 lists the possible points of failure on the network shown in Figure 5-32 and
describes the corresponding network convergence processes.
Table 5-28 Possible points of failure and corresponding network convergence processes
No Point Network Convergence Process
. of
Failure
1 CE1 or The network can rely only on unicast route convergence for recovery. The
link handling process is as follows:
between 1. PE1 detects that the multicast source is unreachable.
PE1
and the 2. PE1 sends to PE3 a BGP Withdraw message that carries information
multica about a VPNv4 route to the source.
st 3. After PE3 receives the message, PE3 preferentially selects the route
source advertised by PE2 as the route to the multicast source. Then, PE3 sends
a BGP C-multicast route to PE2. Upon receipt, PE2 converts the route
to a PIM Join message and sends the message to CE2.
4. CE2 constructs an MDT and sends the multicast traffic received from
the multicast source to PE2. Upon receipt, PE2 sends the traffic to PE3
over the P2MP tunnel.
5. After PE3 receives the traffic, PE3 sends the traffic to CE3, which in
turn sends the traffic to the multicast receiver.

No Point Network Convergence Process

. of
Failure
2 PE1 The network can rely only on unicast route convergence for recovery. The
handling process is as follows:
1. After PE3 uses BFD for BGP to detect that PE1 is unreachable, PE3
withdraws the route (to the multicast source) advertised by PE1 and
preferentially selects the route advertised by PE2 as the route to the
multicast source. Then, PE3 sends a BGP C-multicast route to PE2.
2. After PE2 receives the route, PE2 converts the route to a PIM Join
message and sends the message to CE2.
3 Public If MPLS tunnel protection is configured, the network relies on MPLS

network tunnel protection for recovery. The MVPN is unaware of public network
link link changes. If MPLS tunnel protection is not configured, the network
relies on unicast route convergence for recovery. In this situation, the
handling process is similar to the process for handling PE1 failures.
4 PE3 The network can rely only on unicast route convergence for recovery. The
handling process is as follows:
1. When CE3 detects that PE3 is unreachable, CE3 withdraws the unicast
route (to the multicast source) advertised by PE3 to trigger route
convergence. During route convergence, CE3 preferentially selects the
route advertised by PE4 as the route to the multicast source.
2. CE3 sends a PIM Join message to PE4.
3. After PE4 receives the message, PE4 converts the message to a BGP
C-multicast route and sends the route to PE1.
4. After PE1 receives the route, PE1 converts the route to a PIM Join
message and sends the message to CE1.
In single-MVPN networking protection, if PE3 and PE4 both receive PIM Join messages but
their upstream peers are different (for example, the upstream peer is PE1 for PE3 and PE2 for
PE4), PE1 and PE2 both send multicast traffic to PE3 and PE4. In this situation, you must
ensure that PE3 accepts only the multicast traffic from PE1 and PE4 accepts only the
multicast traffic from PE2. To do so, you must create multiple P2MP tunnels (with each I-
PMSI tunnel corresponds to one P2MP tunnel) when configuring a receiver PE to join
multiple I-PMSI tunnels. Then, when the multicast traffic reaches the receiver PE over
multiple I-PMSI tunnels, the receiver PE can identify the P2MP tunnel corresponding to the

upstream neighbor in its VPN instance multicast routing table. The receiver PE permits traffic
only in the identified P2MP tunnel but discards traffic in all other tunnels.
Dual-MVPN Networking Protection

Dual-MVPN networking protection is another protection solution that relies only on network
convergence to protect NG MVPN traffic. Dual-MVPN networking protection has the
following characteristics:
l On the control plane
– The master sender and receiver PEs belong to one MVPN; the backup sender and
receiver PEs belong to another MVPN.
– One receiver CE sends a PIM Join message to the master receiver PE, and

New IP Technologies

Uploaded by

Copyright:

Available Formats

New IP Technologies

Uploaded by

Document Information

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

Uploaded by

Copyright:

Available Formats

New IP Technologies

HUAWEI TECHNOLOGIES CO., LTD.

Trademarks and Permissions

Huawei Technologies Co., Ltd.

Issue draft 04 (2019-05-20) Copyright © Huawei Technologies Co., Ltd. i

1 Segment Routing MPLS............................................................................................................... 1

Issue draft 04 (2019-05-20) Copyright © Huawei Technologies Co., Ltd. ii

1.1.3 Application Scenarios for Segment Routing MPLS..................................................................................................85

Issue draft 04 (2019-05-20) Copyright © Huawei Technologies Co., Ltd. iii

1.2.8.2 Globally Enabling the SR Capability....................................................................................................................118

Issue draft 04 (2019-05-20) Copyright © Huawei Technologies Co., Ltd. iv

1.2.26 Configuring One-Arm BFD for E2E SR-TE Tunnel.............................................................................................168

Issue draft 04 (2019-05-20) Copyright © Huawei Technologies Co., Ltd. v

1.3.24 isis ti-lfa disable.....................................................................................................................................................339

2 Segment Routing IPv6.............................................................................................................. 385

Issue draft 04 (2019-05-20) Copyright © Huawei Technologies Co., Ltd. vi

2.1.2.3.3 Importing Traffic to SRv6-TE Tunnel............................................................................................................... 398

Issue draft 04 (2019-05-20) Copyright © Huawei Technologies Co., Ltd. vii

2.3.22 peer prefix-sid........................................................................................................................................................483

Issue draft 04 (2019-05-20) Copyright © Huawei Technologies Co., Ltd. viii

3.2.4 Configuring Common EVPN Functions..................................................................................................................597

Issue draft 04 (2019-05-20) Copyright © Huawei Technologies Co., Ltd. ix

3.2.14 Configuring MAC Duplication Suppression for EVPN........................................................................................ 646

Issue draft 04 (2019-05-20) Copyright © Huawei Technologies Co., Ltd. x

3.2.24.4 Example for Configuring EVPN VPWS over MPLS.........................................................................................746

Issue draft 04 (2019-05-20) Copyright © Huawei Technologies Co., Ltd. xi

3.3.14 display default-parameter evpn............................................................................................................................1028

Issue draft 04 (2019-05-20) Copyright © Huawei Technologies Co., Ltd. xii

3.3.56 local-remote vpws-frr enable(global EVPN configuration view)....................................................................... 1085

Issue draft 04 (2019-05-20) Copyright © Huawei Technologies Co., Ltd. xiii

4.1.2.5 VXLAN Gateway Deployment.......................................................................................................................... 1146

Issue draft 04 (2019-05-20) Copyright © Huawei Technologies Co., Ltd. xiv

4.2.8 Configuring the Dynamic VXLAN Active-Active Scenario.................................................................................1275

Issue draft 04 (2019-05-20) Copyright © Huawei Technologies Co., Ltd. xv

4.3.13 display mac-limit bridge-domain.........................................................................................................................1475

Issue draft 04 (2019-05-20) Copyright © Huawei Technologies Co., Ltd. xvi

4.3.55 vxlan anycast-gateway enable............................................................................................................................. 1541

Issue draft 04 (2019-05-20) Copyright © Huawei Technologies Co., Ltd. xvii

Issue draft 04 (2019-05-20) Copyright © Huawei Technologies Co., Ltd. xviii

5.2.5.4.2 Configuring an Automatic mLDP P2MP Tunnel............................................................................................ 1683

Issue draft 04 (2019-05-20) Copyright © Huawei Technologies Co., Ltd. xix

Issue draft 04 (2019-05-20) Copyright © Huawei Technologies Co., Ltd. xx

5.4.25 rpt-prune-delay.................................................................................................................................................... 2085

Issue draft 04 (2019-05-20) Copyright © Huawei Technologies Co., Ltd. xxi

6.1.4 Terminology for Telemetry....................................................................................................................................2152

Issue draft 04 (2019-05-20) Copyright © Huawei Technologies Co., Ltd. xxii

6.3.28 ssl-verify peer (gRPC server view)..................................................................................................................... 2214

Issue draft 04 (2019-05-20) Copyright © Huawei Technologies Co., Ltd. xxiii

1 Segment Routing MPLS

1.1 Segment Routing MPLS

1.1.1 Introduction of Segment Routing MPLS

Issue draft 04 (2019-05-20) Copyright © Huawei Technologies Co., Ltd. 1

Figure 1-1 Service-driven network

Low-latency path High-bandwidth path

Issue draft 04 (2019-05-20) Copyright © Huawei Technologies Co., Ltd. 2

1.1.2 Understanding Segment Routing MPLS

1.1.2.1 Segment Routing MPLS Fundamentals

Table 1-1 Segment category

Prefix Manually Identifies the prefix of a destination address.

Issue draft 04 (2019-05-20) Copyright © Huawei Technologies Co., Ltd. 3