Layer 2 Services and EVPN Guide: VLL, VPLS, PBB - Alcatel

LAYER 2 SERVICES AND EVPN GUIDE: VLL, VPLS, PBB, AND EVPN
RELEASE 15.0.R1
7450 ETHERNET SERVICE SWITCH
7750 SERVICE ROUTER
7950 EXTENSIBLE ROUTING SYSTEM
LAYER 2 SERVICES AND EVPN GUIDE:
VLL, VPLS, PBB, AND EVPN
RELEASE 15.0.R1
3HE 11970 AAAA TQZZA 01
Issue: 01
March 2017
Nokia — Proprietary and confidential.
Use pursuant to applicable agreements.
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
Nokia is a registered trademark of Nokia Corporation. Other products and company
names mentioned herein may be trademarks or tradenames of their respective
owners.
The information presented is subject to change without notice. No responsibility is
assumed for inaccuracies contained herein.
© 2017 Nokia.
Contains proprietary/trade secret information which is the property of Nokia and must
not be made available to, or copied or used by anyone outside Nokia without its
written authorization. Not to be used or disclosed except in accordance with
applicable agreements.
2
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
Table of Contents
Issue: 01
1
Getting Started ..............................................................................17
1.1
1.1.1
About This Guide.......................................................................................17
Audience....................................................................................................18
2
VLL Services .................................................................................19
2.1
2.2
2.2.1
2.2.2
2.2.3
2.2.3.1
2.2.3.2
2.2.3.3
2.2.3.4
2.3
2.3.1
2.3.2
2.3.3
2.3.3.1
2.3.3.2
2.3.3.3
2.3.3.4
2.3.3.5
2.3.4
2.3.5
2.3.6
2.4
2.4.1
2.4.2
2.4.3
2.4.4
2.4.5
2.4.6
2.4.7
2.4.8
2.5
2.5.1
2.5.2
2.5.3
2.5.3.1
2.5.3.2
2.5.3.3
2.5.3.4
2.6
2.6.1
In This Chapter ..........................................................................................19
ATM VLL (Apipe) Services .......................................................................19
ATM VLL For End-to-End ATM Service ...................................................19
ATM Virtual Trunk Over IP/MPLS Packet-Switched Network....................20
Traffic Management Support .....................................................................21
Ingress Network Classification ..................................................................21
Ingress Queuing and Shaping on the IOM ................................................22
Egress Queuing and Shaping on the IOM.................................................22
Egress Shaping/Scheduling ......................................................................22
Circuit Emulation Services (Cpipe)............................................................23
Mobile Infrastructure..................................................................................24
Circuit Emulation Modes............................................................................25
Circuit Emulation Parameters....................................................................27
Circuit Emulation Modes............................................................................27
Absolute Mode Option ...............................................................................27
Payload Size..............................................................................................28
Jitter Buffer ................................................................................................30
CES Circuit Operation ...............................................................................30
Services for Transporting CES Circuits .....................................................31
Network Synchronization Considerations..................................................31
Cpipe Payload ...........................................................................................32
Ethernet Pipe (Epipe) Services ................................................................33
Epipe Service Overview ............................................................................33
Epipe Service Pseudo-wire VLAN Tag Processing ...................................34
Epipe Up Operational State Configuration Option.....................................37
Epipe with PBB..........................................................................................38
Epipe over L2TPv3 ....................................................................................39
Ethernet Interworking VLL .........................................................................39
VLL CAC....................................................................................................41
MC-Ring and VLL ......................................................................................41
Frame Relay VLL (Fpipe) Services ..........................................................42
Frame Relay VLL.......................................................................................42
Frame Relay-to-ATM Interworking (FRF.5) VLL........................................43
Traffic Management Support .....................................................................44
Frame Relay Traffic Management .............................................................44
Ingress SAP Classification and Marking....................................................45
Egress Network EXP Marking ...................................................................45
Ingress Network Classification ..................................................................45
IP Interworking VLL (Ipipe) Services .........................................................45
Ipipe VLL ...................................................................................................46
3HE 11970 AAAA TQZZA 01
3
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
2.6.2
2.6.3
2.6.3.1
2.6.4
2.6.4.1
2.6.4.2
2.7
2.7.1
2.7.2
2.7.2.1
2.7.3
2.7.3.1
2.7.3.2
2.7.3.3
2.7.3.4
2.7.3.5
2.7.3.6
2.8
2.8.1
2.8.2
2.8.3
2.8.4
2.9
2.9.1
2.9.2
2.9.3
2.9.4
2.9.4.1
2.9.5
2.9.6
2.9.6.1
2.9.6.2
2.9.6.3
2.9.6.4
2.9.6.5
2.9.6.6
2.9.6.7
2.9.7
2.9.8
2.9.8.1
2.9.9
2.9.10
2.9.10.1
2.9.10.2
2.9.10.3
2.9.10.4
2.9.10.5
4
IP Interworking VLL Datapath....................................................................47
Extension to IP VLL for Discovery of Ethernet CE IP Address..................48
VLL Ethernet SAP Procedures ..................................................................48
IPv6 Support on IP Interworking VLL ........................................................51
IPv6 Datapath Operation ...........................................................................52
IPv6 Stack Capability Signaling.................................................................54
Services Configuration for MPLS-TP.........................................................55
MPLS-TP SDPs.........................................................................................55
VLL Spoke SDP Configuration ..................................................................57
Epipe VLL Spoke SDP Termination on IES, VPRN and VPLS .................60
Configuring MPLS-TP Lock Instruct and Loopback...................................61
MPLS-TP PW Lock Instruct and Loopback Overview ...............................61
Lock PW End-Point Model ........................................................................62
PW Redundancy and Lock Instruct and Loopback ...................................62
Configuring a Test SAP for an MPLS-TP PW ...........................................62
Configuring an Administrative Lock ...........................................................63
Configuring a Loopback.............................................................................65
VCCV BFD support for VLL, Spoke SDP Termination on IES and
VPRN, and VPLS Services........................................................................66
VCCV BFD Support...................................................................................66
VCCV BFD Encapsulation on a Pseudo-wire............................................67
BFD Session Operation.............................................................................67
Configuring VCCV BFD .............................................................................68
Pseudo-wire Switching ..............................................................................69
Pseudo-wire Switching with Protection......................................................70
Pseudo-wire Switching Behavior ...............................................................72
Static-to-Dynamic Pseudo-wire Switching.................................................74
Ingress VLAN Swapping............................................................................74
Ingress VLAN Translation..........................................................................75
Pseudo-wire Redundancy .........................................................................76
Dynamic Multi-Segment Pseudo-wire Routing ..........................................76
Overview....................................................................................................76
Pseudo-wire Routing .................................................................................81
Configuring VLLs using Dynamic MS-PWs ...............................................83
Pseudo-wire Redundancy .........................................................................85
VCCV OAM for Dynamic MS-PWs ............................................................87
VCCV-Ping on Dynamic MS-PWs .............................................................87
VCCV-Trace on Dynamic MS-PWs ...........................................................88
Example Dynamic MS-PW Configuration..................................................88
VLL Resilience with Two Destination PE Nodes .......................................92
Master-Slave Operation.............................................................................94
Pseudo-wire SAPs.....................................................................................99
Epipe Using BGP-MH Site Support for Ethernet Tunnels .......................100
Operational Overview ..............................................................................101
Detailed Operation...................................................................................102
BGP-MH Site Support for Ethernet Tunnels Operational-Group
Model.......................................................................................................106
BGP-MH Specifics for MH Site Support for Ethernet Tunnels.................107
PW Redundancy for BGP MH Site Support for Ethernet Tunnels...........107
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
2.9.10.6
2.9.11
2.9.12
2.10
2.10.1
2.10.2
2.10.2.1
2.10.2.2
2.11
2.11.1
2.11.2
2.11.3
2.11.3.1
2.12
2.13
2.14
2.14.1
2.14.2
2.14.3
2.14.3.1
2.14.3.2
2.14.3.3
2.14.3.4
2.15
2.15.1
2.15.1.1
2.15.2
2.15.2.1
2.15.2.2
2.15.2.3
2.15.2.4
2.15.2.5
2.16
2.16.1
2.16.2
2.16.3
2.16.3.1
2.16.3.2
2.16.3.3
2.16.3.4
2.16.3.5
2.16.4
2.16.5
2.16.6
2.16.7
2.16.8
2.16.9
Issue: 01
T-LDP Status Notification Handling Rules of BGP-MH Epipes ...............107
Access Node Resilience Using MC-LAG and Pseudo-wire
Redundancy ............................................................................................118
VLL Resilience for a Switched Pseudo-wire Path ...................................120
Pseudo-wire Redundancy Service Models..............................................122
Redundant VLL Service Model................................................................122
T-LDP Status Notification Handling Rules...............................................124
Processing Endpoint SAP Active/Standby Status Bits ...........................124
Processing and Merging..........................................................................125
High-Speed Downlink Packet Access (HSDPA) Off Load Fallback
over ATM .................................................................................................126
Primary Spoke SDP Fallback to Secondary SAP....................................128
Reversion to Primary Spoke SDP Path ...................................................128
MC-APS and MC-LAG.............................................................................128
Failure Scenarios.....................................................................................130
VLL Using G.8031 Protected Ethernet Tunnels ......................................131
MPLS Entropy Label and Hash Label .....................................................132
BGP Virtual Private Wire Service (VPWS) ..............................................132
Single-Homed BGP VPWS......................................................................133
Dual-Homed BGP VPWS ........................................................................133
BGP VPWS Pseudo-wire Switching ........................................................136
Pseudo-wire Signaling.............................................................................137
BGP VPWS Configuration Procedure .....................................................141
Use of Pseudo-wire Template for BGP VPWS........................................141
Use of Endpoint for BGP VPWS..............................................................143
VLL Service Considerations ....................................................................144
SDPs .......................................................................................................144
SDP Statistics for VPLS and VLL Services .............................................144
SAP Encapsulations and Pseudo-wire Types .........................................145
PWE3 N-to-1 Cell Mode ..........................................................................146
PWE3 AAL5 SDU Mode ..........................................................................147
QoS Policies ............................................................................................147
Filter Policies ...........................................................................................147
MAC Resources ......................................................................................148
Configuring a VLL Service with CLI.........................................................149
Basic Configurations................................................................................149
Common Configuration Tasks .................................................................149
Configuring VLL Components .................................................................150
Creating an Apipe Service.......................................................................150
Creating a Cpipe Service.........................................................................157
Creating an Epipe Service.......................................................................160
Creating an Fpipe Service .......................................................................170
Creating an Ipipe Service ........................................................................174
Using Spoke SDP Control Words............................................................177
Same Fate Epipe VLANs Access Protection...........................................178
Pseudowire Configuration Notes .............................................................180
Configuring Two VLL Paths Terminating on T-PE2.................................182
Configuring VLL Resilience .....................................................................184
Configuring VLL Resilience for a Switched Pseudowire Path .................185
3HE 11970 AAAA TQZZA 01
5
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
2.16.10
2.16.10.1
2.16.10.2
2.16.11
2.16.11.1
2.16.11.2
2.16.11.3
2.16.11.4
2.16.11.5
2.16.11.6
2.16.11.7
2.16.11.8
2.16.11.9
2.16.11.10
2.16.11.11
2.16.11.12
2.16.11.13
2.16.11.14
2.16.11.15
2.16.11.16
2.16.11.17
2.16.11.18
2.17
2.17.1
2.17.1.1
2.17.1.2
2.17.1.3
2.17.1.4
2.17.1.5
2.17.1.6
2.17.2
2.17.2.1
2.17.2.2
2.17.2.3
2.17.2.4
2.17.2.5
2.17.2.6
2.17.2.7
2.17.2.8
2.17.2.9
2.17.2.10
2.17.2.11
2.17.2.12
2.17.2.13
2.17.2.14
2.17.2.15
2.18
2.18.1
2.18.1.1
6
Configuring BGP Virtual Private Wire Service (VPWS)...........................187
Single-Homed BGP VPWS......................................................................187
Dual-Homed BGP VPWS ........................................................................189
Service Management Tasks ....................................................................194
Modifying Apipe Service Parameters ......................................................195
Disabling an Apipe Service......................................................................197
Re-Enabling an Apipe Service.................................................................198
Deleting an Apipe Service .......................................................................199
Modifying a Cpipe Service.......................................................................200
Deleting a Cpipe Service .........................................................................200
Modifying Epipe Service Parameters ......................................................200
Disabling an Epipe Service......................................................................201
Re-Enabling an Epipe Service.................................................................201
Deleting an Epipe Service .......................................................................202
Modifying Fpipe Service Parameters.......................................................202
Disabling an Fpipe Service......................................................................204
Re-enabling an Fpipe Service .................................................................205
Deleting an Fpipe Service .......................................................................206
Modifying Ipipe Service Parameters........................................................207
Disabling an Ipipe Service .......................................................................207
Re-enabling an Ipipe Service ..................................................................208
Deleting an Ipipe Service.........................................................................208
VLL Service Configuration Command Reference....................................211
Command Hierarchies.............................................................................211
Apipe Service Configuration Commands.................................................211
Related Apipe Commands.......................................................................215
Cpipe Service Configuration Commands ................................................215
Epipe Service Configuration Commands.................................................219
Fpipe Service Configuration Commands.................................................230
Ipipe Service Configuration Commands ..................................................233
Command Descriptions ...........................................................................239
Generic Commands.................................................................................239
Service Commands .................................................................................241
VLL Global Commands ...........................................................................246
VLL SAP Commands...............................................................................266
Circuit Emulation Commands ..................................................................298
ETH-CFM Service Commands ................................................................302
Service Filter and QoS Policy Commands ..............................................318
VLL Frame Relay Commands .................................................................351
VLL SDP Commands ..............................................................................353
ATM Commands......................................................................................382
OAM Commands .....................................................................................384
Cpipe Commands....................................................................................386
VLL SAP Commands...............................................................................388
CPipe SDP Commands ...........................................................................392
Epipe SAP Template Commands............................................................394
VLL Show Command Reference .............................................................399
Command Hierarchies.............................................................................399
Show Commands ....................................................................................399
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
Issue: 01
2.18.1.2
2.18.1.3
2.18.1.4
2.18.2
2.18.2.1
2.18.2.2
2.18.2.3
2.18.2.4
Clear Commands.....................................................................................400
Debug Commands...................................................................................400
Tools Commands ....................................................................................401
Command Descriptions ...........................................................................402
VLL Show Commands.............................................................................402
VLL Clear Commands .............................................................................470
VLL Debug Commands ...........................................................................474
VLL Tools Commands .............................................................................476
3
Virtual Private LAN Service .......................................................479
3.1
3.2
3.2.1
3.3
3.3.1
3.3.2
3.3.3
3.3.4
3.3.4.1
3.3.4.2
3.3.5
3.3.6
3.3.7
3.3.7.1
3.3.7.2
3.3.7.3
3.3.7.4
3.3.7.5
3.3.7.6
3.3.7.7
3.3.7.8
3.3.7.9
3.3.7.10
3.3.7.11
3.3.7.12
3.3.7.13
3.3.8
3.3.9
3.3.9.1
3.3.9.2
3.3.9.3
3.3.9.4
3.3.9.5
3.3.10
3.3.10.1
3.3.10.2
3.3.10.3
3.3.10.4
In This Chapter ........................................................................................479
VPLS Service Overview ..........................................................................479
VPLS Packet Walkthrough ......................................................................480
VPLS Features ........................................................................................483
VPLS Enhancements ..............................................................................483
VPLS over MPLS.....................................................................................484
VPLS Service Pseudo-wire VLAN Tag Processing .................................484
VPLS MAC Learning and Packet Forwarding .........................................488
MAC Learning Protection ........................................................................489
DEI in IEEE 802.1ad................................................................................490
VPLS Using G.8031 Protected Ethernet Tunnels....................................491
Pseudo-wire Control Word ......................................................................492
Table Management..................................................................................492
Selective MAC Address Learning............................................................492
System FDB Size ....................................................................................499
Per-VPLS Service FDB Size ...................................................................500
System FDB Size Alarms ........................................................................501
Line Card FDB Size Alarms.....................................................................501
Per VPLS FDB Size Alarms ....................................................................501
Local and Remote Aging Timers .............................................................502
Disable MAC Aging .................................................................................502
Disable MAC Learning.............................................................................502
Unknown MAC Discard ...........................................................................502
VPLS and Rate Limiting ..........................................................................503
MAC Move...............................................................................................503
Auto-Learn MAC Protect .........................................................................504
Split Horizon SAP Groups and Split Horizon Spoke SDP Groups ..........509
VPLS and Spanning Tree Protocol..........................................................509
Spanning Tree Operating Modes ............................................................510
Multiple Spanning Tree............................................................................511
MSTP for QinQ SAPs ..............................................................................512
Provider MSTP ........................................................................................513
Enhancements to the Spanning Tree Protocol........................................514
VPLS Redundancy ..................................................................................517
Spoke SDP Redundancy for Metro Interconnection................................517
Spoke SDP Based Redundant Access....................................................518
Inter-Domain VPLS Resiliency Using Multi-Chassis Endpoints ..............519
Support for Single Chassis Endpoint Mechanisms..................................524
3HE 11970 AAAA TQZZA 01
7
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
3.3.10.5
3.3.10.6
3.3.11
3.3.11.1
3.3.11.2
3.3.12
3.3.12.1
3.3.13
3.3.13.1
3.3.13.2
3.3.14
3.3.15
3.3.16
3.3.16.1
3.3.16.2
3.3.16.3
3.3.16.4
3.3.16.5
3.3.16.6
3.3.16.7
3.3.16.8
3.3.16.9
3.3.16.10
3.3.17
3.3.17.1
3.3.17.2
3.3.18
3.3.19
3.3.19.1
3.3.19.2
3.3.19.3
3.3.19.4
3.3.20
3.3.20.1
3.3.20.2
3.3.20.3
3.3.20.4
3.3.20.5
3.3.20.6
3.3.20.7
3.3.21
3.3.22
3.4
3.4.1
3.4.1.1
3.4.1.2
8
Using B-VPLS for Increased Scalability and Reduced
Convergence Times ...............................................................................527
MAC Flush Additions for PBB VPLS ......................................................528
VPLS Access Redundancy......................................................................531
STP-Based Redundant Access to VPLS ................................................532
Redundant Access to VPLS Without STP ...............................................532
Object Grouping and State Monitoring ....................................................533
VPLS Applicability — Block on VPLS a Failure......................................534
MAC Flush Message Processing ............................................................535
Dual Homing to a VPLS Service..............................................................538
MC-Ring and VPLS .................................................................................539
ACL Next-Hop for VPLS ..........................................................................540
SDP Statistics for VPLS and VLL Services .............................................541
BGP Auto-Discovery for LDP VPLS ........................................................541
BGP AD Overview ...................................................................................542
Information Model....................................................................................542
FEC Element for T-LDP Signaling ..........................................................543
BGP-AD and Target LDP (T-LDP) Interaction.........................................545
SDP Usage..............................................................................................546
Automatic Creation of SDPs....................................................................546
Manually Provisioned SDP ......................................................................547
Automatic Instantiation of Pseudo-wires (SDP Bindings)........................548
Mixing Statically Configured and Auto-Discovered Pseudo-wires
in a VPLS.................................................................................................548
Resiliency Schemes ................................................................................549
BGP VPLS...............................................................................................549
Pseudo-wire Signaling Details.................................................................551
Supported VPLS Features.......................................................................553
VCCV BFD Support for VPLS Services...................................................554
BGP Multi-Homing for VPLS ...................................................................555
Information Model and Required Extensions to L2VPN NLRI .................556
Supported Services and Multi-Homing Objects.......................................557
Blackhole Avoidance ...............................................................................558
BGP Multi-Homing for VPLS Inter-Domain Resiliency ............................559
Multicast-Aware VPLS.............................................................................560
IGMP Snooping for VPLS........................................................................560
MLD Snooping for VPLS .........................................................................561
PIM Snooping for VPLS...........................................................................561
IPv6 Multicast Forwarding .......................................................................563
PIM and IGMP/MLD Snooping Interaction .............................................566
Multi-Chassis Synchronization for Layer 2 Snooping States...................567
VPLS Multicast-Aware High Availability Features ...................................570
RSVP and LDP P2MP LSP for Forwarding VPLS/B-VPLS BUM
and IP Multicast Packets .........................................................................570
MPLS Entropy Label and Hash Label .....................................................572
Routed VPLS and I-VPLS .......................................................................572
IES or VPRN IP Interface Binding ...........................................................572
Assigning a Service Name to a VPLS Service ........................................573
Service Binding Requirements ................................................................573
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
3.4.1.3
3.4.1.4
3.4.1.5
3.4.1.6
3.4.1.7
3.4.2
3.4.2.1
3.4.3
3.4.3.1
3.4.4
3.4.4.1
3.4.4.2
3.4.4.3
3.4.4.4
3.4.5
3.4.6
3.4.7
3.4.7.1
3.4.7.2
3.4.7.3
3.4.7.4
3.4.7.5
3.4.7.6
3.4.7.7
3.5
3.5.1
3.5.2
3.5.3
3.5.4
3.5.4.1
3.5.4.2
3.5.4.3
3.5.4.4
3.5.4.5
3.5.5
3.5.5.1
3.5.5.2
3.5.5.3
3.5.5.4
3.5.5.5
3.5.5.6
3.6
3.6.1
3.6.2
3.6.3
3.6.3.1
3.6.3.2
3.6.3.3
Issue: 01
Bound Service Name Assignment...........................................................573
Binding a Service Name to an IP Interface..............................................574
Bound Service Deletion or Service Name Removal ................................574
IP Interface Attached VPLS Service Constraints.....................................575
IP Interface and VPLS Operational State Coordination...........................575
IP Interface MTU and Fragmentation ......................................................575
Unicast IP Routing into a VPLS Service..................................................576
ARP and VPLS FDB Interactions ............................................................576
Routed VPLS Specific ARP Cache Behavior ..........................................577
The allow-ip-int-bind VPLS Flag ..............................................................578
Routed VPLS SAPs Only Supported on Standard Ethernet Ports ..........579
LAG Port Membership Constraints..........................................................579
Routed VPLS Feature Restrictions..........................................................579
Routed I-VPLS Feature Restrictions .......................................................579
IPv4 and IPv6 Multicast Routing Support ................................................580
BGP Auto Discovery (BGP-AD) for Routed VPLS Support .....................583
Routed VPLS Caveats.............................................................................583
VPLS SAP Ingress IP Filter Override ......................................................583
IP Interface Defined Egress QoS Reclassification ..................................584
Remarking for VPLS and Routed Packets ..............................................584
7450 Mixed Mode Chassis ......................................................................584
IPv4 Multicast Routing.............................................................................584
Routed VPLS Supported Routing Related Protocols ..............................585
Spanning Tree and Split Horizon.............................................................585
VPLS Service Considerations .................................................................585
SAP Encapsulations ...............................................................................586
VLAN Processing ....................................................................................586
Ingress VLAN Swapping..........................................................................587
Service Auto-Discovery using Multiple VLAN Registration Protocol
(MVRP)....................................................................................................587
Configure the MVRP Infrastructure using an M-VPLS Context ...............589
Instantiate Related VLAN FDBs and Trunks in MVRP Scope.................589
MVRP Activation of Service Connectivity ................................................591
MVRP Control Plane ...............................................................................594
STP-MVRP Interaction ............................................................................594
VPLS E-Tree Services.............................................................................596
VPLS E-Tree Services Overview ............................................................597
Leaf-ac and Root-ac SAPs ......................................................................598
Leaf-ac and Root-ac SDP Binds .............................................................598
Root-leaf-tag SAPs..................................................................................599
Root-leaf-tag SDP Binds .........................................................................600
Interaction between VPLS E-Tree Services and Other Features ............601
Configuring a VPLS Service with CLI ......................................................603
Basic Configuration .................................................................................603
Common Configuration Tasks .................................................................605
Configuring VPLS Components...............................................................605
Creating a VPLS Service.........................................................................606
Enabling Multiple MAC Registration Protocol (MMRP) ...........................606
Configuring GSMP Parameters ...............................................................615
3HE 11970 AAAA TQZZA 01
9
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
3.6.3.4
3.6.3.5
3.6.3.6
3.6.3.7
3.6.3.8
3.6.4
3.6.4.1
3.6.4.2
3.6.4.3
3.6.4.4
3.6.4.5
3.6.5
3.6.6
3.6.6.1
3.6.6.2
3.6.6.3
3.6.7
3.6.7.1
3.6.8
3.6.9
3.7
3.7.1
3.7.2
3.7.3
3.7.4
3.7.5
3.7.6
3.7.7
3.8
3.8.1
3.8.1.1
3.8.1.2
3.8.1.3
3.8.1.4
3.8.1.5
3.8.1.6
3.8.1.7
3.8.1.8
3.8.1.9
3.8.2
3.8.2.1
3.8.2.2
3.8.2.3
3.8.2.4
3.8.2.5
3.8.2.6
3.8.2.7
10
Configuring a VPLS SAP.........................................................................616
Configuring SAP Subscriber Management Parameters ..........................626
MSTP Control over Ethernet Tunnels......................................................627
Configuring SDP Bindings .......................................................................628
Configuring Overrides on Service SAPs..................................................628
Configuring VPLS Redundancy...............................................................640
Creating a Management VPLS for SAP Protection .................................640
Creating a Management VPLS for Spoke SDP Protection......................643
Configuring Load Balancing with Management VPLS.............................645
Configuring Selective MAC Flush............................................................650
Configuring Multi-Chassis Endpoints.......................................................650
ATM/Frame Relay PVC Access and Termination on a VPLS
Service.....................................................................................................654
Configuring BGP Auto-Discovery ...........................................................656
Configuration Steps .................................................................................656
LDP Signaling..........................................................................................658
Pseudowire Template..............................................................................660
Configuring BGP VPLS ...........................................................................662
Configuring a VPLS Management Interface ............................................663
Configuring Policy-Based Forwarding for Deep Packet Inspection
(DPI) in VPLS ..........................................................................................664
Configuring VPLS E-Tree Services .........................................................667
Service Management Tasks ....................................................................668
Modifying VPLS Service Parameters ......................................................668
Modifying Management VPLS Parameters .............................................669
Deleting a Management VPLS ................................................................669
Disabling a Management VPLS ..............................................................669
Deleting a VPLS Service .........................................................................670
Disabling a VPLS Service........................................................................670
Re-Enabling a VPLS Service...................................................................671
VPLS Service Configuration Command Reference.................................673
Command Hierarchies.............................................................................673
Global Commands...................................................................................673
Oper Group Commands ..........................................................................680
SAP Commands ......................................................................................681
Template Commands ..............................................................................691
Mesh SDP Commands ............................................................................693
Spoke SDP Commands...........................................................................697
Provider Tunnel Commands....................................................................701
Routed VPLS Commands .......................................................................703
Multi-Chassis Redundancy Commands ..................................................703
Command Descriptions ...........................................................................704
Generic Commands.................................................................................704
VPLS Service Commands .......................................................................706
VPLS Interface Commands .....................................................................772
General Switch Management Protocol Commands.................................775
ETH-CFM Service Commands ................................................................797
VPLS Multicast Commands.....................................................................898
BGP Auto-Discovery Commands ............................................................933
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
3.8.2.8
3.9
3.9.1
3.9.1.1
3.9.1.2
3.9.1.3
3.9.1.4
3.9.2
3.9.2.1
3.9.2.2
3.9.2.3
3.9.2.4
3.9.2.5
Redundancy Commands .........................................................................944
VPLS Show, Clear, Debug, and Tools Command Reference .................949
Command Hierarchies.............................................................................949
Show Commands ....................................................................................949
Clear Commands.....................................................................................952
Debug Commands...................................................................................954
Tools Commands ....................................................................................955
Command Descriptions ...........................................................................956
VPLS Show Commands ..........................................................................956
IGMP Snooping Show Commands........................................................1089
IGMP Commands ..................................................................................1106
VPLS Clear Commands ........................................................................1128
VPLS Debug Commands ......................................................................1141
4
IEEE 802.1ah Provider Backbone Bridging ............................1163
4.1
4.2
4.3
4.3.1
4.3.2
4.3.3
4.3.4
4.3.4.1
4.3.4.2
4.3.5
4.3.5.1
4.3.6
4.3.6.1
4.3.6.2
4.3.6.3
4.3.6.4
4.3.6.5
4.3.6.6
4.3.6.7
4.3.7
4.3.7.1
4.3.7.2
4.3.7.3
4.3.8
4.3.8.1
4.3.8.2
4.3.9
4.3.10
4.3.10.1
4.3.11
In This Chapter ......................................................................................1163
IEEE 802.1ah Provider Backbone Bridging (PBB) Overview ................1163
PBB Features ........................................................................................1164
Integrated PBB-VPLS Solution..............................................................1164
PBB Technology ...................................................................................1166
PBB Mapping to Existing VPLS Configurations.....................................1167
SAP and SDP Support ..........................................................................1168
PBB B-VPLS..........................................................................................1168
PBB I-VPLS ...........................................................................................1168
PBB Packet Walkthrough ......................................................................1169
PBB Control Planes...............................................................................1171
Shortest Path Bridging MAC Mode (SPBM) ..........................................1172
Flooding and Learning Versus Link State..............................................1172
SPB for B-VPLS ....................................................................................1173
Control B-VPLS and User B-VPLS........................................................1173
Shortest Path and Single Tree ..............................................................1175
Data Path and Forwarding.....................................................................1179
SPB Ethernet OAM................................................................................1179
SPB Levels ............................................................................................1180
SPBM to Non-SPBM Interworking.........................................................1181
Static MACs and Static ISIDs ...............................................................1181
Epipe Static Configuration .....................................................................1181
SPBM ISID Policies ...............................................................................1183
ISID Policy Control ................................................................................1185
Static ISID Advertisement......................................................................1185
I-VPLS for Unicast Service ....................................................................1185
Default Behaviors ..................................................................................1186
Example Network Configuration ............................................................1187
Sample Configuration for Dut-A.............................................................1187
IEEE 802.1ak MMRP for Service Aggregation and Zero Touch
Provisioning ...........................................................................................1193
MMRP Support Over B-VPLS SAPs and SDPs ....................................1195
I-VPLS Changes and Related MMRP Behavior ....................................1196
Limiting the Number of MMRP Entries on a Per B-VPLS Basis ............1196
4.3.12
4.3.12.1
4.3.12.2
Issue: 01
3HE 11970 AAAA TQZZA 01
11
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
4.3.12.3
4.3.12.4
4.3.13
4.3.14
4.3.14.1
4.3.15
4.3.15.1
4.3.15.2
4.3.15.3
4.3.15.4
4.3.16
4.3.17
4.3.17.1
4.3.18
4.3.18.1
4.3.18.2
4.3.19
4.3.20
4.3.21
4.3.22
4.3.23
4.3.23.1
4.3.24
4.3.24.1
4.3.24.2
4.3.24.3
4.3.24.4
4.3.25
4.3.25.1
4.3.25.2
4.3.25.3
4.4
4.4.1
4.4.2
4.4.3
4.5
4.5.1
4.5.1.1
4.5.1.2
4.5.1.3
4.5.1.4
4.5.1.5
4.5.2
4.5.2.1
4.6
4.6.1
4.6.1.1
12
Optimization for Improved Convergence Time ......................................1196
Controlling MRP Scope using MRP Policies .........................................1197
PBB and BGP-AD..................................................................................1200
PBB ELINE Service ...............................................................................1200
Non-Redundant PBB Epipe Spoke Termination....................................1201
PBB Using G.8031-Protected Ethernet Tunnels ...................................1201
Solution Overview..................................................................................1201
Detailed Solution Description ................................................................1202
Detailed PBB Emulated LAG Solution Description................................1205
Support Service and Solution Combinations .........................................1206
Periodic MAC Notification......................................................................1207
MAC Flush.............................................................................................1208
PBB Resiliency for B-VPLS Over Pseudo-wire Infrastructure ...............1208
Access Multi-Homing for Native PBB (B-VPLS over SAP
Infrastructure) ........................................................................................1212
Solution Description for I-VPLS Over Native PBB Core ........................1213
Solution Description for PBB Epipe over G.8031 Ethernet Tunnels......1216
BGP Multi-homing for I-VPLS ...............................................................1219
Access Multi-Homing over MPLS for PBB Epipes.................................1220
PBB and IGMP/MLD Snooping .............................................................1223
PBB and PIM Snooping.........................................................................1224
PBB QoS ...............................................................................................1224
Transparency of Customer QoS Indication through PBB
Backbone...............................................................................................1226
Egress B-SAP per ISID Shaping ...........................................................1230
B-SAP Egress ISID Shaping Configuration ...........................................1230
Provisioning Model ................................................................................1232
Egress Queue Scheduling.....................................................................1234
B-SAP per-ISID Shaping Configuration Example..................................1236
PBB OAM ..............................................................................................1239
Mirroring ................................................................................................1239
OAM Commands ...................................................................................1240
CFM Support .........................................................................................1240
Configuration Examples ........................................................................1240
PBB using G.8031 Protected Ethernet Tunnels ....................................1240
MC-LAG Multihoming for Native PBB....................................................1244
Access Multi-Homing over MPLS for PBB Epipes.................................1245
PBB Configuration Command Reference..............................................1249
Command Hierarchies...........................................................................1249
Global Commands.................................................................................1249
SAP Commands ....................................................................................1250
Mesh SDP Commands ..........................................................................1251
Spoke SDP Commands.........................................................................1251
BGP-MH for I-VPLS Commands ...........................................................1252
Command Descriptions .........................................................................1253
VPLS Service Commands .....................................................................1253
PBB Show, Clear, and Debug Command Reference ............................1291
Command Hierarchies...........................................................................1291
Show Commands ..................................................................................1291
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
4.6.1.2
4.6.1.3
4.6.2
4.6.2.1
4.6.2.2
4.6.2.3
Clear Commands...................................................................................1292
Debug Commands.................................................................................1292
Command Descriptions .........................................................................1293
PBB Show Commands ..........................................................................1293
PBB Clear Commands ..........................................................................1315
PBB Debug Commands ........................................................................1317
5
Ethernet Virtual Private Networks (EVPNs)............................1321
5.1
5.2
5.3
5.4
In This Chapter ......................................................................................1321
Overview................................................................................................1321
EVPN for VXLAN Tunnels in a Layer-2 DC GW (EVPN-VXLAN) .........1322
EVPN for VXLAN Tunnels in a Layer-2 DC with Integrated Routing
Bridging Connectivity on the DC GW ....................................................1324
EVPN for VXLAN Tunnels in a Layer 3 DC with Integrated Routing
Bridging Connectivity among VPRNs ....................................................1325
EVPN for VXLAN Tunnels in a Layer 3 DC with EVPN-Tunnel
Connectivity among VPRNs ..................................................................1326
EVPN for MPLS Tunnels in ELAN Services ..........................................1328
EVPN for MPLS Tunnels in ELINE Services .........................................1329
EVPN for MPLS Tunnels in ETREE Services .......................................1330
EVPN for PBB over MPLS Tunnels (PBB-EVPN) .................................1330
VXLAN...................................................................................................1331
VXLAN ECMP and LAG .......................................................................1334
VXLAN VPLS Tag Handling ..................................................................1334
VXLAN MTU Considerations .................................................................1334
VXLAN QoS...........................................................................................1335
Ingress...................................................................................................1335
Egress ...................................................................................................1336
VXLAN Ping...........................................................................................1336
IGMP Snooping on VXLAN ...................................................................1341
Static VXLAN Termination in Epipe Services ........................................1343
Non-System IPv4 and IPv6 VXLAN Termination in VPLS, RVPLS, and Epipe Services ....................................................................1344
BGP-EVPN Control Plane for VXLAN Overlay Tunnels ........................1349
EVPN for VXLAN in VPLS Services ......................................................1354
Resiliency and BGP Multi-Homing ........................................................1357
Use of bgp-evpn, bgp-ad, and Sites in the Same VPLS Service...........1357
Use of the unknown-mac-route ............................................................1358
EVPN for VXLAN in R-VPLS Services ..................................................1359
EVPN for VXLAN in IRB Backhaul R-VPLS Services and IP
Prefixes..................................................................................................1361
EVPN for VXLAN in EVPN Tunnel R-VPLS Services ...........................1364
DC GW integration with the Nuage Virtual Services Directory
(VSD).....................................................................................................1369
XMPP Interface on the DC GW .............................................................1371
Overview of the Static-Dynamic VSD Integration Model .......................1374
VSD-Domains and Association to Static-Dynamic Services .................1376
VSD-Domain Type L2-DOMAIN ...........................................................1377
VSD-Domain Type L2-DOMAIN-IRB.....................................................1379
5.5
5.6
5.7
5.8
5.9
5.10
5.11
5.11.1
5.11.2
5.11.3
5.11.4
5.11.4.1
5.11.4.2
5.11.5
5.11.6
5.11.7
5.11.8
5.12
5.13
5.13.1
5.13.2
5.13.3
5.14
5.15
5.16
5.17
5.17.1
5.17.2
5.17.3
5.17.3.1
5.17.3.2
Issue: 01
3HE 11970 AAAA TQZZA 01
13
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
5.17.3.3
5.17.3.4
5.18
5.18.1
5.18.2
5.19
5.19.1
5.19.2
5.19.3
5.20
5.21
5.21.1
5.21.2
5.21.3
5.21.4
5.21.5
5.21.6
5.21.7
5.21.8
5.21.8.1
5.21.8.2
5.21.9
5.21.9.1
5.21.9.2
5.21.9.3
5.21.9.4
5.22
5.23
5.23.1
5.24
5.25
5.25.1
5.26
5.27
5.27.1
5.27.2
5.27.3
5.28
5.28.1
5.28.2
5.28.3
5.28.3.1
5.28.3.2
5.28.3.3
5.28.3.4
14
VSD-Domain Type VRF-GRE ..............................................................1379
VSD-Domain Type VRF-VXLAN ..........................................................1380
Fully-Dynamic VSD Integration Model...................................................1382
Python Script Implementation Details....................................................1385
Provisioning Filters using the VSD Fully Dynamic Model......................1391
Layer 2 Multicast Optimization for VXLAN (Assisted-Replication) .......1392
Replicator (AR-R) Procedures...............................................................1393
Leaf (AR-L) procedures .........................................................................1394
Assisted-Replication Interaction with Other VPLS Features .................1398
BGP-EVPN Control Plane for MPLS Tunnels .......................................1398
EVPN for MPLS Tunnels in VPLS Services (EVPN-MPLS) ..................1405
EVPN and VPLS Integration..................................................................1409
Auto-Derived Route-Distinguisher (RD) in Services with Multiple
BGP Families.........................................................................................1413
EVPN Multi-Homing in VPLS Services..................................................1414
EVPN All-Active Multi-Homing...............................................................1414
All-Active Multi-Homing Service Model..................................................1416
ES Discovery and DF Election Procedures ...........................................1419
Aliasing ..................................................................................................1425
Network Failures and Convergence for All-Active Multi-Homing...........1427
Logical Failures on Ethernet Segments and Black-Holes ....................1428
Transient Issues Due to MAC Route Delays ........................................1429
EVPN Single-Active Multi-Homing.........................................................1430
Single-Active Multi-Homing Service Model............................................1431
ES and DF Election Procedures............................................................1433
Backup PE Function ..............................................................................1435
Network Failures and Convergence for Single-Active MultiHoming ..................................................................................................1436
BGP-EVPN Control Plane for EVPN-VPWS .........................................1438
EVPN for MPLS Tunnels in Epipe Services (EVPN-VPWS) .................1440
Using A/S PW and MC-LAG with EVPN-VPWS Epipes........................1443
EVPN Multi-homing for EVPN-VPWS Services.....................................1444
EVPN for MPLS Tunnels in Routed VPLS Services..............................1447
EVPN-MPLS Multi-Homing and Passive VRRP ....................................1447
P2MP mLDP tunnels for BUM traffic in EVPN-MPLS Services.............1450
BGP-EVPN Control Plane for PBB-EVPN.............................................1453
EVPN Route Type 3 - Inclusive Multicast Ethernet Tag Route .............1453
EVPN Route Type 2 - MAC/IP Advertisement Route (or BMAC
Routes) ..................................................................................................1454
EVPN Route Type 4 - Ethernet Segment Route ..................................1455
PBB-EVPN for I-VPLS and PBB Epipe Services...................................1455
Flood Containment for I-VPLS Services................................................1458
PBB-EVPN and PBB-VPLS Integration.................................................1460
PBB-EVPN Multi-Homing in I-VPLS and PBB Epipe Services..............1461
System BMAC Assignment in PBB-EVPN ............................................1461
PBB-EVPN all-active multi-homing service model ................................1462
PBB-EVPN Single-Active Multi-Homing Service Model ........................1468
PBB-Epipes and EVPN Multi-Homing ...................................................1471
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
5.28.3.5
5.28.3.6
5.28.4
5.29
5.29.1
5.30
5.30.1
5.30.2
5.30.2.1
5.30.3
5.31
5.32
5.33
5.34
5.35
5.36
5.37
5.38
5.38.1
5.38.2
5.39
5.40
5.41
5.41.1
5.41.2
5.41.3
5.42
5.43
5.44
5.44.1
5.44.2
5.44.3
5.44.4
5.45
5.46
5.47
5.48
5.49
Issue: 01
PBB-EVPN and Use of P2MP mLDP Tunnels for Default Multicast
List .........................................................................................................1472
PBB-EVPN ISID-Based CMAC Flush....................................................1473
PBB-EVPN ISID-based Route Targets..................................................1477
Virtual Ethernet Segments.....................................................................1479
Preference-Based and Non-Revertive DF Election ...............................1483
ARP/ND Snooping and Proxy Support ..................................................1487
Proxy-ARP/ND Periodic Refresh, Unsolicited Refresh and ConfirmMessages ..............................................................................................1491
Proxy-ND and the Router Flag in Neighbor Advertisement
messages ..............................................................................................1492
Procedure to Add the R Flag to a Specified Entry.................................1492
Proxy-ARP/ND Mac-List for Dynamic Entries........................................1493
BGP-EVPN MAC-Mobility......................................................................1495
BGP-EVPN MAC-Duplication ................................................................1496
Conditional Static MAC and Protection .................................................1497
Auto-Learn MAC Protect and Restricting Protected Source MACs.......1499
Black-hole MAC and its Application to Proxy-ARP/Proxy-ND
Duplicate Detection ...............................................................................1501
Black-hole MAC for EVPN Loop Detection............................................1503
CFM Interaction with EVPN Services ....................................................1505
DC GW Policy Based Forwarding/Routing to an EVPN ESI
(Ethernet Segment Identifier) ................................................................1507
Policy Based Forwarding in VPLS Services for Nuage Service
Chaining Integration in L2-Domains ......................................................1508
Policy Based Routing in VPRN Services for Nuage Service
Chaining Integration in L2-DOMAIN-IRB Domains................................1511
IGMP Snooping in EVPN-MPLS and PBB-EVPN Services...................1515
PIM Snooping for IPv4 in EVPN-MPLS and PBB-EVPN Services ........1517
Configuring EVPN-VXLAN and EVPN-MPLS in the Same VPLS
Service ..................................................................................................1520
BGP-EVPN Routes in Services Configured With Two BGP
Instances ...............................................................................................1521
Anycast Redundant Solution for Dual BGP Instance Services..............1524
Using P2MP mLDP in Redundant Anycast DC GWs ............................1527
BGP EVPN Control Plane for EVPN ETREE ........................................1529
EVPN for MPLS Tunnels in ETREE Services ......................................1531
EVPN ETREE Operation ......................................................................1532
EVPN ETREE Known Unicast Ingress Filtering ....................................1532
EVPN ETREE BUM Egress Filtering.....................................................1534
EVPN ETREE Egress Filtering Based on MAC Source Address ..........1536
EVPN ETREE and EVPN Multi-homing ................................................1536
BGP and EVPN Route Selection for EVPN Routes ..............................1538
Interaction of EVPN-VXLAN and EVPN-MPLS with Existing VPLS
Features ................................................................................................1539
Interaction of PBB-EVPN with Existing VPLS Features ........................1541
Interaction of EVPN-VXLAN and EVPN-MPLS with Existing VPRN
Features ................................................................................................1541
Routing Policies for BGP EVPN IP Prefixes..........................................1542
3HE 11970 AAAA TQZZA 01
15
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
5.50
5.51
5.51.1
5.51.1.1
5.51.1.2
5.51.1.3
5.51.1.4
16
5.51.2
5.51.2.1
5.51.2.2
5.51.3
5.51.3.1
5.51.3.2
5.52
5.52.1
5.52.1.1
5.52.1.2
5.52.1.3
5.52.1.4
5.52.1.5
5.52.2
5.52.2.1
5.52.2.2
5.52.2.3
5.52.2.4
5.52.2.5
MPLS Entropy Label and Hash Label ...................................................1545
Configuring an EVPN Service with CLI .................................................1547
EVPN-VXLAN Configuration Examples.................................................1547
Layer 2 PE Example .............................................................................1547
EVPN for VXLAN in R-VPLS Services Example ...................................1548
EVPN for VXLAN in EVPN Tunnel R-VPLS Services Example ............1550
EVPN for VXLAN in R-VPLS Services with IPv6 interfaces and
prefixes Example ...................................................................................1551
EVPN-MPLS Configuration Examples...................................................1552
EVPN All-active Multi-homing Example ................................................1552
EVPN Single-active Multi-homing Example ..........................................1555
PBB-EVPN Configuration Examples .....................................................1556
PBB-EVPN All-active Multi-homing Example .......................................1556
PBB-EVPN Single-Active Multi-Homing Example ................................1559
EVPN Command Reference..................................................................1563
Command Hierarchies...........................................................................1563
EVPN Configuration Commands ...........................................................1563
Show Commands ..................................................................................1569
Clear Commands...................................................................................1570
Debug Commands.................................................................................1570
Tools Commands ..................................................................................1570
Command Descriptions .........................................................................1572
EVPN Configuration Commands ...........................................................1572
Show Configuration Commands............................................................1633
Clear Commands...................................................................................1664
Debug Commands.................................................................................1666
Tools Commands ..................................................................................1668
6
Pseudowire Ports .....................................................................1677
6.1
6.2
6.3
6.4
6.4.1
6.4.2
6.4.2.1
6.4.2.2
6.4.2.3
6.4.3
6.4.4
6.4.4.1
6.4.5
6.4.6
In This Chapter ......................................................................................1677
Overview................................................................................................1677
PW-Port Bound to a Physical Port.........................................................1678
FPE-Based PW-Port..............................................................................1679
Cross-Connect Between the External PW and the FPE-Based PWPort ........................................................................................................1680
PXC-Based PW-Port — Building the Cross-Connect............................1682
Building the Internal Transport Tunnel ..................................................1682
Mapping the External PW to the PW-Port .............................................1683
Terminating the Service on PW-SAP ....................................................1684
FPE-Based PW-port Operational State .................................................1686
QoS .......................................................................................................1686
Preservation of Forwarding Class Across PXC .....................................1688
Statistics on the FPE based PW-Port....................................................1689
Intra-Chassis Redundancy Models for PXC Based PW-Port ................1689
7
Standards and Protocol Support ............................................1691
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
Getting Started
1 Getting Started
1.1 About This Guide
This guide describes Layer 2 service and EVPN functionality provided by Nokia’s
family of routers and presents examples to configure and implement various
protocols and services.
This guide is organized into functional chapters and provides concepts and
descriptions of the implementation flow, as well as Command Line Interface (CLI)
syntax and command usage.
The topics and commands described in this document apply to the:
• 7450 ESS
• 7750 SR
• 7950 XRS
Table 1 lists the available chassis types for each SR OS router.
Table 1
Supported SR OS Router Chassis Types
7450 ESS
7750 SR
• 7450 ESS-6/6v
• 7450 ESS-7/12 running in
standard mode (not mixedmode)
• 7450 ESS-7/12 running in
mixed-mode (not standard
mode)
• 7750 SR-a4/a8
• 7750 SR-c4/c12
• 7750 SR-1e/2e/3e
• 7750 SR-7/12
• 7750 SR-12e
7950 XRS
• 7950 XRS-16c
• 7950 XRS-20/40
For a list of unsupported features by platform and chassis, refer to the SR OS
R15.0.Rx Software Release Notes, part number 3HE 12060 000x TQZZA.
Command outputs shown in this guide are examples only; actual displays may differ
depending on supported functionality and user configuration.
Issue: 01
3HE 11970 AAAA TQZZA 01
17
Getting Started
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
Note: This guide generically covers Release 15.0 content and may contain some content
that will be released in later maintenance loads. Please refer to the SR OS R15.0.Rx
Software Release Notes, part number 3HE12060 000x TQZZA, for information on features
supported in each load of the Release 15.0 software.
1.1.1
Audience
This guide is intended for network administrators who are responsible for configuring
routers. It is assumed that the network administrators have an understanding of
networking principles and configurations. Concepts described in this guide include
the following:
• Virtual Leased Lines (VLL)
• Virtual Private LAN Service (VPLS)
• Provider Backbone Bridging (PBB)
• Ethernet VPN (EVPN)
18
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
2 VLL Services
2.1 In This Chapter
This chapter provides information about Virtual Leased Line (VLL) services and
implementation notes.
2.2 ATM VLL (Apipe) Services
This section provides information about the Apipe service and implementation notes.
This feature is supported on the 7450 ESS platform in mixed-mode.
2.2.1
ATM VLL For End-to-End ATM Service
ATM VLLs (Apipe) provide a point-to-point ATM service between users connected to
7450 ESS or 7750 SR nodes on an IP/MPLS network. Users are either directly
connected to a PE or through an ATM access network. In both cases, an ATM PVC
(for example, a virtual channel (VC) or a virtual path (VP)) is configured on the PE.
This feature supports local cross-connecting when users are attached to the same
PE node. VPI/VCI translation is supported in the ATM VLL.
PE1, PE2, and PE3 receive standard UNI/NNI cells on the ATM Service Access
Point (SAP) that are then encapsulated into a pseudo-wire packet using the N:1 cell
mode encapsulation or AAL5 SDU mode encapsulation according to RFC 4717,
Encapsulation Methods for Transport of ATM Over MPLS Networks. When using N:1
cell mode encapsulation, cell concatenation into a pseudo-wire packet is supported.
In this application, the setup of both VC and VP level connections are supported.
The ATM pseudo-wire is initiated using Targeted LDP (TLDP) signaling as specified
in RFC 4447, Pseudo-wire Setup and Maintenance using LDP. The SDP can be an
MPLS or a GRE type.
Figure 1 shows an example of ATM VLL for end-to-end ATM service.
Issue: 01
3HE 11970 AAAA TQZZA 01
19
VLL Services
Figure 1
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
ATM VLL for End-to-End ATM Service
APS Protected
Links
CE1
ATM
UNI
CE2
(ATM-MPLS
Network IWF)
ATM1
ATM
PW
7750 SR
ATM2
(ATM-MPLS
Network IWF)
7750 SR
ATM
UNI
ATM
UNI
PVC/SPVC
ATM
IP/MPLS
PE 1
ATM3
CE4
PE 2
ATM
PW
7750 SR
CE3
ATM
UNI
ATM Cells
ATM Cells
PE 3
ATM Cells
ATMoMPLS
MPLS
POS/GigE
ATM Cells
OSSG053
2.2.2
ATM Virtual Trunk Over IP/MPLS Packet-Switched
Network
For 7450 ESS or 7750 SR OS, ATM virtual trunk (VT) implements a transparent
trunking of user and control traffic between two ATM switches over an ATM pseudowire. Figure 2 depicts ATM 2 and ATM 3 switches that appear as if they are directly
connected over an ATM link. Control traffic includes PNNI signaling and routing
traffic.
Figure 2
VT Application Example
Virtual Trunks
On ATM Link
PSN Tunnel
N:1 ATM PWs
CE1
ATM/FR
UNI
ATM 1
7750 SR
(PE1)
ATM 2
ATM/PNNI
ATM Edge
7750 SR
(PE2)
ATM/PNNI
PW1
PW2
VT1
VT2
PE1
IP/MPLS
ATM 4
ATM 3
VT1
PE2
VT2
ATM Edge
CE2
ATM 5
OSSG054
20
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
The virtual trunk (VT) SAP on a PE is identified by a tuple (port, VPI-range) meaning
that all cells arriving on the specified port within the specified VPI range are fed into
a single ATM pseudo-wire for transport across the IP/MPLS network. Note that a
user can configure the whole ATM port as a VT and does not need to specify a VPI
range. No VPI/VCI translation is performed on ingress or egress. Cell order is
maintained within a VT. Note that, as a special case, the two ATM ports could be on
the same PE node.
By carrying all cells from all VPIs making up the VT in one pseudo-wire, a solution is
provided that is both robust, for example no black holes on some VPIs but not others,
as well as operationally efficient since the entire VT can be managed as a single
entity from the Network Manager (single point for configuration, status, alarms,
statistics, and so on).
ATM virtual trunks use PWE3 N:1 ATM cell mode encapsulation to provide a cellmode transport, supporting all AAL types, over the MPLS network. Cell
concatenation on a pseudo-wire packet is supported. The SDP can be of an MPLS
or a GRE type.
The ATM pseudo-wire is initiated using Targeted LDP (TLDP) signaling (defined in
RFC 4447, Pseudowire Setup and Maintenance using LDP). In this application, there
is no ATM signaling on the gateway nodes since both endpoints of the MPLS network
are configured by the network operator. ATM signaling between the ATM nodes is
passed transparently over the VT (along with user traffic) from one ATM port on a PE
to another ATM port on a remote (or the same) SR PE.
2.2.3
Traffic Management Support
Traffic management support is supported only on the 7750 SR.
2.2.3.1
Ingress Network Classification
Classification is based on the EXP value of the pseudo-wire label and EXP-to-FC
mapping is determined by the network ingress QoS policy.
Issue: 01
3HE 11970 AAAA TQZZA 01
21
VLL Services
2.2.3.2
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
Ingress Queuing and Shaping on the IOM
Each SAP of an ATM VLL has an associated single ingress service queue on the
IOM. The default QoS policy configures this queue to have CIR=0 and PIR=line rate.
Other QoS policies can be applied if they specify a single service queue. Applying a
non-default QoS policy allows the CIR/PIR of the incoming traffic to be controlled,
regardless of whether ATM policing is configured, and provides queuing and shaping
to smooth traffic flows on the ingress of the network.
2.2.3.3
Egress Queuing and Shaping on the IOM
Each SAP of an ATM VLL has a single associated egress service queue on the IOM.
The default QoS policy configures this queue to have CIR=0 and PIR=line rate. Other
QoS policies can be applied if they specify a single service queue. Applying a nondefault QoS policy allows the CIR/PIR of the outgoing traffic to be controlled,
regardless of whether ATM shaping is configured.
2.2.3.4
Egress Shaping/Scheduling
Each SAP of an ATM VLL has an egress ATM traffic descriptor associated with it.
The default traffic descriptor has service category UBR with zero MIR, resulting in
endpoints associated with this descriptor being scheduled at the lowest priority on
the ATM MDA. Egress traffic may be shaped or scheduled, depending on the
configuration of the egress ATM traffic descriptor associated with the SAP. Table 2
provides details of how the different service categories and shaping settings affect
egress transmission rates.
Shaping applies to CBR, rtVBR and nrtVBR service categories and results in cells
being transmitted in such a way as to satisfy a downstream ATM UPC function. In
particular, the transmission rate will be limited (in the case of CBR, there is a hard
limit of PIR, while rtVBR/nrtVBR will transmit at SIR with short (constrained by MBS)
bursts of up to PIR), and the inter-cell gap will also be controlled.
Service category UBR and rtVBR are scheduled on the WRR scheduler with the
configured rates (MIR for UBR+) determining the weight applied to the flow. Weights
are between 1 and 255 and are determined by a formula applied to the configured
rate. UBR flows (for example, those with no MIR) receive a weight of 1 and the
maximum weight of 255 is reached by flows with configured rates of around 8 Mbps.
Scheduling does not apply a limit to the transmission rate; the available port
bandwidth is shared out by the scheduler according to the weight, so if other flows
are quiescent, a given flow may burst up to port bandwidth.
22
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
Shaping and scheduling of egress ATM VLL traffic is performed entirely at the ATM
layer and is therefore not forwarding-class-aware. If the offered rate is greater than
can be transmitted towards the customer (either because the shaping rate limits
transmission or because the SAP does not receive sufficient servicing in the weighed
round-robin used for scheduled SAPs), the per-VC queue will back up and this will
trigger the congestion control mechanisms in the MDA queues or in the IOM service
egress queues associated with the SAP. For AAL5 SDU VLLs, these discards occur
at the AAL5 SDU level. For N-to-1 VLLs, these discards occur at the level of the cell
or a block of cells when cell concatenation is enabled.
Table 2
Behavior and Relative Priorities
Flow type
Transmission rate
Priority
shaped CBR
Limited to configured PIR
Strict priority over all other traffic
shaped rtVBR
Limited to configured SIR, but with bursts up to
PIR within MBS
Strict priority over all but shaped CBR
shaped nrtVBR
Limited to configured SIR, but with bursts up to
PIR within MBS
Strict priority over all scheduled traffic
scheduled
nrtVBR
Weighted share (according to SIR) of port
bandwidth remaining after shaped traffic has
been exhausted
In the same WRR scheduler as UBR+
and UBR
scheduled UBR+
Weighted share (according to MIR) of port
bandwidth remaining after shaped traffic has
been exhausted
In the same WRR scheduler as nrtVBR
and UBR
scheduled UBR
Weighted share (with weight of 1) of port
bandwidth remaining after shaped traffic has
been exhausted
In the same WRR scheduler as nrtVBR
and UBR+
2.3 Circuit Emulation Services (Cpipe)
Cpipe is supported for the 7450 ESS and 7750 SR only.
Issue: 01
3HE 11970 AAAA TQZZA 01
23
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
2.3.1
Mobile Infrastructure
Packet infrastructure is required within 2G, 2.5G and 3G mobile networks to handle
SMS messaging, web browsing and emerging applications such as streaming video,
gaming and video on demand. Within existing 2.5G and 3G mobile networks, ATM is
defined as the transport protocol. Within existing 2G networks, TDM is defined as the
transport protocol. Due to the relatively low bit rate of existing handsets, most cell
sites use 2-10 DS1s or E1s to transport traffic. When using ATM over multiple DS1/
E1 links, Inverse Multiplexing over ATM (IMA) is very effective for aggregating the
available bandwidth for maximum statistical gain and providing automatic resilience
in the case of a link failure. Also, multiple DS1s or E1s are required to transport the
2G voice traffic.
Typically, low cost devices are used at the many cell sites to transport multiple DS1
or E1 using ATM/IMA and TDM over an Ethernet/MPLS infrastructure. In Nokia
applications, the circuit emulation would currently be performed using the 7705 SAR.
This could be performed by DMXplore at the cell site. However, a large number of
cell sites aggregate into a single switching center. Book-ending 7705 SAR nodes
would require a very large number of systems at the switching center (Figure 3).
Therefore, a channelized OC3/STM1 solution is much more efficient at the switching
center. With a channelized OC3/STM1 CES CMA/MDA in the 7750 SR, Nokia can
provide a converged, flexible solution for IP/MPLS infrastructures for 2G/2.5G/3G
mobile networks supporting both the CES (by CES CMA/MDA) and ATM/IMA
transported traffic (by the ASAP MDA).
Figure 3
Mobile Infrastructure
Access
Hub
Core
(MTSO)
Node B BTS
BSC
Node B
CSR
CSR
Node B
M
S
C
PSTN
CS
MGW
BR
VoIP
Peers
IP/MPLS
Aggregation
Network
MAR
CEC
CEC
MSR
MCR
IP/MPLS
Core Network
SGSN
MCR
BTS
RNC
BR
GGSN
Data
Peers
BTS
OSSG184
24
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
Table 3
VLL Services
Mobile Infrastructure Definitions
Cellsite Backhaul Type
CSR Role
Transport Acronyms
Microwave
Circuit emulation
CSR: Cellsite Service Router
xDSL
ATM IMA termination into pseudo-wire
MAR: Mobile Aggregation Router
Fiber, dark or light
Ethernet VLL switching
MSR: Mobile Service Router
ATM, ATM IMA
IP/MPLS aggregation
CEC: Circuit Emulation Concentrator
Leased line
—
MCR: Mobile Core Router
—
—
BR: Border Router
2.3.2
Circuit Emulation Modes
Two modes of circuit emulation are supported, unstructured and structured.
Unstructured mode is supported for DS1 and E1 channels per RFC 4553, StructureAgnostic Time Division Multiplexing (TDM) over Packet (SAToP). Structured mode
is supported for n*64 kbps circuits as per RFC 5086, Structure-Aware Time Division
Multiplexed (TDM) Circuit Emulation Service over Packet Switched Network
(CESoPSN). In addition, DS1, E1 and n*64 kbps circuits are supported (per MEF8).
TDM circuits are optionally encapsulated in MPLS or Ethernet as per the referenced
standards in the following examples.
RFC 4553 (SAToP) MPLS PSN Encapsulation:
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
...
|
|
MPLS Label Stack
|
|
...
|
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|
SAToP Control Word
|
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|
OPTIONAL
|
+---+
|
|
+---+
|
Fixed RTP Header (see [RFC3550])
|
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|
Packetized TDM data (Payload)
|
|
...
|
|
...
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
CESoPSN Packet Format for an MPLS PSN:
Issue: 01
3HE 11970 AAAA TQZZA 01
25
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
...
|
|
MPLS Label Stack
|
|
...
|
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|
CESoPSN Control Word
|
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|
OPTIONAL
|
+---+
|
|
+---+
|
Fixed RTP Header (see [RFC3550])
|
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|
Packetized TDM data (Payload)
|
|
...
|
|
...
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MEF8 PSN Encapsulation:
0
26
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination MAC Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Destination MAC Address (cont)
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Source MAC Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Source MAC Address (cont) |
VLAN Ethertype (opt)
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|VLP|C|
VLAN ID (opt)
|
Ethertype
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
ECID (20 bits)
|
RES (set to 0x102) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RES(0)|L|R| M |FRG| Length
|
Sequence Number
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
opt|RTV|P|X| CC
|M|
PT
|
RTP Sequence Number
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
opt|
Timestamp
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
opt|
SSRC identifier
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
|
Adapted Payload
|
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Frame Check Sequence
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
2.3.3
2.3.3.1
VLL Services
Circuit Emulation Parameters
Circuit Emulation Modes
All channels on the CES CMA/MDA are supported as circuits to be emulated across
the packet network. Structure aware mode is supported for n*64 kbps channel
groups in DS1 and E1 carriers. Fragmentation is not supported for circuit emulation
packets (structured or unstructured).
For DS1 and E1 unstructured circuits, the framing can be set to unframed. When
channel group 1 is created on an unframed DS1 or E1, it is automatically configured
to contain all 24 or 32 channels respectively.
N*64 kbps circuit emulation supports basic and Channel Associated Signaling (CAS)
options for timeslots 1-31 (channels 2-32) on E1 carriers and channels 1-24 on DS1
carriers. CAS in-band is supported, therefore no separate pseudo-wire support for
CAS is provided. CAS option can be enabled or disabled for all channel groups on a
given DS1 or E1. If CAS operation is enabled, timeslot 16 (channel 17) cannot be
included in the channel group on E1 carriers. CCS operation is not supported.
2.3.3.2
Absolute Mode Option
For all circuit emulation channels except those with differential clock sources, RTP
headers in absolute mode can be optionally enabled (off by default). For circuit
emulation channels which use differential clock sources, this configuration is
blocked. All channel groups on a given DS1 or E1 can be configured for the same
mode of operation.
When enabled for absolute mode operation, an RTP header will be inserted. On
transmit, the CES IWF will insert an incrementing (by 1 for each packet) timestamp
into the packets. All other fields will be set to zero. The RTP header will be ignored
on receipt. This mode is enabled for interoperability purposes only for devices which
require an RTP header to be present.
Issue: 01
3HE 11970 AAAA TQZZA 01
27
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
2.3.3.3
Payload Size
For DS3, E3, DS1 and E1 circuit emulation, the payload size can be configurable in
number of octets. The default values for this parameter are shown in Table 4.
Unstructured payload sizes can be set to a multiple of 32 octets and minimally be 64
octets. TDM satellite supports only unstructured payloads.
Table 4
Unstructured Payload Defaults
TDM Circuit
Default Payload Size
DS1
192 octets
E1
256 octets
For n*64 kbps circuits, the number of octets or DS1/E1 frames to be included in the
TDM payload needs to be configurable in the range 4 to128 DS1/E1 frames in
increments of 1 or the payload size in octets. The default number of frames is shown
in the table below with associated packet sizes. For the number of 64 kbps channels
included (N), the following number of frames defaults apply for no CAS: N=1, 64
frames; 2<=N<= 4, 32 frames; 5<=N<= 15, 16 frames; N>=16, 8 frames.For CAS
circuits, the number of frames can be 24 for DS1 and 16 for E1 which yields a
payload size of N*24 octets for T1 and N*16 octets for E1. For CAS, the signaling
portion is an additional ((N+1)/2) bytes where N is the number of channels. The
additional signaling bytes are not included in the TDM payload size, although they
are included in the actual packet size shown in Table 5.
The full ABCD signaling value can be derived before the packet is sent. This occurs
for every 24 frames for DS1 ESF and every 16 frames for E1. Note that for DS1 SF,
ABAB signaling is actually sent as SF framing only supports AB signaling every 12
frames.
Table 5
Structured Number of Frames Defaults
Num
Timeslots
no CAS
numframes
default
Default
Payload
Minimum
Payload
Payload
(24
frames)
Packet
Size
Payload
(16
frames)
Packet
Size
1
64
64
40
24
25
16
17
2
32
64
64
48
49
32
33
3
32
96
96
72
74
48
50
4
32
128
128
96
98
64
66
28
DS1 CAS
3HE 11970 AAAA TQZZA 01
E1 CAS
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
Table 5
VLL Services
Structured Number of Frames Defaults (Continued)
Num
Timeslots
no CAS
numframes
default
Default
Payload
Minimum
Payload
Payload
(24
frames)
Packet
Size
Payload
(16
frames)
Packet
Size
5
16
80
80
120
123
80
83
6
16
96
96
144
147
96
99
7
16
112
112
168
172
112
116
8
16
128
128
192
196
128
132
9
16
144
144
216
221
144
149
10
16
160
160
240
245
160
165
11
16
176
176
264
270
176
182
12
16
192
192
288
294
192
198
13
16
208
208
312
319
208
215
14
16
224
224
336
343
224
231
15
16
240
240
360
368
240
248
16
8
128
128
384
392
256
264
17
8
136
136
408
417
272
281
18
8
144
144
432
441
288
297
19
8
152
152
456
466
304
314
20
8
160
160
480
490
320
330
21
8
168
168
504
515
336
347
22
8
176
176
528
539
352
363
23
8
184
184
552
564
368
380
24
8
192
192
576
588
384
396
25
8
200
200
NA
NA
400
413
26
8
208
208
NA
NA
416
429
27
8
216
216
NA
NA
432
446
28
8
224
224
NA
NA
448
462
29
8
232
232
NA
NA
464
479
Issue: 01
DS1 CAS
3HE 11970 AAAA TQZZA 01
E1 CAS
29
VLL Services
Table 5
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
Structured Number of Frames Defaults (Continued)
Num
Timeslots
no CAS
DS1 CAS
E1 CAS
numframes
default
Default
Payload
Minimum
Payload
Payload
(24
frames)
Packet
Size
Payload
(16
frames)
Packet
Size
30
8
240
240
NA
NA
480
495
31
8
248
248
NA
NA
NA
NA
Note: num-frames DS1 CAS are multiples of 24; num-frames E1 is a multiple of 16.
2.3.3.4
Jitter Buffer
For each circuit, the maximum receive jitter buffer are configurable. Playout from this
buffer starts when the buffer is 50% full to give an operational packet delay variance
(PDV) equal to 75% of the maximum buffer size. The default value for the jitter buffer
is nominally 5 ms. However, for lower speed N*64kbps circuits and CAS circuits, the
following default values are used to align with the default number of frames (and
resulting packetization delay) to allow at least two frames to be received before
starting to playout the buffer. The jitter buffer is at least four times the packetization
delay. The following default jitter buffer values for structured circuits apply:
Basic CES (DS1 & E1):
N=1, 32 ms
2<=N<= 4, 16 ms
5<=N<=15, 8 ms
N>=16, 5 ms
2.3.3.5
CES Circuit Operation
The circuit status can be tracked to be either up, loss of packets or administratively
down. Statistics are available for the number of in service seconds and the number
of out of service seconds when the circuit is administratively up.
30
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
Jitter buffer overrun and under-run counters are available by statistics and optionally
logged while the circuit is up. On overruns, excess packets are discarded and
counted. On under runs, all ones are sent for unstructured circuits. For structured
circuits, all ones or a user defined data pattern is sent based on configuration. Also,
if CAS is enabled, all ones or a user defined signaling pattern is sent based on
configuration.
For each CES circuit, alarms can be optionally disabled/enabled for stray packets,
malformed packets, packet loss, receive buffer overrun and remote packet loss. An
alarm is raised if the defect persists for 3 seconds, and cleared when defect no longer
persists for 10 seconds. These alarms are logged and trapped when enabled.
2.3.4
Services for Transporting CES Circuits
Each circuit can be optionally encapsulated in MPLS, Ethernet packets. Circuits
encapsulated in MPLS use circuit pipes (Cpipes) to connect to the far-end circuit.
Cpipes support either SAP-spoke SDP or SAP-SAP connections. Cpipes are
supported over MPLS and GRE tunnels. Cpipe’s default service MTU is set to 1514
bytes.
Circuits encapsulated in Ethernet can be selected as a SAP in Epipes. Circuits
encapsulated in Ethernet can be SAP-spoke SDP connections or Ethernet CEM SAP
to Ethernet SAP for all valid epipe SAPs. Circuits requiring CEM SAP — CEM SAP
connections use Cpipes. A local and remote EC-ID and far-end destination MAC
address can be configurable for each circuit. The CMA/MDA’s MAC address will be
used as the source MAC address for these circuits.
For all service types, there are deterministic PIR=CIR values with class=EF
parameters based on the circuit emulation parameters.
All circuit emulation services support the display of status of up, loss of packets
(LOP) or admin down. Also, any jitter buffer overruns or under runs are logged.
Non-stop services are supported for Cpipes and CES over Epipes.
2.3.5
Network Synchronization Considerations
Each OC-3/STM-1 port can be independently configured to be loop-timed or nodetimed. Each OC-3/STM-1 port can be configured to be a timing source for the node.
TDM satellites only support node-timed mode.
Issue: 01
3HE 11970 AAAA TQZZA 01
31
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
Each DS-1 or E-1 channel without CAS signaling enabled can be independently
configured to be loop-timed, node-timed, adaptive-timed or differential-timed. Each
DS-1 or E-1 channel with CAS signaling enabled can be independently configured to
be loop-timed or node-timed. Adaptive-timed and differential-timed are not supported
on DS-1 or E-1 channels with CAS signaling enabled. For the TDM satellite, each
DS1/E1 channel can be loop-timed, node-timed, or differential-timed.
A CES circuit’s adaptive recovered clock can be used a timing reference source for
the node (ref1 or ref2). This is required to distribute network timing to network
elements which only have packet connectivity to the network. One timing source on
the CMA/MDA can be monitored for timing integrity. Both timing sources can be
monitored if they are configured on separate CMA/MDAs while respecting the timing
subsystem slot requirements. If a CES circuit is being used for adaptive clock
recovery at the remote end (such that the local end is now an adaptive clock master),
it is recommended to set the DS-1/E-1 to be node-timed to prevent potential jitter
issues in the recovered adaptive clock at the remote device. This is not applicable to
TDM satellites.
For differential-timed circuits, the following timestamp frequencies are supported:
103.68 MHz (for recommended >100MHz operation), 77.76 MHz (for interoperability
with SONET/SDH based systems such as TSS-5) and 19.44 MHz (for Y.1413
compliance). TDM Satellite supports only 77.76 MHz.
Adaptive and differential timing recovery must comply with published jitter and
wander specifications (G.823, G.824 and G.8261) for traffic interfaces under typical
network conditions and for synchronous interfaces under specified packet network
delay, loss and delay variance (jitter) conditions. The packet network requirements
to meet the synchronous interface requirements are to be determined during the
testing phase.
On the 7450 ESS and 7750 SR CES CMA, a BITS port is also provided. The BITS
port can be used as one of the two timing reference sources in the system timing
subsystem. The operation of BITS ports configured as ref1 or ref2 is the same as
existing ports configured as ref1 and ref2 with all options supported. The operation
of the 7450 ESS or 7750 SR BITS source is unchanged and the BITS ports are not
available on the CES MDAs (only SF/CPM BITS are currently available).
2.3.6
Cpipe Payload
Figure 4 shows the format of the CESoPSN TDM payload (with and without CAS) for
packets carrying trunk-specific 64 kb/s service. In CESoPSN, the payload size is
dependent on the number of timeslots used. This is not applicable to TDM satellite
since only unstructured DS1/E1 is supported.
32
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
Figure 4
0
VLL Services
CESoPSN MPLS Encapsulation
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
•••
MPLS Label Stack
•••
CESoPSN Control Word
OPTIONAL
Fixed RTP Header (see [RFC 3550])
Packetized TDM data (Payload)
•••
•••
0985
2.4 Ethernet Pipe (Epipe) Services
This section provides information about the Epipe service and implementation notes.
2.4.1
Epipe Service Overview
An Epipe service is Nokia’s implementations of an Ethernet VLL based on the IETF
“Martini Drafts” (draft-martini-l2circuit-trans-mpls-08.txt and draft-martini-l2circuitencapmpls-04.txt) and the IETF Ethernet Pseudo-wire Draft (draft-so-pwe3ethernet-00.txt).
An Epipe service is a Layer 2 point-to-point service where the customer data is
encapsulated and transported across a service provider’s IP, MPLS or PBB VPLS
network. An Epipe service is completely transparent to the customer’s data and
protocols. The Epipe service does not perform any MAC learning. A local Epipe
service consists of two SAPs on the same node, whereas a distributed Epipe service
consists of two SAPs on different nodes. SDPs are not used in local Epipe services.
Issue: 01
3HE 11970 AAAA TQZZA 01
33
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
Each SAP configuration includes a specific port or channel on which service traffic
enters the router from the customer side (also called the access side). Each port is
configured with an encapsulation type. If a port is configured with an IEEE 802.1Q
(referred to as Dot1q) encapsulation, then a unique encapsulation value (ID) must be
specified.
Figure 5
Epipe/VLL Service
Customer 1
Customer 2
IP/MPLS Network
EPIPE (VLL) Service 1
Customer 1
Customer 2
EPIPE (VLL) Service 2
OSSG021
2.4.2
Epipe Service Pseudo-wire VLAN Tag Processing
Distributed Epipe services are connected using a pseudo-wire, which can be
provisioned statically or dynamically and is represented in the system as a spoke
SDP. The spoke SDP can be configured to process zero, one or two VLAN tags as
traffic is transmitted and received; see Table 6 and Table 7 for configuration details.
In the transmit direction, VLAN tags are added to the frame being sent. In the
received direction, VLAN tags are removed from the frame being received. This is
analogous to the SAP operations on a null, dot1q and QinQ SAP.
The system expects a symmetrical configuration with its peer; specifically, it expects
to remove the same number of VLAN tags from received traffic as it adds to
transmitted traffic. When removing VLAN tags from a spoke SDP, the system
attempts to remove the configured number of VLAN tags (see below for configuration
details). If fewer tags are found, the system removes the VLAN tags found and
forwards the resulting packet. As some of the related configuration parameters are
local and not communicated in the signaling plane, an asymmetrical behavior cannot
always be detected and so cannot be blocked. With an asymmetrical behavior,
protocol extractions will not necessarily function as they would with a symmetrical
configurations, thus resulting in an unexpected operation.
The VLAN tag processing is configured as follows on a spoke SDP in an Epipe
service:
34
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
• Zero VLAN tags processed—This requires the configuration of vc-type ether
under the spoke SDP, or in the related pw-template.
• One VLAN tag processed—This requires one of the following configurations:
− vc-type vlan under the spoke SDP or in the related pw-template
− vc-type ether and force-vlan-vc-forwarding under the spoke SDP or in
the related pw-template
• Two VLAN tags processed—This requires the configuration of force-qinq-vcforwarding under the spoke SDP or in the related pw-template.
The pw-template configuration provides support for BGP VPWS services.
The following restrictions apply to VLAN tag processing:
• The configuration of vc-type vlan and force-vlan-vc-forwarding is mutually
exclusive.
• force-qinq-vc-forwarding can be configured with the spoke SDP signaled as
either vc-type ether or vc-type vlan.
• The following are not supported with force-qinq-vc-forwarding configured
under the spoke SDP, or in the related pw-template:
− Multi-segment pseudo-wires.
− BGP VPWS routes are not accepted over an iBGP session.
− ETH-CFM MIPs and MEPs are not supported on dynamically signaled BGP
QinQ PWs.
Table 6 and Table 7 describe the VLAN tag processing with respect to the zero, one
and two VLAN tag configuration described above for the VLAN identifiers, Ether type,
ingress QoS classification (dot1p/DE) and QoS propagation to the egress (which can
be used for egress classification and/or to set the QoS information in the innermost
egress VLAN tag).
Table 6
Epipe Spoke SDP VLAN Tag Processing: Ingress
Ingress (received on
spoke SDP)
Zero VLAN tags
One VLAN tag
Two VLAN tags
VLAN identifiers
N/A
Ignored
Both inner and outer ignored
Ether type (to
determine the presence
of a VLAN tag)
N/A
0x8100 or value
configured under sdp
vlan-vc-etype
Both inner and outer VLAN
tags: 0x8100, or outer VLAN
tag value configured under sdp
vlan-vc-etype (inner VLAN tag
value must be 0x8100)
Ingress QoS (dot1p/
DE) classification
N/A
Ignored
Both inner and outer ignored
Issue: 01
3HE 11970 AAAA TQZZA 01
35
VLL Services
Table 6
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
Epipe Spoke SDP VLAN Tag Processing: Ingress (Continued)
Ingress (received on
spoke SDP)
Zero VLAN tags
One VLAN tag
Two VLAN tags
QoeE (dot1p/DE)
propagation to egress
Dot1p/DE= 0
Dot1p/DE taken from
received VLAN tag
Dot1p/DE taken from inner
received VLAN tag
Table 7
Epipe Spoke SDP VLAN Tag Processing: Egress
Egress (sent on mesh
or spoke SDP)
Zero VLAN tags
VLAN identifiers (set in
VLAN tags)
N/A
One VLAN tag
• The vlan-vc-tag value
configured in pwtemplate or under the
spoke SDP or
• Taken from the inner
tag received on a QinQ
SAP or QinQ spoke
SDP or
• Taken from the VLAN
tag received on a dot1q
SAP or spoke SDP
(with vc-type vlan or
force-vlan-vcforwarding) or
• Taken from the outer
tag received on a qtag.*
SAP or
• 0 if there is no service
delimiting VLAN tag at
the ingress SAP or
spoke SDP
Ether type (set in VLAN
tags)
36
N/A
0x8100 or value configured
under sdp vlan-vc-etype
3HE 11970 AAAA TQZZA 01
Two VLAN tags
Both inner and outer VLAN tag:
• The vlan-vc-tag value
configured in pwtemplate or under the
spoke SDP or
• Taken from the inner
tag received on a QinQ
SAP or QinQ spoke
SDP or
• Taken from the VLAN
tag received on a dot1q
SAP or spoke SDP
(with vc-type vlan or
force-vlan-vcforwarding) or
• Taken from the outer
tag received on a qtag.*
SAP or
• 0 if there is no service
delimiting VLAN tag at
the ingress SAP or
spoke SDP
Both inner and outer VLAN
tags: 0x8100, or outer VLAN
tag value configured under
sdp vlan-vc-etype (inner
VLAN tag value will be 0x8100)
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
Table 7
VLL Services
Epipe Spoke SDP VLAN Tag Processing: Egress (Continued)
Egress (sent on mesh
or spoke SDP)
Zero VLAN tags
One VLAN tag
Two VLAN tags
Egress QoS (dot1p/DE)
(set in VLAN tags)
N/A
Taken from the inner most
ingress service delimiting tag:
Both inner and outer dot1p/DE:
Taken from the innermost
ingress service delimiting tag:
• The inner tag received
on a QinQ SAP or QinQ
spoke SDP or
• Taken from the VLAN
tag received on a dot1q
SAP or spoke SDP
(with vc-type vlan or
force-vlan-vcforwarding) or
• Taken from the outer
tag received on a qtag.*
SAP or
• 0 if there is no service
delimiting VLAN tag at
the ingress SAP or
spoke SDP.
Note that neither the inner nor
outer dot1p/DE values can be
explicitly set.
• The inner tag received
on a QinQ SAP or QinQ
spoke SDP or
• Taken from the VLAN
tag received on a dot1q
SAP or spoke SDP
(with vc-type vlan or
force-vlan-vcforwarding) or
• Taken from the outer
tag received on a qtag.*
SAP or
• 0 if there is no service
delimiting VLAN tag at
the ingress SAP or
spoke SDP.
Note that neither the inner nor
outer dot1p/DE values can be
explicitly set.
Any non-service delimiting VLAN tags are forwarded transparently through the Epipe
service. SAP egress classification is possible on the outer most customer VLAN tag
received on a spoke SDP using the ethernet-ctag parameter in the associated SAP
egress QoS policy.
2.4.3
Epipe Up Operational State Configuration Option
By default, the operational state of the Epipe is tied to the state of the two
connections that comprise the Epipe. If either of the connections in the Epipe are
operationally down, the Epipe service that contains that connection will also be
operationally down. The operator does have the ability to configure a single SAP
within an Epipe not to affect the operational state of that Epipe using the optional
command ignore-oper-state. Within an Epipe, if a SAP that includes this optional
Issue: 01
3HE 11970 AAAA TQZZA 01
37
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
command becomes operationally down state, the operational state of the Epipe will
not transition to down. The operational state of the Epipe will remain up. This does
not change the fact that the SAP is down and no traffic will transit an operationally
down SAP. Removing and adding this command on the fly will evaluate the service's
operational state based on the SAPs and the addition or deletion of this command.
Service OAM (SOAM) designers may consider using this command if an UP MEP
configured on the operationally down SAP within an Epipe is required to receive and
process SOAM PDUs. When a service is operationally down, this is not possible. For
SOAM PDUs to continue to arrive on an UP, MEP configured on the failed SAP the
service must be operationally up. Consider the case where an UP MEP is placed on
a UNI-N or E-NNI and the UNI-C on E-NNI peer is shutdown in such a way that it
causes the SAP to enter an operational state Down.
Two connections must be configured within the Epipe, otherwise, the service will be
operationally down regardless of this command. The ignore-oper-state functionality
will only operate as intended when the Epipe has one ingress and one egress. This
command is not to be used for Epipe services with redundant connections that
provide alternate forwarding in case of failure, even though the CLI does not prevent
this configuration.
Support is available on Ethernet SAPs configured on ports or Ethernet SAPs
configured on LAG. However, it is not allowed on SAPs using LAG profiles or if the
SAP is configured on a LAG which has no ports.
2.4.4
Epipe with PBB
A pbb-tunnel may be linked to an Epipe to a B-VPLS. MAC switching and learning is
not required for the point-to-point service (all packets ingressing the SAP are PBB
encapsulated and forwarded to the PBB tunnel to the backbone destination MAC
address and all the packets ingressing the B-VPLS destined for the ISID are PBB deencapsulated and forwarded to the Epipe SAP. A fully specified backbone
destination address must be provisioned for each PBB Epipe instance to be used for
each incoming frame on the related I-SAP. If the backbone destination address is not
found in the B-VPLS FDB then packets may be flooded through the B-VPLSs
All B-VPLS constructs may be used including B-VPLS resiliency and OAM. Not all
generic Epipe commands are applicable when using a PBB tunnel.
38
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
2.4.5
VLL Services
Epipe over L2TPv3
The L2TPv3 feature provides a framework to transport Ethernet pseudo-wire
services over an IPv6-only network without MPLS. This architecture relies on the
abundance of address space in the IPv6 protocol to provide unique far-end and localend addressing that uniquely identify each tunnel and service binding.
L2TPv3 provides the capability of transporting multiple EPipes (up to 16K per
system), by binding multiple IPv6 addresses to each node and configuring one SDP
per Epipe.
As the IPv6 addressing uniqueness identifies the customer and service binding, the
L2TPv3 control plane is disabled in this mode.
L2TPv3 is supported on non-12e 7750 SR and 7450 ESS (mixed mode) and
7950 XRS platforms.
ETH-CFM is supported for OAM services.
Figure 6
L2TPv3 SDP Illustration
IPv6 Routing
No Service Visibility
PE1: 7750SR
EPIPE
SAP
SAP is the logical interface towards
the subscriber and includes L2
encapsulation info (S, C Tags)
P1
PE2: 7750SR
SDP
EPIPE refers to an Ethernet
pseudowire service type
Remote Endpoint:
Datacenter or PE
SDP
EPIPE
SAP
SDP is the router-to-router tunnel.
For L2TPv3 this is configured with:
• Unique IPv6 SA
• IPv6DA
• Unique tx and rx cookies
• Encapsulated into L2TPv3
EPIPE refers to an Ethernet
pseudowire service type
Ingress traffic is validated by DA, SA, and RX cookie
configuration. All three must match before traffic is
decapsulated and forwarded out egress interface
IPv6 SA: 2001:DB8:1238:40::FFFF:80
IPv6 DA: 2001:DB8:CAFE::60:2
TX-Cookie: <64-bit>
IPv6 SA: 2001:DB8:CAFE::60:2
IPv6 DA: 2001:DB8:1238:40::FFFF:80
RX-Cookie: <64-bit>
al_0201
2.4.6
Ethernet Interworking VLL
Figure 7 provides an example of an Ethernet interworking VLL. The Ethernet
interworking VLL provides a point-to-point Ethernet VLL service between FrameRelay-attached users, ATM attached users, and Ethernet-attached users across an
IP/MPLS packet switched network. It effectively provides ATM and FR bridged
encapsulation termination on the existing Epipe service of the 7750 SR.
Issue: 01
3HE 11970 AAAA TQZZA 01
39
VLL Services
Figure 7
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
Application of Ethernet Interworking VLL Example
APS Protected
Links
ATM Switching/
CE1 ATM/FR FRF.8.2 IWF
ATM1
UNI
ATM2
CE2
Ethernet-MPLS
Network IWF
Ethernet
PW
7750 SR
PVC/SPVC
7750 SR
IP/MPLS
ATM
PE 1
ATM3
FRF8.2
Interworking
7750 SR
PE 2
Ethernet
PW
Ethernet
(VLAN) UNI
CE4
Ethernet
(VLAN) UNI
CE3
ATM/FR
UNI
IP/IPX
RFC2684/RFC2427
B-PDU
AAL5 ATM
FR
PE 3
IP/IPX
RFC2684
B-PDU
AAL5 ATM
IP/IPX
Ethernet (VLAN)
EthoMPLS
MPLS
POS/GigE
IP/IPX
Ethernet (VLAN)
OSSG059
The following connectivity scenarios are supported:
• A Frame Relay or ATM user connected to a ATM network communicating with
a Ethernet user connected to a 7750 SR PE node on a IP/MPLS network.
• A Frame Relay or ATM user connected to 7750 SR PE node communicating
with an Ethernet user connected to a 7750 SR PE node on a IP/MPLS network.
This feature supports local cross-connecting when these users are attached to
the same 7750 SR PE node.
Users attach over an ATM UNI with RFC 2684, Multiprotocol Encapsulation over
ATM Adaptation Layer 5, tagged/untagged bridged Ethernet PDUs, a FR UNI using
RFC 2427, Multiprotocol Interconnect over Frame Relay, tagged/untagged bridged
Ethernet PDUs, or an Ethernet tagged/untagged UNI interface. However, the VCI/
VPI and the data-link control layer (DLCI) are the identifiers of the SAP in the case
of ATM and FR respectively and the received tags are transparent to the service and
are thus preserved.
The Ethernet pseudo-wire is established using Targeted LDP (TLDP) signaling and
can use the ether or vlan VC types on the SDP. The SDP can be either an MPLS or
GRE type.
40
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
2.4.7
VLL Services
VLL CAC
This feature is supported for the 7750 SR only and provides a method to
administratively account for the bandwidth used by VLL services inside an SDP
which consists of RSVP LSPs.
The service manager keeps track of the available bandwidth for each SDP. The SDP
available bandwidth is applied through a configured booking factor. An administrative
bandwidth value is assigned to the spoke SDP. When a VLL service is bound to an
SDP, the amount of bandwidth is subtracted from the adjusted available SDP
bandwidth. When the VLL service binding is deleted from the SDP, the amount of
bandwidth is added back into the adjusted SDP available bandwidth. If the total
adjusted SDP available bandwidth is overbooked when adding a VLL service, a
warning is issued and the binding is rejected.
This feature does not guarantee bandwidth to a VLL service as there is no change to
the datapath to enforce the bandwidth of an SDP by means such as shaping or
policing of constituent RSVP LSPs.
2.4.8
MC-Ring and VLL
To support redundant VLL access in ring configurations, the multi-chassis ring
feature is applicable to VLL SAPs. A conceptual drawing of the operation is shown
in Figure 8. The given CPE which is connected behind the ring node has access to
both BSA through the same VLAN provisioned in all ring nodes. There are two SAPs
(with the same VLAN) provisioned on both nodes.
If a closed ring status occurs, one of the BSAs becomes the master and it will signal
an active status bit on the corresponding VLL pseudo-wire. Similarly, the standby
BSA will signal a standby status. With this information, the remote node can choose
the correct path to reach the CPE. In case of a broken ring, the node that can reach
the ring node that the given CPE is connected to by RNCV check, will become master
and will signal corresponding status on its pseudo-wire.
The mapping of individual SAPs to the ring nodes is done statically through CLI
provisioning. In order to keep the convergence time to a minimum, MAC learning
must be disabled on the ring node so all CPE originated traffic is sent in both
directions. If the status is oper-down on the SAP on the standby BSA, that part of the
traffic will be blocked and not forwarded to the remote site.
Issue: 01
3HE 11970 AAAA TQZZA 01
41
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
Figure 8
MC-Ring in a Combination with VLL Service
CPE
CPE
sap-3
sap-3
BSA-3
BSA-3
sdp-2
sdp-1
Active
Master
BSA-1
sap-1
sdp-2
Standby
BSA-2
sdp-1
Standby
Standby
Standby
sap-2
Active
BSA-1
BSA-2
sap-1
Master
sap-2
RNCV
CPE
CPE
OSSG174
For further information about Multi-Chassis Ring Layer 2 (with ESM), refer to the
Advanced Configuration Guide.
2.5 Frame Relay VLL (Fpipe) Services
This section provides information about the Fpipe service and implementation notes.
Epipe is supported for the 7750 SR only.
2.5.1
Frame Relay VLL
Figure 9 shows an application of a Frame Relay VLL. The Frame Relay VLL (Fpipe)
provides a point-to-point Frame Relay service between users connected to 7750 SR
nodes on the IP/MPLS network. Users are connected to the 7750 SR.
42
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
Figure 9
VLL Services
Application of a Frame Relay VLL Example
CE2
(FR-MPLS
Network IWF)
CE1
FR
UNI
(FR-MPLS
Network IWF)
FR
PW
7750 SR
7750 SR
FR
UNI
FR
UNI
IP/MPLS
PE 1
PE 2
CE4
FR
PW
7750 SR
CE3
FR
UNI
IP/IPX/SNA
RFC2427
B-PDU/R-PDU
FR
PE 3
IP/IPX/SNA
RFC2427
B-PDU/R-PDU
FRoMPLS
MPLS
POS/GigE
IP/IPX/SNA
RFC2427
B-PDU/R-PDU
FR
OSSG056
PE nodes using Frame Relay PVCs. PE1, PE2, and PE3 receive a standard Q.922
Core frame on the Frame Relay SAP and encapsulate it into a pseudo-wire packet
according to the 1-to-1 Frame Relay encapsulation mode in RFC 4619,
Encapsulation Methods for Transport of Frame Relay Over MPLS Networks. The
7750 SR Frame Relay VLL feature supports local cross-connecting when the users
are attached to the same 7750 SR PE node.
The FR pseudo-wire is initiated using Targeted LDP (TLDP) signaling as specified in
RFC 4447, pseudo-wire Setup and Maintenance using LDP. The SDP can be an
MPLS or a GRE type.
2.5.2
Frame Relay-to-ATM Interworking (FRF.5) VLL
Figure 10 provides an example of a point-to-point Frame Relay service between
users where one user is connected to an existing ATM network, the other to a
7750 SR PE node on an IP/MPLS network.
Issue: 01
3HE 11970 AAAA TQZZA 01
43
VLL Services
Figure 10
CE1
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
Frame Relay-to-ATM Network Interworking (FRF.5) VLL
APS Protected
Links
(FR-ATM Network
Interworking- FRF.5)
FR
UNI
CE2
FRF.5
Interworking
ATM1
ATM2
7750 SR
7750 SR
FR
UNI
PVC/SPVC
ATM AAL5 SDU PW
ATM
IP/IPX/SNA
RFC2427
B-PDU/R-PDU
FR
IP/IPX/SNA
RFC2427
B-PDU/R-PDU
FR SSCS
AAL5 ATM
ATM3
PE 1
PE 2
IP/MPLS
IP/IPX/SNA
RFC2427
B-PDU/R-PDU
FR SSCS
AAL5 ATM
IP/IPX/SNA
RFC2427
B-PDU/R-PDU
ATMoMPLS
MPLS
POS/GigE
IP/IPX/SNA
RFC2427
B-PDU/R-PDU
FR
OSSG070
This VLL is realized using an ATM AAL5 SDU pseudo-wire between the 7750 SR SR
PE nodes. It is configured by adding a FR SAP to an Apipe service using vc-type atmsdu. The 7750 SR SR PE2 node performs an FRF.5 interworking function to
interwork the ingress and egress data paths in addition to the operations required in
an FR and an ATM VLL.
The pseudo-wire is initiated using Targeted LDP signaling as specified in draft-ietfpwe3-control-protocol-xx.txt. The SDP can be of an MPLS or a GRE type.
2.5.3
Traffic Management Support
2.5.3.1
Frame Relay Traffic Management
Traffic management of Frame Relay VLLs is supported for the 7750 SR only and is
achieved through the application of ingress and egress QoS policies to SAPs like
other Frame Relay SAPs. No queuing occurs on the MDA; all queuing, policing and
shaping occurs on the IOM and, as a result, traffic management is forwarding-classaware. Forwarding classes may be determined by inspecting the DSCP marking of
contained IP packets (for example) and this will determine both the queuing and the
EXP bit setting of packets on a Frame Relay VLL.
44
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
2.5.3.2
VLL Services
Ingress SAP Classification and Marking
Ingress SAP classification and marking is supported for the 7450 ESS and 7750 SR
only. DE=0 frames are subject to the CIR marking algorithm in the queue. Drop
preference for these packets will follow the state of the CIR bucket associated with
the ingress queue. The value is marked in the drop preference bit of the internal
header and into the DE bit in the Q.922 frame header. DE=1 frames are classified
into “out-of-profile” state and are not be overwritten by the CIR marking in the ingress
queue. The drop preference is set to high.
2.5.3.3
Egress Network EXP Marking
FC-to-EXP mapping is supported for the 7450 ESS and 7750 SR only and is as per
the Network Egress QoS policy. Marking of the EXP field in both label stacks is
performed.
2.5.3.4
Ingress Network Classification
Classification is supported for the 7450 ESS and 7750 SR only and is based on the
EXP value of the pseudo-wire label and EXP-to-FC mapping is as per Network
Ingress QoS policy.
2.6 IP Interworking VLL (Ipipe) Services
• IP Interworking VLL (Ipipe) Services
− Ipipe VLL
− IP Interworking VLL Datapath
− IPv6 Support on IP Interworking VLL
• Basic Configurations
• Common Configuration Tasks
− Configuring VLL Components
• Creating an Ipipe Service
• Service Management Tasks
Issue: 01
3HE 11970 AAAA TQZZA 01
45
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
2.6.1
Ipipe VLL
Figure 11 provides an example of IP connectivity between a host attached to a pointto-point access circuit (FR, ATM, PPP) with routed PDU IPv4 encapsulation and a
host attached to an Ethernet interface. Both hosts appear to be on the same LAN
segment. This feature is supported for the 7450 ESS and 7750 SR and enables
service interworking between different link layer technologies. A typical use of this
application is in a Layer 2 VPN when upgrading a hub site to Ethernet while keeping
the spoke sites with their existing Frame Relay or ATM IPv4 (7750 SR only) routed
encapsulation.
Figure 11
IP Interworking VLL (Ipipe)
SR-series
router
CE 1 [64.47.30.1/32]
FR SAP
1/1/1:100
ATM SAP
2/1/1:0/100
CE 3 [64.47.31.1/32]
IP PW
SR-series
router
IP/MPLS
PE 1
PE 2
CE 2 [64.47.30.2/32]
Ethernet/VLAN
SAP 1/1/1:1000
Ethernet VLAN
SAP 3/1/1:1001
CE 4 [64.47.31.2/32]
IPIPE_001
The ATM SAP is supported by the 7750 SR only. It carries the IPv4 packet using
RFC 2684, Multiprotocol Encapsulation over ATM Adaptation Layer 5, VC-Mux or
LLC/SNAP routed PDU encapsulation.
The Frame Relay SAP makes use of RFC 2427, Multiprotocol Interconnect over
Frame Relay, routed PDU encapsulation of an IPv4 packet. A PPP interface makes
use of RFC 1332, The PPP Internet Protocol Control Protocol (IPCP), PPP IPCP
encapsulation of an IPv4 packet. A Cisco HDLC SAP uses the routed IPv4
encapsulation. The pseudo-wire uses the IP Layer 2 transport pseudo-wire
encapsulation type.
Note that the Ipipe is a point-to-point Layer 2 service. All packets received on one
SAP of the Ipipe will be forwarded to the other SAP. No IP routing of customer
packets occurs.
46
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
2.6.2
VLL Services
IP Interworking VLL Datapath
In Figure 11, PE 2 is manually configured with both CE 1 and CE 2 IP addresses.
These are host addresses and are entered in /32 format. PE 2 maintains an ARP
cache context for each IP interworking VLL. PE 2 responds to ARP request
messages received on the Ethernet SAP. PE 2 responds with the Ethernet SAP
configured MAC address as a proxy for any ARP request for CE 1 IP address. PE 2
silently discards any ARP request message received on the Ethernet SAP for an
address other than that of CE 1. Likewise, PE 2 silently discards any ARP request
message with the source IP address other than that of CE 2. In all cases, PE 2 keeps
track of the association of IP to MAC addresses for ARP requests it receives over the
Ethernet SAP.
In order to forward unicast frames destined to CE 2, PE 2 needs to know CE 2 MAC
address. When the Ipipe SAP is first configured and administratively enabled, PE2
sends an ARP request message for CE 2 MAC address over the Ethernet SAP. Until
an ARP reply is received from CE2, providing CE2's MAC address, unicast IP
packets destined for CE2 will be discarded at PE2. IP broadcast and IP multicast
packets are sent on the Ethernet SAP using the broadcast or direct-mapped
multicast MAC address.
In order to forward unicast frames destined to CE 1, PE 2 validates the MAC
destination address of the received Ethernet frame. It should match that of the
Ethernet SAP. It then removes the Ethernet header and encapsulates the IP packet
directly into a pseudo-wire without a control word. PE 1 removes the pseudo-wire
encapsulation and forwards the IP packet over the Frame Relay SAP using RFC
2427, Multiprotocol Interconnect over Frame Relay, routed PDU encapsulation.
In order to forward unicast packets destined to CE1, PE2 validates the MAC
destination address of the received Ethernet frame. If the IP packet is unicast, the
MAC destination must match that of the Ethernet SAP. If the IP packet is multicast
or broadcast, the MAC destination address must be an appropriate multicast or
broadcast MAC address.
The other procedures are similar to the case of communication between CE 1 and
CE 2, except that the ATM SAP and the Ethernet SAP are cross-connected locally
and IP packets do not get sent over an SDP.
A PE does not flush the ARP cache unless the SAP goes administratively or
operationally down. The PE with the Ethernet SAP sends unsolicited ARP requests
to refresh the ARP cache every T seconds. ARP requests are staggered at an
increasing rate if no reply is received to the first unsolicited ARP request. The value
of T is configurable by user through the mac-refresh CLI command.
Issue: 01
3HE 11970 AAAA TQZZA 01
47
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
2.6.3
Extension to IP VLL for Discovery of Ethernet CE IP
Address
VLL services provide IP connectivity between a host attached to a point to point
access circuit (FR, ATM, PPP) with routed PDU encapsulation and a host attached
to an Ethernet interface. Both hosts appear to be on the same IP interface. This
feature is supported only for IPv4 payload.
In deployments where it is not practical for operators to obtain and configure their
customer CE address, the following behaviors apply:
• A service comes up without prior configuration of the CE address parameter
under both the SAP and the spoke SDP.
• Rely solely on received ARP messages from the Ethernet SAP attached CE
device to update the ARP cache with no further check of the validity of the
source IP address of the ARP request message and the IP address ARPed for.
• The LDP address list TLV to signal the learned CE IP address to the remote PE
is supported. This is to allow the PE with the FR SAP to respond to an invFR
ARP request message received from the FR attached CE device. Only Ethernet
SAP and FR SAP can learn the CE address through ARP and invFR ARP
respectively. The 7450 ESS and 7750 SR OS do not support invATM ARP on
an ATM interface.
2.6.3.1
VLL Ethernet SAP Procedures
The operator can enable the following CE address discovery procedures by
configuring the ce-address-discovery in the config>service>ipipe context.
• The service is brought up without the CE address parameter configured at either
the SAP or the spoke SDP.
• The operator cannot configure the ce-address parameter under the
config>service>ipipe>sap or config>service>ipipe>spoke-sdp context
when the ce-address-discovery in the config>service>ipipe context is
enabled. Conversely, the operator is not allowed to enable the ce-addressdiscovery option under the Ipipe service if it has a SAP and/or spoke SDP with
a user-entered ce-address parameter.
• While an ARP cache is empty, the PE does not forward unicast IP packets over
the Ethernet SAP but forwards multicast/broadcast packets.
48
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
• The PE waits for an ARP request from the CE to learn both IP and MAC
addresses of the CE. Both entries are added into the ARP cache. The PE
accepts any ARP request message received over Ethernet SAP and updates
the ARP cache IP and MAC entries with no further check of the source IP
address of the ARP request message or of the IP address being ARPed.
• The 7450 ESS, 7750 SR, and 7950 XRS routers will always reply to a received
ARP request message from the Ethernet SAP with the SAP MAC address and
a source IP address of the IP address being ARPed without any further check of
the latter.
• If the router received an address list TLV from the remote PE node with a valid
IP address of the CE attached to the remote PE, it not checks it against the IP
address being ARPed for when replying to an ARP request over the Ethernet
SAP.
• The ARP cache is flushed when the SAP bounces or when the operator
manually clears the ARP cache. This results in the clearing of the CE address
discovered on this SAP. However, when the SAP comes up initially or comes
back up from a failure, an unsolicited ARP request is not sent over the Ethernet
SAP.
• If the Ipipe service makes use of a spoke SDP, the router includes the address
list TLV in the interface parameters field of the pseudo-wire FEC TLV in the label
mapping message. The address list TLV contains the current value of the CE
address in the ARP cache. If no address was learned, then an address value of
0.0.0.0 must be used.
• If the remote PE included the address list TLV in the received label mapping
message, the local updates the remote PE node with the most current IP
address of the Ethernet CE using a T-LDP notification message with status TLV
status code is set to 0x0000002C and containing an LDP address list. The
notification message is sent each time an IP address different from the current
value in the ARP cache is learned. This includes when the ARP is flushed and
the CE address is reset to the value of 0.0.0.0.
• If the remote PE did not include the address list TLV in the received label
mapping message, the local router will not send any notification messages
containing the address list TLV during the lifetime of the IP pseudo-wire.
• If the operator disables the ce-address-discovery option under the VLL
service, service manager instructs LDP to withdraw the service label and the
service is shutdown. The pseudo-wire labels will only be signaled and the
service will come up if the operator re-enters the option again or enters manually
the ce-address parameter under SAP and spoke SDP.
Issue: 01
3HE 11970 AAAA TQZZA 01
49
VLL Services
2.6.3.1.1
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL FR SAP Procedures
The operator enables the following CE address dynamic learning procedures by
enabling the ce-address-discovery option under the VLL service on the 7450 ESS
or 7750 SR.
• Allow the service to come up without the CE address parameter configured at
both the SAP and spoke SDP. If one or both parameters are configured, they are
ignored.
• The operator cannot configure the ce-address parameter under SAP or spoke
SDP when the ce-address-discovery option under the VLL service is enabled.
Conversely, the operator is not allowed to enable the ce-address-discovery
option under the Ipipe service if it has a SAP and/or spoke SDP with a userentered ce-address parameter.
• If the router receives an invFR ARP request message over the FR SAP, it
updates the ARP cache with the FR CE address. It also replies with the IP
address of the CE attached to the remote PE if a valid address was advertised
in the address list TLV by this remote PE. Otherwise, the router updates the ARP
cache but does not reply to the invFR ARP.
• If the Ipipe service makes use of a spoke SDP, the router includes the address
list TLV in the interface parameters field of the pseudo-wire FEC TLV in the label
mapping message. The address list TLV contains the current value of the CE
address in the ARP cache. If no address was learned, then an address value of
0.0.0.0 is used.
• If the remote PE included the address list TLV in the received label mapping
message, the local router updates the remote PE node with the most current IP
address of the FR CE using a T-LDP status notification message containing an
LDP address list. The notification message is sent each time an IP address
different from the current value in the ARP cache is learned. This includes when
the ARP is flushed and the CE address is reset to the value of 0.0.0.00.
• If the remote PE did not include the address list TLV in the received label
mapping message, the local router does not send any notification messages
containing the address list TLV during the lifetime of the IP pseudo-wire.
2.6.3.1.2
VLL ATM SAP Procedures
The operator enables the following CE address dynamic learning procedures by
enabling the ce-address-discovery option under the VLL service on the 7750 SR.
• Allow the service to come up without the ce-address parameter configured at
both the SAP and spoke SDP. If one or both parameters are configured, they are
ignored.
50
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
• The operator is not allowed to configure the ce-address parameter under the
SAP or spoke SDP when the ce-address-discovery option under the VLL
service is enabled. Conversely, the operator is not allowed to enable the ceaddress-discovery option under the Ipipe service if it has a SAP and/or spoke
SDP with a user-entered ce-address parameter.
• If the router receives an invATM ARP request message over the ATM SAP,
silently discards it. The router does not support receiving or sending of an
invATM ARP message.
• If the Ipipe service makes use of a spoke SDP, the router includes the address
list TLV in the interface parameters field of the pseudo-wire FEC TLV in the label
mapping message. The address list TLV contains an address value of 0.0.0.0.
• If the remote PE included the address list TLV in the received label mapping
message, the local router will not make further updates to the address list TLV
to the remote PE node using a T-LDP status notification message since the
learned IP address of the ATM attached CE will never change away from the
value of 0.0.0.0.
• If the remote PE did not include the address list TLV in the received label
mapping message, the local router will not send any notification messages
containing the address list TLV during the lifetime of the IP pseudo-wire.
2.6.3.1.3
VLL PPP/IPCP and Cisco-HDLC SAP Procedures
The procedures are similar to the case of an ATM SAP. The remote CE address can
only be learned in the case of a PPP SAP but is not sent in the address list TLV to
the remote PE in both PPP and Cisco-HDLC SAP cases.
2.6.4
IPv6 Support on IP Interworking VLL
The 7450 ESS, 7750 SR, and 7950 XRS nodes support both the transport of IPv6
packets and the interworking of IPv6 Neighbor discovery/solicitation messages on an
IP Interworking VLL. IPv6 capability is enabled on an Ipipe using the ce-addressdiscovery ipv6 command in the CLI.
Issue: 01
3HE 11970 AAAA TQZZA 01
51
VLL Services
2.6.4.1
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
IPv6 Datapath Operation
The IPv6 uses ICMPv6 extensions to automatically resolve IP address and link
address associations. These are IP packets, as compared to ARP and invARP in
IPv4, which are separate protocols and not based on IP packets. Manual
configuration of IPv6 addresses is not supported on the IP Interworking VLL.
Each PE device intercepts ICMPv6 Neighbor Discovery (RFC 2461) packets,
whether received over the SAP or over the pseudo-wire, inspects them to learn IPv6
interface addresses and CE link-layer addresses, and modifies these packets as
required according to the SAP type, and then forwards them towards the original
destination. The PE is also capable of generating packets to interwork between CEs
by using IPv6 Neighbor Discovery, and CEs that use other neighbor discovery
protocols to bring up the link, for example, IPv6CP for PPP.
The PE device learns the IPv6 interface addresses for its directly-attached CE and
another IPv6 interface addresses for the far-end CE. The PE device also learns the
link-layer address of the local CE and uses it when forwarding traffic between the
local and far-end CEs. As with IPv4, the SAP accepts both unicast and multicast
packets. For unicast packets, the PE checks that the MAC address/IP addresses are
consistent with that in the ARP cache before forwarding; otherwise the packet is
silently discarded. Multicast packets are validated and forwarded. If more than one
IP address is received per MAC address in a neighbor discovery packet, or if multiple
neighbor discovery packets are received for a given MAC address, the currently
cached address is overwritten with the most recent value.
Figure 12 illustrates the data path operation for IPv6 on an IP Interworking VLL
between the Ethernet and PPP (IPv6CP) SAPs.
52
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
Figure 12
VLL Services
Data Path for Ethernet CE to PPP Attached CE
Neighbor
Solicitation
SRC IP@: CE2
SRC MAC: CE2
TGT IP@: CE3
PE1
Neighbor
Solicitation
SRC IP@: CE2
SRC MAC: CE2
TGT IP@: CE3
PE2
2
1
SAP comes up
using IPv6CP
3
store
Neighbor
4
Advertisement
SRC IP@: CE3 Link Local
SRC MAC: SAP
ARP Cache
TGT IP@: CE3
SR-series
router
CE1[2001:fc3:85a7::
812e:a70:7334/128]
CE3[2001:fc3:85a7::
812e:e70:7334/128]
SR-series
router
IP PW
FR SAP
1/1/1:100
PPP SAP
1/1/1:100
Neighbor
Advertisement
SRC IP@: CE3 Link Local
SRC MAC: PE2
TGT IP@: CE3
Eth VLAN SAP
1/1/1:1000
IP/MPLS
PE1
CE2[2001:fc3:85a7::
812e:a70:7335/128]
PE2
HDLC SAP
3/1/1:100
CE4[2001:fc3:85a7::
812e:e70:7335/128]
OSSG482-7450
With reference to neighbor discovery between Ethernet and PPP CEs in Figure 12,
the steps are as follows:
1. Ethernet attached CE2 sends a Neighbor Solicitation message towards PE2 in
order to begin the neighbor discovery process.
2. PE2 snoops this message, and the MAC address and IP address of CE2 is
stored in the ARP cache of PE2 before forwarding the Neighbor Solicitation on
the IP pseudo-wire to PE1.
3. PE1 snoops this message that arrives on the IP pseudo-wire and stores the IP
address of the remote CE2. Since CE3 is attached to a PPP SAP, which uses
IPv6CP to bring up the link, PE1 generates a neighbor advertisement message
and sends it on the ipipe towards PE2.
4. PE2 receives the neighbor advertisement on the Ipipe from PE1. It must replace
the layer 2 address in the neighbor advertisement message with the MAC
address of the SAP before forwarding to CE2.
Issue: 01
3HE 11970 AAAA TQZZA 01
53
VLL Services
2.6.4.2
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
IPv6 Stack Capability Signaling
The 7750 SR, 7450 ESS and 7950 XRS support IPv6 capability negotiation between
PEs at the ends of an IP interworking VLL. Stack capability negotiation is performed
if stack-capability-signaling is enabled in the CLI. Stack capability negotiation is
disabled by default. In which case, it must be assumed that the remote PE supports
both IPv4 and IPv6 transport over an ipipe.
A 'stack capability' sub-TLV is signaled by the two PEs using T-LDP so that they can
agree on which stacks they should be using.
By default, the IP pseudo-wire will always be capable of carrying IPv4 packets. Thus
this capability sub-TLV is used to indicate if other stacks need to be supported
concurrently with IPv4.
The stack capability sub-TLV is a part of the interface parameters of the pseudo-wire
FEC. This means any change to the stack support requires that the pseudo-wire be
torn down and re-signaled.
A PE that supports IPv6 on an IP pseudo-wire must signal the stack capability subTLV in the initial label mapping message for the pseudo-wire. For the 7750 SR,
7450 ESS and 7950 XRS, this means that the stack capability sub-TLV must be
included if both the stack-capability-signaling and ce-address-discovery ipv6
options are enabled under the VLL service.
In this release, if one PE of an IP interworking VLL supports IPv6, while the far endPE does not support IPv6 (or ce-address-discovery ipv6 is disabled), the pseudowire does not come up.
If a PE that supports IPv6 (that is, stack-capability-signaling ipv6 is enabled) has
already sent an initial label mapping message for the pseudo-wire, but does not
receive a ‘stack capability’ sub-TLV from the far-end PE in the initial label mapping
message, or one is received but it is set to a reserved value, then the PE assumes
that a configuration error has occurred. That is, if the remote PE did not include the
capability sub-TLV in the received Label Mapping message, or it does include the
sub-TLV but with the IPv6 bit cleared, and if stack-capability-signaling is enabled, the
local node with ce-address-discovery ipv6 enabled withdraws its pseudo-wire label
with the LDP status code “IP Address type mismatch”.
If a 7750 SR, 7450 ESS and 7950 XRS PE that supports IPv6 (that is, stackcapability-signaling ipv6 is enabled) has not yet sent a label mapping message for
the pseudo-wire and does not receive a ‘stack capability’ sub-TLV from the far-end
PE in the initial label mapping message, or one is received but it is set to a reserved
value, the PE assumes that a configuration error has occurred and does not send a
label mapping message of its own.
54
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
If the IPv6 stack is not supported by both PEs, or at least one of the PEs does support
IPv6 but does not have the ce-address-discovery ipv6 option selected in the CLI,
IPv6 packets received from the AC are discarded by the PE. IPv4 packets are always
supported.
If IPv6 stack support is implemented by both PEs, but the ce-address-discovery
ipv6 command was not enabled on both so that the IP pseudo-wire came up with
only IPv4 support, and one PE is later toggled to ce-address-discovery ipv6, then
that PE sends a label withdraw with the LDP status code meaning “Wrong IP
Address Type” (Status Code 0x0000004B9).
If the IPv6 stack is supported by both PEs, and therefore the pseudo-wire is
established with IPv6 capability at both PEs, but the ce-address-discovery ipv6
command on one PE is later toggled to no ce-address-discovery ipv6 so that a PE
ceases to support the IPv6 stack, then that PE sends a label withdraw with the LDP
status code meaning “Wrong IP Address Type”.
2.7 Services Configuration for MPLS-TP
MPLS-TP PWs are supported in epipe, apipe and cpipe VLLs and epipe spoke
termination on IES/VPRN and VPLS, iVPLS and B-VPLS on the 7450 ESS and
7750 SR only.
This section describes how SDPs and spoke SDP are used with MPLS-TP LSPs and
static pseudo-wires with MPLS-TP OAM. It also describes how to conduct test
service throughput for PWs, using lock instruct messages and loopback
configuration.
2.7.1
MPLS-TP SDPs
Only MPLS SDPs are supported.
An SDP used for MPLS-TP supports the configuration of an MPLS-TP identifier as
the far end address as an alternative to an IP address. IP addresses are used if IP/
MPLS LSPs are used by the SDP, or if MPLS-TP tunnels are identified by IPv4
source / destination addresses. MPLS-TP node identifiers are used if MPLS-TP
tunnels are used.
Only static SDPs with signaling off support MPLS-TP spoke SDPs.
The following CLI shows the MPLS-TP options:
Issue: 01
3HE 11970 AAAA TQZZA 01
55
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
config
service
sdp 10 [mpls | GRE | [ldp-enabled] [create]
signaling <off | on>
[no] lsp <xyz>
[no] accounting-policy <policy-id>
[no] adv-mtu-override
[no] booking-factor <percentage>
[no] class-forwarding
[no] collect-stats
[no] description <description-string>
[no] far-end <ip-address> | [node-id
{<ip-address> | <0…4,294,967,295>} [global-id <global-id>]]
[no] tunnel-far-end <ip-address>
[no] keep-alive
[no] mixed-lsp-mode
[no] metric <metric>
[no] network-domain <network-domain-name>
[no] path-mtu <mtu>
[no] pbb-etype <ethertype>
[no] vlan-vc-etype <ethertype>
[no] shutdown
The far-end node-id ip-address global-id global-id command is used to associate
an SDP far end with an MPLS-TP tunnel whose far end address is an MPLS-TP node
ID. If the SDP is associated with an RSVP-TE LSP, then the far-end must be a
routable IPv4 address.
The system accepts the node-id being entered in either 4-octet IP address format
<a.b.c.d> or unsigned integer format.
The SDP far-end refers to an MPLS-TP node-id/global-id only if:
• delivery type is MPLS
• signaling is off
• keep-alive is disabled
• mixed-lsp-mode is disabled
• adv-mtu-override is disabled
An LSP can only be allowed to be configured if the far-end information matches the
lsp far-end information (whether MPLS-TP or RSVP).
• Only one LSP is allowed if the far-end is an MPLS-TP node-id/global-id
• MPLS-TP or RSVP-TE LSPs are supported. However, note that LDP and BG
LSPs are not blocked in CLI.
Signaling LDP or BGP is blocked if:
• far-end node-id/global-id is configured
• control-channel-status is enabled on any spoke (or mate vc-switched spoke)
56
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
• pw-path-id is configured on any spoke (or mate vc-switched spoke)
• if IES/VPRN interface spoke control-word is enabled
The following commands are blocked if a far-end node-id/global-id is configured:
• class-forwarding
• tunnel-far-end
• mixed-lsp-mode
• keep-alive
• ldp or bgp-tunnel
• adv-mtu-override
2.7.2
VLL Spoke SDP Configuration
The system can be a T-PE or and S-PE for a pseudo-wire (a spoke SDP) supporting
MPLS-TP OAM. MPLS-TP related commands are applicable to spoke SDPs
configured under all services supported by MPLS-TP pseudo-wires. All commands
and functions that are applicable to spoke SDPs are supported, except for those that
explicitly depend on an LDP session on the SDP or as stated below. Likewise, all
existing functions on a given service SAP are supported if the spoke SDP that it is
mated to is MPLS-TP.
vc-switching is supported.
The following describes how to configure MPLS-TP on an Epipe VLL. However, a
similar configuration applies to other VLL types.
A spoke SDP bound to an SDP with the mpls-tp keyword cannot be no shutdown
unless the ingress label, the egress label, the control word, and the pw-path-id are
configured.
config
service
epipe
[no] spoke-sdp sdp-id[:vc-id]
[no] hash-label
[no]standby-signaling-slave
[no] spoke-sdp sdp-id[:vc-id] [vc-type {ether|vlan}]
[create] [vc-switching] [no-endpoint | {endpoint [icb]}]
egress
vc-label <out-label>
ingress
vc-label <in-label>
control-word
bandwidth <bandwidth>
Issue: 01
3HE 11970 AAAA TQZZA 01
57
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
[no] pw-path-id
agi <agi>
saii-type2 <global-id:node-id:ac-id>
taii-type2 <global-id:node-id:ac-id>
exit
[no] control-channel-status
[no] refresh-timer <value>
request-timer <request-timer-secs> retry-timer <retry-timer-secs> timeoutmultiplier <multiplier>
no request-timer
[no] acknowledgment
[no] shutdown
exit
The pw-path-id context is used to configure the end-to-end identifiers for an MS-PW.
These may not coincide with those for the local node if the configuration is at an SPE. The saii and taii are consistent with the source and destination of a label
mapping message for a signaled PW.
The control-channel-status command enables static pseudo-wire status signaling.
This is valid for any spoke SDP where signaling none is configured on the SDP (for
example, where T-LDP signaling is not in use). The refresh timer is specified in
seconds, from 10-65535, with a default of 0 (off). This value can only be changed if
control-channel-status is shutdown. Commands that rely on PW status signaling
are allowed if control-channel-status is configured for a spoke SDP bound to an SDP
with signaling off, but the system will use control channel status signaling rather than
T-LDP status signaling. The ability to configure control channel status signaling on a
given spoke SDP is determined by the credit based algorithm described earlier.
Control-channel-status for a particular pseudo-wire only counts against the credit
based algorithm if it is in a no shutdown state and has a non-zero refresh timer and
a non-zero request timer.
Note that a shutdown of a service will result in the static PW status bits for the
corresponding PW being set.
The spoke SDP is held down unless the pw-path-id is complete.
The system will accept the node-id of the pw-path-id saii or taii being entered in either
4-octet IP address format <a.b.c.d> or unsigned integer format.
The control-word must be enabled to use MPLS-TP on a spoke SDP.
The optional acknowledgment to a static pw status message is enabled using the
acknowledgment command. The default is no acknowledgment.
Only static pw to static pw switching is supported for MPLS-TP. Therefore, the vcswitching command is mutually exclusive with the configuration of the MPLS-TP
parameters if the mate PW is not configured for an SDP with signaling off. However,
vc-switching is supported if the mate SDP has signaling off.
58
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
The pw-path-id is only configurable if all of the following are true:
• in network mode D
• sdp signaling is off
• control-word is enabled (control-word is disabled by default)
• on service type epipe, vpls, cpipe, or IES/VPRN interface
• mate sdp signaling is off for vc-switched services
• An MPLS-TP node-id/global-id is configured under the
config>router>mpls>mpls-tp context. This is required for OAM to provide a
reply address.
In the vc-switching case, if configured on a mate spoke SDP, then the TAII of the
spoke SDP must match the SAII of its mate, and SAII of spoke SDP has to match the
TAII of its mate.
A control-channel-status no shutdown is allowed only if all of the following are true:
• in network-mode D
• sdp signaling is off
• control-word is enabled (control-word by default is disabled)
• the service type is epipe, apipe, vpls, cpipe, or IES/VPRN interface
• mate sdp signaling is off (in vc-switched services)
• pw-status-signaling is enabled (see below)
• pw-path-id is configured for this spoke.
The hash-label option is only configurable if SDP far-end is not node-id/global-id.
The control channel status request mechanism is enabled when the request-timer
<timer> parameter is non-zero. When enabled, this overrides the normal RFCcompliant refresh timer behavior. The refresh timer value in the status packet defined
in RFC 6478 is always set to zero. The refresh-timer in the sending node is taken
from the request-timer <timer1> timer. The two mechanisms are not compatible with
each other. One node sends a request timer while the other is configured for refresh
timer. In a given node, the request timer can only be configured with both
acknowledgment and refresh timers disabled.
Once configured, the procedures below are used instead of the RFC 6478
procedures when a PW status changes.
The CLI commands to configure control channel status requests are shown, below:
[no] control-channel-status
[no] refresh-timer <value> //0,10-65535, default:0
[no] request-timer <timer1> retry-timer <timer2>
Issue: 01
3HE 11970 AAAA TQZZA 01
59
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
[timeout-multiplier <value>]
[no] shutdown
exit
request-timer <timer1>: 0, 10-65535, defaults: 0.
• This parameter determines the interval at which PW status messages, including
a reliable delivery TLV, with the “request” bit set (see below) are sent. This
cannot be enabled if refresh-timer not equal to zero (0).
retry-timer <timer2>: 3-60s
• This parameter determines the timeout interval if no response to a PW status is
received. This defaults to zero (0) when no retry-timer.
timeout-multiplier <value> - 3-15.
• If a requesting node does not hear back after retry-timer times multiplier, then it
must assume that the peer is down. This defaults to zero (0) when no retry-timer.
2.7.2.1
Epipe VLL Spoke SDP Termination on IES, VPRN and VPLS
All existing commands (except for those explicitly specified below) are supported for
spoke SDP termination on IES, VPRN and VPLS (VPLS, iVPLS and bVPLS and
routed VPLS) services. In addition, the MPLS-TP commands listed above are
supported. The syntax and default values, and functional behavior of these
commands is the same as for Epipe VLLs, as specified above.
In addition, the PW Control Word is supported on spoke SDP termination on IES/
VPRN interfaces for pseudo-wires of type “Ether” with statically assigned labels
(signaling off) for spoke SDPs configured with MPLS-TP Identifiers.
The following CLI commands under spoke SDP are blocked for spoke SDPs with
statically assigned labels (and the SDP has signaling off) and MPLS-TP identifiers:
• no status-signaling – This command causes the spoke SDP to fall back to
using PW label withdrawal as a status signaling method. However, T-LDP is not
supported on MPLS-TP SDPs. Control channel status signaling should always
be used for signaling PW status. Note that since active/standby dual-homing into
a routed VPLS requires the use of T-LDP label withdrawal as the method for
status signaling, active/standby dual-homing into routed VPLS is not supported
if the spoke SDPs are MPLS-TP.
• propagate-mac-flush – This command requires the ability to receive MAC
Flush messages using T-LDP signaling and is blocked.
60
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
2.7.3
VLL Services
Configuring MPLS-TP Lock Instruct and Loopback
MPLS-TP supports lock instruct and loopback for PWs.
2.7.3.1
MPLS-TP PW Lock Instruct and Loopback Overview
The lock instruct and loopback capability for MPLS-TP PWs includes the ability to:
• administratively lock a spoke SDP with MPLS-TP identifiers
• divert traffic to and from an external device connected to a SAP
• create a data path loopback on the corresponding PW at a downstream S-PE or
T-PE that was not originally bound to the spoke SDP being tested
• forward test traffic from an external test generator into an administratively locked
PW, while simultaneously blocking the forwarding of user service traffic
MPLS-TP provides the ability to conduct test service throughput for PWs, using lock
instruct messages and loopback configuration. To conduct a service throughput test,
you can apply an administrative lock at each end of the PW. This creates a test
service, that contains the SAP connected to the external device. Lock request
messaging is not supported. You can also configure a MEP to send a lock instruct
message to the far-end MEP. The lock instruct message is carried in a G-ACh on
Channel 0x0026. A lock can be applied using the CLI or NMS. The forwarding state
of the PW can be either active or standby.
After locking a PW, you can put it into loopback mode (for two way tests) so the
ingress data path in the forward direction is cross connected to the egress data path
in the reverse direction of the PW. This is accomplished by configuring the source
MEP to send a loopback request to an intermediate MIP or MEP. A PW loopback is
created at the PW level, so everything under the PW label is looped back. This
distinguishes a PW loopback from a service loopback, where only the native service
packets are looped back. The loopback is also configured through CLI or NMS.
The following MPLS-TP lock instruct and loopback functionality is supported:
• An MPLS-TP loopback can be created for an Epipe, Cpipe or Apipe VLL
• Test traffic can be inserted at an epipe, cpipe or apipe VLL endpoint or at an
Epipe spoke-sdp termination on a VPLS interface
Issue: 01
3HE 11970 AAAA TQZZA 01
61
VLL Services
2.7.3.2
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
Lock PW End-Point Model
You can administratively lock a spoke SDP by locking the host service using the
admin-lock parameter of the tools command. The following conditions and
constraints apply:
• Both ends of a PW or MS-PW represented by a spoke SDP must be
administratively locked.
• Test traffic can be injected into the spoke SDP using a SAP defined within a test
service. The test service must be identified in the tools command at one end of
the locked PW.
• All traffic is forwarded to and from the test SAP defined in the test service, which
must be of a type that is compatible with the spoke SDP.
• Traffic to and from a non-test-SAP is dropped. If no test SAP is defined all traffic
received on the spoke SDP is dropped, and all traffic received on the paired SAP
is also dropped.
• If a spoke SDP is administratively locked, it is treated as operationally down. If
a VLL SAP is paired with a spoke SDP that is administratively locked, the SAP
OAM treats this as if the spoke SDP is operationally down.
• If a VPLS interface is paired to a spoke SDP that is administratively locked, the
L2 interface is taken down locally.
• Control-channel-status must be shutdown prior to administratively locking a
spoke SDP.
2.7.3.3
PW Redundancy and Lock Instruct and Loopback
It is possible to apply an administrative lock and loopback to one or more spoke
SDPs within a redundant set. That is, it is possible to move a spoke SDP from an
existing endpoint to a test service. When an administrative lock is applied to a spoke
SDP, it becomes operationally down and cannot send or receive traffic from the
normal service SAP or spoke interface. If the lock is applied to all the spoke SDPs in
a service, then all the spoke SDPs will become operationally down.
2.7.3.4
Configuring a Test SAP for an MPLS-TP PW
A test SAP is configured under a unique test service type. This looks similar to a
normal service context, but will normally only contain a SAP configuration.
config
service
62
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
epipe <service-id> [test][create]
[no] sap <sap-id>
[no] shutdown
[no] shutdown
config
service
apipe <service-id> [vc-type {atm-vcc | atm-sdu | atm-vpc | atm-cell}
[test][create]
[no] sap <sap-id>
[no] shutdown
[no] shutdown
config
service
cpipe <service-id> [vc-type {satop-e1 | satop-t1 | cesopsn | cesopsncas}
[test][create]
[no] sap <sap-id>
[no] shutdown
[no] shutdown
You can define test SAPs appropriate to any service or PW type supported by MPLSTP including an Apipe, Cpipe or Epipe. The following test SAP types are supported:
• Ethernet NULL, 1q, Q-in-Q
• ATM VC, VP, VT and so on
• TDM E1, E3, DS0, DS3 and so on
The following constraints and conditions apply:
• Up to a maximum a 16 test services can be configured per system.
• It is possible to configure access ingress and access egress QoS policies on a
test SAP, as well as any other applicable SAP-specific commands and
overrides.
• Vc-switching and spoke SDP are blocked for services configured under the test
context.
• The test keyword is mutually exclusive with vc-switching and customer.
• Valid commands under a compatible test service context do not need to be
blocked just because the service is a test service.
2.7.3.5
Configuring an Administrative Lock
An administrative lock is configured on a spoke SDP using the admin-lock option of
the tools perform command, as follows:
tools
perform
service-id <svc-id>
admin-lock
Issue: 01
3HE 11970 AAAA TQZZA 01
63
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
pw
sdp <sdp-id> admin-lock [test-svc-id <id>]
The following conditions and constraints apply for configuring an administrative lock:
• Can be configured either on a spoke SDP that is bound to a SAP, another spoke
SDP or a VPLS interface.
• Is only allowed if a PW path ID is defined (for example, for static PWs with
MPLS-TP identifiers).
• Cannot be configured on spoke SDPs that are an ICB or if the vc-switching
keyword is present.
• The control-channel-status must be shutdown. The operator should also
shutdown control-channel-status on spoke SDPs belonging to an MS-PW at an
S-PE whose far ends are administratively locked at its T-PEs. This should be
enforced throughout the network management if using the Service Access
Manager.
• When enabled, all traffic on the spoke SDP is sent to and from a paired SAP that
has the test keyword present, if such a SAP exists in the X endpoint. Otherwise
all traffic to and from the paired SAP is dropped.
• Can be configured at a spoke SDP that is bound to a VLL SAP or a VPLS
interface.
• The test-svc-id parameter refers to the test service that should be used to inject
test traffic into the service. The test service must be of a compatible type to the
existing spoke SDP under test (see Table 8).
• If the test-svc-id parameter is not configured on an admin-locked spoke SDP,
then user traffic is simply blocked on the spoke SDP.
The service manager should treat an administrative lock as a fault from the
perspective of a paired SAP that is not a test SAP. This will cause the appropriate
SAP OAM fault indication.
Table 8 illustrates the mapping between supported real services and their
corresponding test services.
Table 8
64
Mapping of Real Services to Test Service Types
Service
Test Service
CPIPE
CPIPE
EPIPE
EPIPE
APIPE
APIPE
VPLS
EPIPE
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
Table 8
2.7.3.6
VLL Services
Mapping of Real Services to Test Service Types (Continued)
Service
Test Service
PBB VPLS
EPIPE
Configuring a Loopback
If a loopback is configured on a spoke SDP, then all traffic on the ingress direction of
the spoke-sdp and associated with the ingress vc-label is forwarded to the egress
direction of the spoke SDP. A loopback may be configured at either a T-PE or an SPE. Note that it is recommended that you configure an administrative lock before
configuring the loopback on a spoke SDP. This is enforced by the NMS.
A data path loopback is configured using a tools perform command, as follows:
tools
perform
service-id <svc-id>
loopback
pw
sdp <sdp-id>:<vc-id> {start | stop}
The following constraints and conditions apply for PW loopback configuration:
• The spoke SDP cannot be an ICB or be bound to a VPLS interface.
• A PW path ID must be configured, that is, the spoke SDP must be static and use
MPLS-TP identifiers.
• The spoke SDP must be bound to a VLL mate SAP or another spoke SDP that
is not an ICB.
• The control-channel-status must be shutdown.
• The following is disabled on a spoke SDP for which a loopback is configured:
− Filters
− PW shaping
• Only network port QoS is supported.
Issue: 01
3HE 11970 AAAA TQZZA 01
65
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
2.8 VCCV BFD support for VLL, Spoke SDP
Termination on IES and VPRN, and VPLS
Services
VCCV BFD is supported on the 7450 ESS and 7750 SR only.
2.8.1
VCCV BFD Support
The SR OS supports RFC 5885, which specifies a method for carrying BFD in a
pseudo-wire-associated channel. This enables BFD to monitor the pseudo-wire
between its terminating PEs, regardless of how many P routers or switching PEs the
pseudo-wire may traverse. This makes it possible for faults that are local to individual
pseudo-wires to be detected, whether or not they also affect forwarding for other
pseudo-wires, LSPs or IP packets. VCCV BFD is ideal for monitoring specific highvalue services, where detecting forwarding failures (and potentially restoring from
them) in the minimal amount of time is critical.
VCCV BFD is supported on VLL services using T-LDP spoke-SDPs or BGP VPWS.
It is supported for Apipe, Cpipe, Epipe, Fpipe, and Ipipe VLL services.
VCCV BFD is supported on IES/VPRN services with T-LDP spoke -SDP termination
(for Epipes and Ipipes).
VCCV BFD is supported on LDP- and BGP-signaled pseudo-wires, and on pseudowires with statically configured labels, whether signaling is off or on for the SDP.
VCCV BFD is not supported on MPLS-TP pseudo-wires
VCCV BFD is supported on VPLS services (both spoke SDPs and mesh SDPs).
VCCV BFD is configured by:
• configuring generic BFD session parameters in a BFD template.
• applying the BFD template to a spoke SDP or pseudo-wire-template binding,
using the bfd-template template_name command.
• enabling the template on that spoke SDP, mesh SDP or pseudo-wire-template
binding using the bfd-enable command.
66
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
2.8.2
VLL Services
VCCV BFD Encapsulation on a Pseudo-wire
The SR OS supports IP/UDP encapsulation for BFD. With this encapsulation type,
the UDP headers are included on the BFD packet. IP/UDP encapsulation is
supported for pseudo-wires that use router alert (VCCV Type 2), and for pseudowires with a control word (VCCV Type 1). In the control word case, the IPv4 channel
(channel type 0x0021) is used. On the node, the destination IPv4 address is fixed at
127.0.0.1 and the source address is 127.0.0.2.
VCCV BFD sessions run end-to-end on a switched pseudo-wire. They do not
terminate on an intermediate S-PE; therefore, the TTL of the pseudo-wire label on
VCCV BFD packets is always set to 255 to ensure that the packets reach the far-end
T-PE of an MS-PW.
2.8.3
BFD Session Operation
BFD packets flow along the full length of a PW, from T-PE to T-PE. Since they are
not intercepted at an S-PE, single-hop initialization procedures are used.
A single BFD session exists per pseudo-wire.
BFD runs in asynchronous mode.
BFD operates as a simple connectivity check on a pseudo-wire. The BFD session
state is reflected in the MIBs and in the show>service id>sdp>vccv-bfd session
command. In this sense, BFD operates in a similar manner to other proactive OAM
tools, such as SAA with VCCV Ping. BFD is not used to change the operation state
of the pseudo-wire or to modify pseudo-wire redundancy. Furthermore, mapping the
BFD state to SAP OAM is not supported.
VCCV BFD runs in software with a minimum supported timer interval of 1s.
Note that BFD is only used for fault detection. While RFC 5885 provides a mode in
which VCCV BFD can be used to signal pseudo-wire status, this mode is only
applicable for pseudo-wires that have no other status signaling mechanism in use.
LDP status and static pseudo-wire status signaling always take precedence over
BFD-signaled PW status, and BFD-signaled pseudo-wire status is not used on
pseudo-wires that use LDP status or static pseudo-wire status signaling
mechanisms.
Issue: 01
3HE 11970 AAAA TQZZA 01
67
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
2.8.4
Configuring VCCV BFD
Generic BFD session parameters are configured for VCCV using the bfd-template
command, in the config>router>bfd context. However, there are some restrictions.
For VCCV, the BFD session can not terminate on the CPM network processor.
Therefore, an error is generated if the user tries to bind a BFD template using the
type cpm-np command within the config>router>bfd>bfd-template context.
As well, the minimum supported value for the transmit-interval and receiveinterval commands when BFD is used for VCCV-BFD is 1s. Attempting to bind a
BFD template with any unsupported transmit or receive interval will generate an
error.
Finally, attempting to commit changes to a BFD template that is already bound to a
pseudo-wire where the new values are invalid for VCCV BFD will result in an error.
Note that if the above BFD timer values are changed in a given template, any BFD
sessions on pseudo-wires to which that template is bound will try to renegotiate their
timers to the new values.
Commands within the BFD-template use a begin-commit model. To edit any value
within the BFD template, a begin command needs to be executed once the template
context has been entered. However, a value will still be stored temporarily in the
template-module until the commit command is issued. Once the commit is issued,
values will be used by other modules such as the MPLS-TP module and BFD
module.
For pseudo-wires where the pseudo-wire template does not apply (for example,
LDP-signaled spoke SDPs for a VLL service that uses the pseudo-wire ID FEC
(FEC128) or spoke SDPs with static pseudo-wire labels with or without MPLS-TP
identifiers), a named BFD template is configured on the spoke SDP using the
command config>service>epipe | cpipe | apipe | fpipe | ipipe>spoke-sdp>bfdtemplate name and then enabled using the command config>service> epipe |
cpipe | apipe | fpipe | ipipe>spoke-sdp>bfd-enable.
Configuring and enabling a BFD template on a static pseudo-wire already configured
with MPLS-TP identifiers (that is, with a pw-path-id) or on a spoke SDP with a
configured pw-path-id is not supported. Likewise, if a BFD template is configured and
enabled on a spoke SDP, then a pw-path-id can not be configured on the spoke SDP.
The bfd-enable command is blocked on a spoke SDP configured with VC-switching.
This is because VCCV BFD always operates end-to-end on an MS-pseudo-wire. It is
not possible to extract VCCV BFD packets at the S-PE.
68
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
For IES and VPRN spoke SDP termination where the pseudo-wire template does not
apply (that is, where the spoke SDP is signaled with LDP and uses the pseudo-wire
ID FEC (FEC128), the BFD template is configured using the command
config>service>ies | vprn>if>spoke-sdp>bfd-template name and then enabled
using the command config>service>ies | vprn>if>spoke-sdp>bfd-enable.
For H-VPLS where the PW-Template does not apply (that is, LDP-VPLS spoke and
mesh SDPs that use the Pwid FEC(FEC128) the bfd template is configured using
config>service>vpls>spoke>sdp>bfd-name name or
config>service>vpls>mesh-sdp>bfd-name name. VCCV BFD is then enabled
with the bfd-enable command under the VPLS spoke SDP or mesh SDP context.
pseudo-wires where the pw-template does apply and that support VCCV BFD are as
follows:
• BGP-AD, which is signaled using the Generalized pseudo-wire ID FEC
(FEC129) with AII type I
• BGP VPLS
• BGP VPWS
For these pseudo-wire types, a named BFD template is configured and enabled from
the pseudo-wire template binding context.
For BGP VPWS, the BFD template is configured using the command
config>service> epipe>bgp>pw-template-binding>bfd-template name and then
enabled using the command config>service>epipe>bgp>pw-templatebinding>bfd-enable.
2.9 Pseudo-wire Switching
The pseudo-wire switching feature provides the user with the ability to create a VLL
service by cross-connecting two spoke SDPs. This feature allows the scaling of VLL
and VPLS services in a large network in which the otherwise full mesh of PE devices
would require thousands of Targeted LDP (T-LDP) sessions per PE node.
Services with one SAP and one spoke SDP are created normally on the PE;
however, the target destination of the SDP is the pseudo-wire switching node instead
of what is normally the remote PE. In addition, the user configures a VLL service on
the pseudo-wire switching node using the two SDPs.
Issue: 01
3HE 11970 AAAA TQZZA 01
69
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
The pseudo-wire switching node acts in a passive role with respect to signaling of the
pseudo-wires. It waits until one or both of the PEs sends the label mapping message
before relaying it to the other PE. This is because it needs to pass the Interface
Parameters of each PE to the other.
A pseudo-wire switching point TLV is inserted by the switching pseudo-wire to record
its system address when relaying the label mapping message. This TLV is useful in
a few situations:
• It allows for troubleshooting of the path of the pseudo-wire especially if multiple
pseudo-wire switching points exist between the two PEs.
• It helps in loop detection of the T-LDP signaling messages where a switching
point would receive back a label mapping message it had already relayed.
• The switching point TLV is inserted in pseudo-wire status notification messages
when they are sent end-to-end or from a pseudo-wire switching node towards a
destination PE.
Pseudo-wire OAM is supported for the manual switching pseudo-wires and allows
the pseudo-wire switching node to relay end-to-end pseudo-wire status notification
messages between the two PEs. The pseudo-wire switching node can generate a
pseudo-wire status and to send it to one or both of the PEs by including its system
address in the pseudo-wire switching point TLV. This allows a PE to identify the
origin of the pseudo-wire status notification message.
In the following example, the user configures a regular Epipe VLL service PE1 and
PE2. These services consist each of a SAP and a spoke-SDP. However, the target
destination of the SDP is actually not the remote PE but the pseudo-wire switching
node. In addition, the user configures an Epipe VLL service on the pseudo-wire
switching node using the two SDPs.
|7450 ESS, 7750 SR, and 7950 XRS PE1 (Epipe)|---sdp 2:10---|7450 ESS, 7750 SR, and
7950 XRS PW SW (Epipe)|---sdp 7:15---|7450 ESS, 7750 SR, and 7950 XRS PE2 (Epipe)|
Configuration examples can be found in Configuring Two VLL Paths Terminating on
T-PE2.
2.9.1
Pseudo-wire Switching with Protection
Pseudo-wire switching scales VLL and VPLS services over a multi-area network by
removing the need for a full mesh of targeted LDP sessions between PE nodes.
Figure 13 illustrates the use of pseudo-wire redundancy to provide a scalable and
resilient VLL service across multiple IGP areas in a provider network.
70
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
In the network in Figure 13, PE nodes act as masters and pseudo-wire switching
nodes act as slaves for the purpose of pseudo-wire signaling. A switching node will
need to pass the SAP Interface Parameters of each PE to the other.T-PE1 sends a
label mapping message for the Layer 2 FEC to the peer pseudo-wire switching node”
for example, S-PE1. It will include the SAP interface parameters, such as MTU, in
the label mapping message. S-PE1 checks the FEC against the local information and
if a match exists, it appends the optional pseudo-wire switching point TLV to the FEC
TLV in which it records its system address. T-PE1 then relays the label mapping
message to S-PE2. S-PE2 performs similar operations and forwards a label mapping
message to T-PE2. The same procedures are followed for the label mapping
message in the reverse direction, for example, from T-PE2 to T-PE1. S-PE1 and SPE2 will effect the spoke SDP cross-connect only when both directions of the
pseudo-wire have been signaled and matched.
Figure 13
VLL Resilience with Pseudo-wire Redundancy and Switching
Primary PW
Access Node
Standby PW
7x50 T-PE2
Metro area B
SDP3:300
PW switching
7x50 T-PE3
SDP6:600
7x50
7x50
7x50 S-PE3
7x50 S-PE4
PW switching
Core area
PW switching
7x50 S-PE2
7x50 S-PE1
PW switching
SDP4:400
SDP1:100
7x50
7x50
Metro area A
7x50 T-PE1
7x50
Access Node
OSSG114
The pseudo-wire switching TLV is useful in a few situations. First, it allows for
troubleshooting of the path of the pseudo-wire especially if multiple pseudo-wire
switching points exist between the two T-PE nodes. Secondly, it helps in loop
detection of the T-LDP signaling messages where a switching point receives back a
label mapping message it already relayed. Finally, it can be inserted in pseudo-wire
status messages when they are sent from a pseudo-wire switching node towards a
destination PE.
Issue: 01
3HE 11970 AAAA TQZZA 01
71
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
Pseudo-wire status messages can be generated by the T-PE nodes and/or the S-PE
nodes. Pseudo-wire status messages received by a switching node are processed
and then passed on to the next hop. An S-PE node appends the optional pseudowire switching TLV, with its system address added to it, to the FEC in the pseudowire status notification message only if it originated the message or the message was
received with the TLV in it. Otherwise, it means the message was originated by a TPE node and the S-PE should process and pass the message without changes
except for the VCID value in the FEC TLV.
2.9.2
Pseudo-wire Switching Behavior
In the network in Figure 13, PE nodes act as masters and pseudo-wire switching
nodes act as slaves for the purpose of pseudo-wire signaling. This is because a
switching node will need to pass the SAP interface parameters of each PE to the
other.T-PE1 sends a label mapping message for the Layer 2 FEC to the peer
pseudo-wire switching node, for example, S-PE1. It will include the SAP interface
parameters, such as MTU, in the label mapping message. S-PE1 checks the FEC
against the local information and if a match exists, it appends the optional pseudowire switching point TLV to the FEC TLV in which it records its system address. TPE1 then relays the label mapping message to S-PE2. S-PE2 performs similar
operation and forwards a label mapping message to T-PE2. The same procedures
are followed for the label mapping message in the reverse direction, for example,
from T-PE2 to T-PE1. S-PE1 and S-PE2 will effect the spoke SDP cross-connect
only when both directions of the pseudo-wire have been signaled and matched.
Pseudo-wire status notification messages can be generated by the T-PE nodes and/
or the S-PE nodes. Pseudo-wire status notification messages received by a
switching node are processed and then passed on to the next hop. An S-PE node
appends the optional pseudo-wire switching TLV, with its system address added to
it, to the FEC in the pseudo-wire status notification message only if it originated the
message or the message was received with the TLV in it. Otherwise, it means the
message was originated by a T-PE node and the S-PE should process and pass the
message without changes except for the VC ID value in the FEC TLV.
The merging of the received T-LDP status notification message and the local status
for the spoke SDPs from the service manager at a PE complies with the following
rules:
• When the local status for both spokes is up, the S-PE passes any received SAP
or SDP binding generated status notification message unchanged, for example,
the status notification TLV is unchanged but the VC-ID in the FEC TLV is set to
value of the pseudo-wire segment to the next hop.
72
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
• When the local operational status for any of the spokes is down, the S-PE
always sends an SDP-binding down status bits regardless if the received status
bits from the remote node indicated SAP up or down or SDP-binding up or down.
Pseudo-wire Switching TLV
The format of the pseudo-wire switching TLV is as follows:
0
1
2
3
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0|
pw sw TLV (0x096D)
|
pseudowire sw TLV Length
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Type
|
Length
|
Variable Length Value
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Variable Length Value
|
|
"
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
PW sw TLV Length — Specifies the total length of all the following pseudo-wire
switching point TLV fields in octets
Type — Encodes how the Value field is to be interpreted.
Length — Specifies the length of the Value field in octets.
Value — Octet string of Length octets that encodes information to be interpreted as
specified by the Type field.
Pseudo-wire Switching Point Sub-TLVs
Below are details specific to pseudo-wire switching point sub-TLVs:
pseudo-wire ID of last pseudo-wire segment traversed — This sub-TLV type contains
a pseudo-wire ID in the format of the pseudo-wire ID
Pseudo-wire switching point description string — An optional description string of text
up to 80 characters long.
IP address of pseudo-wire switching point.
The IP V4 or V6 address of the pseudo-wire switching point. This is an optional subTLV.
MH VCCV capability indication.
Issue: 01
3HE 11970 AAAA TQZZA 01
73
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
2.9.3
Static-to-Dynamic Pseudo-wire Switching
When one segment of the pseudo-wire cross-connect at the S-PE is static while the
other is signaled using T-LDP, the S-PE operates much like a T-PE from a signaling
perspective and as an S-PE from a data plane perspective.
The S-PE signals a label mapping message as soon as the local configuration is
complete. The control word C-bit field in the pseudo-wire FEC is set to the value
configured on the static spoke SDP.
When the label mapping for the egress direction is also received from the T-LDP
peer, and the information in the FEC matches that of the local configuration, the
static-to-dynamic cross-connect is effected.
Note that it is possible that end nodes of a static pseudo-wire segment be
misconfigured. In this case, an S-PE or T-PE node may be receiving packets with the
wrong encapsulation. In this case, it is possible that an invalid payload will be
forwarded over the pseudo-wire or the SAP respectively. Furthermore, if the S-PE or
T-PE node is expecting the control word in the packet encapsulation and the
received packet comes with no control word but the first nibble below the label stack
is 0x0001, the packet may be mistaken for a VCCV OAM packet and may be
forwarded to the CPM. In that case, the CPM will perform a check of the IP header
fields such as version, IP header length, and checksum. If any of this fails the VCCV
packet will be discarded.
2.9.4
Ingress VLAN Swapping
This feature is supported on VPLS and VLL services where the end to end solution
is built using two node solutions (requiring SDP connections between the nodes).
In VLAN swapping, only the VLAN-id value is copied to the inner VLAN position. The
Ethertype of the inner tag will be preserved and all consecutive nodes will work with
that value. Similarly, the dot1p bits value of outer-tag will not be preserved.
The network diagram in Figure 14 describes the network where at user access side
(DSLAM facing SAPs) every subscriber is represented by several QinQ SAPs with
inner-tag encoding service and outer-tag encoding subscriber (DSL line). The
aggregation side (BRAS or PE facing SAPs) the is represented by DSL line number
(inner VLAN tag) and DSLAM (outer VLAN tag). The effective operation on VLAN tag
is to “drop inner tag at access side and push another tag at the aggregation side”.
74
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
Figure 14
VLL Services
Ingress VLAN Swapping
C-VLAN= application
Lb= VC label
L-VLAN= DSL line
D-VLAN= DSLAM
CPE
Payload
MPLS network
C
Payload
C
L
Payload
L
Lb
Service per application
per DSLAM
DSLAM
Payload
L
D
SAP per
DSLAM
Service per application
per DSLAM
SAP per DSL &
per application
Ingress PE
BRAS
Egress PE SAP per
DSLAM
Video
Fig_36
2.9.4.1
Ingress VLAN Translation
The drawing in Figure 15 indicates an application where different circuits are
aggregated in the VPLS-based network.The access side is represented by an
explicit do1q encapsulated SAP. As the VLAN-id is port specific, those connected to
different ports might have the same VLAN. The aggregation side (the right side
Figure 15) is aggregated on the same port, and hence, unique a VLAN-id is required.
Figure 15
Ingress VLAN Translation
Aggregation Side:
Null Encapsulated Port Packets
Have Unique VLAN per Customer
VLAN 1 - 1000
1/1/1:100
VLAN 1 - 1000
1/1/2:100
VLAN 1 - 1000
1/1/3:100
VLAN 1 - 1000
1/1/4:100
1/1/10
VLAN 1 - 4000
Access Side:
Dot 1q Encapsulated Port Explicit
Sap for Every Customer VLAN
OSSG146
Issue: 01
3HE 11970 AAAA TQZZA 01
75
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
2.9.5
Pseudo-wire Redundancy
Pseudo-wire redundancy provides the ability to protect a pseudo-wire with a preprovisioned pseudo-wire and to switch traffic over to the secondary standby pseudowire in case of a SAP and/or network failure condition. Normally, pseudo-wires are
redundant by the virtue of the SDP redundancy mechanism. For instance, if the SDP
is an RSVP LSP and is protected by a secondary standby path and/or by FastReroute paths, the pseudo-wire is also protected. However, there are a couple of
applications in which SDP redundancy does not protect the end-to-end pseudo-wire
path:
• There are two different destination PE nodes for the same VLL service. The
main use case is the provision of dual-homing of a CPE or access node to two
PE nodes located in different POPs. The other use case is the provision of a pair
of active and standby BRAS nodes, or active and standby links to the same
BRAS node, to provide service resiliency to broadband service subscribers.
• The pseudo-wire path is switched in the middle of the network and the pseudowire switching node fails.
Pseudo-wire and VPLS link redundancy extends link-level resiliency for pseudowires and VPLS to protect critical network paths against physical link or node
failures. These innovations enable the virtualization of redundant paths across the
metro or core IP network to provide seamless and transparent fail-over for point-topoint and multi-point connections and services. When deployed with multi-chassis
LAG, the path for return traffic is maintained through the pseudo-wire or VPLS
switchover, which enables carriers to deliver “always on” services across their IP/
MPLS networks.
2.9.6
2.9.6.1
Dynamic Multi-Segment Pseudo-wire Routing
Overview
Dynamic Multi-Segment Pseudo-wire Routing (Dynamic MS-PWs) enable a
complete multi-segment pseudo-wire to be established, while only requiring perpseudo-wire configuration on the T-PEs. No per-pseudo-wire configuration is
required on the S-PEs. End-to-end signaling of the MS-PW is achieved using T-LDP,
while multi-protocol BGP is used to advertise the T-PEs, so allowing dynamic routing
of the MS-PW through the intervening network of S-PEs. Dynamic multi-segment
pseudo-wires are described in the IETF in draft-ietf-pwe3-dynamic-ms-pw-13.txt.
Figure 16 illustrates the operation of dynamic MS-PWs.
76
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
Figure 16
VLL Services
Dynamic MS-PW Overview
Fully qualified info in signalled
FEC allows T-PE/S-PE to
select next hop
T-LDP
T-LDP
CE
T-LDP
MPLS
CE
T-PE
S-PE
MPLS
T-PE
MS-PW
T-PE
CE
CE
CE
S-PE
MPLS tunnel
FEC 129 provides
a unique key for the
Attachment circuit (AII)
MPLS
IP/MPLS
Backbone
Global ID
(e.g. AS#)
+ AC identifier
CE
T-PE
S-PE
T-PE/S-PE
CE
Routing protocol advertises reachability
Global ID + prefix
OSSG572
The FEC 129 AII Type 2 structure depicted in Figure 17 is used to identify each
individual pseudo-wire endpoint:
Figure 17
MS-PW Addressing using FEC129 AII Type 2
New SAP, Spoke SDP
T-PE 1
S-PE
LDP
T-PE 2
LDP
Unique Endpoint ID
Unique Endpoint ID
• AII11 = Global ID-Prefix1-AC ID11
• AII21 = Global ID-Prefix2-AC ID21
No per-PW Provisioning
• Automatic Selection of the next hop
• Pseudowire Label Switching
• Provision S-PE Address and BGP
OSSG573
A 4-byte global ID followed by a 4 byte prefix and a 4 byte attachment circuit ID are
used to provide for hierarchical, independent allocation of addresses on a per service
provider network basis. The first 8 bytes (Global ID + Prefix) may be used to identify
each individual T-PE or S-PE as a loopback Layer 2 Address.
Issue: 01
3HE 11970 AAAA TQZZA 01
77
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
This new AII type is mapped into the MS-PW BGP NLRI (a new BGP AFI of L2VPN,
and SAFI for network layer reachability information for dynamic MS-PWs. As soon
as a new T- PE is configured with a local prefix address of global id:prefix, pseudowire routing will proceed to advertise this new address to all the other T- PEs and SPEs in the network, as depicted in Figure 18:
Figure 18
Advertisement of PE Addresses by PW Routing
Static/MP-BGP
NSH = Next Signaling Hop
4
5
T-PE 1
3. PE2 -> NSH = S-PE2
LDP
S-PE3
• L2 ID: Global ID-Prefix
3
LDP
PE2 -> NSH = S-PE3
1. New PE2 Added
S-PE4
PE2 -> NSH = PE2
RR
LDP
2
T-PE 2
PE2-local
OSSG574
In step 1, a new T-PE (T-PE2) is configured with a local prefix.
Next, in steps 2 to 5, MP-BGP will use the NLRI for the MS-PW routing SAFI to
advertise the location of the new T-PE to all the other PEs in the network.
Alternatively, static routes may be configured on a per T-PE/S-PE basis to
accommodate non-BGP PEs in the solution.
As a result, pseudo-wire routing tables for all the S-PEs and remote T-PEs are
populated with the next hop to be used to reach T-PE2.
VLL services can then be established, as illustrated in Figure 19.
78
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
Figure 19
VLL Services
Signaling of Dynamic MS-PWs using T-LDP
1 T-PE1 (IP1) provisioning:
1’ T-PE2 (IP2) provisioning:
SAII (GID:Prefix: AC ID) = 1:IP1:100
TAII (GID:Prefix:AC ID) = 1:IP2:200
SAII (GID:Prefix:AC ID) = 1:IP2:200
TAII (GID:Prefix:AC ID) = 1:IP1:100
2 Before sending LM:
4 On LM receipt:
6 On LM receipt:
Check TAII against “routing table”.
No full match on “local i/f”.
Longest match =>NSH
Check TAII against “routing table”
If no full match on “local i/f”.
Longest match => NSH
Check TAII against “routing table”.
Full match on “local i/f” implies T-PE.
PP
SP
T-PE1
P
S-PE
T-PE2
LDP1
LDP2
3 SS-PWa LSP Fwd
5 SS-PWb LSP Fwd
8 SS-PWa LSP Rev
7 SS-PWb LSP Rev
OSSG575
In step 1 and 1' the T-PEs are configured with the local and remote endpoint
information, Source AII (SAII), Target AII (TAII). On the router, the AIIs are locally
configured for each spoke SDP, according to the model shown in Figure 20. The
router therefore provides for a flexible mapping of AII to SAP. That is, the values used
for the AII are through local configuration, and it is the context of the spoke SDP that
binds it to a specific SAP.
Figure 20
Mapping of AII to SAP
VLL
AII:
Spoke-SDP
GID: 1
Prefix:
1.1.4.1
AC-ID: 1
SAP
SAP: 10
OSSG576
Issue: 01
3HE 11970 AAAA TQZZA 01
79
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
Before T-LDP signaling starts, the two T-PEs decide on an active and passive
relationship using the highest AII (comparing the configured SAII and TAII) or the
configured precedence. Next, the active T-PE (in the IETF draft this is referred to as
the source T-PE or ST-PE) checks the PW Routing Table to determine the next
signaling hop for the configured TAII using the longest match between the TAII and
the entries in the PW routing table
This signaling hop is then used to choose the T-LDP session to the chosen next-hop
S-PE. Signaling proceeds through each subsequent S-PE using similar matching
procedures to determine the next signaling hop. Otherwise, if a subsequent S-PE
does not support dynamic MS-PW routing and thus uses a statically configured PW
segment, the signaling of individual segments follows the procedures already
implemented in the PW Switching feature. Note that BGP can install a PW AII route
in the PW routing table with ECMP next-hops. However when LDP needs to signal a
PW with matching TAII, it will choose only one next-hop from the available ECMP
next-hops. PW routing supports up to 4 ECMP paths for each destination.
The signaling of the forward path ends once the PE matches the TAII in the label
mapping message with the SAII of a spoke SDP bound to a local SAP. The signaling
in the reverse direction can now be initiated, which follows the entries installed in the
forward path. The PW Routing tables are not consulted for the reverse path. This
ensures that the reverse direction of the PW follows exactly the same set of S-PEs
as the forward direction.
This solution can be used in either a MAN-WAN environment or in an Inter-AS/InterProvider environment as depicted in Figure 21.
Figure 21
VLL Using Dynamic MS-PWs, Inter-AS Scenario
ASBR
ASBR
T-PEs
PW/MPLS
(AS1)
PW/MPLS
(AS2)
S-PE
T-PEs
S-PE
Control Plane Session
OSSG577
Note that data plane forwarding at the S-PEs uses pseudo-wire service label
switching, as per the pseudo-wire switching feature.
80
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
2.9.6.2
VLL Services
Pseudo-wire Routing
Each S-PE and T-PE has a pseudo-wire routing table that contains a reference to the
T-LDP session to use to signal to a set of next hop S-PEs to reach a given T-PE (or
the T-PE if that is the next hop). For VLLs, this table contains aggregated AII Type 2
FECs and may be populated with routes that are learned through MP-BGP or that
are statically configured.
MP-BGP is used to automatically distribute T-PE prefixes using the new MS-PW
NLRI, or static routes can be used. The MS-PW NLRI is composed of a Length, an
8-byte RD, a 4-byte Global-ID, a 4-byte local prefix, and (optionally) a 4-byte AC-ID.
Support for the MS-PW address family is configured in CLI under
config>router>bgp>family ms-pw.
MS-PW routing parameters are configured in the config>service>pw-routing
context.
In order to enable support for dynamic MS-PWs on a 7750 SR, 7450 ESS or
7950 XRS node to be used as a T-PE or S-PE, a single, globally unique, S-PE ID,
known as the S-PE Address, is first configured under config>service>pw-routing
on each node to be used as a T-PE or S-PE. The S-PE Address has the format
global-id:prefix. It is not possible to configure any local prefixes used for pseudo-wire
routing or to configure spoke-SDPs using dynamic MS-PWs at a T-PE unless an SPE address has already been configured. The S-PE address is used as the address
of a node used to populate the switching point TLV in the LDP label mapping
message and the pseudo-wire status notification sent for faults at an S-PE.
Each T-PE is also be configured with the following parameters:
• Global ID — This is a 4 byte identifier that uniquely identifies an operator or the
local network.
• Local Prefix — One or more local (Layer 2) prefixes (up to a maximum of 16),
which are formatted in the style of a 4-octet IPv4 address. A local prefix identifies
a T-PE or S-PE in the PW routing domain.
• For each local prefix, at least one 8-byte route distinguisher can be configured.
It is also possible to configure an optional BGP community attribute.
For each local prefix, BGP then advertises each global ID/prefix tuple and unique RD
and community pseudo-wire using the MS-PW NLRI, based on the aggregated
FEC129 AII Type 2 and the Layer 2 VPN/PW routing AFI/SAFI 25/6, to each T-PE/
S-PE that is a T-LDP neighbor, subject to local BGP policies.
The dynamic advertisement of each of these pseudo-wire routes is enabled for each
prefix and RD using the advertise-bgp command.
Issue: 01
3HE 11970 AAAA TQZZA 01
81
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
An export policy is also required in order to export MS-PW routes in MP-BGP. This
can be done using a default policy, such as the following:
*A:lin-123>config>router>policy-options# info
---------------------------------------------policy-statement "ms-pw"
default-action accept
exit
exit
----------------------------------------------
However, this would export all routes. A recommended choice is to enable filtering
per-family, as follows:
*A:lin-123>config>router>policy-options# info
---------------------------------------------policy-statement "to-mspw"
entry 1
from
family ms-pw
exit
action accept
exit
exit
exit
----------------------------------------------
The following command is then added in the config>router>bgp context
export "to-mspw"
Local-preference for iBGP and BGP communities can be configured under such a
policy.
2.9.6.2.1
Static Routing
In addition to support for BGP routing, static MS-PW routes may also be configured
using the config>services>pw-routing>static-route command. Each static route
comprises the target T-PE Global-ID and prefix, and the IP address of the T-LDP
session to the next hop S-PE or T-PE that should be used.
If a static route is set to 0, then this represents the default route. If a static route exists
to a given T-PE, then this is used in preference to any BGP route that may exist.
82
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
2.9.6.2.2
VLL Services
Explicit Paths
A set of default explicit routes to a remote T-PE or S-PE prefix may be configured on
a T-PE under config>services>pw-routing using the path name command.
Explicit paths are used to populate the explicit route TLV used by MS-PW T-LDP
signaling. Only strict (fully qualified) explicit paths are supported.
Note that it is possible to configure explicit paths independently of the configuration
of BGP or static routing.
2.9.6.3
Configuring VLLs using Dynamic MS-PWs
One or more spoke SDPs may be configured for distributed Epipe VLL services.
Dynamic MS-PWs use FEC129 (also known as the Generalized ID FEC) with
Attachment Individual Identifier (AII) Type 2 to identify the pseudo-wire, as opposed
to FEC128 (also known as the PW ID FEC) used for traditional single segment
pseudo-wires and for pseudo-wire switching. FEC129 spoke SDPs are configured
under the spoke-sdp-fec command in the CLI.
FEC129 AII Type 2 uses a Source Attachment Individual Identifier (SAII) and a
Target Attachment Individual Identifier (TAII) to identify the end of a pseudo-wire at
the T-PE. The SAII identifies the local end, while the TAII identifies the remote end.
The SAII and TAII are each structured as follows:
• Global-ID — This is a 4 byte identifier that uniquely identifies an operator or the
local network.
• Prefix — A 4-byte prefix, which should correspond to one of the local prefixes
assigned under pw-routing.
• AC-ID — A 4-byte identifier for this end of the pseudo-wire. This should be
locally unique within the scope of the global-id:prefix.
2.9.6.3.1
Active/Passive T-PE Selection
Dynamic MS-PWs use single-sided signaling procedures with double-sided
configuration, a fully qualified FEC must be configured at both endpoints. That is, one
T-PE (the source T-PE, ST-PE) of the MS-PW initiates signaling for the MS-PW,
while the other end (the terminating T-PE, TT-PE) passively waits for the label
mapping message from the far-end and only responds with a label mapping
message to set up the opposite direction of the MS-PW when it receives the label
mapping from the ST-PE. By default, the router will determine which T-PE is the STPE (the active T-PE) and which is the TT-PE (the passive T-PE) automatically, based
on comparing the SAII with the TAII as unsigned integers. The T-PE with SAII>TAII
Issue: 01
3HE 11970 AAAA TQZZA 01
83
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
assumes the active role. However, it is possible to override this behavior using the
signaling {master | auto} command under spoke-sdp-fec. If master is selected at a
given T-PE, then it will assume the active role. If a T-PE is at the endpoint of a spoke
SDP that is bound to an VLL SAP and single sided auto-configuration is used (see
below), then that endpoint is always passive. Therefore, signaling master should only
be used when it is known that the far end will assume a passive behavior.
2.9.6.3.2
Automatic Endpoint Configuration
Automatic endpoint configuration allows the configuration of an endpoint without
specifying the TAII associated with that spoke-sdp-fec. It allows a single-sided
provisioning model where an incoming label mapping message with a TAII that
matches the SAII of that spoke SDP to be automatically bound to that endpoint. This
is useful in scenarios where a service provider wishes to separate service
configuration from the service activation phase.
Automatic endpoint configuration is supported required for Epipe VLL spoke-sdpfec endpoints bound to a VLL SAP. It is configured using the spoke-sdp-fec>autoconfig command, and excluding the TAII from the configuration. When autoconfiguration is used, the node assumed passive behavior from a point of view of TLDP signaling (see above). Therefore, the far-end T-PE must be configured for
signaling master for that spoke-sdp-fec.
2.9.6.3.3
Selecting a Path for an MS-PW
Path selection for signaling occurs in the outbound direction (ST-PE to TT-PE) for an
MS-PW. In the TT-PE to ST-PE direction, a label mapping message simply follows
the reverse of the path already taken by the outgoing label mapping.
A node can use explicit paths, static routes, or BGP routes to select the next hop SPE or T-PE. The order of preference used in selecting these routes is:
1. Explicit Path
2. Static route
3. BGP route
In order to use an explicit path for an MS-PW, an explicit path must have been
configured in the config>services>pw-routing>path path-name context. The user
must then configure the corresponding path path-name under spoke-sdp-fec.
84
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
If an explicit path name is not configured, then the TT-PE or S-PE will perform a
longest match lookup for a route (static if it exists, and BGP if not) to the next hop SPE or T-PE to reach the TAII.
Pseudo-wire routing chooses the MS-PW path in terms of the sequence of S-PEs to
use to reach a given T-PE. It does not select the SDP to use on each hop, which is
instead determined at signaling time. When a label mapping is sent for a given
pseudo-wire segment, an LDP SDP will be used to reach the next-hop S-PE/T-PE if
such an SDP exists. If not, and a RFC 3107 labeled BGP SDP is available, then that
will be used. Otherwise, the label mapping will fail and a label release will be sent.
2.9.6.3.4
Pseudo-wire Templates
Dynamic MS-PWs support the use of the pseudo-wire template for specifying generic
pseudo-wire parameters at the T-PE. The pseudo-wire template to use is configured
in the spoke-sdp-fec>pw-template-bind policy-id context. Dynamic MS-PWs do
not support the provisioned SDPs specified in the pseudo-wire template.
2.9.6.4
Pseudo-wire Redundancy
Pseudo-wire redundancy is supported on dynamic MS-PWs used for VLLs. It is
configured in a similar manner to pseudo-wire redundancy on VLLs using FEC128,
whereby each spoke-sdp-fec within an endpoint is configured with a unique SAII/
TAII.
Figure 22 illustrates the use of pseudo-wire redundancy.
Issue: 01
3HE 11970 AAAA TQZZA 01
85
VLL Services
Figure 22
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
Pseudo-wire Redundancy
BGP –1:1.1.4.1
BGP –1:1.1.1.1
GID:1
Pr efix:
1.1.4.1
AC_ID:1
GID:1
Pre fix: 1.1.2.1
GID:1
Prefix:
1.1.1.1
AC_ID:1
CE1
SAP:1
7750 S-PE1
7750 T-PE2
MC-LAG
SAP:1
CE2
GID:1
Prefix:
1.1.1.2
AC_ID:1
7750 T-PE1
GID:1
Pr efix:
1.1.5.1
AC_ID:1
GID:1
Prefix:1.1.3.1
BGP –1:1.1.1.2
SAP:1
7750 S-PE2
BGP –1:1.1.5.1
7750 T-PE3
OSSG578
The following is a summary of the key points to consider in using pseudo-wire
redundancy with dynamic MS-PWs:
• Each MS-PW in the redundant set must have a unique SAII/TAII set and is
signaled separately. The primary pseudo-wire is configured in the spoke-sdpfec>primary context.
• Each MS-PW in the redundant set should use a diverse path (from the point of
view of the S-PEs traversed) from every other MS-PW in that set if path diversity
is possible in a given network topology. There are a number of possible ways to
achieve this:
− Configure an explicit path for each MS-PW.
− Allow BGP routing to automatically determine diverse paths using BGP
policies applied to different local prefixes assigned to the primary and
standby MS-PWs.
− Path diversity can be further provided for each primary pseudo-wire through
the use of a BGP route distinguisher.
If the primary MS-PW fails, fail-over to a standby MS-PW, as per the normal pseudowire redundancy procedures. A configurable retry timer for the failed primary MS-PW
is then started. When the timer expires, attempt to re-establish the primary MS-PW
using its original path, up to a maximum number of attempts as per the retry count
parameter. The T-PE may then optionally revert back to the primary MS-PW on
successful reestablishment.
86
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
Note that since the SDP ID is determined dynamically at signaling time, it cannot be
used as a tie breaker to choose the primary MS-PW between multiple MS-PWs of
the same precedence. The user should therefore explicitly configure the precedence
values to determine which MS-PW is active in the final selection.
2.9.6.5
VCCV OAM for Dynamic MS-PWs
The primary difference between dynamic MS-PWs and those using FEC128 is
support for FEC129 AII type 2. As in PW Switching, VCCV on dynamic MS-PWs
requires the use of the VCCV control word on the pseudo-wire. Both the vccv-ping
and vccv-trace commands support dynamic MS-PWs.
2.9.6.6
VCCV-Ping on Dynamic MS-PWs
VCCV-ping supports the use of FEC129 AII type 2 in the target FEC stack of the ping
echo request message. The FEC to use in the echo request message is derived in
one of two ways: Either the user can specify only the spoke-sdp-fec-id of the MS-PW
in the vccv-ping command, or the user can explicitly specify the SAII and TAII to use.
If the SAII:TAII is entered by the user in the vccv-ping command, then those values
are be used for the vccv-ping echo request, but their order is be reversed before
being sent so that they match the order for the downstream FEC element for an SPE, or the locally configured SAII:TAII for a remote T-PE of that MS-PW. Note that is
SAII:TAII is entered in addition to the spoke-sdp-fec-id, then the system will verify the
entered values against the values stored in the context for that spoke-sdp-fec-id.
Otherwise, if the SAII:TAII to use in the target FEC stack of the vccv-ping message
is not entered by the user, and if a switching point TLV was previously received in the
initial label mapping message for the reverse direction of the MS-PW (with respect
to the sending PE), then the SAII:TAII to use in the target FEC stack of the vccv-ping
echo request message is derived by parsing that switching point TLV based on the
user-specified TTL (or a TTL of 255 if none is specified). In this case, the order of the
SAII:TAII in the switching point TLV is maintained for the vccv-ping echo request
message.
If no pseudo-wire switching point TLV was received, then the SAII:TAII values to use
for the vccv-ping echo request are derived from the MS-PW context, but their order
is reversed before being sent so that they match the order for the downstream FEC
element for an S-PE, or the locally configured SAII:TAII for a remote T-PE of that MSPW.
Issue: 01
3HE 11970 AAAA TQZZA 01
87
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
Note that the use of spoke-sdp-fec-id in vccv-ping is only applicable at T-PE nodes,
since it is not configured for a given MS-PW at S-PE nodes.
2.9.6.7
VCCV-Trace on Dynamic MS-PWs
The 7750 SR, 7450 ESS, and 7950 XRS support the MS-PW path trace mode of
operation for VCCV trace, as per pseudo-wire switching, but using FEC129 AII type
2. As in the case of vccv-ping, the SAII:TAII used in the VCCV echo request message
sent from the T-PE or S-PE from which the VCCV trace command is executed is
specified by the user or derived from the context of the MS-PW. Note that the use of
spoke-sdp-fec-id in vccv-trace is only applicable at T-PE nodes, since it is not
configured for a given MS-PW at S-PE nodes.
2.9.7
Example Dynamic MS-PW Configuration
This section presents an example of how to configure Dynamic MS-PWs for a VLL
service between a set of Nokia nodes. The network consists of two T-PEs and two
nodes playing the role of S-PEs, as shown in the following figure. Each 7750 SR,
7450 ESS, or 7950 XRS peers with its neighbor using LDP and BGP.
Figure 23
7750 T-PE1
10.20.1.3
Dynamic MS-PW Example
BGP
BGP
BGP
LDP
LDP
LDP
7750 S-PE1
10.20.1.5
7750 S-PE2
10.20.1.2
7750 T-PE2
10.20.1.6
OSSG579
The example uses BGP to route dynamic MS-PWs and T-LDP to signal them.
Therefore each node must be configured to support the MS-PW address family
under BGP, and BGP and LDP peerings must be established between the T-PEs/SPEs. The appropriate BGP export policies must also be configured.
Next, pseudo-wire routing must be configured on each node. This includes an S-PE
address for every participating node, and one or more local prefixes on the T-PEs.
MS-PW paths and static routes may also be configured.
88
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
Once this routing and signaling infrastructure is established, spoke-sdp-fecs can be
configured on each of the T-PEs.
config
router
ldp
targeted-session
peer 10.20.1.5
exit
exit
policy-options
begin
policy-statement "exportMsPw"
entry 10
from
family ms-pw
exit
action accept
exit
exit
exit
commit
exit
bgp
family ms-pw
connect-retry 1
min-route-advertisement 1
export "exportMsPw"
rapid-withdrawal
group "ebgp"
neighbor 10.20.1.5
multihop 255
peer-as 200
exit
exit
exit
config
service
pw-routing
spe-address 3:10.20.1.3
local-prefix 3:10.20.1.3 create
exit
path "path1_to_F" create
hop 1 10.20.1.5
hop 2 10.20.1.2
no shutdown
exit
exit
epipe 1 customer 1 vpn 1 create
description "Default epipe
description for service id 1"
service-mtu 1400
service-name "XYZ Epipe 1"
sap 2/1/1:1 create
exit
spoke-sdp-fec 1 fec 129 aii-type 2 create
retry-timer 10
retry-count 10
Issue: 01
3HE 11970 AAAA TQZZA 01
89
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
saii-type2 3:10.20.1.3:1
taii-type2 6:10.20.1.6:1
no shutdown
exit
no shutdown
exit
config
router
ldp
targeted-session
peer 10.20.1.2
exit
exit
…
policy-options
begin
policy-statement "exportMsPw"
entry 10
from
family ms-pw
exit
action accept
exit
exit
exit
commit
exit
bgp
family ms-pw
connect-retry 1
min-route-advertisement 1
export "exportMsPw"
rapid-withdrawal
group "ebgp"
neighbor 10.20.1.2
multihop 255
peer-as 300
exit
exit
exit
config
service
pw-routing
spe-address 6:10.20.1.6
local-prefix 6:10.20.1.6 create
exit
path "path1_to_F" create
hop 1 10.20.1.2
hop 2 10.20.1.5
no shutdown
exit
exit
epipe 1 customer 1 vpn 1 create
description "Default epipe
description for service id 1"
service-mtu 1400
service-name "XYZ Epipe 1"
sap 1/1/3:1 create
90
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
exit
spoke-sdp-fec 1 fec 129 aii-type 2 create
retry-timer 10
retry-count 10
saii-type2 6:10.20.1.6:1
taii-type2 3:10.20.1.3:1
no shutdown
exit
no shutdown
exit
config
router
ldp
targeted-session
peer 10.20.1.3
exit
peer 10.20.1.2
exit
exit
…
bgp
family ms-pw
connect-retry 1
min-route-advertisement 1
rapid-withdrawal
group "ebgp"
neighbor 10.20.1.2
multihop 255
peer-as 300
exit
neighbor 10.20.1.3
multihop 255
peer-as 100
exit
exit
exit
service
pw-routing
spe-address 5:10.20.1.5
exit
config
router
ldp
targeted-session
peer 10.20.1.5
exit
peer 10.20.1.6
exit
exit
…
bgp
family ms-pw
connect-retry 1
min-route-advertisement 1
Issue: 01
3HE 11970 AAAA TQZZA 01
91
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
rapid-withdrawal
group "ebgp"
neighbor 10.20.1.5
multihop 255
peer-as 200
exit
neighbor 10.20.1.6
multihop 255
peer-as 400
exit
exit
exit
service
pw-routing
spe-address 2:10.20.1.2
exit
2.9.8
VLL Resilience with Two Destination PE Nodes
Figure 24 illustrates the application of pseudo-wire redundancy to provide Ethernet
VLL service resilience for broadband service subscribers accessing the broadband
service on the service provider BRAS.
Figure 24
VLL Resilience
7x50 ESS
7x50 ESS
Eth SAP
Primary Eth
Eth SAP
(primary)
PE 2
PE 1
IP/MPLS
7x50 ESS
BRAS 1
DSLAM
Standby
backup Eth
PW
Eth SAP
(standby)
PE 3
OSSG115
If the Ethernet SAP on PE2 fails, PE2 notifies PE1 of the failure by either withdrawing
the primary pseudo-wire label it advertised or by sending a pseudo-wire status
notification with the code set to indicate a SAP defect. PE1 will receive it and will
immediately switch its local SAP to forward over the secondary standby spoke SDP.
In order to avoid black holing of in-flight packets during the switching of the path, PE1
will accept packets received from PE2 on the primary pseudo-wire while transmitting
92
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
over the backup pseudo-wire. However, in other applications such as those
described in Access Node Resilience Using MC-LAG and Pseudo-wire Redundancy,
it will be important to minimize service outage to end users.
When the SAP at PE2 is restored, PE2 updates the new status of the SAP by sending
a new label mapping message for the same pseudo-wire FEC or by sending pseudowire status notification message indicating that the SAP is back up. PE1 then starts
a timer and reverts back to the primary at the expiry of the timer. By default, the timer
is set to 0, which means PE1 reverts immediately. A special value of the timer
(infinity) will mean that PE1 should never revert back to the primary pseudo-wire.
The behavior of the pseudo-wire redundancy feature is the same if PE1 detects or is
notified of a network failure that brought the spoke SDP operational status to DOWN.
The following are the events which will cause PE1 to trigger a switchover to the
secondary standby pseudo-wire:
1. T-LDP peer (remote PE) node withdrew the pseudo-wire label.
2. T-LDP peer signaled a FEC status indicating a pseudo-wire failure or a remote
SAP failure.
3. T-LDP session to peer node times out.
4. SDP binding and VLL service went down as a result of network failure condition
such as the SDP to peer node going operationally down.
The SDP type for the primary and secondary pseudo-wires need not be the same. In
other words, the user can protect a RSVP-TE based spoke SDP with an LDP or GRE
based one. This provides the ability to route the path of the two pseudo-wires over
different areas of the network. All VLL service types, for example, Apipe, Epipe,
Fpipe, and Ipipe are supported on the 7750 SR.
Nokia’s routers support the ability to configure multiple secondary standby pseudowire paths. For example, PE1 uses the value of the user configurable precedence
parameter associated with each spoke SDP to select the next available pseudo-wire
path after the failure of the current active pseudo-wire (whether it is the primary or
one of the secondary pseudo-wires). The revertive operation always switches the
path of the VLL back to the primary pseudo-wire though. There is no revertive
operation between secondary paths meaning that the path of the VLL will not be
switched back to a secondary pseudo-wire of higher precedence when the latter
comes back up again.
Nokia’s routers support the ability for a user-initiated manual switchover of the VLL
path to the primary or any of the secondary be supported to divert user traffic in case
of a planned outage such as in node upgrade procedures.
On the 7750 SR, this application can make use of all types of VLL supported on SRSeries routers. However, if a SAP is configured on a MC-LAG instance, only the
Epipe service type is allowed.
Issue: 01
3HE 11970 AAAA TQZZA 01
93
VLL Services
2.9.8.1
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
Master-Slave Operation
Master-Slave pseudo-wire redundancy is discussed in this section. It adds the ability
for the remote peer to react to the pseudo-wire standby status notification, even if
only one spoke SDP terminates on the VLL endpoint on the remote peer, by blocking
the transmit (Tx) direction of a VLL spoke SDP when the far-end PE signals standby.
This solution enables the blocking of the Tx direction of a VLL spoke SDP at both
master and slave endpoints when standby is signaled by the master endpoint. This
approach satisfies a majority of deployments where bidirectional blocking of the
forwarding on a standby spoke SDP is required.
Figure 25 illustrates the operation of master-slave pseudo-wire redundancy. In this
scenario, an Epipe service is provided between CE1 and CE2. CE2 is dual homed to
PE2 and PE3, and thus PE1 is dual-homed to PE2 and PE3 using Epipe spoke
SDPs. The objectives of this feature is to ensure that only one pseudo-wire is used
for forwarding in both directions by PE1, PE2 and PE3 in the absence of a native dual
homing protocol between CE2 and PE2/PE3, such as MC-LAG. In normal operating
conditions (the SAPs on PE2 and PE3 towards CE2 are both up and there are no
defects on the ACs to CE2), PE2 and PE3 cannot choose which spoke SDP to
forward on based on the status of the AC redundancy protocol.
Figure 25
Master-Slave Pseudo-wire Redundancy
A
A
CE1
L2 Switch
PE2
epipe
NO MC-LAG
PE1
S
epipe
standby-signaling-master
A
PE3
CE2
Block
Fwd
standby-signaling-slave
al_0149
Master-slave pseudo-wire redundancy adds the ability for the remote peer to react to
the pseudo-wire standby status notification, even if only one spoke SDP terminates
on the VLL endpoint on the remote peer. When the CLI command standbysignaling-slave is enabled at the spoke SDP or explicit endpoint level in PE2 and
PE3, then any spoke SDP for which the remote peer signals PW FWD Standby will
be blocked in the transmit direction.
94
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
This is achieved as follows. The standby-signaling-master state is activated on the
VLL endpoint in PE1. In this case, a spoke SDP is blocked in the transmit direction
at this master endpoint if it is either in operDown state, or it has lower precedence
than the highest precedence spoke SDP, or the given peer PE signals one of the
following pseudo-wire status bits:
• Pseudo-wire not forwarding (0x01)
• SAP (ingress) receive fault (0x02)
• SAP (egress) transmit fault (0x04)
• SDP binding (ingress) receive fault (0x08)
• SDP binding (egress) transmit fault (0x10)
The fact that the given spoke SDP has been blocked will be signaled to LDP peer
through the pseudo-wire status bit (PW FWD Standby (0x20)). This will prevent traffic
being sent over this spoke SDP by the remote peer, but obviously only in case that
remote peer supports and reacts to pseudo-wire status notification. Previously, this
applied only if the spoke SDP terminates on an IES, VPRN or VPLS. However, if
standby-signaling-slave is enabled at the remote VLL endpoint then the Tx direction
of the spoke SDP will also be blocked, according to the rules in Operation of MasterSlave Pseudo-wire Redundancy with Existing Scenarios.
Note that although master-slave operation provides bidirectional blocking of a
standby spoke SDP during steady-state conditions, it is possible that the Tx
directions of more than one slave endpoint can be active for transient periods during
a fail-over operation. This is due to slave endpoints transitioning a spoke SDP from
standby to active receiving and/or processing a pseudo-wire preferential forwarding
status message before those transitioning a spoke SDP to standby. This transient
condition is most likely when a forced switch-over is performed, or the relative
preferences of the spoke SDPs is changed, or the active spoke SDP is shutdown at
the master endpoint. During this period, loops of unknown traffic may be observed.
Fail-overs due to common network faults that can occur during normal operation, a
failure of connectivity on the path of the spoke SDP or the SAP, would not result in
such loops in the data path.
2.9.8.1.1
Interaction with SAP-Specific OAM
If all of the spoke SDPs bound to a SAP at a slave PE are selected as standby, then
this should be treated from a SAP OAM perspective in the same manner as a fault
on the service, an SDP binding down or remote SAP down. That is, a fault should be
indicated to the service manager. If SAP-specific OAM is enabled towards the CE,
such as Ethernet CCM, E-LMI, or FR LMI, then this should result in the appropriate
OAM message being sent on the SAP. This can enable the remote CE to avoid
forwarding traffic towards a SAP which will drop it.
Issue: 01
3HE 11970 AAAA TQZZA 01
95
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
Figure 26 shows an example for the case of Ethernet LMI.
Figure 26
Example of SAP OAM Interaction with Master-Slave Pseudo-wire
Redundancy
A
E-LMI: active
A
E-LMI: active
CE1
L2 Switch
PE2
epipe
NO MC-LAG
PE1
CE2
S
epipe
E-LMI: non-active
standby-signaling-master
A
PE3
Block
Fwd
standby-signaling-slave
al_0150
2.9.8.1.2
Local Rules at Slave VLL PE
It is not possible to configure a standby-signaling-slave on endpoints or spoke SDPs
bound to an IES, VPRN, ICB, MC-EP or that form part of an MC-LAG or MC-APS.
If standby-signaling-slave is configured on a given spoke SDP or explicit endpoint,
then the following rules apply. Note that the rules describe the case of several spoke
SDPs in an explicit endpoint. The same rules apply to the case of a single spoke SDP
outside of an endpoint where no endpoint exists:
• Rules for processing endpoint SAP active/standby status bits:
− Since the SAP in endpoint X is never a part of a MC-LAG/MC-APS instance,
a forwarding status of ACTIVE is always advertised.
• Rules for processing and merging local and received endpoint object status Up/
Down operational status:
1. Endpoint ‘X’ is operationally UP if at least one of its objects is operationally UP.
It is Down if all its objects are operationally down.
2. If all objects in endpoint ‘X’ transition locally to Down state, and/or received a
“SAP Down” notification via remote T-LDP status bits or via SAP specific OAM
signal, and/or received status bits of “SDP-binding down”, and/or received status
bits of “PW not forwarding”, the node must send status bits of “SAP Down” over
all ‘Y’ endpoint spoke SDPs.
3. Endpoint ‘Y’ is operationally UP if at least one of its objects is operationally UP.
It is Down if all its objects are operationally down.
96
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
4. If a spoke SDP in endpoint ‘Y’, including the ICB spoke SDP, transitions locally
to Down state, the node must send T-LDP “SDP-binding down” status bits on
this spoke SDP.
5. If a spoke SDP in endpoint ‘Y’, received T-LDP “SAP down” status bits, and/or
received T-LDP “SDP-binding down” status bits, and/or received status bits of
“PW not forwarding”, the node saves this status and takes no further action. The
saved status is used for selecting the active transmit endpoint object.
6. If, all objects in endpoint ‘Y’, or a single spoke SDP that exists outside of an
endpoint (and no endpoint exists), transition locally to down state, and/or
received T-LDP “SAP Down” status bits, and/or received T-LDP “SDP-binding
down” status bits, and/or received status bits of “PW not forwarding”, and/or the
received status bits of ‘PW FWD standby’, the node must send a “SAP down”
notification on the ‘X’ endpoint SAP via the SAP specific OAM signal, if
applicable.
7. If the peer PE for a given object in endpoint ‘Y’ signals ‘PW FWD standby’, the
spoke SDP must be blocked in the transmit direction and the spoke SDP is not
eligible for selection by the active transmit selection rules.
8. If the peer PE for a given object in endpoint ‘Y’ does not signal ‘PW FWD
standby’, then spoke SDP is eligible for selection.
2.9.8.1.3
Operation of Master-Slave Pseudo-wire Redundancy with Existing
Scenarios
This section discusses how master-slave pseudo-wire redundancy could operate.
VLL Resilience
Figure 27 shows a VLL resilience path example. An sample configuration follows.
Figure 27
VLL Resilience
spoke-sdp 1:100
sap 1/1/1:100
PE-2
PE-1
sap 1/2/1:100
BRAS
spoke-sdp 2:200
sap 1/1/2:100
PE-3
OSSG246
Issue: 01
3HE 11970 AAAA TQZZA 01
97
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
Note that a revert-time value of zero (default) means that the VLL path will be
switched back to the primary immediately after it comes back up
PE1
configure service epipe 1
endpoint X
exit
endpoint Y
revert-time 0
standby-signaling-master
exit
sap 1/1/1:100 endpoint X
spoke-sdp 1:100 endpoint Y
precedence primary
spoke-sdp 2:200 endpoint Y
precedence 1
PE2
configure service epipe 1
endpoint X
exit
sap 2/2/2:200 endpoint X
spoke-sdp 1:100
standby-signaling-slave
PE3
configure service epipe 1
endpoint X
exit
sap 3/3/3:300 endpoint X
spoke-sdp 2:200
standby-signaling-slave
2.9.8.1.4
VLL Resilience for a Switched Pseudo-wire Path
Figure 28 displays a VLL resilience for a switched pseudo-wire path example. A
sample configuration follows.
Figure 28
VLL Resilience with Pseudo-wire Switching
S-PE-1
spoke-sdp 1:100
spoke-sdp 4:400
sap 2/2/2:200
sap 1/1/1:100
T-PE-1
spoke-sdp 2:200
S-PE-2
spoke-sdp 5:500 T-PE-2
spoke-sdp 6:600
spoke-sdp 3:300
S-PE-3
OSSG246PW
98
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
Configuration
T-PE1
configure service epipe 1
endpoint X
exit
endpoint Y
revert-time 100
standby-signaling-master
exit
sap 1/1/1:100 endpoint X
spoke-sdp 1:100 endpoint Y
precedence primary
spoke-sdp 2:200 endpoint Y
precedence 1
spoke-sdp 3:300 endpoint Y
precedence 1
T-PE2
configure service epipe 1
endpoint X
exit
endpoint Y
revert-time 100
standby-signaling-slave
exit
sap 2/2/2:200 endpoint X
spoke-sdp 4:400 endpoint Y
precedence primary
spoke-sdp 5:500 endpoint Y
precedence 1
spoke-sdp 6:600 endpoint Y
precedence 1
S-PE1
VC switching indicates a VC cross-connect so that the service manager does not
signal the VC label mapping immediately but will put this into passive mode.
configure service epipe 1 vc-switching
spoke-sdp 1:100
spoke-sdp 4:400
2.9.9
Pseudo-wire SAPs
Refer to the Layer 3 Services Guide for details of how to use pseudo-wire SAPs with
Layer-2 services.
Issue: 01
3HE 11970 AAAA TQZZA 01
99
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
2.9.10
Epipe Using BGP-MH Site Support for Ethernet
Tunnels
Using Epipe in combination with G.8031 and BGP Multi-Homing in the same manner
as VPLS offers a multi-chassis resiliency option for Epipe services that is a nonlearning and non-flooded service. Note that MC-LAG (see, Access Node Resilience
Using MC-LAG and Pseudo-wire Redundancy) offers access node redundancy with
active/stand-by links while Ethernet Tunnels offers per service redundancy with all
active links and active or standby services. G.8031 offers an end to end service
resiliency for Epipe and VPLS services. BGP-MH Site Support for Ethernet Tunnels
offers Ethernet edge resiliency for Epipe services that integrates with MPLS Pseudowire Redundancy.
Figure 29 shows the BGP-MH Site Support for Ethernet Tunnels; where a G.8031
edge device (A) is configure to two provider edge switches (B and C). G.8031 is
configured on the Access devices (A and F). An Epipe Endpoint service is configured
along with BGP Multi-homing and Pseudo-wire Redundancy on the provider edge
nodes (B,C and D,E). This configuration offers a fully redundant Epipe service.
Figure 29
BGP-MH Site Support for Ethernet Tunnels
Provider Edge
B
Site 1
SAP
Oper Up
Provider Edge
D
Endpoint
Endpoint
Epipe
Site 2
SAP
Epipe
Oper Up
A
SAP
F
MPLS
PW Resiliency
SAP
G.8031
Standby
SAP
BGP-MH
C
BGP-MH
E
Epipe
Epipe
SAP
Endpoint
Endpoint
Standby
SAP
G.8031
SAP
OSSG750
100
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
2.9.10.1
VLL Services
Operational Overview
G.8031offers a number of redundant configurations. Normally it offers the ability to
control two independent paths for 1:1 protection. In the BGP-MH Site Support for
Ethernet Tunnels case, BGP drives G.8031 as a slave service. In this case, the
Provider Edge operates using only standard 802.1ag MEPs with CCM to monitor the
paths. Figure 30 shows an Epipe service on a Customer Edge (CE) device that uses
G.8031 with two paths and two MEPs. The Paths can use a single VLAN of DOT1Q
or QinQ encapsulation.
Figure 30
G.8031 for Slave Operation
CE A
PE B
Epipe
VLAN 100
Data and
Control
MEP
Epipe
Endpoint
SAP
Path a
MEP
SAP
G.8031
SAP
Path b
MEP
MEP
VLAN 101
Data and
Control
Epipe
Endpoint
SAP
PE C
OSSG749
In a single-service deployment the control (CFM) and data will share the same port
and VID. For multiple services for scaling fate sharing is allowed between multiple
SAPs, but all SAPs within a group must be on the same physical port.
To get fate sharing for multiple services with this feature, a dedicated G.8031 CE
based service (one VLAN) is connect to a Epipe SAP on a PE which uses BGP-MH
and operational groups to control other G.8031 tunnels. This dedicated G.8031 still
has a data control capabilities, but the data Epipe service is not bearing user data
packets. On the CE, this dedicated G.8031 is only used for group control. The choice
of making this a dedicated Control for a set of G.8031 tunnels is merely to simplify
operation and allow individual disabling of services. Using a dedicated G.8031 for
both control and to carry data traffic is allowed.
Issue: 01
3HE 11970 AAAA TQZZA 01
101
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
Fate sharing from the PE side is achieved using BGP and operational groups.
G.8031 Epipe services can be configured on the CE as regular non-fate shared
G.8031 services but due to the configuration on the PE side, these Ethernet Tunnels
will be treated as a group following the one designated control service. The G.8031
control logic on the CE is slaved to the BGP-MH control.
On the CE G.8031 allows independent configuration of VIDs on each path. On the
PE the Epipe or Endpoint that connects to the G.8031 must have a SAP with the
corresponding VID. If the G.8031 service has a Maintenance End Point (MEP) for
that VID, the SAP should be configured with a MEP. The MEPs on the paths on the
CE signal standard interface status TLV (ifStatusTLV), No Fault (Up) and Fault
(Down). The MEPs on the PE (Epipe or Endpoint) also use signaling of ifStatusTlv
No Fault, and Fault to control the G.8031 SAP. However in the 7750 SR, 7450 ESS,
and 7950 XRS model fate shared Ethernet Tunnels with no MEP are allowed. In this
case it is up to the CE to manage these CE based fate shared tunnels.
Interfaces status signaling (ifStatusTLV) is used to control the G.8031 tunnel form the
PE side. Normally the CE will signal No Fault in the path SAP MEP inStatusTLV
before the BGP-MH will cause the SAP MEP to become active by signaling No Fault.
2.9.10.2
Detailed Operation
For this feature, BGP-MH is used the master control and the Ethernet Tunnel is a
slave. The G.8031 on the CE is unaware that it is being controlled. While a single
Epipe service is configured and will serve as the control for the CE connection
allowing fate sharing all signaling to the CE is based on the ifstatusTLV per G.8031
tunnel. Note with G.8031 by controlling it with BGP-MH, the G.8031 CE is forced to
be slaved to the PE BGP-MH election.BGP-MH election is control by the received
VPLS preference or BGP local-preference or PE Id (IP address of Provider Edge) if
local-preference is equal. There may be traps generated on the CE side for some
G.8031 implementations but these can be suppressed or filtered to allow this feature
to operate.
There are two configuration options:
• Every G.8031 service SAP terminates on a single Epipe that has BGP-MH.
These Epipes may utilize endpoints with or without ICBs.
• A control Epipe service that monitors a single SAP that is used for group control
of fate shared CE services. In this case, the Epipe service has a SAP that serves
as the control termination for one Ethernet Tunnel connection. The group fate
sharing SAPs may or may not have MEPs if they use shared fate. In this case
the Epipe may have endpoints but will not support ICBs.
102
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
The MEP ifStatusTlv and CCM are used for monitoring the PE to CE SAP. MEP
ifStatusTlv is used to signal, the Ethernet Tunnel inactive and is used CCM as an
aliveness mechanism. There is no G.8031 logic on the PE, the SAP is simply
controlling the correspond CE SAP.
2.9.10.2.1
Sample Operation of G.8031 BGP-MH
Any Ethernet tunnel actions (force, lock) on the CE (single site) do not control the
action to switch paths directly but they may influence the outcome of BGP-MH if they
are on a control tunnel. If a path is disabled on the CE the result may force the SAP
with an MEP on the PE to eventually take the SAP down but it is suggested to run
commands from the BGP-MH side to control these connections.
Figure 31
Full Redundancy G.8031 Epipe & BGP-MH
B
SAP x
A
Oper Up
G.8031
PW
PW
PW
PW
y
x
Epipe
ICB ICB
BGP
SAP
SAP
D
Epipe
ICB ICB
BGP
MH
ICB ICB
Epipe
Standby
SAP x
y SAP
MH
ICB ICB
Epipe
PW
PW
PW
PW
y
F
SAP
SAP
Oper Up
G.8031
SAP
x
C
Standby
y SAP
E
OSSG751
Table 9 lists the SAP MEP signaling shown in Figure 31. For a description of the
events shown in this sample operation, see Events in Sample Operation.
Table 9
SAP MEP Signaling
G.8031 ET on CE
Path A MEP
Facing Node B
Local ifStatus
Path B MEP
Facing Node
C Local
ifStatus
Path B PE MEP
ifStatus
Path B PE MEP
ifStatus
1
Down (inactive)
No Fault 1
No Fault
Fault
Fault
2
Up use Path A
No Fault
No Fault
No Fault
Fault
Issue: 01
3HE 11970 AAAA TQZZA 01
103
VLL Services
Table 9
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
SAP MEP Signaling (Continued)
G.8031 ET on CE
Path A MEP
Facing Node B
Local ifStatus
Path B MEP
Facing Node
C Local
ifStatus
Path B PE MEP
ifStatus
Path B PE MEP
ifStatus
3
Up use Path B
No Fault
No Fault
Fault
No Fault
4
Down Path a fault
Fault 2
No Fault
Fault
Fault
5
Down Path A & B
fault at A
Fault
No Fault
Fault
Fault
6
Partitioned Network
Use Path
Precedence
Up use Path A
No Fault
No Fault
No Fault
No Fault
Notes:
1. No Fault = no ifStatusTlv transmit | CCM transmit normally
2. Fault = ifStatusTlv transmit down | no CCM transmit
Events in Sample Operation
The following represents a walk through of the events for switchover in Figure 31.
This configuration uses operational groups. The nodes of interest are A, B and C
listed in Table 9.
1. A single G.8031 SAP that represents the control for a group of G.8031 SAPs is
configured on the CE.
− The Control SAP does not normally carry any data, however it can if
desired.
− An Epipe service is provisioned on each PE node (B,C) purely for control
(no customer traffic flows over this service).
− On CE A, there is an Epipe Ethernet Tunnel (G.8031) control SAP.
− The Ethernet Tunnel has two paths:
• one facing B
• one facing C.
− PE B has an Epipe control SAP that is controlled by BGP-MH site and PE
C also has the corresponding SAP that is controlled by the same BGP-MH
site.
104
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
2. At node A, there are MEPs configured under each path that check connectivity
on the A-B and A-C links. At nodes B and C, there is a MEP configured under
their respective SAPs with fault propagation enabled with use ifStatusTlv.
3. Initially, assume there is no link failure:
− SAPs on node A have ifStatusTlv No Fault to B and C (no MEP fault
detected at A); see Table 9 row 1 (Fault is signaled in the other direction PE
to CE).
− BGP-MH makes its determination of the master or Designated Forwarder
(DF).
− Assume SAP on node B is picked as the DF.
− The MEP at Path A-B signals ifStatusTlv No Fault. Due to this signal, the
MEP under the node A path facing node B, detects the path to node B is
usable by the path manager on A.
4. At the CE node A, Path A-C becomes standby and is brought down; see Table 9
row 2.
− Since fault propagation is enabled under the SAP node C MEP, and
ifStatusTlv is operationally Down is remains in the present state.
− Under these conditions, the MEP under the node A path facing node C
detects the fault and informs Ethernet manager on node A.
− Node A then considers bringing path A-C down.
− ET port remains up since path A-B is operationally up. This is a stable state.
5. On nodes B and C, each Epipe controlled SAP is the sole (controlling) member
of an operational-group.
− Other data SAPs may be configured for fate shared VLANs (Ethernet
Tunnels) and to monitor the control SAP.
− The SAPs facing the CE node A share the fate of the control SAP and follow
the operation.
6. If there is a break in path A-B connectivity (CCM time out or LOS on the port for
link A-B), then on node A the path MEP detects connectivity failure and informs
Ethernet Tunnel Manger; see Table 9 row 4.
7. At this point the Ethernet Tunnel is down since both path A-B and path A-C are
down.
8. The CE node A Ethernet Tunnel goes down.
9. Node B on the PE the SAP also detects the failure and the propagation of fault
status goes to BGP-MH; see Table 9 row 4.
10. This in turn feeds into BGP-MH which deems the site non-DF and makes the site
standby.
11. Since the SAP at Node B is standby, Service Manager feeds this to CFM, which
then propagates a Fault towards Node A. This is a cyclic fault propagation.
However, since path A-B is broken, the situation is stable; see Table 9 row 5.
Issue: 01
3HE 11970 AAAA TQZZA 01
105
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
12. There is traffic loss during the BGP-MH convergence.
− Load sharing mode is recommended when using a 7450 as a CE node A
device.
− BGP-MH signals that node C is now the DF; see Table 9 row 3.
13. BGP-MH on node C elects sap and bring it up.
14. ET port transitions to port A-C is operationally up. This is a stable state. The AC SAPs monitoring the operational-group on C transitions to operationally up.
Unidirectional failures: At point 6 the failure was detected at both ends. In the case
of a unidirectional failure, CCM times out on one side.
1. In the case where the PE detects the failure, it propagates the failure to BGPMH and the BGP-MH takes the site down causing the SAPs on the PE to signal
to the CE Fault.
2. In the case of G.8031 on the CE detecting the failure, it takes the tunnel down
and signals a fault to the PE, and then the SAP propagates that to BGP-MH.
2.9.10.3
BGP-MH Site Support for Ethernet Tunnels OperationalGroup Model
For operational groups, one or more services follow the controlling service. On node
A, there is an ET SAP facing nodes B/C, and on nodes B/C there are SAPs of the
Epipe on physical ports facing node A. Each of the PE data SAPs monitor their
respective operational groups, meaning they are operationally up, or down based on
the operational status of the control SAPs. On node A, since the data SAP is on the
ET logical port, it goes operationally down whenever the ET port goes down and
similarly for going operationally up.
Alternatively, an Epipe Service may be provisioned on each node for each G.8031
data SAP (one for one service with no fate sharing). On CE node A, there will be a
G.8031 Ethernet Tunnel. The Ethernet Tunnel has two paths: one facing node B and
one facing node C. This option is the same as the control SAP, but there are no
operational groups. However, now there is a BGP-MH Site per service. For large
sites operational groups are more efficient.
106
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
2.9.10.4
VLL Services
BGP-MH Specifics for MH Site Support for Ethernet
Tunnels
BGP Multi-Homing for VPLS describes the procedures for using BGP to control
resiliency for VPLS. These procedures are the same except that an Epipe service
can be configured for BGP-MH.
2.9.10.5
PW Redundancy for BGP MH Site Support for Ethernet
Tunnels
Pseudo-wire Redundancy Service Models and VLL Resilience with Pseudo-wire
Redundancy and Switching are used for the MPLS network resiliency. BGP MH Site
Support for Ethernet Tunnels reuses this model.
2.9.10.6
T-LDP Status Notification Handling Rules of BGP-MH
Epipes
Using Figure 34 as a reference, the following are the rules for generating,
processing, and merging T-LDP status notifications in VLL service with endpoints.
2.9.10.6.1
Rules for Processing Endpoint SAP Active/Standby Status Bits
1. The advertised admin forwarding status of Active/Standby reflects the status of
the local Epipe SAP in BGP-MH instance. If the SAP is not part of a MC-LAG
instance or a BGP-MH instance, the forwarding status of Active is always
advertised.
2. When the SAP in endpoint X is part of a BGP-MH instance, a node must send
T-LDP forwarding status bit of SAP Active/Standby over all Y endpoint spoke
SDPs, except the ICB spoke SDP whenever this (BGP-MH designated
forwarder) status changes. The status bit sent over the ICB is always zero
(Active by default).
3. When the SAP in endpoint X is not part of a MC-LAG instance or BGP-MH
instance, then the forwarding status sent over all Y endpoint spoke SDPs should
always be set to zero (Active by default).
4. The received SAP Active/Standby status is saved and used for selecting the
active transmit endpoint object Pseudo-wire Redundancy procedures.
Issue: 01
3HE 11970 AAAA TQZZA 01
107
VLL Services
2.9.10.6.2
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
Rules for Processing, Merging Local, and Received Endpoint
Operational Status
1. Endpoint X is operationally Up if at least one of its objects is operationally Up. It
is Down if all its objects are operationally Down.
2. If the SAP in endpoint X transitions locally to the Down state, or received a SAP
Down notification via SAP specific OAM signal (SAP MEP), the node must send
T-LDP SAP Down status bits on the Y endpoint ICB spoke SDP only. BGP-MH
SAP support MEPs for
ifStatusTlv signaling. All other SAP types cannot exist on the same endpoint as
an ICB spoke SDP since non-Ethernet SAP cannot be part of a MC-LAG
instance or a BGP-MH Instance.
3. If the ICB spoke SDP in endpoint X transitions locally to Down state, the node
must send
T-LDP SDP-binding Down status bits on this spoke SDP.
4. If the ICB spoke SDP in endpoint X received T-LDP SDP-binding Down status
bits or
PW not forwarding status bits, the node saves this status and takes no further
action. The saved status is used for selecting the active transmit endpoint object
as per the pseudo-code per Pseudo-wire Redundancy procedures.
5. If all objects in endpoint X transition locally to Down state due to operator or
BGP-MH DF election, or received a SAP Down notification via remote T-LDP
status bits or via SAP specific OAM signal (SAP MEP), or received status bits of
SDP-binding Down, or received status bits of PW not forwarding, the node must
send status bits of SAP Down over all Y endpoint spoke SDPs, including the
ICB.
6. Endpoint Y is operationally Up if at least one of its objects is operationally Up. It
is Down if all its objects are operationally Down.
7. If a spoke SDP in endpoint Y, including the ICB spoke SDP, transitions locally
to Down state, the node must send T-LDP SDP-binding Down status bits on this
spoke SDP.
8. If a spoke SDP in endpoint Y, including the ICB spoke SDP, received T-LDP
SAP Down status bits, or received T-LDP SDP-binding Down status bits, or
received status bits of PW not forwarding, the node saves this status and takes
no further action. The saved status is used for selecting the active transmit
endpoint object as per Pseudo-wire Redundancy procedures.
9. If all objects in endpoint Y, except the ICB spoke SDP, transition locally to Down
state, or received T-LDP SAP Down status bits, or received T-LDP SDP-binding
Down status bits, and/or received status bits of PW not forwarding, the node
must send status bits of SDP-binding Down over the X endpoint ICB spoke SDP
only.
108
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
10. If all objects in endpoint Y transition locally to Down state, or received T-LDP
SAP Down status bits, or received T-LDP SDP-binding Down status bits, or
received status bits of PW not forwarding, the node must send status bits of
SDP-binding Down over the X endpoint ICB spoke SDP, and must send a SAP
Down notification on the X endpoint SAP via the SAP specific OAM signal in this
case the SAP MEP ifStatusTlv operationally-Down and also signal the BGP-MH
Site, if this SAP is part of a BGP Site.
2.9.10.6.3
Operation for BGP MH Site Support for Ethernet Tunnels
A multi-homed site can be configured on up to four PEs although two PEs are
sufficient for most applications with each PE having a single object SAP connecting
to the multi-homed site. Note that SR OS G.8031 implementation with load sharing
allows multiple PEs as well. The designated forwarder election chooses a single
connection to be operationally up with the other placed in standby. Only revertive
behavior is supported in this release.
Fate-sharing (the status of one site can be inherited from another site) is achievable
using monitor-groups.
The following are supported:
• All Ethernet-tunnels G.8031 SAPs on CE:
− 7750 SR, 7450 ESS, or 7950 XRS G.8031 in load sharing mode
(recommended)
− 7750 SR, 7450 ESS, or 7950 XRS G.8031 in non-load sharing mode
• Epipe and Endpoint with SAPs on PE devices.
• Endpoints with PW.
• Endpoints with active/standby PWs.
There are the following constraints with this feature:
• Not supported with PBB Epipes.
• Spoke SDP (pseudo-wire).
− BGP signaling is not supported.
− Cannot use BGP MH for auto-discovered pseudo-wire. This is achieved in
a VPLS service using SHGs, which are not available in Epipes.
• Other multi-chassis redundancy features are not supported on the multi-homed
site object, namely:
− MC-LAG
− MC-EP
Issue: 01
3HE 11970 AAAA TQZZA 01
109
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
− MC-ring
− MC-APS
• Master and Slave pseudo-wire is not supported.
Figure 32
Sample Topology Full Redundancy
1/1/2
1/1/4
Node-1: PE
Sys: 1.1.1.1/32
1/1/3
1/1/2
1/1/6
1/1/4
Node-4: P
Sys: 1.1.1.4/32
1/1/1
1/1/5
1/1/1
1/1/3
1/1/3
1/1/1
1/1/3
1/1/1
1/1/5
1/1/6
1/1/3
Node-3: CE
1/1/1
Sys: 1.1.1.3/32
1/1/2
1/1/4
1/1/2
1/1/4
Node-2: PE
Sys: 1.1.1.2/32
1/1/5
1/1/4
1/1/6
1/1/2
Node-5: P
Sys: 1.1.1.5/32
1/1/5
1/1/6
OSSG752
Refer to Configuration Examples for configuration examples derived from Figure 32.
Configuration Examples
Node-1: Using operational groups and Ethernet CFM per SAP
#-------------------------------------------------echo "Eth-CFM Configuration"
#-------------------------------------------------eth-cfm
domain 100 format none level 3
association 2 format icc-based name "node-3-site-1-0"
bridge-identifier 1
exit
remote-mepid 310
exit
association 2 format icc-based name "node-3-site-1-1"
bridge-identifier 100
exit
remote-mepid 311
exit
exit
110
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
exit
#-------------------------------------------------echo "Service Configuration"
#-------------------------------------------------service
customer 1 create
description "Default customer"
exit
sdp 2 mpls create
far-end 1.1.1.4
lsp "to-node-4-lsp-1"
keep-alive
shutdown
exit
no shutdown
exit
sdp 3 mpls create // Etcetera
pw-template 1 create
vc-type vlan
exit
oper-group "og-name-et" create
exit
oper-group "og-name-et100" create
exit
epipe 1 customer 1 create
service-mtu 500
bgp
route-distinguisher 65000:1
route-target export target:65000:1 import target:65000:1
exit
site "site-1" create
site-id 1
sap 1/1/2:1.1
boot-timer 100
site-activation-timer 2
no shutdown
exit
endpoint "x" create
exit
endpoint "y" create
exit
sap 1/1/2:1.1 endpoint "x" create
eth-cfm
mep 130 domain 100 association 2 direction down
fault-propagation-enable use-if-tlv
ccm-enable
no shutdown
exit
exit
oper-group "og-name-et"
exit
spoke-sdp 2:1 endpoint "y" create
precedence primary
no shutdown
exit
spoke-sdp 3:1 endpoint "y" create
precedence 2
Issue: 01
3HE 11970 AAAA TQZZA 01
111
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
no shutdown
exit
no shutdown
exit
epipe 100 customer 1 create
description "Epipe 100 in separate opergroup"
service-mtu 500
bgp
route-distinguisher 65000:2
route-target export target:65000:2 import target:65000:2
exit
site "site-name-et100" create
site-id 1101
sap 1/1/4:1.100
boot-timer 100
site-activation-timer 2
no shutdown
exit
endpoint "x" create
exit
endpoint "y" create
exit
sap 1/1/4:1.100 endpoint "x" create
eth-cfm
mep 131 domain 1 association 2 direction down
fault-propagation-enable use-if-tlv
ccm-enable
no shutdown
exit
exit
oper-group "og-name-et100"
exit
spoke-sdp 2:2 vc-type vlan endpoint "y" create
precedence 1
no shutdown
exit
spoke-sdp 3:2 vc-type vlan endpoint "y" create
precedence 2
no shutdown
exit
no shutdown
exit
exit
#-------------------------------------------------echo "BGP Configuration"
#-------------------------------------------------bgp
rapid-withdrawal
rapid-update l2-vpn
group "internal"
type internal
neighbor 1.1.1.2
family l2-vpn
exit
exit
exit
112
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
exit
Node-3: Using operational groups and Ethernet CFM per SAP
#-------------------------------------------------echo "Eth-CFM Configuration"
#-------------------------------------------------eth-cfm
domain 100 format none level 3
association 2 format icc-based name "node-3-site-1-0"
bridge-identifier 1
exit
ccm-interval 1
remote-mepid 130
exit
association 2 format icc-based name "node-3-site-1-1"
bridge-identifier 100
exit
ccm-interval 1
remote-mepid 131
association 3 format icc-based name "node-3-site-2-0"
bridge-identifier 1
exit
ccm-interval 1
remote-mepid 120
exit
association 3 format icc-based name "node-3-site-2-1"
bridge-identifier 100
exit
ccm-interval 1
remote-mepid 121
exit
exit
exit
#-------------------------------------------------echo "Service Configuration"
#-------------------------------------------------eth-tunnel 1
description "Eth Tunnel loadsharing mode QinQ example"
protection-type loadsharing
ethernet
encap-type qinq
exit
path 1
member 1/1/3
control-tag 1.1
eth-cfm
mep 310 domain 100 association 2
ccm-enable
control-mep
no shutdown
exit
exit
no shutdown
exit
path 2
Issue: 01
3HE 11970 AAAA TQZZA 01
113
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
member 1/1/4
control-tag 1.2
eth-cfm
mep 320 domain 100 association 3
ccm-enablepath
control-mep
no shutdown
exit
exit
no shutdown
exit
no shutdown
exit
#-------------------------------------------------echo "Ethernet Tunnel Configuration"
#-------------------------------------------------eth-tunnel 2
description "Eth Tunnel QinQ"
revert-time 10
path 1
precedence primary
member 1/1/1
control-tag 1.100
eth-cfm
mep 311 domain 100 association 2
ccm-enable
control-mep
no shutdown
exit
exit
no shutdown
exit
path 2
member 1/1/2
control-tag 1.100
eth-cfm
mep 321 domain 100 association 3
ccm-enable
control-mep
no shutdown
exit
exit
no shutdown
exit
no shutdown
exit
#-------------------------------------------------echo "Service Configuration"
#-------------------------------------------------service
epipe 1 customer 1 create
sap 2/1/2:1.1 create
exit
sap eth-tunnel-1 create
exit
no shutdown
exit
epipe 100 customer 1 create
service-mtu 500
114
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
sap 2/1/10:1.100 create
exit
sap eth-tunnel-2 create
exit
no shutdown
exit
Configuration with Fate Sharing on Node-3 In this example the SAPs monitoring the
operational groups do not need CFM if the corresponding SAP on the CE side is
using fate sharing.
Node-1:
#-------------------------------------------------echo "Service Configuration" Oper-groups
#-------------------------------------------------service
customer 1 create
description "Default customer"
exit
sdp 2 mpls create
...
exit
pw-template 1 create
vc-type vlan
exit
oper-group "og-name-et" create
exit
epipe 1 customer 1 create
service-mtu 500
bgp
route-distinguisher 65000:1
route-target export target:65000:1 import target:65000:1
exit
site "site-1" create
site-id 1
sap 1/1/2:1.1
boot-timer 100
site-activation-timer 2
no shutdown
exit
endpoint "x" create
exit
endpoint "y" create
exit
sap 1/1/2:1.1 endpoint "x" create
eth-cfm
mep 130 domain 100 association 1 direction down
fault-propagation-enable use-if-tlv
ccm-enable
no shutdown
exit
exit
oper-group "og-name-et"
exit
spoke-sdp 2:1 endpoint "y" create
Issue: 01
3HE 11970 AAAA TQZZA 01
115
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
precedence primary
no shutdown
exit
spoke-sdp 3:1 endpoint "y" create
precedence 2
no shutdown
exit
no shutdown
exit
epipe 2 customer 1 create
description "Epipe 2 in opergroup with Epipe 1"
service-mtu 500
bgp
route-distinguisher 65000:2
route-target export target:65000:2 import target:65000:2
exit
endpoint "x" create
exit
endpoint "y" create
exit
sap 1/1/2:1.2 endpoint "x" create
monitor-oper-group "og-name-et"
exit
spoke-sdp 2:2 vc-type vlan endpoint "y" create
precedence 1
no shutdown
exit
spoke-sdp 3:2 vc-type vlan endpoint "y" create
precedence 2
no shutdown
exit
no shutdown
exit
exit
Node-3:
#-------------------------------------------------echo "Eth-CFM Configuration"
#-------------------------------------------------eth-cfm
domain 100 format none level 3
association 1 format icc-based name "node-3-site-1-0"
bridge-identifier 1
exit
ccm-interval 1
remote-mepid 130
exit
association 2 format icc-based name "node-3-site-2-0"
bridge-identifier 2
exit
ccm-interval 1
remote-mepid 120
exit
exit
exit
116
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
#-------------------------------------------------echo "Service Configuration"
#-------------------------------------------------eth-tunnel 2
description "Eth Tunnel loadsharing mode QinQ example"
protection-type loadsharing
ethernet
encap-type qinq
exit
path 1
member 1/1/1
control-tag 1.1
eth-cfm
mep 310 domain 100 association 1
ccm-enable
control-mep
no shutdown
exit
exit
no shutdown
exit
path 2
member 1/1/2
control-tag 1.1
eth-cfm
mep 320 domain 100 association 2
ccm-enablepath
control-mep
no shutdown
exit
exit
no shutdown
exit
no shutdown
exit
#-------------------------------------------------echo "Service Configuration"
#-------------------------------------------------service
epipe 1 customer 1 create
sap 1/10/1:1 create
exit
sap eth-tunnel-1 create
exit
no shutdown
exit
#-------------------------------------------------echo "Service Configuration for a shared fate Ethernet Tunnel"
#-------------------------------------------------epipe 2 customer 1 create
sap 1/10/2:3 create
exit
sap eth-tunnel-1:2 create
eth-tunnel
path 1 tag 1.2
path 2 tag 1.2
Issue: 01
3HE 11970 AAAA TQZZA 01
117
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
exit
exit
no shutdown
exit
2.9.11
Access Node Resilience Using MC-LAG and
Pseudo-wire Redundancy
Figure 33 shows the use of both Multi-Chassis Link Aggregation (MC-LAG) in the
access network and pseudo-wire redundancy in the core network to provide a
resilient end-to-end VLL service to the customers.
118
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
Figure 33
VLL Services
Access Node Resilience
TLDP
Aggregation
node
A
Active
MSAN
Active
Standby
Active
Aggregation
node
C
Standby
Inter-chassis
PW for VLL
Standby
Inter-chassis
PW for VLL
MSAN
Active
Standby
Standby
Active
Aggregation
node
Standby
Active
B
Aggregation
node
D
TLDP
Aggregation
node
Aggregation
node
A
C
Active
MSAN
Inter-chassis
PW for VLL
Standby
Inter-chassis
PW for VLL
Standby
MSAN
Active
Aggregation
node
Aggregation
node
B
D
OSSG116
In this application, a new pseudo-wire status bit of active or standby indicates the
status of the SAP in the MC-LAG instance in the SR-Series aggregation node. All
spoke SDPs are of secondary type and there is no use of a primary pseudo-wire type
in this mode of operation. Node A is in the active state according to its local MC-LAG
instance and thus advertises active status notification messages to both its peer
pseudo-wire nodes, for example, nodes C and D. Node D performs the same
operation. Node B is in the standby state according to the status of the SAP in its
local MC-LAG instance and thus advertises standby status notification messages to
both nodes C and D. Node C performs the same operation.
Issue: 01
3HE 11970 AAAA TQZZA 01
119
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
An SR-Series node selects a pseudo-wire as the active path for forwarding packets
when both the local pseudo-wire status and the received remote pseudo-wire status
indicate active status. However, an SR-Series device in standby status according to
the SAP in its local MC-LAG instance is capable of processing packets for a VLL
service received over any of the pseudo-wires which are up. This is to avoid black
holing of user traffic during transitions. The SR-Series standby node forwards these
packets to the active node bye the Inter-Chassis Backup pseudo-wire (ICB pseudowire) for this VLL service. An ICB is a spoke SDP used by a MC-LAG node to backup
a MC-LAG SAP during transitions. The same ICB can also be used by the peer MCLAG node to protect against network failures causing the active pseudo-wire to go
down.
Note that at configuration time, the user specifies a precedence parameter for each
of the pseudo-wires which are part of the redundancy set as described in the
application in VLL Resilience with Two Destination PE Nodes. An SR-Series node
uses this to select which pseudo-wire to forward packet to in case both pseudo-wires
show active/active for the local/remote status during transitions.
Only VLL service of type Epipe is supported in this application. Furthermore, ICB
spoke SDP can only be added to the SAP side of the VLL cross-connect if the SAP
is configured on a MC-LAG instance.
2.9.12
VLL Resilience for a Switched Pseudo-wire Path
Figure 34 illustrates the use of both pseudo-wire redundancy and pseudo-wire
switching to provide a resilient VLL service across multiple IGP areas in a provider
network.
120
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
Figure 34
VLL Services
VLL Resilience with Pseudo-wire Redundancy and Switching
Primary PW
Access Node
Standby PW
7x50 T-PE2
Metro area B
SDP3:300
PW switching
7x50 T-PE3
SDP6:600
7x50
7x50
7x50 S-PE3
7x50 S-PE4
PW switching
Core area
PW switching
7x50 S-PE2
7x50 S-PE1
PW switching
SDP4:400
SDP1:100
7x50
7x50
Metro area A
7x50 T-PE1
7x50
Access Node
OSSG114
Pseudo-wire switching is a method for scaling a large network of VLL or VPLS
services by removing the need for a full mesh of T-LDP sessions between the PE
nodes as the number of these nodes grows over time.
Like in the application in VLL Resilience with Two Destination PE Nodes, the T-PE1
node switches the path of a VLL to a secondary standby pseudo-wire in the case of
a network side failure causing the VLL binding status to be DOWN or if T-PE2 notified
it that the remote SAP went down. This application requires that pseudo-wire status
notification messages generated by either a T-PE node or a S-PE node be
processed and relayed by the S-PE nodes.
Note that it is possible that the secondary pseudo-wire path terminates on the same
target PE as the primary, for example, T-PE2. This provides protection against
network side failures but not against a remote SAP failure. When the target
destination PE for the primary and secondary pseudo-wires is the same, T-PE1 will
normally not switch the VLL path onto the secondary pseudo-wire upon receipt of a
pseudo-wire status notification indicating the remote SAP is down since the status
notification is sent over both the primary and secondary pseudo-wires. However, the
status notification on the primary pseudo-wire may arrive earlier than the one on the
secondary pseudo-wire due to the differential delay between the paths. This will
Issue: 01
3HE 11970 AAAA TQZZA 01
121
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
cause T-PE1 to switch the path of the VLL to the secondary standby pseudo-wire and
remain there until the status notification is cleared. At that point in time, the VLL path
is switched back to the primary pseudo-wire due to the revertive behavior operation.
The path will not switch back to a secondary path when it becomes up even if it has
a higher precedence than the currently active secondary path.
For the 7750 SR, this application can make use of all types of VLL supported on the
routers, for example, Apipe, Fpipe, Epipe, and Ipipe services. A SAP can be
configured on SONET/SDH port which is part of an APS group. However, if a SAP is
configured on a MC-LAG instance, only the Epipe service type will be allowed.
2.10
Pseudo-wire Redundancy Service Models
This section describes the various MC-LAG and pseudo-wire redundancy scenarios
as well as the algorithm used to select the active transmit object in a VLL endpoint.
The redundant VLL service model is described in the following section, Redundant
VLL Service Model.
2.10.1
Redundant VLL Service Model
In order to implement pseudo-wire redundancy, a VLL service accommodates more
than a single object on the SAP side and on the spoke SDP side. Figure 35 illustrates
the model for a redundant VLL service based on the concept of endpoints.
122
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
Figure 35
VLL Services
Redundant VLL Endpoint Objects
VLL
SAP
Spoke-SDP
Spoke-SDP
ICB
spoke-sdp
Spoke-SDP
Spoke-SDP
Endpoint X
Endpoint Y
OSSG211
A VLL service supports by default two implicit endpoints managed internally by the
system. Each endpoint can only have one object, a SAP or a spoke SDP.
In order to add more objects, up to two (2) explicitly named endpoints may be created
per VLL service. The endpoint name is locally significant to the VLL service. They are
referred to as endpoint 'X' and endpoint 'Y' as illustrated in Figure 35.
Note that Figure 35 is merely an example and that the “Y” endpoint can also have a
SAP and/or an ICB spoke SDP. The following details the four types of endpoint
objects supported and the rules used when associating them with an endpoint of a
VLL service:
• SAP — There can only be a maximum of one SAP per VLL endpoint.
• Primary spoke SDP — The VLL service always uses this pseudo-wire and only
switches to a secondary pseudo-wire when it is down the VLL service switches
the path to the primary pseudo-wire when it is back up. The user can configure
a timer to delay reverting back to primary or to never revert. There can only be
a maximum of one primary spoke SDP per VLL endpoint.
• Secondary spoke SDP — There can be a maximum of four secondary spoke
SDP per endpoint. The user can configure the precedence of a secondary
pseudo-wire to indicate the order in which a secondary pseudo-wire is activated.
Issue: 01
3HE 11970 AAAA TQZZA 01
123
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
• Inter-Chassis Backup (ICB) spoke SDP — Special pseudo-wire used for MCLAG and pseudo-wire redundancy application. Forwarding between ICBs is
blocked on the same node. The user has to explicitly indicate the spoke SDP is
actually an ICB at creation time. There are however a few scenarios below
where the user can configure the spoke SDP as ICB or as a regular spoke SDP
on a given node. The CLI for those cases will indicate both options.
A VLL service endpoint can only use a single active object to transmit at any given
time but can receive from all endpoint objects
An explicitly named endpoint can have a maximum of one SAP and one ICB. Once
a SAP is added to the endpoint, only one more object of type ICB spoke SDP is
allowed. The ICB spoke SDP cannot be added to the endpoint if the SAP is not part
of a MC-LAG instance. Conversely, a SAP which is not part of a MC-LAG instance
cannot be added to an endpoint which already has an ICB spoke SDP.
An explicitly named endpoint, which does not have a SAP object, can have a
maximum of four spoke SDPs and can include any of the following:
• A single primary spoke SDP.
• One or many secondary spoke SDPs with precedence.
• A single ICB spoke SDP.
2.10.2
T-LDP Status Notification Handling Rules
Referring to Redundant VLL Endpoint Objects as a reference, the following are the
rules for generating, processing, and merging T-LDP status notifications in VLL
service with endpoints. Note that any allowed combination of objects as specified in
Redundant VLL Service Model can be used on endpoints “X” and “Y”. The following
sections refer to the specific combination objects in Figure 35 as an example to
describe the more general rules.
2.10.2.1
Processing Endpoint SAP Active/Standby Status Bits
The advertised admin forwarding status of active/standby reflects the status of the
local LAG SAP in MC-LAG application. If the SAP is not part of a MC-LAG instance,
the forwarding status of active is always advertised.
124
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
When the SAP in endpoint “X” is part of a MC-LAG instance, a node must send TLDP forwarding status bit of “SAP active/standby” over all “Y” endpoint spoke SDPs,
except the ICB spoke SDP, whenever this status changes. The status bit sent over
the ICB is always zero (active by default).
When the SAP in endpoint “X” is not part of a MC-LAG instance, then the forwarding
status sent over all “Y” endpoint spoke SDP's should always be set to zero (active by
default).
2.10.2.2
Processing and Merging
Endpoint “X” is operationally up if at least one of its objects is operationally up. It is
down if all its objects are operationally down.
If the SAP in endpoint “X” transitions locally to the down state, or received a SAP
down notification by SAP-specific OAM signal, the node must send T-LDP SAP down
status bits on the “Y” endpoint ICB spoke SDP only. Note that Ethernet SAP does not
support SAP OAM protocol. All other SAP types cannot exist on the same endpoint
as an ICB spoke SDP since a non-Ethernet SAP cannot be part of a MC-LAG
instance.
If the ICB spoke SDP in endpoint “X” transitions locally to down state, the node must
send T-LDP SDP-binding down status bits on this spoke SDP.
If the ICB spoke SDP in endpoint “X” received T-LDP SDP-binding down status bits
or pseudo-wire not forwarding status bits, the node saves this status and takes no
further action. The saved status is used for selecting the active transmit endpoint
object.
If all objects in endpoint “X” transition locally to down state, and/or received a SAP
down notification by remote T-LDP status bits or by SAP specific OAM signal, and/
or received status bits of SDP-binding down, and/or received status bits of pseudowire not forwarding, the node must send status bits of SAP down over all “Y” endpoint
spoke SDPs, including the ICB.
Endpoint “Y” is operationally up if at least one of its objects is operationally up. It is
down if all its objects are operationally down.
If a spoke SDP in endpoint “Y”, including the ICB spoke SDP, transitions locally to
down state, the node must send T-LDP SDP-binding down status bits on this spoke
SDP.
Issue: 01
3HE 11970 AAAA TQZZA 01
125
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
If a spoke SDP in endpoint “Y”, including the ICB spoke SDP, received T-LDP SAP
down status bits, and/or received T-LDP SDP-binding down status bits, and/or
received status bits of pseudo-wire not forwarding, the node saves this status and
takes no further action. The saved status is used for selecting the active transmit
endpoint object.
If all objects in endpoint “Y”, except the ICB spoke SDP, transition locally to down
state, and/or received T-LDP SAP down status bits, and/or received T-LDP SDPbinding down status bits, and/or received status bits of pseudo-wire not forwarding,
the node must send status bits of SDP-binding down over the “X” endpoint ICB spoke
SDP only.
If all objects in endpoint “Y” transition locally to down state, and/or received T-LDP
SAP down status bits, and/or received T-LDP SDP-binding down status bits, and/or
received status bits of pseudo-wire not forwarding, the node must send status bits of
SDP-binding down over the “X” endpoint ICB spoke SDP, and must send a SAP
down notification on the “X” endpoint SAP by the SAP specific OAM signal if
applicable. An Ethernet SAP does not support signaling status notifications.
2.11
High-Speed Downlink Packet Access
(HSDPA) Off Load Fallback over ATM
For many Universal Mobile Telecommunications System (UMTS) networks planning
to deploy High-Speed Downlink Packet Access (HSDPA), the existing mobile
backhaul topology consists of a cell site that is partially backhauled over DSL (for the
HSDPA portion) and partially over an existing TDM/ATM infrastructure (for UMTS
voice traffic).
126
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
Figure 36
HSDPA Off Load Fallback over ATM
ATM orTDM
(no IP/MPLS)
Cell Site
7705 SAR
ATM
ETH
VLL Services
SAP
PW
SDP
ATM
ATM
ETH
ETH
SAP
PW
MSC Site
7750 SR
ATM
ETH
SDP
IP / MPLS
ATM PW
ETH PW
BFD for T-LDP
OSSG483
For example, the service pseudo-wires provider may use a 7705 SAR with one or
two ATM E1 uplinks for real-time voice traffic and an Ethernet uplink connected to a
DSL model for NRT data traffic. At the RNC site, a 7750 SR service router can be
used, connected by ASAP (E1 IMA bundles) or STM-n ATM to the TDM/ATM
network, and Ethernet to the DSL backhaul network.
On the MSC-located SR connected to the Radio Network Controller (RNC), there is
a standard pseudo-wire (Ethernet or ATM) which has an active pseudo-wire by IP/
MPLS, but the standby path is not IP/MPLS capable Therefore, the active/standby
pseudo-wire concept is extended to allow standby to be an access SAP to an ATM
network for ATM pseudo-wire or Ethernet (bridged over ATM) for ETH pseudo-wire.
Normally, if the MPLS pseudo-wire path is active, this is taken. If a failure happens
on the IP/MPLS path, detected through BFD-TLDP or local notification, we need to
switch to the SAP which is connected to the ATM/TDM backhaul network As soon as
the MPLS pseudo-wire path becomes available again, reversion back to the pseudowire path is supported.
Issue: 01
3HE 11970 AAAA TQZZA 01
127
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
2.11.1
Primary Spoke SDP Fallback to Secondary SAP
For HSDPA, Apipe and Epipe service termination on the SR where an endpoint-X
SAP connects to the mobile RNC (by ATM or Ethernet) and an endpoint Y has a
primary spoke SDP and a secondary SAP on an SR ATM or ASAP MDA (with
bridged PDU encapsulation for Epipes). The secondary SAP has the same
restrictions as the SAP in endpoint-X for Apipe and Epipe respectively.
It sufficient to have a single secondary SAP (without any precedence) which implies
it can not be mixed with any secondary spoke SDPs 1+1 APS and MC-APS is
supported on the secondary SAP interface.
Similar to the current pseudo-wire redundancy implementation, receive should be
enabled on both objects even though transmit is only enabled on one.
It is expected that BFD for T-LDP [bfd-for-tldp] will be used in most applications to
decrease the fault detection times and minimize the outage times upon failure.
2.11.2
Reversion to Primary Spoke SDP Path
The endpoint revert-time reversion from secondary to primary paths in the
config>service>apipe>endpoint and config>service>epipe>endpoint contexts
are consistent with standard pseudo-wire redundancy. Various network
configurations and equipment require different reversion configurations. The default
revert-time is 0.
2.11.3
MC-APS and MC-LAG
In many cases, 7750 SRs are deployed in redundant pairs at the MSC. In this case,
MC-APS is typically used for all ATM connections. Figure 37 illustrates this case
assuming that MC-APS is deployed on both the RNC connection and the ATM
network connection. For MC-APS to be used, clear channel SONET or SDH
connections should be used.
128
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
Figure 37
VLL Services
HSDPA Off Load Fallback with MC-APS
7750 SR #1
apipe
epipe
Endpoint Endpoint
Y
X
Endpoint
X
SDP1
Endpoint
Y
SAP1
MPLS Network
SDP1
HSPA
NodeB
SDP2
SAP
ICBA
ICBB
ATM
MCAPS RNC
SAP
SAP
7705 SAR
apipe
epipe
ETH
L2 Switched
Network
MCAPS
ICBB
ICBA
SDP2
SAP
SAP2
Endpoint Endpoint
Y
X
7750 SR #2
apipe
epipe
OSSG484
In this scenario, endpoint Y allows the addition of an ICB spoke SDP in addition to
the primary spoke SDP and secondary SAP. ICB operation is maintained as the
current redundant pseudo-wire operation and the ICB spoke SDP is always given an
active status. The ICB spoke SDP is only used if both the primary spoke SDP and
secondary SAP are not available. The secondary SAP is used if it is operationally up
and the primary spoke SDP pseudo-wire status is not active. The receive is enabled
on all objects even though transmit is only enabled on one.
To allow proper operation in all failure scenarios, an ICB spoke SDP must be added
to endpoint X. The ICB spoke SDP is only used if the SAP is operationally down.
The following is an example configuration of Epipes mapping to Figure 37. Note that
a SAP can be added to an endpoint with a non-ICB spoke SDP only if the spoke's
precedence is primary.
7750 SR#1:
*A:ALA-A>config>service# epipe 1
---------------------------------------------endpoint X
exit
endpoint Y
exit
Issue: 01
3HE 11970 AAAA TQZZA 01
129
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
sap 1/1/2:0 endpoint X
exit
spoke-sdp 1:100 endpoint X icb
exit
spoke-sdp 10:500 endpoint Y
precedence primary
exit
sap 1/1/3:0 endpoint Y
exit
spoke-sdp 1:200 endpoint Y icb
exit
---------------------------------------------*A:ALA-A>config>service#
7750 SR#2
*A:ALA-B>config>service# epipe 1
---------------------------------------------endpoint X
exit
endpoint Y
exit
sap 2/3/4:0 endpoint X
exit
spoke-sdp 1:200 endpoint X icb
exit
spoke-sdp 20:600 endpoint Y
precedence primary
exit
sap 2/3/5:0 endpoint Y
exit
spoke-sdp 1:100 endpoint Y icb
exit
---------------------------------------------*A:ALA-B>config>service#
2.11.3.1
Failure Scenarios
Following the before mentioned rules, the following are examples of a failure
scenario operation. Assuming both links are active on 7750 SR#1 and the Ethernet
connection to the cell site fails (most likely failure scenario as it would not be
protected), SDP1 would go down and the secondary SAP would be used in
7750 SR#1 and 7705 SAR as shown in Figure 38.
130
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
Figure 38
VLL Services
Ethernet Failure At Cell Site
7750 SR #1
apipe
epipe
Endpoint Endpoint
Y
X
Endpoint
X
SDP1
HSPA
NodeB
SDP1
Endpoint
Y
SAP
SAP1
Active
MPLS Network
ICBA
ICBB
SDP2
MCAPS RNC
SAP
Active
SAP
7705 SAR
apipe
epipe
L2 Switched
Network
MCAPS
Standby
ICBB
ICBA
SDP2
SAP
Standby
SAP2
Endpoint Endpoint
Y
X
7750 SR #2
apipe
epipe
OSSG485
If the active link to the Layer 2 switched network was on 7750 SR#2 at the time of the
failure, SAP1 would be operationally down (as the link is in standby) and ICBA would
be used. As the RNC SAP on 7750 SR#2 is on a standby APS link, ICBA would be
active and it would connect to SAP2 as SDP2 is operationally down as well.
All APS link failures would be handled through the standard pseudo-wire status
messaging procedures for the RNC connection and through standard ICB usage for
the Layer 2 switched network connection.
2.12
VLL Using G.8031 Protected Ethernet Tunnels
The use of MPLS tunnels provides the 7450 ESS and 7750 SR OS a way to scale
the core while offering fast failover times using MPLS FRR. In environments where
Ethernet services are deployed using native Ethernet backbones, Ethernet tunnels
are provided to achieve the same fast failover times as in the MPLS FRR case.
Issue: 01
3HE 11970 AAAA TQZZA 01
131
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
The Nokia VLL implementation offers the capability to use core Ethernet tunnels
compliant with ITU-T G.8031 specification to achieve 50 ms resiliency for backbone
failures. This is required to comply with the stringent SLAs provided by service
providers in the current competitive environment. Epipe and Ipipe services are
supported.
When using Ethernet Tunnels, the Ethernet Tunnel logical interface is created first.
The Ethernet tunnel has member ports which are the physical ports supporting the
links. The Ethernet tunnel control SAPs carries G.8031 and 802.1ag control traffic
and user data traffic. Ethernet service SAPs are configured on the Ethernet tunnel.
Optionally when tunnels follow the same paths end to end services may be
configured with, same-fate Ethernet tunnel SAPs which carry only user data traffic
and shares the fate of the Ethernet tunnel port (if properly configured).
Ethernet tunnels provide a logical interface that VLL SAPs may use just as regular
interfaces. The Ethernet tunnel provides resiliency by providing end to end tunnels.
The tunnels are stitched together by VPLS or Epipe services at intermediate points.
Epipes offer a more scalable option.
For further information, see the 7450 ESS, 7750 SR, and 7950 XRS Services
Overview Guide.
2.13
MPLS Entropy Label and Hash Label
The router supports the MPLS entropy label (RFC 6790) and the Flow Aware
Transport label (known as the hash label) (RFC 6391). These labels allow LSR
nodes in a network to load-balance labeled packets in a much more granular fashion
than allowed by simply hashing on the standard label stack. See the MPLS Guide for
further information.
2.14
BGP Virtual Private Wire Service (VPWS)
BGP Virtual Private Wire Service (VPWS) is a point-to-point L2 VPN service based
on RFC 6624 (Layer 2 Virtual Private Networks using BGP for Auto-Discovery and
Signaling) which in turn uses the BGP pseudo-wire signaling concepts from RFC
4761, Virtual Private LAN Service Using BGP for Auto-Discovery and Signaling.
132
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
2.14.1
VLL Services
Single-Homed BGP VPWS
A single-homed BGP VPWS service is implemented as an Epipe connecting a SAP
or static GRE tunnel (a spoke SDP using a GRE SDP configured with static MPLS
labels) and a BGP signaled pseudo-wire, maintaining the Epipe properties such as
no MAC learning. The pseudo-wire data plane uses a two label stack, the inner label
is derived from the BGP signaling and identifies the Epipe service while the outer
label is the tunnel label of an LSP transporting the traffic between the two end
systems.
Figure 39 shows how this service would be used to provide a virtual lease-line
service across an MPLS network between two sites, A and B.
Figure 39
Single-Homed BGP-VPWS Example
ve-id=1
rd=65536:1
rt=65536:1
ve-id=2
rd=65536:2
rt=65536:1
PE1
Site A
SAP 1/1/1:1
epipe
PE2
Spoke-SDP
Spoke-SDP
epipe
SAP 1/1/1:1
Site B
SR_QPD_0001
An Epipe is configured on PE1 and PE2 with BGP VPWS enabled. PE1 and PE2 are
connected to site A and B, respectively, each using a SAP. The interconnection
between the two PEs is achieved through a pseudo-wire which is signaled using
BGP VPWS updates over a given tunnel LSP.
2.14.2
Dual-Homed BGP VPWS
A BGP-VPWS service can benefit from dual-homing, as described in draft-ietf-l2vpnvpls-multihoming-03. When using dual-homing, two PEs connect to a site with one
PE being the designated forwarder for the site and the other blocking its connection
to the site. On failure of the active PE, its pseudo-wire or its connection to the site,
the other PE becomes the designated forwarder and unblocks its connection to the
site.
Single Pseudo-wire Example:
Issue: 01
3HE 11970 AAAA TQZZA 01
133
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
A pseudo-wire is established between the designated forwarder of the dual-homed
PEs and the remote PE. If a failure causes a change in the designated forwarder, the
pseudo-wire is deleted and re-established between the remote PE and the new
designated forwarder. This topology requires that the VE IDs on the dual-homed PEs
are set to the same value.
An example is shown in Figure 40.
Figure 40
Dual-Homed BGP VPWS with Single Pseudo-wire
ve-id=1
mh-id=1
rd=65536:1
rt=65536:1
PE1
Designated
Forwarder
SAP
epipe
Spoke-SDP
Site A
epipe
PE2
Blocked
PE3
SAP
epipe
SAP
Site B
ve-id=3
rd=65536:3
rt=65536:1
ve-id=1
mh-id=1
rd=65536:2
rt=65536:1
SR_QPD_0002
An Epipe with BGP VPWS enabled is configured on each PE. Site A is dual-homed
to PE1 and PE2 with the remote PE, PE3, connecting to site B. An Epipe service is
configured on each PE in which there is a SAP connecting to the local site.
The pair of dual-homed PEs perform a designated forwarder election, which is
influenced by BGP route selection, the site state, and by configuring the sitepreference. A site will only be eligible to be the designated forwarder if it is up (note
that the site state will be down if there is no pseudo-wire established or if the pseudowire is in an oper down state). The winner, for example PE1, becomes the active
switch for traffic sent to and from site A, while the loser blocks its connection to site
A. Pseudo-wires are signaled using BGP from PE1 and PE2 to PE3 but only from
PE3 to the designated forwarder in the opposite direction (thereby only one bidirectional pseudo-wire is established). There is no pseudo-wire between PE1 and
PE2; this is achieved by configuration.
Traffic is sent and received traffic on the pseudo-wire connected between PE3 and
the designated forwarder, PE1.
134
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
If the site state is oper down then both the D and CSV bits (see below for more
details) are set in the BGP-VPWS update which will cause the remote PE to use the
pseudo-wire to the new designated forwarder.
Active/Standby Pseudo-wire Example:
Pseudo-wires are established between the remote PE and each dual-homed PE.
The remote PE can receive traffic on either pseudo-wire but will only send on the one
to the designated forwarder. This creates an active/standby pair of pseudo-wires. At
most one standby pseudo-wire will be established; this being determined using the
tie-breaking rules defined in the multi-homing draft. This topology requires each PE
to have a different VE ID.
A dual-homed topology example is shown in Figure 41.
Figure 41
Dual-homed BGP VPWS with Active/Standby Pseudo-wires
ve-id=1
mh-id=1
rd=65536:1
rt=65536:1
site-preference 200
PE1
SAP
epipe
Designated
Forwarder
Active Spoke-SDP
Site A
epipe
PE2
Blocked
PE3
Standby Spoke-SDP
SAP
epipe
SAP
Site B
ve-id=3
rd=65536:3
rt=65536:1
ve-id=2
mh-id=1
rd=65536:2
rt=65536:1
site-preference 10
SR_QPD_0003
An Epipe with BGP VPWS enabled is configured on each PE. Site A is dual-homed
to PE1 and PE2 with the remote PE, PE3, connecting to site B. An Epipe service is
configured on each PE in which there is a SAP connecting to the local site.
Issue: 01
3HE 11970 AAAA TQZZA 01
135
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
The pair of dual-homed PEs perform a designated forwarder election, which is
influenced by configuring the site-preference. The winner, PE1 (based on its higher
site-preference) becomes the active switch for traffic sent to and from site A, while
the loser, PE2, blocks its connection to site A. Pseudo-wires are signaled using BGP
between PE1 and PE3, and between PE2 and PE3. There is no pseudo-wire
between PE1 and PE2; this is achieved by configuration. The active/standby
pseudo-wires on PE3 are part of an endpoint automatically created in the Epipe
service.
Traffic is sent and received traffic on the pseudo-wire connected to the designated
forwarder, PE1.
2.14.3
BGP VPWS Pseudo-wire Switching
Pseudo-wire switching is supported with a BGP VPWS service allowing the cross
connection between a BGP VPWS signaled spoke SDP and a static GRE tunnel, the
latter being a spoke SDP configured with static MPLS labels using a GRE SDP. No
other spoke SDP types are supported. Support is not included for BGP multi-homing
using an active and a standby pseudo-wire to a pair of remote PEs.
Operational state changes to the GRE tunnel are reflected in the state of the Epipe
and propagated accordingly in the BGP VPWS spoke SDP's status signaling,
specifically using the BGP update D/csv bits.
The following configuration is required:
1. The Epipe service must be created using the vc-switching parameter.
2. The GRE tunnel spoke SDP must be configured using a GRE SDP with
signaling off, and have the ingress and egress vc-labels statically configured.
An example configuration is shown below:
configure
service
sdp 1 create
signaling off
far-end 192.168.1.1
keep-alive
shutdown
exit
no shutdown
exit
pw-template 1 create
exit
epipe 1 customer 1 vc-switching create
description "BGP VPWS service"
bgp
136
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
route-distinguisher 65536:1
route-target export target:65536:1 import target:65536:1
pw-template-binding 1
exit
exit
bgp-vpws
ve-name "PE1"
ve-id 1
exit
remote-ve-name "PE2"
ve-id 2
exit
no shutdown
exit
spoke-sdp 1:1 create
ingress
vc-label 1111
exit
egress
vc-label 1122
exit
no shutdown
exit
no shutdown
exit
2.14.3.1
Pseudo-wire Signaling
The BGP signaling mechanism used to establish the pseudo-wires is described in
the BGP VPWS with the following differences
• As stated in Section 3 of RFC 6624, there are two modifications of messages
when compared to RFC 4761.
− The Encaps Types supported in the associated extended community.
− The addition of a circuit status vector sub-TLV at the end of the VPWS
NLRI.
• The Control Flags and VPLS preference in the associated extended community
are based on draft-ietf-l2vpn-vpls-multihoming-03.
Figure 42 shows the format of the BGP VPWS update extended community.
Issue: 01
3HE 11970 AAAA TQZZA 01
137
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
Figure 42
BGP VPWS Update Extended Community Format
Extended Community Type (2 Octets)
Encaps Type (1 Octet)
Control Flags (1 Octet)
Layer-2 MTU (2 Octets)
VPLS Preference (2 Octets)
L2_Guide_42
• Extended community type — The value allocated by IANA for this attribute is
0x800A
• Encaps Type — Encapsulation type, identifies the type of pseudo-wire
encapsulation. Ethernet VLAN (4) and Ethernet Raw mode (5), as described in
RFC 4448, are the only values supported. If there is a mismatch between the
Encaps Type signaled and the one received, the pseudo-wire is created but with
the oper state down.
• Control Flags — Control information regarding the pseudo-wires, see below for
details.
• Layer-2 MTU is the Maximum Transmission Unit to be used on the pseudowires. If the received Layer-2 MTU is zero no MTU check is performed and the
related pseudo-wire is established. If there is a mismatch between the local
service-mtu and the received Layer-2 MTU the pseudo-wire is created with the
oper state down and a MTU/Parameter mismatch indication.
• VPLS preference – VPLS preference has a default value of zero for BGP-VPWS
updates sent by the system, indicating that it is not in use. If the site-preference
is configured, its value is used for the VPLS preference and is also used in the
local designated forwarder election. On receipt of a BGP VPWS update
containing a non-zero value, it will be used to determine to which system the
pseudo-wire is established as part of the VPWS update process tie-breaking
rules. The BGP local preference of the BGP VPWS update sent by the system
is set to the same value as the VPLS preference if the latter is non-zero, as
required by the draft (as long as the D bit in the extended community is not set
to 1). Consequently, attempts to change the BGP local preference when
exporting a BGP VPWS update with a non-zero VPLS preference will be
ignored. This prevents the updates being treated as malformed by the receiver
of the update.
The control flags are described in Figure 43.
138
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
Figure 43
VLL Services
Control Flags
0 1 2 3 4 5 6 7
D A F Z Z Z C S (Z - Must Be Zero)
L2_Guide_46
The following bits in the Control Flags are defined:
D — Access circuit down indicator from draft-kothari-l2vpn-auto-site-id-01. D is 1 if
all access circuits are down, otherwise D is 0.
A — Automatic site id allocation, which is not supported. This is ignored on receipt
and set to 0 on sending.
F — MAC flush indicator. This is not supported as it relates to a VPLS service. This
is set to 0 and ignored on receipt.
C — Presence of a control word. Control word usage is supported. When this is set
to 1, packets will be send and are expected to be received, with a control word. When
this is set to 0, packets will be send and are expected to be received, without a control
word. This is the default.
S — Sequenced delivery. Sequenced delivery is not supported. This is set to 0 on
sending (no sequenced delivery) and if a non-zero value is received (indicating
sequenced delivery required) the pseudo-wire will not be created.
The BGP VPWS NLRI is based on that defined for BGP VPLS but is extended with
a circuit status vector, as shown in Figure 44.
Figure 44
BGP VPWS NLRI
Length (2 Octets)
Route Distinguisher (8 Octets)
VE ID (2 Octets)
VE Block Offset (2 Octets)
VE Block Size (2 Octets)
Label Base (3 Octets)
Circuit Status Vector (4 Octets)
L2_Guide_43
Issue: 01
3HE 11970 AAAA TQZZA 01
139
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
The VE ID value is configured within each BGP VPWS service, the label base is
chosen by the system and the VE block offset corresponds to the remote VE ID as a
VE block size of 1 is always used.
The circuit status vector is encoded as a TLV as shown in Figure 45.
Figure 45
BGP VPWS NLRI TLV Extension Format
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
Type
Value
Length
Value (Continued, if Needed)...
L2_Guide_44
Figure 46
Circuit Status Vector TLV Type
TLV Type
Description
1
Circuit Status Vector
L2_Guide_45
The circuit status vector is used to indicate the status of both the SAP/GRE tunnel
and the status of the spoke SDP within the local service. As the VE block size used
is 1, the most significant bit in the circuit status vector TLV value will be set to 1 if
either the SAP/GRE tunnel or spoke SDP is down, otherwise it will be set to 0. On
receiving a circuit status vector, only the most significant byte of the CSV is examined
for designated forwarder selection purposes.
If a circuit status vector length field of greater than 32 is received, the update will be
ignored and not reflected to BGP neighbors. If the length field of greater than 800, a
notification message will be sent and the BGP session will restart. Also, BGP VPWS
services support a single access circuit, consequently only the most significant bit of
the CSV is examined on receipt.
A pseudo-wire will be established when a BGP VPWS update is received which
matches the service configuration, specifically the configured route-targets and
remote VE ID. If multiple matching updates are received, the system to which the
pseudo-wire is established is determined by the tie-breaking rules, as described in
draft-ietf-l2vpn-vpls-multihoming-03.
Traffic will be sent on the active pseudo-wire connected to the remote designated
forwarder. It can be received on either the active or standby pseudo-wire, though no
traffic should be received on the standby pseudo-wire as the SAP/GRE tunnel on the
non-designated forwarder should be blocked.
140
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
2.14.3.2
VLL Services
BGP VPWS Configuration Procedure
In addition to configuring the associated BGP and MPLS infrastructure, the
provisioning of a BGP VPWS service requires:
• Configure BGP Route Distinguisher, Route Target
− Updates are accepted into the service only if they contain the configured
import route-target
• Configure a binding to the pseudo-wire template
− Multiple pseudo-wire template bindings can be configure with their
associated route-targets used to control which is applied
• Configure the SAP or static GRE tunnel.
• Configure the name of the local VE and its associate VE ID
• Configure the name of the remote VE and its associated VE ID
• For a dual-homed PE
− Enable the site
− Configure the site with non-zero site-preference
• For a remote PE
− Up to two remove VE names and associated VE IDs can be configured
• Enable BGP VPWS
2.14.3.3
Use of Pseudo-wire Template for BGP VPWS
The pseudo-wire template concept used for BGP AD is re-used for BGP VPWS to
dynamically instantiate pseudo-wire (SDP-bindings) and the related SDP
(provisioned or automatically instantiated).
The settings for the L2-Info extended community in the BGP Update sent by the
system are derived from the pseudo-wire-template attributes. The following rules
apply:
• If multiple pseudo-wire-template-bindings (with or without import-rt) are
specified for the VPWS instance, the first (numerically lowest id) pseudo-wiretemplate entry will be used.
• Both Ethernet VLAN and Ethernet Raw Mode encaps types are supported;
these are selected by configuring the vc-type in the pseudo-wire template to be
either vlan or ether, respectively. The default is ether.
− The same value must be used by the remote BGP VPWS instance to
ensure the related pseudo-wire will come up
Issue: 01
3HE 11970 AAAA TQZZA 01
141
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
• Layer 2 MTU – derived from service vpls service-mtu parameter.
− The same value must be used by the remote BGP VPWS instance to
ensure the related pseudo-wire will come up.
• Control Flag C – can be 0 or 1, depending on the setting of the controlword
parameter in the pw-template 0.
• Control Flag S – always 0.
On reception the values of the parameters in the L2-Info extended community of the
BGP update are compared with the settings from the corresponding pseudo-wiretemplate. The following steps are used to determine the local pseudo-wire-template:
• The route-target values are matched to determine the pseudo-wire-template.
• If no matches are found from the previous step, the first (numerically lowest id)
pw-template-binding configured without an import-rt is used.
• If the values used for encaps type or Layer 2 MTU do not match the pseudo-wire
is created but with the oper state down.
− In order to interoperate with existing implementations if the received MTU
value = 0, then MTU negotiation does not take place; the related pseudowire is setup ignoring the MTU.
• If the values of the S flag is not zero the pseudo-wire is not created.
The following pseudo-wire template parameters are supported when applied within
a BGP VPWS service; the remainder are ignored:
configure service pw-template policy-id [use-provisioned-sdp |
prefer-provisioned-sdp] [create]
accounting-policy acct-policy-id
no accounting-policy
[no] collect-stats
[no] controlword
egress
filter ipv6 ipv6-filter-id
filter ip ip-filter-id
filter mac mac-filter-id
no filter [ip ip-filter-id] [mac mac-filter-id] [ipv6 ipv6-filter-id]
qos network-policy-id port-redirect-group queue-group-name instance instance
id
no qos [network-policy-id]
[no] force-vlan-vc-forwarding
hash-label [signal-capability]
no hash-label
ingress
filter ipv6 ipv6-filter-id
filter ip ip-filter-id
filter mac mac-filter-id
no filter [ip ip-filter-id] [mac mac-filter-id] [ipv6 ipv6-filter-id]
qos network-policy-id fp-redirect-group queue-group-name instance instance-id
no qos [network-policy-id]
[no] sdp-exclude
[no] sdp-include
142
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
vc-type {ether|vlan}
vlan-vc-tag vlan-id
no vlan-vc-tag
For more information on this command, see the 7450 ESS, 7750 SR, and 7950 XRS
Services Overview Guide.
The use-provisioned-sdp option is permitted when creating the pseudo-wire
template if a pre-provisioned SDP is to be used. Pre-provisioned SDPs must be
configured whenever GRE, RSVP, or BGP signaled transport tunnels are used.
When the prefer-provisioned-sdp option is specified, if the system finds an existing
matching SDP that conforms to any restrictions defined in the pseudo-wire template
(for example, sdp-include/sdp-exclude group), it uses this matching SDP (even if
the existing sdp is operationally down); otherwise, it automatically creates an SDP.
The tools perform command can be used in the same way as for BGP-AD to apply
changes to the pseudo-wire template using the following format:
tools perform service [id service-id] eval-pw-template
policy-id [allow-service-impact]
If a user configures a service using a pseudo-wire template with the preferprovisioned-sdp option but without an applicable SDP being provisioned, and the
system binds to an automatic SDP, and the user subsequently provisions an
appropriate SDP, the system will not automatically switch to the new provisioned
SDP. This will only occur if the pseudo-wire template is re-evaluated using the tools
perform service id service-id eval-pw-template command.
2.14.3.4
Use of Endpoint for BGP VPWS
An Endpoint is required on a remote PE connecting to two dual-homed PEs to
associate the active/standby pseudo-wires with the Epipe service. An endpoint is
automatically created within the Epipe service such that active/standby pseudo-wires
are associated with that endpoint. The creation of the endpoint occurs when bgpvpws is enabled (and deleted when it is disabled) and so will exist in both a single
and dual homed scenario (this simplifies converting a single homed service to a dualhomed service). The naming convention used is _tmnx_BgpVpws-x, where x is the
service identifier. The automatically created endpoint has the default parameter
values, although all are ignored in a BGP-VPWS service with the description field
being defined by the system.
Note that the command:
tools perform service id <service-id> endpoint <endpoint-name> force-switchover
Issue: 01
3HE 11970 AAAA TQZZA 01
143
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
will have no affect on an automatically created VPWS endpoint.
2.15
VLL Service Considerations
This section describes the general 7450 ESS, 7750 SR, and 7950 XRS service
features and any special capabilities or considerations as they relate to VLL services.
2.15.1
SDPs
The most basic SDPs must have the following:
• A locally unique SDP identification (ID) number.
• The system IP address of the originating and far-end routers.
• An SDP encapsulation type, either GRE or MPLS.
The most basic Apipe and Fpipe SDP configurations for the 7750 SR must have the
following:
• A locally unique SDP identification (ID) number and vc-id.
2.15.1.1
SDP Statistics for VPLS and VLL Services
The simple three-node network described in Figure 47 shows two MPLS SDPs and
one GRE SDP defined between the nodes. These SDPs connect VPLS1 and VPLS2
instances that are defined in the three nodes. With this feature the operator will have
local CLI based as well as SNMP based statistics collection for each VC used in the
SDPs. This will allow for traffic management of tunnel usage by the different services
and with aggregation the total tunnel usage.
144
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
Figure 47
VLL Services
SDP Statistics for VPLS and VLL Services
SDP 103
LDP
VPLS1
VPLS1
VPLS2
VPLS2
PE1
PE3
IP/MPLS
SDP 101
GRE
PE2
VPLS1
SDP 102
RSVP
VPLS2
OSSG208
2.15.2
SAP Encapsulations and Pseudo-wire Types
The Epipe service is designed to carry Ethernet frame payloads, so it can provide
connectivity between any two SAPs that pass Ethernet frames. The following SAP
encapsulations are supported on the 7450 ESS, 7750 SR, and 7950 XRS Epipe
service:
• Ethernet null
• Ethernet dot1q
• QinQ
• SONET/SDH BCP-null for the 7450 ESS and 7750 SR
• SONET/SDH BCP-dot1q for the 7450 ESS and 7750 SR
• ATM VC with RFC 2684 Ethernet-bridged encapsulation (see Ethernet
Interworking VLL) for the 7750 SR
• FR VC with RFC 2427 Ethernet-bridged encapsulation (see Ethernet
Interworking VLL) for the 7450 ESS and 7750 SR
Issue: 01
3HE 11970 AAAA TQZZA 01
145
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
Note that while different encapsulation types can be used, encapsulation
mismatching can occur if the encapsulation behavior is not understood by
connecting devices and are unable to send and receive the expected traffic. For
example if the encapsulation type on one side of the Epipe is dot1q and the other is
null, tagged traffic received on the null SAP will be double tagged when it is
transmitted out of the Dot1q SAP.
ATM VLLs can be configured with both endpoints (SAPs) on the same router or with
the two endpoints on different 7750 SRs. In the latter case, Pseudo-wire Emulation
Edge-to-Edge (PWE3) signaling is used to establish a pseudo-wire between the
devices allowing ATM traffic to be tunneled through an MPLS or GRE network:
Two pseudo-wire encapsulation modes, i.e., SDP vc-type, are available:
• PWE3 N-to-1 Cell Mode Encapsulation
• PWE3 AAL5 SDU Mode Encapsulation
The endpoints of Frame Relay VLLs must be Data-Link Connection Identifiers
(DLCIs) on any port that supports Frame Relay. The pseudo-wire encapsulation, or
SDP vc-type, supported is the 1-to-1 Frame Relay encapsulation mode.
2.15.2.1
PWE3 N-to-1 Cell Mode
The endpoints of an N-to-1 mode VLL on a 7750 SR can be:
• ATM VCs — VPI/VCI translation is supported (i.e., the VPI/VCI at each endpoint
does not need to be the same).
• ATM VPs — VPI translation is supported (i.e., the VPI at each endpoint need not
be the same, but the original VCI will be maintained).
• ATM VTs (a VP range) — No VPI translation is supported (i.e., the VPI/VCI of
each cell is maintained across the network).
• ATM ports — No translation is supported (i.e., the VPI/VCI of each cell is
maintained across the network).
For N-to-1 mode VLLs, cell concatenation is supported. Cells will be packed on
ingress to the VLL and unpacked on egress. As cells are being packed, the
concatenation process may be terminated by:
• Reaching a maximum number of cells per packet.
• Expiry of a timer.
• (Optionally) change of the CLP bit.
• (Optionally) change of the PTI bits indicating end of AAL5 packet.
146
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
In N-to-1 mode, OAM cells are transported through the VLL as any other cell. The
PTI and CLP bits are untouched, even if VPI/VCI translation is carried out.
2.15.2.2
PWE3 AAL5 SDU Mode
The endpoints of an AAL5 SDU mode VLL on a 7750 SR must be ATM VCs specified
by port/vpi/vci. VPI/ VCI translation is supported. The endpoint can also be a FR VC,
specified by port/dlci. In this case FRF.5 FR-ATM network interworking is performed
between the ATM VC SAP or the SDP and the FR VC SAP.
In SDU mode, the mandatory PWE3 control word is supported. This allows the ATM
VLL to transport OAM cells along with SDU frames, using the “T” bit to distinguish
between them, to recover the original SDU length, and to carry CLP, EFCI and UU
information.
2.15.2.3
QoS Policies
When applied to 7450 ESS, 7750 SR, or 7950 XRS Epipe, Apipe, and Fpipe
services, service ingress QoS policies only create the unicast queues defined in the
policy. The multipoint queues are not created on the service.
With Epipe, Apipe, and Fpipe services, egress QoS policies function as with other
services where the class-based queues are created as defined in the policy. Note
that both Layer 2 or Layer 3 criteria can be used in the QoS policies for traffic
classification in a service. QoS policies on Apipes cannot perform any classification
and on Fpipes Layer 3 (IP) classification is performed.
2.15.2.4
Filter Policies
7450 ESS, 7750 SR, and 7950 XRS Epipe, Fpipe, and Ipipe services can have a
single filter policy associated on both ingress and egress. Both MAC and IP filter
policies can be used on Epipe services.
Filters cannot be configured on 7750 SR Apipe service SAPs.
Issue: 01
3HE 11970 AAAA TQZZA 01
147
VLL Services
2.15.2.5
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
MAC Resources
Epipe services are point-to-point layer 2 VPNs capable of carrying any Ethernet
payloads. Although an Epipe is a Layer 2 service, the 7450 ESS, 7750 SR, and
7950 XRS Epipe implementation does not perform any MAC learning on the service,
so Epipe services do not consume any MAC hardware resources.
148
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
2.16
VLL Services
Configuring a VLL Service with CLI
This section provides information to configure Virtual Leased Line (VLL) services
using the command line interface.
2.16.1
Basic Configurations
• Creating an Apipe Service
• Creating a Cpipe Service
• Creating an Epipe Service
• Creating an Fpipe Service
• Creating an Ipipe Service
• Using Spoke SDP Control Words
• Pseudowire Configuration Notes
− Configuring Two VLL Paths Terminating on T-PE2
− Configuring VLL Resilience
− Configuring VLL Resilience for a Switched Pseudowire Path
2.16.2
Common Configuration Tasks
This section provides a brief overview of the tasks that must be performed to
configure the VLL services and provides the CLI commands.
1. Associate the service with a customer ID.
2. Define SAP parameters
− Optional - configure ATM parameters on the 7750 SR
− Optional - select egress and ingress QoS and/or scheduler policies
(configured in the config>qos context).
− Optional - select accounting policy (configured in the config>log context).
3. Define spoke SDP parameters.
4. Enable the service.
Issue: 01
3HE 11970 AAAA TQZZA 01
149
VLL Services
2.16.3
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
Configuring VLL Components
This section provides VLL configuration examples for the VLL services:
• Creating an Apipe Service
− Configuring Basic Apipe SAP Parameters
− Configuring an ATM SAP in the N-to-1 Mapping of ATM VPI/VCI to ATM
Pseudowire
− Configuring Apipe SDP Bindings
• Creating a Cpipe Service
− Basic Configuration
− Configuration Requirements
− Configuring Cpipe SAPs and Spoke SDPs
• Creating an Epipe Service
− Configuring Epipe SAP Parameters
• Local Epipe SAPs
• Distributed Epipe SAPs
• Configuring Ingress and Egress SAP Parameters
• Creating an Fpipe Service
− Configuring Fpipe SAP Parameters
− Configuring Fpipe SDP Bindings
• Creating an Ipipe Service
− Creating an Ipipe Service
2.16.3.1
Creating an Apipe Service
Use the following CLI syntax to create an Apipe service on a 7750 SR.
CLI Syntax:
config>service# apipe service-id [customer customer-id]
[vpn vpn-id] [vc-type {atm-vcc|atm-sdu|atm-vpc|atmcell}][vc-switching]
description description-string
interworking {frf-5}
service-mtu octets
no shutdown
The following example shows the command usage to create an Apipe service:
150
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
PE router 1 (A:ALA-41):
Example:
A:ALA-41>config>service# apipe 5 customer 1 create
A:ALA-41config>service>apipe# description “apipe test”
A:ALA-41config>service>apipe# service-mtu 1400
A:ALA-41config>service>apipe# no shutdown
A:ALA-41config>service>apipe#
PE router 2 (A:ALA-42):
Example:
A:ALA-42>config>service# apipe
A:ALA-42>config>service>apipe#
A:ALA-42>config>service>apipe#
A:ALA-42>config>service>apipe#
A:ALA-42>config>service>apipe#
5 customer 1 create
description “apipe test”
service-mtu 1400
no shutdown
The following example shows the Apipe service creation output.
PE Router 1 (ALA-41):
A:ALA-41>config>service# info
------------------------------------...
apipe 5 customer 1 create
description "apipe test"
service-mtu 1400
no shutdown
exit
...
------------------------------------A:ALA-41>config>service#
PE Router 2 (ALA-42):
A:ALA-42>config>service# info
------------------------------------...
apipe 5 customer 1 create
description "apipe test"
service-mtu 1400
no shutdown
exit
...
------------------------------------A:ALA-42>config>service#
2.16.3.1.1
Configuring Basic Apipe SAP Parameters
Use the following CLI syntax to configure Apipe SAP parameters.
Issue: 01
3HE 11970 AAAA TQZZA 01
151
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
CLI Syntax:
config>service# apipe service-id [customer customer-id]
[vpn vpn-id] [vc-type {atm-vcc|atm-sdu|atm-vpc|atmcell}][vc-switching]
sap sap-id
accounting-policy acct-policy-id
atm
egress
traffic-desc traffic-desc-profile-id
ingress
traffic-desc traffic-desc-profile-id
oam
alarm-cells
terminate
collect-stats
description description-string
egress
qos policy-id
scheduler-policy scheduler-policy-name
ingress
qos policy-id [shared-queuing]
scheduler-policy scheduler-policy-name
multi-service-site customer-site-name
no shutdown
The following example shows the command usage to create Apipe SAPs:
PE router 1 (A:ALA-41):
Example:
A:ALA-41>config>service# apipe 5
A:ALA-41>config>service>apipe# sap 1/1/1:0/32 create
A:ALA-41>config>service>apipe>sap# ingress
A:ALA-41>config>service>apipe>sap>ingress# qos 102
A:ALA-41>config>service>apipe>sap>ingress# exit
A:ALA-41>config>service>apipe>sap# egress
A:ALA-41>config>service>apipe>sap>egress# qos 103
A:ALA-41>config>service>apipe>sap>egress# exit
A:ALA-41>config>service>apipe>sap# no shutdown
A:ALA-41>config>service>apipe>sap# exit
A:ALA-41>config>service>apipe#
PE router 2 (A:ALA-42):
Example:
152
Example:A:ALA-42>config>service# apipe 5
A:ALA-42>config>service>apipe# sap 2/2/2:0/32 create
A:ALA-42>config>service>apipe>sap# ingress
A:ALA-42>config>service>apipe>sap>ingress# qos 102
A:ALA-42>config>service>apipe>sap>ingress# exit
A:ALA-42>config>service>apipe>sap# egress
A:ALA-42>config>service>apipe>sap>egress# qos 103
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
A:ALA-42>config>service>apipe>sap>egress# exit
A:ALA-42>config>service>apipe>sap# no shutdown
A:ALA-42>config>service>apipe>sap# exit
A:ALA-42>config>service>apipe#
The following output shows the Apipe SAP configuration.
PE Router 1 (ALA-41):
A:ALA-41>config>service# info
------------------------------------...
apipe 5 customer 1 create
description "apipe test"
service-mtu 1400
sap 1/1/1:0/32 create
ingress
qos 102
exit
egress
qos 103
exit
exit
no shutdown
exit
...
------------------------------------A:ALA-41>config>service#
PE Router 2 (ALA-42):
A:ALA-42>config>service# info
------------------------------------...
apipe 5 customer 1 create
description "apipe test"
service-mtu 1400
sap 2/2/2:0/32 create
ingress
qos 102
exit
egress
qos 103
exit
exit
no shutdown
exit
...
------------------------------------A:ALA-42>config>service#
Issue: 01
3HE 11970 AAAA TQZZA 01
153
VLL Services
2.16.3.1.2
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
Configuring an ATM SAP in the N-to-1 Mapping of ATM VPI/VCI to
ATM Pseudowire
Users can configure an ATM-cell Apipe service with a new ATM SAP type. The SAP
type refers to a pre-configured ATM connection profile name.
configure service apipe 100 vc-type atm-cell
sap <port-id|aps-id>[:cp.<connection-profile-num>]
The ATM SAP connection profile is configured with the list of discrete VPI/VCI
values.
configure connection-profile 2 {member vpi/vci...(up to 16)}
A connection profile can only be applied to a SAP which is part of an apipe VLL
service of vc-type atm-cell. The ATM SAP can be on a regular port or APS port. A
connection profile can be applied to any number of ATM SAPs.
Up to a maximum of 16 discrete VPI/VCI values can be configured in a connection
profile. After creation of the connection profile, the user can subsequently add,
remove, or modify the VPI/VCI entries. This triggers a re-evaluation of all the ATM
SAPs which are currently using that profile.
The user must also override the PW type signaled to type '0x0009 N:1 VCC cell' by
using the following command:
config>service>apipe>signaled-vc-type-override atm-vcc
This command is not allowed in an Apipe VLL of vc-type value atm-cell if a configured
ATM SAP is not using a connection profile. Conversely, if the signaling override
command is enabled, only an ATM SAP with a connection profile assigned will be
allowed.
The override command is not allowed on an Apipe VLL service of vc-type value other
than atm-cell. It is also not allowed on a VLL service with the vc-switching option
enabled since signaling of the pseudowire FEC in a Multi-Segment Pseudowire (MSPW) is controlled by the T-PE nodes. Thus for this feature to be used on a MS-PW,
it is required to configure an Apipe service of vc-type atm-cell at the T-PE nodes with
the signaled-vc-type-override command enabled, and to configure an Apipe VLL
service of vc-type atm-vcc at the S-PE node with the vc-switching option enabled.
The following are the restrictions of this feature:
• A SAP-to-SAP VLL service is not supported using ATM SAP with a connection
profile assigned. The user must configure each VPI/VCI into a separate SAP
and create as many Apipe VLL services of type atm-vcc as required.
154
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
• An ATM SAP with a connection profile assigned cannot be configured on a port
with is part of a MC-APS protection group.
• It is strongly recommended to not apply a VCI based QoS Filter to the ingress of
an ATM SAP with a connection profile. Because the filter matches the VCI value
of the first cell of a concatenated packet, the entire packet will be treated the
same way based on the action of the entry of the criteria, all cells of the
concatenated packet are mapped to the same FC and profile based on the VCI
value of the first cell.
This feature is supported on the 4-port OC-3/STM-1:OC-12/STM-4 ATM MDA and
on the 16-port OC-3/STM-1 ATM MDA and is supported IOM3/IMM on the
7750 SR-7, and 7750 SR-12 as well as the 7750-C4 and C12 chassis.
2.16.3.1.3
Configuring Apipe SDP Bindings
Use the following CLI syntax to create a spoke SDP binding with an Apipe service:
CLI Syntax:
config>service# apipe service-id [customer customer-id]
[vpn vpn-id] [vc-type {atm-vcc|atm-sdu|atm-vpc|atmcell}] [vc-switching]
spoke-sdp sdp-id:vc-id
cell-concatenation
aal5-frame-aware
clp-change
max-cells cell-count
max-delay delay-time
egress
vc-label egress-vc-label
ingress
vc-label ingress-vc-label
no shutdown
The following example displays the command usage to create Apipe spoke SDPs:
PE router 1 (A:ALA-41):
Example:
Example:A:ALA-41>config>service# apipe 5
A:ALA-41>config>service>apipe# spoke-sdp 1:5 create
A:ALA-41>config>service>apipe>spoke-sdp# no shutdown
A:ALA-41>config>service>apipe>spoke-sdp# exit
PE router 2 (A:ALA-42):
Example:
Issue: 01
Example:A:ALA-42>config>service# apipe 5
A:ALA-42>config>service>apipe# spoke-sdp 1:5 create
3HE 11970 AAAA TQZZA 01
155
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
A:ALA-42>config>service>apipe>spoke-sdp# no shutdown
A:ALA-42>config>service>apipe>spoke-sdp# exit
The following output shows the Apipe spoke SDP configurations.
PE Router 1 (ALA-41):
A:ALA-41>config>service# info
------------------------------------...
apipe 5 customer 1 create
description "apipe test"
service-mtu 1400
sap 1/1/1:0/32 create
ingress
qos 102
exit
egress
qos 103
exit
exit
spoke-sdp 1:5 create
exit
no shutdown
exit
...
------------------------------------A:ALA-41>config>service#
PE Router 2 (ALA-42):
A:ALA-42>config>service# info
------------------------------------...
apipe 5 customer 1 create
description "apipe test"
service-mtu 1400
sap 2/2/2:0/32 create
ingress
qos 102
exit
egress
qos 103
exit
exit
spoke-sdp 1:5 create
exit
no shutdown
exit
...
------------------------------------A:ALA-42>config>service#
156
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
2.16.3.2
Creating a Cpipe Service
2.16.3.2.1
Basic Configuration
VLL Services
Use the following CLI syntax to create a Cpipe service on a 7750 SR. A route
distinguisher must be defined in order for Cpipe to be operationally active.
CLI Syntax:
config>service# cpipe service-id [customer customer-id]
[vpn vpn-id] [vc-type {satop-e1 | satop-t1 | cesopsn |
cesopsn-cas}] [vc-switching] [create]
For the 7450 ESS platforms, the vc-switching option must be configured for Cpipe
functionality:
cpipe 1 customer 1 vc-switching vc-type cesopsn create
service-name "XYZ Cpipe 1"
spoke-sdp 20:1 create
description "Description for Sdp Bind 20 for Svc ID 1"
ingress
vc-label 10002
exit
egress
vc-label 10001
exit
exit
spoke-sdp 50:1 create
description "Description for Sdp Bind 50 for Svc ID 1"
exit
no shutdown
exit
The following displays a Cpipe service configuration example:
*A:ALA-1>config>service# info
---------------------------------------------...
cpipe 210 customer 1 vc-type cesopsn create
service-mtu 1400
sap 1/5/1.1.3.1 create
exit
spoke-sdp 1:210 create
exit
no shutdown
exit
...
---------------------------------------------*A:ALA-1>config>service#
Issue: 01
3HE 11970 AAAA TQZZA 01
157
VLL Services
2.16.3.2.2
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
Configuration Requirements
Before a Cpipe service can be provisioned, the following tasks must be completed:
• Configuring a DS1 Port
• Configuring a Channel Group
Configuring a DS1 Port
The following example shows a DS1 port configured for CES:
A:sim216# show port 1/5/1.1.3.1
===============================================================================
TDM DS1 Interface
===============================================================================
Description
: DS1
Interface
: 1/5/1.1.3,1
Type
: ds1
Framing
: esf
Admin Status
: up
Oper Status
: up
Physical Link
: yes
Clock Source
: loop-timed
Signal Mode
: none
Last State Change : 10/31/2006 14:23:12
Channel IfIndex
: 580943939
Loopback
: none
Invert Data
: false
Remote Loop respond: false
In Remote Loop
: false
Load-balance-algo : default
Egr. Sched. Pol
: n/a
BERT Duration
: N/A
BERT Pattern
: none
BERT Synched
: 00h00m00s
Err Insertion Rate
: 0
BERT Errors
: 0
BERT Status
: idle
BERT Total Bits
: 0
Cfg Alarm
: ais los
Alarm Status
:
===============================================================================
A:sim216#
Configuring a Channel Group
The following example shows a DS1 channel group configured for CES:
A:sim216# show port 1/5/1.1.3.1
===============================================================================
TDM DS0 Chan Group
===============================================================================
Description
: DS0GRP
Interface
: 1/5/1.1.3.1
TimeSlots
: 1-12
Speed
: 64
CRC
: 16
Admin Status
: up
Oper Status
: up
Last State Change : 10/31/2006 14:23:12
Chan-Grp IfIndex
: 580943940
Configured mode
: access
Encap Type
: cem
Admin MTU
: 4112
Oper MTU
: 4112
Physical Link
: Yes
Bundle Number
: none
158
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
Idle Cycle Flags
: flags
Load-balance-algo
: default
Egr. Sched. Pol
: n/a
===============================================================================
A:sim216#
2.16.3.2.3
Configuring Cpipe SAPs and Spoke SDPs
The following examples show Cpipe SAP and spoke SDP configurations.
*A:ALA-49>config>service# info
#-------------------------------------------------echo "Service Configuration"
#-------------------------------------------------...
cpipe 100 customer 1 vc-type cesopsn create
service-mtu 1400
sap 1/5/1.1.1.1 create
exit
spoke-sdp 1:100 create
exit
no shutdown
exit
cpipe 200 customer 1 vc-type cesopsn-cas create
sap 1/5/1.2.1.1 create
exit
sap 1/5/1.2.2.1 create
exit
no shutdown
exit
cpipe 210 customer 1 vc-type cesopsn-cas create
service-mtu 1400
sap 1/5/1.1.3.1 create
exit
spoke-sdp 1:210 create
exit
no shutdown
exit
cpipe 300 customer 1 vc-type cesopsn create
sap 1/5/1.3.4.1 create
exit
sap 1/5/1.3.6.1 create
exit
no shutdown
exit
cpipe 400 customer 1 vc-type satop-e1 create
sap 1/5/1.2.3.1 create
exit
spoke-sdp 1:400 create
exit
no shutdown
exit
...
#-------------------------------------------------*A:ALA-49>config>service#
Issue: 01
3HE 11970 AAAA TQZZA 01
159
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
A:sim213>config>service>cpipe# info
---------------------------------------------description "cpipe-100"
sap 1/5/1.1.1.1 create
cem
packet jitter-buffer 16 payload-size 384
report-alarm rpktloss
no report-alarm stray
rtp-header
exit
exit
spoke-sdp 1:100 create
exit
no shutdown
---------------------------------------------A:sim213>config>service>cpipe#
2.16.3.3
Creating an Epipe Service
Use the following CLI syntax to create an Epipe service.
CLI Syntax:
config>service# epipe service-id [customer customer-id]
[vpn vpn-id] [vc-switching]
description description-string
no shutdown
The following example shows an Epipe configuration:
A:ALA-1>config>service# info
------------------------------------------...
epipe 500 customer 5 vpn 500 create
description "Local epipe service"
no shutdown
exit
------------------------------------------A:ALA-1>config>service#
2.16.3.3.1
Configuring Epipe SAP Parameters
A default QoS policy is applied to each ingress and egress SAP. Additional QoS
policies can be configured in the config>qos context. Filter policies are configured
in the config>filter context and explicitly applied to a SAP. There are no default filter
policies.
Use the following CLI syntax to create:
• Local Epipe SAPs
160
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
• Distributed Epipe SAPs
The following example shows a configuration for the 7950 XRS.
CLI Syntax:
config>service# epipe service-id [customer customer-id]
sap sap-id [endpoint endpoint-name]
sap sap-id [no-endpoint]
accounting-policy policy-id
collect-stats
description description-string
no shutdown
egress
filter {ip ip-filter-name | mac mac-filtername}
qos sap-egress-policy-id
scheduler-policy scheduler-policy-name
ingress
filter {ip ip-filter-name | mac mac-filtername}
match-qinq-dot1p {top | bottom}
qos policy-id
scheduler-policy scheduler-policy-name
The following example shows a configuration for the 7450 ESS and 7750 SR.
CLI Syntax:
Issue: 01
config>service# epipe service-id [customer customer-id]
sap sap-id [endpoint endpoint-name]
sap sap-id [no-endpoint]
accounting-policy policy-id
collect-stats
description description-string
no shutdown
egress
filter {ip ip-filter-name | mac mac-filtername}
qos sap-egress-policy-id
scheduler-policy scheduler-policy-name
ingress
filter {ip ip-filter-name | mac mac-filtername}
match-qinq-dot1p {top|bottom}
qos policy-id [shared-queuing]
scheduler-policy scheduler-policy-name
3HE 11970 AAAA TQZZA 01
161
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
Local Epipe SAPs
To configure a basic local Epipe service, enter the sap sap-id command twice with
different port IDs in the same service configuration.
By default, QoS policy ID 1 is applied to ingress and egress service SAPS. Existing
filter policies or other existing QoS policies can be associated with service SAPs on
ingress and egress ports.
Table 10
Supported SAP Types
Uplink
Type
Svc SAP
Type
Cust.
VID
Access SAPs
Network SAPs
L2
Null-star
N/A
Null, dot1q *
Q.*
L2
Dot1q
N/A
Dot1q
Q.*
L2
Dot1qpreserve
X
Dot1q (encap = X)
Q1.Q2 (where Q2 =
X)
An existing scheduler policy can be applied to ingress and egress SAPs to be used
by the SAP queues and, at egress only, policers. The schedulers comprising the
policy are created at the time the scheduler policy is applied to the SAP. If any
policers or orphaned queues (with a non-existent local scheduler defined) exist on a
SAP and the policy application creates the required scheduler, the status on the
queue becomes non-orphaned at this time.
Ingress and Egress SAP parameters can be applied to local and distributed Epipe
service SAPs.
This example shows the SAP configurations for local Epipe service 500 on SAP 1/1/
2 and SAP 1/1/3 on ALA-1.
A:ALA-1>config>service# epipe 500 customer 5 create
config>service>epipe$ description "Local epipe service"
config>service>epipe# sap 1/1/2:0 create
config>service>epipe>sap? ingress
config>service>epipe>sap>ingress# qos 20
config>service>epipe>sap>ingress# filter ip 1
config>service>epipe>sap>ingress# exit
config>service>epipe>sap# egress
config>service>epipe>sap>egress# qos 20
config>service>epipe>sap>egress# scheduler-policy test1
config>service>epipe>sap>egress# exit
config>service>epipe>sap# no shutdown
config>service>epipe>sap# exit
config>service>epipe# sap 1/1/3:0 create
config>service>epipe>sap# ingress
config>service>epipe>sap>ingress# qos 555
162
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
config>service>epipe>sap>ingress# filter ip 1
config>service>epipe>sap>ingress# exit
config>service>epipe>sap# egress
config>service>epipe>sap>egress# qos 627
config>service>epipe>sap>egress# scheduler-policy alpha
config>service>epipe>sap>egress# exit
config>service>epipe>sap# no shutdown
config>service>epipe>sap# exit
The following example shows the local Epipe configuration:
A:ALA-1>config>service# info
---------------------------------------------...
epipe 500 customer 5 vpn 500 create
description "Local epipe service"
sap 1/1/2:0 create
ingress
qos 20
filter ip 1
exit
egress
scheduler-policy "test1"
qos 20
exit
exit
sap 1/1/3:0 create
ingress
qos 555
filter ip 1
exit
egress
scheduler-policy "alpha"
qos 627
exit
exit
no shutdown
exit
---------------------------------------------A:ALA-1>config>service#
2.16.3.3.2
Distributed Epipe SAPs
To configure a distributed Epipe service, you must configure service entities on the
originating and far-end nodes. You should use the same service ID on both ends (for
example, Epipe 5500 on ALA-1 and Epipe 5500 on ALA-2). The spoke-sdp sdpid:vc-id must match on both sides. A distributed Epipe consists of two SAPs on
different nodes.
By default, QoS policy ID 1 is applied to ingress and egress service SAPS. Existing
filter policies or other existing QoS policies can be associated with service SAPs on
ingress and egress.
Issue: 01
3HE 11970 AAAA TQZZA 01
163
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
An existing scheduler policy can be applied to ingress and egress SAPs to be used
by the SAP queues and, at egress only, policers. The schedulers comprising the
policy are created at the time the scheduler policy is applied to the SAP. If any
policers or orphaned queues (with a non-existent local scheduler defined) exist on a
SAP and the policy application creates the required scheduler, the status on the
queue becomes non-orphaned at this time.
Ingress and egress SAP parameters can be applied to local and distributed Epipe
service SAPs.
For SDP configuration information, see the 7450 ESS, 7750 SR, and 7950 XRS
Services Overview Guide. For SDP binding information, see Configuring SDP
Bindings.
This example shows a configuration of a distributed service between ALA-1 and
ALA-2.
A:ALA-1>epipe 5500 customer 5 create
config>service>epipe$ description "Distributed epipe service to east coast"
config>service>epipe# sap 221/1/3:21 create
config>service>epipe>sap# ingress
config>service>epipe>sap>ingress# qos 555
config>service>epipe>sap>ingress# filter ip 1
config>service>epipe>sap>ingress# exit
config>service>epipe>sap# egress
config>service>epipe>sap>egress# qos 627
config>service>epipe>sap>egress# scheduler-policy alpha
config>service>epipe>sap>egress# exit
config>service>epipe>sap# no shutdown
config>service>epipe>sap# exit
config>service>epipe#
A:ALA-2>config>service# epipe 5500 customer 5 create
config>service>epipe$ description "Distributed epipe service to west coast"
config>service>epipe# sap 441/1/4:550 create
config>service>epipe>sap# ingress
config>service>epipe>sap>ingress# qos 654
config>service>epipe>sap>ingress# filter ip 1020
config>service>epipe>sap>ingress# exit
config>service>epipe>sap# egress
config>service>epipe>sap>egress# qos 432
config>service>epipe>sap>egress# filter ip 6
config>service>epipe>sap>egress# scheduler-policy test1
config>service>epipe>sap>egress# exit
config>service>epipe>sap# no shutdown
config>service>epipe#
The following example shows the SAP configurations for ALA-1 and ALA-2:
A:ALA-1>config>service# info
---------------------------------------------...
epipe 5500 customer 5 vpn 5500 create
description "Distributed epipe service to east coast"
164
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
sap 221/1/3:21 create
ingress
qos 555
filter ip 1
exit
egress
scheduler-policy "alpha"
qos 627
exit
exit
exit
...
---------------------------------------------A:ALA-1>config>service#
A:ALA-2>config>service# info
---------------------------------------------...
epipe 5500 customer 5 vpn 5500 create
description "Distributed epipe service to west coast"
sap 441/1/4:550 create
ingress
qos 654
filter ip 1020
exit
egress
scheduler-policy "test1"
qos 432
filter ip 6
exit
exit
exit
...
---------------------------------------------A:ALA-2>config>service#
PBB Epipe Configuration
The following example shows the PBB Epipe configuration:
*A:Wales-1>config>service>epipe# info
----------------------------------------------------------------------...
description "Default epipe description for service id 20000"
pbb-tunnel 200 backbone-dest-mac 00:03:fa:15:d3:a8 isid 20000
sap 1/1/2:1.1 create
description "Default sap description for service id 20000"
ingress
filter mac 1
exit
exit
no shutdown
----------------------------------------------------------------------*A:Wales-1>config>service>epipe#
Issue: 01
3HE 11970 AAAA TQZZA 01
165
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
CLI Syntax:
configure service vpls 200 customer 1 b-vpls create
*A:Wales-1>config>service>vpls# info
---------------------------------------------------------------------...
service-mtu 2000
fdb-table-size 131071
stp
no shutdown
exit
sap 1/1/8 create
exit
sap 1/2/3:200 create
exit
mesh-sdp 1:200 create
exit
mesh-sdp 100:200 create
exit
mesh-sdp 150:200 create
exit
mesh-sdp 500:200 create
exit
no shutdown
-------------------------------------------------------------------*A:Wales-1>config>service>vpls#
Configuring Ingress and Egress SAP Parameters
By default, QoS policy ID 1 is applied to ingress and egress service SAPs. Existing
filter policies or other existing QoS policies can be associated with service SAPs on
ingress and egress ports.
An existing scheduler policy can be applied to ingress and egress SAPs to be used
by the SAP queues and, at egress only, policers. The schedulers comprising the
policy are created at the time the scheduler policy is applied to the SAP. If any
policers or orphaned queues (with a non-existent local scheduler defined) exist on a
SAP and the policy application creates the required scheduler, the status on the
queue becomes non-orphaned at this time.
Ingress and egress SAP parameters can be applied to local and distributed Epipe
service SAPs.
This example shows the SAP ingress and egress parameters.
ALA-1>config>service# epipe 5500
config>service>epipe# sap 2/1/3:21
config>service>epipe>sap# ingress
config>service>epipe>sap>ingress# qos 555
config>service>epipe>sap>ingress# filter ip 1
config>service>epipe>sap>ingress# exit
config>service>epipe>sap# egress
config>service>epipe>sap>egress# qos 627
166
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
config>service>epipe>sap>egress# scheduler-policy alpha
config>service>epipe>sap>egress# exit
config>service>epipe>sap#
The following example shows the Epipe SAP ingress and egress configuration:
A:ALA-1>config>service#
---------------------------------------------...
epipe 5500 customer 5 vpn 5500 create
description "Distributed epipe service to east coast"
sap 2/1/3:21 create
ingress
qos 555
filter ip 1
exit
egress
scheduler-policy "alpha"
qos 627
exit
exit
spoke-sdp 2:123 create
ingress
vc-label 6600
exit
egress
vc-label 5500
exit
exit
no shutdown
exit
---------------------------------------------A:ALA-1>config>service#
2.16.3.3.3
Configuring SDP Bindings
Figure 48 shows an example of a distributed Epipe service configuration between
two routers, identifying the service and customer IDs, and the uni-directional SDPs
required to communicate to the far-end routers.
A spoke SDP is treated like the equivalent of a traditional bridge “port” where flooded
traffic received on the spoke SDP is replicated on all other “ports” (other spoke and
mesh SDPs or SAPs) and not transmitted on the port it was received.
Issue: 01
3HE 11970 AAAA TQZZA 01
167
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
Figure 48
SDPs — Uni-Directional Tunnels
ALA-1
ALA-2
demux
SDP 3
SPOKE-SDP 3
EPIPE 2 for
Customer 6
SDP 2
EPIPE 2 for
Customer 6
SPOKE-SDP 2
demux
L2_Guide_47
Use the following CLI syntax to create a spoke SDP binding with an Epipe service:
CLI Syntax:
config>service# epipe service-id [customer customer-id]
spoke-sdp sdp-id:vc-id [vc-type {ether | vlan}]
vlan-vc-tag 0..4094
egress
filter {ip ip-filter-id}
vc-label egress-vc-label
ingress
filter {ip ip-filter-id}
vc-label ingress-vc-label
no shutdown
The following example shows the command usage to bind an Epipe service between
ALA-1 and ALA-2. This example assumes the SAPs have already been configured
(see Distributed Epipe SAPs).
A:ALA-1>config>service# epipe 5500
config>service>epipe# spoke-sdp 2:123
config>service>epipe>spoke-sdp# egress
config>service>epipe>spoke-sdp>egress# vc-label 5500
config>service>epipe>spoke-sdp>egress# exit
config>service>epipe>spoke-sdp# ingress
config>service>epipe>spoke-sdp>ingress# vc-label 6600
config>service>epipe>spoke-sdp>ingress# exit
config>service>epipe>spoke-sdp# no shutdown
ALA-2>config>service# epipe 5500
config>service>epipe# spoke-sdp 2:456
config>service>epipe>spoke-sdp# egress
config>service>epipe>spoke-sdp>egress# vc-label 6600
config>service>epipe>spoke-sdp>egress# exit
config>service>epipe>spoke-sdp# ingress
config>service>epipe>spoke-sdp>ingress# vc-label 5500
config>service>epipe>spoke-sdp>ingress# exit
config>service>epipe>spoke-sdp# no shutdown
This example shows the SDP binding for the Epipe service between ALA-1 and ALA2:
168
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
A:ALA-1>config>service# info
---------------------------------------------...
epipe 5500 customer 5 vpn 5500 create
description "Distributed epipe service to east coast"
sap 2/1/3:21 create
ingress
qos 555
filter ip 1
exit
egress
scheduler-policy "alpha"
qos 627
exit
exit
spoke-sdp 2:123 create
ingress
vc-label 6600
exit
egress
vc-label 5500
exit
exit
no shutdown
exit
...
---------------------------------------------A:ALA-1>config>service#
A:ALA-2>config>service# info
---------------------------------------------...
exit
epipe 5500 customer 5 vpn 5500 create
description "Distributed epipe service to west coast"
sap 441/1/4:550 create
ingress
qos 654
filter ip 1020
exit
egress
scheduler-policy "test1"
qos 432
filter ip 6
exit
exit
spoke-sdp 2:456 create
ingress
vc-label 5500
exit
egress
vc-label 6600
exit
exit
no shutdown
exit
...
----------------------------------------------
Issue: 01
3HE 11970 AAAA TQZZA 01
169
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
A:ALA-2>config>service#
2.16.3.4
Creating an Fpipe Service
Use the following CLI syntax to create an Fpipe service on a 7750 SR.
CLI Syntax:
config>service# fpipe service-id [customer customer-id]
[vpn vpn-id] [vc-type {fr-dlci}][vc-switching]
description description-string
service-mtu octets
no shutdown
The following example shows the command usage to create an Fpipe service:
PE router 1 (A:ALA-41):
Example:
A:ALA-41>config>service# fpipe 1 customer 1 create
A:ALA-41config>service>fpipe# description “fpipe test”
A:ALA-41config>service>fpipe# service-mtu 1400
A:ALA-41config>service>fpipe# no shutdown
A:ALA-41config>service>fpipe#
PE router 2 (A:ALA-42):
Example:
A:ALA-42>config>service# fpipe
A:ALA-42>config>service>fpipe#
A:ALA-42>config>service>fpipe#
A:ALA-42>config>service>fpipe#
A:ALA-42>config>service>fpipe#
1 customer 1 create
description “fpipe test”
service-mtu 1400
no shutdown
The following example shows the Fpipe service creation output.
PE router 1 (A:ALA-41):
A:ALA-41>config>service# info
------------------------------------------...
fpipe 1 customer 1 create
description “fpipe test”
service-mtu 1400
no shutdown
exit
...
------------------------------------------A:ALA-41>config>service#
170
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
PE router 2 (A:ALA-42):
A:ALA-42>config>service# info
------------------------------------------...
fpipe 1 customer 1 create
description “fpipe test”
service-mtu 1400
no shutdown
exit
...
------------------------------------------A:ALA-42>config>service#
2.16.3.4.1
Configuring Fpipe SAP Parameters
Use the following CLI syntax to configure Fpipe SAP parameters.
CLI Syntax:
config>service# fpipe service-id [customer customer-id]
[vpn vpn-id] [vc-type {fr-dlci}] [vc-switching]
sap sap-id
accounting-policy acct-policy-id
collect-stats
description description-string
egress
filter [ip ip-filter-id]
qos policy-id
scheduler-policy scheduler-policy-name
ingress
filter [ip ip-filter-id]
qos policy-id [shared-queuing]
scheduler-policy scheduler-policy-name
multi-service-site customer-site-name
no shutdown
The following example shows the command usage to create an Fpipe SAP:
PE router 1 (A:ALA-41):
Example:
Issue: 01
A:ALA-41>config>service# fpipe 1
A:ALA-41>config>service>fpipe# sap 1/2/1:16 create
A:ALA-41>config>service>fpipe>sap# ingress
A:ALA-41>config>service>fpipe>sap>ingress# qos 101
A:ALA-41>config>service>fpipe>sap>ingress# exit
A:ALA-41>config>service>fpipe>sap# egress
A:ALA-41>config>service>fpipe>sap>egress# qos 1020
3HE 11970 AAAA TQZZA 01
171
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
A:ALA-41>config>service>fpipe>sap>egress# exit
A:ALA-41>config>service>fpipe>sap# no shutdown
A:ALA-41>config>service>fpipe>sap# exit
A:ALA-41>config>service>fpipe#
PE router 2 (A:ALA-42):
Example:
A:ALA-42>config>service# fpipe 1
A:ALA-42>config>service>fpipe# sap 2/1/1.1:16 create
A:ALA-42>config>service>fpipe>sap# ingress
A:ALA-42>config>service>fpipe>sap>ingress# qos 101
A:ALA-42>config>service>fpipe>sap>ingress# exit
A:ALA-42>config>service>fpipe>sap# egress
A:ALA-42>config>service>fpipe>sap>egress# qos 1020
A:ALA-42>config>service>fpipe>sap>egress# exit
A:ALA-42>config>service>fpipe>sap# no shutdown
A:ALA-42>config>service>fpipe>sap# exit
A:ALA-42>config>service>fpipe#
The following example shows the Fpipe SAP configurations.
PE Router 1 (ALA-41):
A:ALA-41>config>service# info
------------------------------------...
fpipe 1 customer 1 create
description "fpipe test"
service-mtu 1400
sap 1/2/1:16 create
ingress
qos 101
exit
egress
qos 1020
exit
exit
no shutdown
exit
...
------------------------------------A:ALA-41>config>service#
PE Router 2 (ALA-42):
A:ALA-42>config>service# info
------------------------------------...
fpipe 1 customer 1 create
description "fpipe test"
service-mtu 1400
sap 2/1/1.1:16 create
ingress
172
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
qos 101
exit
egress
qos 1020
exit
exit
no shutdown
exit
...
------------------------------------A:ALA-42>config>service#
2.16.3.4.2
Configuring Fpipe SDP Bindings
Use the following CLI syntax to create a spoke SDP binding with an Fpipe service:
CLI Syntax:
config>service# fpipe service-id [customer customer-id]
[vpn vpn-id] [vc-type {fr-dlci}][vc-switching]
spoke-sdp sdp-id:vc-id
egress
filter ip ip-filter-id
vc-label egress-vc-label
ingress
filter ip ip-filter-id
vc-label ingress-vc-label
no shutdown
The following example shows the command usage to create an Fpipe spoke SDP:
PE router 1 (A:ALA-41):
Example:
A:ALA-41>config>service# fpipe 1
A:ALA-41>config>service>fpipe# spoke-sdp 1:1 create
A:ALA-41>config>service>spoke-sdp# no shutdown
A:ALA-41>config>service>spoke-sdp# exit
PE router 2 (A:ALA-42):
Example:
A:ALA-42>config>service# fpipe 1
A:ALA-42>config>service>fpipe# spoke-sdp 1:1 create
A:ALA-42>config>service>spoke-sdp# no shutdown
A:ALA-42>config>service>spoke-sdp# exit
The following example shows the Fpipe spoke SDP configuration.
PE Router 1 (ALA-41):
A:ALA-41>config>service# info
Issue: 01
3HE 11970 AAAA TQZZA 01
173
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
------------------------------------...
fpipe 1 customer 1 create
description "fpipe test"
service-mtu 1400
sap 1/2/1:16 create
ingress
qos 101
exit
egress
qos 1020
exit
exit
spoke-sdp 1:1 create
exit
no shutdown
exit
...
------------------------------------A:ALA-41>config>service#
PE Router 2 (ALA-42):
A:ALA-42>config>service# info
------------------------------------...
fpipe 1 customer 1 create
description "fpipe test"
service-mtu 1400
sap 2/1/1.1:16 create
ingress
qos 101
exit
egress
qos 1020
exit
exit
spoke-sdp 1:1 create
exit
no shutdown
exit
...
------------------------------------A:ALA-42>config>service#
2.16.3.5
Creating an Ipipe Service
Use the following CLI syntax to create an Ipipe service on a 7450 ESS or 7750 SR.
CLI Syntax:
174
config>service# ipipe service-id [customer customer-id]
[vpn vpn-id][vc-switching]
description description-string
no shutdown
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
The following example shows an Ipipe configuration example:
A:ALA-1>config>service# info
------------------------------------------...
ipipe 202 customer 1 create
description "eth_ipipe"
no shutdown
exit
------------------------------------------A:ALA-1>config>service#
2.16.3.5.1
Configuring Ipipe SAP Parameters
The following example shows an Ipipe SAP configuration example:
A:ALA-48>config>service# info
---------------------------------------------...
ipipe 202 customer 1 create
sap 1/1/2:444 create
description "eth_ipipe"
ce-address 31.31.31.1
exit
sap 1/3/2:445 create
description "eth_ipipe"
ce-address 31.31.31.2
exit
no shutdown
exit
...
---------------------------------------------A:ALA-48>config>service#
The following examples shows a Frame Relay to Ethernet local Ipipe configuration.
Example:
config>service# ipipe 204 customer 1 create
config>service>ipipe$ sap 1/1/2:446 create
config>service>ipipe>sap$ description "eth_fr_ipipe"
config>service>ipipe>sap$ ce-address 32.32.32.1
config>service>ipipe>sap$ no shutdown
config>service>ipipe>sap$ exit
config>service>ipipe# sap 2/2/2:16 create
config>service>ipipe>sap$ ce-address 32.32.32.2
config>service>ipipe>sap$ no shutdown
config>service>ipipe>sap$ exit
config>service>ipipe# no shutdown
config>service>ipipe# exit
config>service#
The following example shows the output.
Issue: 01
3HE 11970 AAAA TQZZA 01
175
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
A:ALA-48>config>service# info
---------------------------------------------...
ipipe 204 customer 1 create
sap 1/1/2:446 create
description "eth_fr_ipipe"
ce-address 32.32.32.1
exit
sap 2/2/2:16 create
ce-address 32.32.32.2
exit
no shutdown
exit
...
---------------------------------------------A:ALA-48>config>service#
The following examples shows a PPP to Ethernet local Ipipe configuration.
Example:
config>service# ipipe 206 customer 1 create
config>service>ipipe$ sap 1/1/2:447 create
config>service>ipipe>sap$ description "eth_ppp_ipipe"
config>service>ipipe>sap$ ce-address 33.33.33.1
config>service>ipipe>sap$ no shutdown
config>service>ipipe>sap$ exit
config>service>ipipe# sap 2/2/2 create
config>service>ipipe>sap$ description "ppp_eth_ipipe"
config>service>ipipe>sap$ ce-address 33.33.33.2
config>service>ipipe>sap$ no shutdown
config>service>ipipe>sap$ exit
config>service>ipipe# no shutdown
config>service>ipipe# exit
config>service#
The following example shows the output.
A:ALA-48>config>service# info
---------------------------------------------...
ipipe 206 customer 1 create
sap 1/1/2:447 create
description "eth_ppp_ipipe"
ce-address 33.33.33.1
exit
sap 2/2/2 create
description "ppp_eth_ipipe"
ce-address 33.33.33.2
exit
no shutdown
exit
...
---------------------------------------------A:ALA-48>config>service#
176
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
2.16.3.5.2
VLL Services
Configuring Ipipe SDP Bindings
The following example shows an Ipipe SDP configuration.
A:ALA-48>config>service# info
---------------------------------------------...
sdp 16 mpls create
far-end 4.4.4.4
ldp
path-mtu 1600
keep-alive
shutdown
exit
no shutdown
exit
...
ipipe 207 customer 1 create
shutdown
sap 1/1/2:449 create
description "Remote_Ipipe"
ce-address 34.34.34.1
exit
spoke-sdp 16:516 create
ce-address 31.31.31.2
exit
exit
...
---------------------------------------------A:ALA-48>config>service#
2.16.4
Using Spoke SDP Control Words
The control word command provides the option to add a control word as part of the
packet encapsulation for PW types for which the control word is optional. These are
Ethernet pseudowire (Epipe), ATM N:1 cell mode pseudowires (Apipe vc-types atmvcc and atm-vpc) and VT pseudowire (Apipe vc-type atm-cell). The control word
might be needed because when ECMP is enabled on the network, packets of a given
pseudowire may be spread over multiple ECMP paths if the hashing router mistakes
the PW packet payload for an IPv4 or IPv6 packet. This occurs when the first nibble
following the service label corresponds to a value of 4 or 6.
Issue: 01
3HE 11970 AAAA TQZZA 01
177
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
The control word negotiation procedures described in Section 6.2 of RFC 4447 are
not supported and therefore the service will only come up if the same C bit value is
signaled in both directions. If a spoke-sdp is configured to use the control word but
the node receives a label mapping message with a C-bit clear, the node releases the
label with an “Illegal C-bit” status code per Section 6.1 of RFC 4447. As soon as the
user enables control of the remote peer, the remote peer withdraws its original label
and sends a label mapping with the C-bit set to 1 and the VLL service is up in both
nodes.
When the control word is enabled, VCCV packets also include the VCCV control
word. In that case, the VCCV CC type 1 (OAM CW) is signaled in the VCCV
parameter in the FEC. If the control word is disabled on the spoke-sdp, then the
Router Alert label is used. In that case, VCCV CC type 2 is signaled. Note that for a
multi-segment pseudowire (MS-PW), the CC type 1 is the only supported and thus
the control word must be enabled on the spoke-sdp to be able to use VCCV-ping and
VCCV-trace.
The following example shows a spoke SDP control word configuration:
-Dut-B>config>service>epipe# info
---------------------------------------------description "Default epipe description for service id 2100"
sap 1/2/7:4 create
description "Default sap description for service id 2100"
exit
spoke-sdp 1:2001 create
control-word
exit
no shutdown
---------------------------------------------*A:ALA-Dut-B>config>service>epipe#
To disable the control word on spoke-sdp 1:2001:
*A:ALA-Dut-B>config>service>epipe# info
---------------------------------------------description "Default epipe description for service id 2100"
sap 1/2/7:4 create
description "Default sap description for service id 2100"
exit
spoke-sdp 1:2001 create
exit
no shutdown
---------------------------------------------*A:ALA-Dut-B>config>service>epipe#
2.16.5
Same Fate Epipe VLANs Access Protection
The following example shows a G.8031 Ethernet Tunnel for Epipe protection
configuration for 7450 ESS or 7750 SR using same-fate SAPs for each Epipe access
(two Ethernet member ports 1/1/1 and 2/1/1/1 are used):
178
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
*A:7750_ALU>config>eth-tunnel 1
---------------------------------------------description "Protection is APS"
protection-type 8031_1to1
ethernet
mac 00:11:11:11:11:12
encap-type dot1q
exit
ccm-hold-time down 5 up 10 // 50 ms down, 1 second up
path 1
member 1/1/1
control-tag 5 // primary control vlan 5
precedence primary
eth-cfm
mep 2 domain 1 association 1
ccm-enable
control-mep
no shutdown
exit
exit
no shutdown
exit
path 2
member 2/1/1
control-tag 105 //secondary control vlan 105
eth-cfm
mep 2 domain 1 association 2
ccm-enable
control-mep
no shutdown
exit
exit
no shutdown
exit
no shutdown
-------------------------------------------------# Configure Ethernet tunnel SAPs
-------------------------------------------------*A:7750_ALU>config>service epipe 10 customer 5 create
sap eth-tunnel-1 create // Uses control tags from the Ethernet tunnel port
description "g8031-protected access ctl/data SAP for eth-tunnel 1"
exit
no shutdown
---------------------------------------------*A:7750_ALU>config>service epipe 11 customer 5 create
sap eth-tunnel-1:1 create
description "g8031-protected access same-fate SAP for eth-tunnel 1"
// must specify tags for each corresponding path in Ethernet tunnel port
eth-tunnel path 1 tag 6
eth-tunnel path 2 tag 106
exit
…
---------------------------------------------*A:7750_ALU>config>service epipe 10 customer 5 create
sap eth-tunnel-1:3 create
description "g8031-protected access same-fate SAP for eth-tunnel 1"
// must specify tags for each path for same-fate SAPs
Issue: 01
3HE 11970 AAAA TQZZA 01
179
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
eth-tunnel path 1 tag 10
eth-tunnel path 2 tag 110
exit
…
----------------------------------------------
2.16.6
Pseudowire Configuration Notes
The vc-switching parameter must be specified at the time the VLL service is
created. Note that when the vc-switching parameter is specified, you are
configuring an S-PE. This is a pseudowire switching point (switching from one
pseudowire to another). Therefore, you cannot add a SAP to the configuration.
The following example shows the configuration when a SAP is added to a
pseudowire. The CLI generates an error response if you attempt to create a SAP. VC
switching is only needed on the pseudowire at the S-PE.
*A:ALA-701>config>service# epipe 28 customer 1 create vc-switching
*A:ALA-701>config>service>epipe$ sap 1/1/3 create
MINOR: SVCMGR #1311 SAP is not allowed under PW switching service
*A:ALA-701>config>service>epipe$
Use the following CLI syntax to create pseudowire switching VLL services. These are
examples only. Different routers support different pseudowire switching VLL
services.
180
CLI Syntax:
config>service# apipe service-id [customer customer-id]
[vpn vpn-id] [vc-type {atm-vcc|atm-sdu|atm-vpc|atmcell}] [vc-switching]
description description-string
spoke-sdp sdp-id:vc-id
CLI Syntax:
config>service# epipe service-id [customer customerid][vpn vpn-id][vc-switching]
description description-string
spoke-sdp sdp-id:vc-id
CLI Syntax:
config>service# fpipe service-id [customer customerid][vpn vpn-id] [vc-type {fr-dlci}] [vc-switching]
description description-string
spoke-sdp sdp-id:vc-id
CLI Syntax:
config>service# ipipe service-id [customer customerid][vpn vpn-id] [vc-switching]
description description-string
spoke-sdp sdp-id:vc-id
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
The following example shows the command usage to configure VLL pseudowire
switching services:
Example:
config>service# apipe 1 customer 1 vpn 1 vc-switching
create
config>service>apipe$ description “Default apipe
description for service id 100”
config>service>apipe# spoke-sdp 3:1 create
config>service>apipe>spoke-sdp# exit
config>service>apipe# spoke-sdp 6:200 create
config>service>apipe>spoke-sdp# exit
config>service>apipe# no shutdown
The following example shows configurations for each service:
*A:ALA-48>config>service# info
---------------------------------------------...
apipe 100 customer 1 vpn 1 vc-switching create
description "Default apipe description for service
spoke-sdp 3:1 create
exit
spoke-sdp 6:200 create
exit
no shutdown
exit
...
epipe 107 customer 1 vpn 107 vc-switching create
description "Default epipe description for service
spoke-sdp 3:8 create
exit
spoke-sdp 6:207 create
exit
no shutdown
exit
...
ipipe 108 customer 1 vpn 108 vc-switching create
description "Default ipipe description for service
spoke-sdp 3:9 create
exit
spoke-sdp 6:208 create
exit
no shutdown
exit
...
fpipe 109 customer 1 vpn 109 vc-switching create
description "Default fpipe description for service
spoke-sdp 3:5 create
exit
spoke-sdp 6:209 create
exit
no shutdown
exit
...
---------------------------------------------*A:ALA-48>config>service#
Issue: 01
3HE 11970 AAAA TQZZA 01
id 100"
id 107"
id 108"
id 109"
181
VLL Services
2.16.7
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
Configuring Two VLL Paths Terminating on T-PE2
Figure 49
VLL Resilience with Pseudowire Redundancy and Switching
Primary PW
Access Node
Standby PW
7x50 T-PE2
Metro area B
SDP3:300
PW switching
7x50 T-PE3
SDP6:600
7x50
7x50
7x50 S-PE3
7x50 S-PE4
PW switching
Core area
PW switching
7x50 S-PE2
7x50 S-PE1
PW switching
SDP4:400
SDP1:100
7x50
7x50
Metro area A
7x50 T-PE1
7x50
Access Node
OSSG114
T-PE1
The following shows an example of the T-PE1 configuration.
*A:ALA-T-PE1>config>service>epipe# info
---------------------------------------------endpoint "x" create
exit
endpoint "y" create
exit
spoke-sdp 1:100 endpoint "y" create
precedence primary
revert-time 0
exit
spoke-sdp 4:400 endpoint "y" create
precedence 0
exit
no shutdown
---------------------------------------------*A:ALA-T-PE1>config>service>epipe#
182
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
The following shows an example of the T-PE2 configuration for 7950 XRS.
T-PE2
*A:ALA-T-PE2>config>service>epipe# info
---------------------------------------------endpoint "x" create
exit
endpoint "y" create
exit
sap endpoint "x" create
exit
spoke-sdp 3:300 endpoint "y" create
precedence primary
revert-time 0
exit
spoke-sdp 6:600 endpoint "y" create
precedence 0
exit
no shutdown
---------------------------------------------*A:ALA-T-PE2>config>service>epipe#
The following example shows the T-PE2 configuration for 7450 ESS and 7750 SR.
T-PE2
*A:ALA-T-PE2>config>service>epipe# info
---------------------------------------------endpoint "x" create
exit
endpoint "y" create
exit
sap 2/2/2:200 endpoint "x" create
exit
spoke-sdp 3:300 endpoint "y" create
precedence primary
revert-time 0
exit
spoke-sdp 6:600 endpoint "y" create
precedence 0
exit
no shutdown
---------------------------------------------*A:ALA-T-PE2>config>service>epipe#
S-PE1: Note that specifying the vc-switching parameter enables a VC crossconnect so the service manager does not signal the VC label mapping immediately
but will put this into passive mode.
The following example shows the configuration:
*A:ALA-S-PE1>config>service>epipe# info
---------------------------------------------...
Issue: 01
3HE 11970 AAAA TQZZA 01
183
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
spoke-sdp 2:200 create
exit
spoke-sdp 3:300 create
exit
no shutdown
---------------------------------------------*A:ALA-S-PE1>config>service>epipe#
S-PE2: Note that specifying the vc-switching parameter enables a VC crossconnect so the service manager does not signal the VC label mapping immediately
but will put this into passive mode.
The following example shows the configuration:
*A:ALA-S-PE2>config>service>epipe# info
---------------------------------------------...
spoke-sdp 2:200 create
exit
spoke-sdp 3:300 create
exit
no shutdown
---------------------------------------------*A:ALA-S-PE2>config>service>epipe#
2.16.8
Configuring VLL Resilience
Figure 50 shows an example to create VLL resilience. Note that the zero revert-time
value means that the VLL path will be switched back to the primary immediately after
it comes back up.
Figure 50
VLL Resilience
spoke-sdp 1:100
sap 1/1/1:100
PE-2
PE-1
sap 1/2/1:100
BRAS
spoke-sdp 2:200
sap 1/1/2:100
PE-3
OSSG246
PE1:
The following example shows the configuration on PE1.
184
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
*A:ALA-48>config>service>epipe# info
---------------------------------------------endpoint "x" create
exit
endpoint "y" create
exit
spoke-sdp 1:100 endpoint "y" create
precedence primary
exit
spoke-sdp 2:200 endpoint "y" create
precedence 1
exit
no shutdown
---------------------------------------------*A:ALA-48>config>service>epipe#
2.16.9
Configuring VLL Resilience for a Switched
Pseudowire Path
Figure 51
VLL Resilience with Pseudowire Switching
S-PE-1
spoke-sdp 1:100
sap 1/1/1:100
sap 1/2/1:100
spoke-sdp 2:200
T-PE-1
spoke-sdp 4:400
S-PE-2
spoke-sdp 3:300
T-PE-2
spoke-sdp 6:600
S-PE-3
OSSG247
T-PE1
The following example shows the configuration on TPE1.
*A:ALA-48>config>service>epipe# info
---------------------------------------------endpoint "x" create
exit
endpoint "y" create
exit
sap 1/1/1:100 endpoint "x" create
exit
spoke-sdp 1:100 endpoint "y" create
precedence primary
exit
spoke-sdp 2:200 endpoint "y" create
precedence 1
Issue: 01
3HE 11970 AAAA TQZZA 01
185
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
exit
spoke-sdp 3:300 endpoint "y" create
precedence 1
exit
no shutdown
---------------------------------------------*A:ALA-48>config>service>epipe#
T-PE2
The following example shows the configuration on TPE2.
*A:ALA-49>config>service>epipe# info
---------------------------------------------endpoint "x" create
exit
endpoint "y" create
revert-time 100
exit
spoke-sdp 4:400 endpoint "y" create
precedence primary
exit
spoke-sdp 5:500 endpoint "y" create
precedence 1
exit
spoke-sdp 6:600 endpoint "y" create
precedence 1
exit
no shutdown
---------------------------------------------*A:ALA-49>config>service>epipe#
S-PE1
The following example shows the configuration on S-PE1.
*A:ALA-50>config>service>epipe# info
---------------------------------------------...
spoke-sdp 1:100 create
exit
spoke-sdp 4:400 create
exit
no shutdown
---------------------------------------------*A:ALA-49>config>service>epipe#
186
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
2.16.10
2.16.10.1
VLL Services
Configuring BGP Virtual Private Wire Service
(VPWS)
Single-Homed BGP VPWS
Figure 52 shows an example topology for a BGP VPWS service used to create a
virtual lease-line across an MPLS network between two sites, A and B.
Figure 52
Single-Homed BGP VPWS Configuration Example
ve-id=1
rd=65536:1
rt=65536:1
ve-id=2
rd=65536:2
rt=65536:1
PE1
Site A
SAP 1/1/1:1
epipe
PE2
Spoke-SDP
Spoke-SDP
epipe
SAP 1/1/1:1
Site B
SR_QPD_0001
An Epipe is configured on PE1 and PE2 with BGP VPWS enabled. PE1 and PE2 are
connected to site A and B, respectively, each using a SAP. The interconnection
between the two PEs is achieved through a pseudowire, using Ethernet VLAN
encaps, which is signaled using BGP VPWS over a tunnel LSP between PE1 and
PE2. A MIP or MEP can be configured on a BGP VPWS SAP. However, fault
propagation between a MEP and the BGP update state signaling is not supported.
BGP VPWS routes are accepted only over an iBGP session.
The following examples shows the BGP VPWS configuration on each PE.
PE1:
pw-template 1 create
vc-type vlan
exit
epipe 1 customer 1 create
bgp
route-distinguisher 65536:1
route-target export target:65536:1 import target:65536:1
pw-template-binding 1
exit
exit
bgp-vpws
ve-name PE1
ve-id 1
exit
remote-ve-name PE2
ve-id 2
exit
no shutdown
Issue: 01
3HE 11970 AAAA TQZZA 01
187
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
exit
sap 1/1/1:1 create
exit
no shutdown
exit
PE2:
pw-template 1 create
vc-type vlan
exit
epipe 1 customer 1 create
bgp
route-distinguisher 65536:2
route-target export target:65536:1 import target:65536:1
pw-template-binding 1
exit
exit
bgp-vpws
ve-name PE2
ve-id 2
exit
remote-ve-name PE1
ve-id 1
exit
no shutdown
exit
sap 1/1/1:1 create
exit
no shutdown
exit
The BGP-VPWS update can be shown using the following command:
A:PE1# show service l2-route-table bgp-vpws detail
===============================================================================
Services: L2 Bgp-Vpws Route Information - Summary
===============================================================================
Svc Id
: 1
VeId
: 2
PW Temp Id
: 1
RD
: *65536:2
Next Hop
: 1.1.1.2
State (D-Bit) : up(0)
Path MTU
: 1514
Control Word
: 0
Seq Delivery
: 0
Status
: active
Tx Status
: active
CSV
: 0
Preference
: 0
Sdp Bind Id
: 17407:4294967295
===============================================================================
A:PE1#
188
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
2.16.10.2
VLL Services
Dual-Homed BGP VPWS
Single Pseudowire Example:
Figure 53 shows an example topology for a dual-homed BGP VPWS service used to
create a virtual lease-line across an MPLS network between two sites, A and B. A
single pseudowire is established between the designated forwarder of the dualhomed PEs and the remote PE.
Figure 53
Example of Dual-Homed BGP VPWS with Single Pseudowire
ve-id=1
mh-id=1
rd=65536:1
rt=65536:1
PE1
SAP
epipe
Designated
Forwarder
Spoke-SDP
Site A
PE3
epipe
SAP
PE2
Blocked
SAP
epipe
Site B
ve-id=3
rd=65536:3
rt=65536:1
ve-id=1
mh-id=1
rd=65536:2
rt=65536:1
SR_QPD_0002
An Epipe with BGP VPWS enabled is configured on each PE. Site A is dual-homed
to PE1 and PE2 with a remote PE, PE3, connected to site B; each connection uses
a SAP. A single pseudowire using Ethernet Raw Mode encaps connects PE3 to PE1.
The pseudowire is signaled using BGP VPWS over a tunnel LSPs between the PEs.
Site A is configured on PE1 and PE2 with the BGP route selection, the site state, and
the site-preference used to ensure PE1 is the designated forwarder when the
network is fully operational.
The following example shows the BGP VPWS configuration on each PE.
PE1:
pw-template 1 create
exit
epipe 1 customer 1 create
bgp
route-distinguisher 65536:1
route-target export target:65536:1 import target:65536:1
pw-template-binding 1
Issue: 01
3HE 11970 AAAA TQZZA 01
189
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
exit
exit
bgp-vpws
ve-name PE1
ve-id 1
exit
remote-ve-name PE3
ve-id 3
exit
no shutdown
exit
sap 1/1/1:1 create
exit
site "siteA" create
site-id 1
sap 1/1/1:1
boot-timer 20
site-activation-timer 5
no shutdown
exit
no shutdown
exit
PE2:
pw-template 1 create
exit
epipe 1 customer 1 create
bgp
route-distinguisher 65536:2
route-target export target:65536:1 import target:65536:1
pw-template-binding 1
exit
exit
bgp-vpws
ve-name PE2
ve-id 1
exit
remote-ve-name PE3
ve-id 3
exit
no shutdown
exit
sap 1/1/1:1 create
exit
site "siteA" create
site-id 1
sap 1/1/1:1
boot-timer 20
site-activation-timer 5
no shutdown
exit
no shutdown
exit
190
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
PE3:
pw-template 1 create
exit
epipe 1 customer 1 create
bgp
route-distinguisher 65536:3
route-target export target:65536:1 import target:65536:1
pw-template-binding 1
exit
exit
bgp-vpws
ve-name PE3
ve-id 3
exit
remote-ve-name PE1orPE2
ve-id 1
exit
no shutdown
exit
sap 1/1/1:1 create
exit
no shutdown
exit
Active/Standby Pseudowire Example:
Figure 54 shows an example topology for a dual-homed BGP VPWS service used to
create a virtual lease-line across an MPLS network between two sites, A and B. Two
pseudowires are established between the remote PE and the dual-homed PEs. The
active pseudowire used for the traffic is the one connecting the remote PE to the
designated forwarder of the dual-homed PEs.
Issue: 01
3HE 11970 AAAA TQZZA 01
191
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
Figure 54
Example of Dual-homed BGP VPWS with Active/Standby
Pseudowires
ve-id=1
mh-id=1
rd=65536:1
rt=65536:1
site-preference 200
PE1
SAP
epipe
Designated
Forwarder
Active Spoke-SDP
Site A
PE3
epipe
SAP
PE2
Blocked
Standby Spoke-SDP
SAP
epipe
Site B
ve-id=3
rd=65536:3
rt=65536:1
ve-id=2
mh-id=1
rd=65536:2
rt=65536:1
site-preference 10
SR_QPD_0003
An Epipe with BGP VPWS enabled is configured on each PE. Site A is dual-homed
to PE1 and PE2 with a remote PE, PE3, connected to site B; each connection uses
a SAP. Active/standby pseudowires using Ethernet Raw Mode encaps connect PE3
to PE1 and PE2, respectively. The pseudowires are signaled using BGP VPWS over
a tunnel LSPs between the PEs.
Site A is configured on PE1 and PE2 with the site-preference set to ensure that PE1
is the designated forwarder when the network is fully operational. An endpoint is
automatically created on PE3 in which the active/standby pseudowires are created.
The following example shows the BGP VPWS configuration on each PE.
PE1:
pw-template 1 create
exit
epipe 1 customer 1 create
bgp
route-distinguisher 65536:1
route-target export target:65536:1 import target:65536:1
pw-template-binding 1
exit
exit
bgp-vpws
ve-name PE1
ve-id 1
exit
remote-ve-name PE3
192
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
ve-id 3
exit
no shutdown
exit
sap 1/1/1:1 create
exit
site "siteA" create
site-id 1
sap 1/1/1:1
boot-timer 20
site-activation-timer 5
site-preference 200
no shutdown
exit
no shutdown
exit
PE2:
pw-template 1 create
exit
epipe 1 customer 1 create
bgp
route-distinguisher 65536:2
route-target export target:65536:1 import target:65536:1
pw-template-binding 1
exit
exit
bgp-vpws
ve-name PE2
ve-id 2
exit
remote-ve-name PE3
ve-id 3
exit
no shutdown
exit
sap 1/1/1:1 create
exit
site "siteA" create
site-id 1
sap 1/1/1:1
boot-timer 20
site-activation-timer 5
site-preference 10
no shutdown
exit
no shutdown
exit
PE3:
pw-template 1 create
exit
epipe 1 customer 1 create
Issue: 01
3HE 11970 AAAA TQZZA 01
193
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
bgp
route-distinguisher 65536:3
route-target export target:65536:1 import target:65536:1
pw-template-binding 1
exit
exit
bgp-vpws
ve-name PE3
ve-id 3
exit
remote-ve-name PE1
ve-id 1
exit
remote-ve-name PE2
ve-id 2
exit
no shutdown
exit
sap 1/1/1:1 create
exit
no shutdown
exit
2.16.11
Service Management Tasks
This section discusses the following Apipe service management tasks, supported on
the 7750 SR only:
• Modifying Apipe Service Parameters
• Disabling an Apipe Service
• Re-Enabling an Apipe Service
• Deleting an Apipe Service
This section discusses the following Cpipe service management tasks, supported on
the 7750 SR only:
• Modifying a Cpipe Service
• Deleting a Cpipe Service
This section discusses the following Epipe service management tasks:
• Modifying Epipe Service Parameters
• Disabling an Epipe Service
• Re-Enabling an Epipe Service
• Deleting an Epipe Service
194
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
This section discusses the following Fpipe service management tasks, supported on
the 7750 SR only:
• Modifying Fpipe Service Parameters
• Disabling an Fpipe Service
• Re-enabling an Fpipe Service
• Deleting an Fpipe Service
This section discusses the following Ipipe service management tasks, supported on
the 7750 SR only:
• Modifying Ipipe Service Parameters
• Disabling an Ipipe Service
• Re-enabling an Ipipe Service
• Deleting an Ipipe Service
2.16.11.1
Modifying Apipe Service Parameters
The following example shows the command usage to modify Apipe parameters,
supported on the 7750 SR only:
PE router 1 (A:ALA-41):
Example:
A:ALA-41>config>service# apipe 5
A:ALA-41>config>service>apipe# sap 1/1/1:0/32 create
A:ALA-41>config>service>apipe>sap# accounting-policy 2
A:ALA-41>config>service>apipe>sap# exit
A:ALA-41>config>service>apipe# spoke-sdp 1:4
A:ALA-41>config>service>apipe>spoke-sdp# egress
A:ALA-41>config>service>apipe>spoke-sdp>egress# vclabel 16
A:ALA-41>config>service>apipe>spoke-sdp>egress# exit
A:ALA-41>config>service>apipe>spoke-sdp# exit
A:ALA-41>config>service>apipe#
PE router 2 (A:ALA-42):
Example:
Issue: 01
A:ALA-42>config>service# apipe 5
A:ALA-42>config>service>apipe# sap 2/2/2:0/32 create
A:ALA-42>config>service>apipe>sap# accounting-policy 2
A:ALA-42>config>service>apipe>sap# exit
A:ALA-42>config>service>apipe# spoke-sdp 1:4
A:ALA-42>config>service>apipe>spoke-sdp# egress
3HE 11970 AAAA TQZZA 01
195
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
A:ALA-42>config>service>apipe>spoke-sdp>egress# vclabel 16
A:ALA-42>config>service>apipe>spoke-sdp>egress# exit
A:ALA-42>config>service>apipe>spoke-sdp# exit
A:ALA-42>config>service>apipe#
PE Router 1 (ALA-41):
A:ALA-41>config>service# info
------------------------------------...
apipe 5 customer 1 create
description "apipe test"
service-mtu 1400
sap 1/1/1:0/32 create
accounting-policy 2
ingress
qos 102
exit
egress
qos 103
exit
exit
spoke-sdp 1:4 create
egress
vc-label 16
exit
no shutdown
exit
...
------------------------------------A:ALA-41>config>service#
PE Router 2 (ALA-42):
A:ALA-42>config>service# info
------------------------------------...
apipe 5 customer 1 create
description "apipe test"
service-mtu 1400
sap 2/2/2:0/32 create
accounting-policy 2
ingress
qos 102
exit
egress
qos 103
exit
exit
spoke-sdp 1:4 create
egress
vc-label 16
exit
no shutdown
exit
...
------------------------------------A:ALA-42>config>service#
196
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
2.16.11.2
VLL Services
Disabling an Apipe Service
An Apipe service can be shut down without deleting any service parameters.
CLI Syntax:
config>service#
apipe service-id
shutdown
PE router 1 (A:ALA-41):
Example:
A:ALA-41>config>service# apipe 5
A:ALA-41>config>service>apipe# shutdown
A:ALA-41>config>service>apipe# exit
PE router 2 (A:ALA-42):
Example:
A:ALA-42>config>service# apipe 5
A:ALA-42>config>service>apipe# shutdown
A:ALA-42>config>service>apipe# exit
PE Router 1 (ALA-41):
A:ALA-41>config>service# info
------------------------------------...
apipe 5 customer 1 create
shutdown
description "apipe test"
service-mtu 1400
sap 1/1/1:0/32 create
accounting-policy 2
ingress
qos 102
exit
egress
qos 103
exit
exit
spoke-sdp 1:4 create
egress
vc-label 16
exit
no shutdown
exit
...
------------------------------------A:ALA-41>config>service#
PE Router 2 (ALA-42):
A:ALA-42>config>service# info
Issue: 01
3HE 11970 AAAA TQZZA 01
197
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
------------------------------------...
apipe 5 customer 1 create
shutdown
description "apipe test"
service-mtu 1400
sap 2/2/2:0/32 create
accounting-policy 2
ingress
qos 102
exit
egress
qos 103
exit
exit
spoke-sdp 1:4 create
egress
vc-label 16
exit
exit
...
------------------------------------A:ALA-42>config>service#
2.16.11.3
Re-Enabling an Apipe Service
To re-enable an Apipe service that was shut down.
CLI Syntax:
config>service#
apipe service-id
no shutdown
PE router 1 (A:ALA-41):
Example:
A:ALA-41>config>service# apipe 5
A:ALA-41>config>service>apipe# no shutdown
A:ALA-41>config>service>apipe# exit
PE router 2 (A:ALA-42):
Example:
198
A:ALA-42>config>service# apipe 5
A:ALA-42>config>service>apipe# no shutdown
A:ALA-42>config>service>apipe# exit
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
2.16.11.4
VLL Services
Deleting an Apipe Service
An Apipe service cannot be deleted until the SAP is shut down. If protocols and/or a
spoke-SDP are defined, they must be shut down and removed from the configuration
as well.
Use the following CLI syntax to delete Apipe services:
CLI Syntax:
config>service#
no apipe service-id
shutdown
no sap sap-id
shutdown
no spoke-sdp [sdp-id:vc-id]
shutdown
PE router 1 (A:ALA-41):
Example:
A:ALA-41>config>service# apipe 5
A:ALA-41>config>service>apipe# sap 1/1/1:0/32
A:ALA-41>config>service>apipe>sap# shutdown
A:ALA-41>config>service>apipe>sap# exit
A:ALA-41>config>service>apipe# no sap 1/1/1:0/32
A:ALA-41>config>service>apipe# spoke-sdp 1:4
A:ALA-41>config>service>apipe>spoke-sdp# shutdown
A:ALA-41>config>service>apipe>spoke-sdp# exit
A:ALA-41>config>service>apipe# no spoke-sdp 1:4
A:ALA-41>config>service>apipe# shutdown
A:ALA-41>config>service>apipe# exit
A:ALA-41>config>service# no apipe 5
PE router 2 (A:ALA-42):
Example:
Issue: 01
Example:A:ALA-41>config>service# apipe 5
A:ALA-41>config>service>apipe# sap 2/2/2:0/32
A:ALA-41>config>service>apipe>sap# shutdown
A:ALA-41>config>service>apipe>sap# exit
A:ALA-41>config>service>apipe# no sap 2/2/2:0/32
A:ALA-41>config>service>apipe# spoke-sdp 1:4
A:ALA-41>config>service>apipe>spoke-sdp# shutdown
A:ALA-41>config>service>apipe>spoke-sdp# exit
A:ALA-41>config>service>apipe# no spoke-sdp 1:4
A:ALA-41>config>service>apipe# shutdown
A:ALA-41>config>service>apipe# exit
A:ALA-41>config>service# no apipe 5
3HE 11970 AAAA TQZZA 01
199
VLL Services
2.16.11.5
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
Modifying a Cpipe Service
The following example shows the Cpipe service configuration, supported on the
7750 SR only.
*A:ALA-1>config>service# info
---------------------------------------------...
cpipe 94002 customer 1 vc-type cesopsn create
endpoint "to7705" create
exit
endpoint "toMC-APS" create
exit
sap aps-4.1.1.2.1 endpoint "toMC-APS" create
ingress
qos 20
exit
exit
spoke-sdp 14004:94002 endpoint "to7705" create
exit
spoke-sdp 100:294002 endpoint "toMC-APS" icb create
exit
spoke-sdp 100:194002 endpoint "to7705" icb create
exit
no shutdown
exit
...
---------------------------------------------*A:ALA-1>config>service> Cpipe#
2.16.11.6
Deleting a Cpipe Service
A Cpipe service cannot be deleted until SAPs are shut down and deleted. If a spokeSDP is defined, it must be shut down and removed from the configuration as well.
Use the following CLI syntax to delete a Cpipe service:
CLI Syntax:
2.16.11.7
config>service#
[no] cpipe service-id [customer customer-id]
[no] spoke-sdp sdp-id
[no] shutdown
shutdown
Modifying Epipe Service Parameters
The following example shows how to add an accounting policy to an existing SAP:
200
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
Example:
VLL Services
config>service# epipe 2
config>service>epipe# sap 2/1/3:21
config>service>epipe>sap# accounting-policy 14
config>service>epipe>sap# exit
The following example shows the SAP configuration:
ALA-1>config>service# info
---------------------------------------------epipe 2 customer 6 vpn 2 create
description "Distributed Epipe service to east coast"
sap 2/1/3:21 create
accounting-policy 14
exit
spoke-sdp 2:6000 create
exit
no shutdown
exit
---------------------------------------------ALA-1>config>service#
2.16.11.8
Disabling an Epipe Service
You can shut down an Epipe service without deleting the service parameters.
2.16.11.9
CLI Syntax:
config>service> epipe service-id
shutdown
Example:
config>service# epipe 2
config>service>epipe# shutdown
config>service>epipe# exit
Re-Enabling an Epipe Service
To re-enable an Epipe service that was shut down.
Issue: 01
CLI Syntax:
config>service# epipe service-id
no shutdown
Example:
config>service# epipe 2
config>service>epipe# no shutdown
config>service>epipe# exit
3HE 11970 AAAA TQZZA 01
201
VLL Services
2.16.11.10
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
Deleting an Epipe Service
Perform the following steps prior to deleting an Epipe service:
Step 1. Shut down the SAP and SDP.
Step 2. Delete the SAP and SDP.
Step 3. Shut down the service.
Use the following CLI syntax to delete an Epipe service:
2.16.11.11
CLI Syntax:
config>service
[no] epipe service-id
shutdown
[no] sap sap-id
shutdown
[no] spoke-sdp sdp-id:vc-id
shutdown
Example:
config>service# epipe 2
config>service>epipe# sap 2/1/3:21
config>service>epipe>sap# shutdown
config>service>epipe>sap# exit
config>service>epipe# no sap 2/1/3:21
config>service>epipe# spoke-sdp 2:6000
config>service>epipe>spoke-sdp# shutdown
config>service>epipe>spoke-sdp# exit
config>service>epipe# no spoke-sdp 2:6000
config>service>epipe# epipe 2
config>service>epipe# shutdown
config>service>epipe# exit
config>service# no epipe 2
Modifying Fpipe Service Parameters
The following example shows the command usage to modify Fpipe parameters,
supported on the 7750 SR only:
PE router 1 (A:ALA-41):
Example:
202
A:ALA-41>config>service# fpipe 1
A:ALA-41>config>service>fpipe# sap 1/2/1:16 create
A:ALA-41>config>service>fpipe>sap# accounting-policy 2
A:ALA-41>config>service>fpipe>sap# exit
A:ALA-41>config>service>fpipe# spoke-sdp 1:4
A:ALA-41>config>service>fpipe>spoke-sdp# ingress
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
A:ALA-41>config>service>fpipe>spoke-sdp>filter ip 10
A:ALA-41>config>service>fpipe>spoke-sdp# exit
A:ALA-41>config>service>fpipe#
PE router 2 (A:ALA-42):
Example:
A:ALA-42>config>service# fpipe 1
A:ALA-42>config>service>fpipe# sap 2/1/1.1:16 create
A:ALA-42>config>service>fpipe>sap# accounting-policy 2
A:ALA-42>config>service>fpipe>sap# exit
A:ALA-42>config>service>fpipe# spoke-sdp 1:1
A:ALA-42>config>service>fpipe>spoke-sdp# egress
A:ALA-42>config>service>fpipe>spoke-sdp>egress# filter
ip 10
A:ALA-42>config>service>fpipe>spoke-sdp>egress# exit
A:ALA-42>config>service>fpipe>spoke-sdp# exit
A:ALA-42>config>service>fpipe#
PE Router 1 (ALA-41):
A:ALA-41>config>service# info
------------------------------------...
fpipe 1 customer 1 create
description "fpipe test"
service-mtu 1400
sap 1/2/1:16 create
accounting-policy 2
ingress
qos 101
exit
egress
qos 1020
exit
exit
spoke-sdp 1:1 create
ingress
filter ip 10
exit
no shutdown
exit
...
------------------------------------A:ALA-41>config>service#
PE Router 2 (ALA-42):
A:ALA-42>config>service# info
------------------------------------...
fpipe 1 customer 1 create
description "fpipe test"
service-mtu 1400
sap 2/1/1.1:16 create
Issue: 01
3HE 11970 AAAA TQZZA 01
203
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
accounting-policy 2
ingress
qos 101
exit
egress
qos 1020
exit
exit
spoke-sdp 1:1 create
egress
filter ip 10
exit
no shutdown
exit
...
------------------------------------A:ALA-42>config>service#
2.16.11.12
Disabling an Fpipe Service
An Fpipe service can be shut down without deleting any service parameters.
CLI Syntax:
config>service#
fpipe service-id
shutdown
PE router 1 (A:ALA-41):
Example:
A:ALA-41>config>service# fpipe 1
A:ALA-41>config>service>fpipe# shutdown
PE router 2 (A:ALA-42):
Example:
A:ALA-42>config>service# fpipe 1
A:ALA-42>config>service>fpipe# shutdown
PE Router 1 (ALA-41):
A:ALA-41>config>service# info
------------------------------------...
fpipe 1 customer 1 create
shutdown
description "fpipe test"
service-mtu 1400
sap 1/2/1:16 create
accounting-policy 2
ingress
qos 101
exit
egress
204
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
qos 1020
exit
exit
spoke-sdp 1:1 create
ingress
filter ip 10
exit
exit
...
------------------------------------A:ALA-41>config>service#
PE Router 2 (ALA-42):
A:ALA-42>config>service# info
------------------------------------...
fpipe 1 customer 1 create
shutdown
description "fpipe test"
service-mtu 1400
sap 2/1/1.1:16 create
accounting-policy 2
ingress
qos 101
exit
egress
qos 1020
exit
exit
spoke-sdp 1:1 create
egress
filter ip 10
exit
exit
...
------------------------------------A:ALA-42>config>service#
2.16.11.13
Re-enabling an Fpipe Service
To re-enable an Fpipe service that was shut down.
CLI Syntax:
config>service#
fpipe service-id
no shutdown
PE router 1 (A:ALA-41):
Example:
Issue: 01
A:ALA-41>config>service# fpipe 1
A:ALA-41>config>service>fpipe# no shutdown
A:ALA-41>config>service>fpipe# exit
3HE 11970 AAAA TQZZA 01
205
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
PE router 2 (A:ALA-42):
Example:
2.16.11.14
A:ALA-42>config>service# fpipe 1
A:ALA-42>config>service>fpipe# no shutdown
A:ALA-42>config>service>fpipe# exit
Deleting an Fpipe Service
An Fpipe service cannot be deleted until the SAP is shut down. If protocols and/or a
spoke-SDP are defined, they must be shut down and removed from the configuration
as well.
Use the following CLI syntax to delete a Fpipe service:
CLI Syntax:
config>service#
no fpipe service-id
shutdown
no sap sap-id
shutdown
no spoke-sdp [sdp-id:vc-id]
shutdown
PE router 1 (A:ALA-41):
Example:
A:ALA-41>config>service# fpipe 1
A:ALA-41>config>service>fpipe# sap 1/1/1:0/32
A:ALA-41>config>service>fpipe>sap# shutdown
A:ALA-41>config>service>fpipe>sap# exit
A:ALA-41>config>service>fpipe# no sap 1/1/1:0/32
A:ALA-41>config>service>fpipe# spoke-sdp 1:1
A:ALA-41>config>service>fpipe>spoke-sdp# shutdown
A:ALA-41>config>service>fpipe>spoke-sdp# exit
A:ALA-41>config>service>fpipe# no spoke-sdp 1:1
A:ALA-41>config>service>fpipe# shutdown
A:ALA-41>config>service>fpipe# exit
A:ALA-41>config>service# no fpipe 1
PE router 2 (A:ALA-42):
Example:
206
A:ALA-41>config>service# fpipe 1
A:ALA-41>config>service>fpipe# sap 2/1/1.1:16
A:ALA-41>config>service>fpipe>sap# shutdown
A:ALA-41>config>service>fpipe>sap# exit
A:ALA-41>config>service>fpipe# no sap 2/1/1.1:16
A:ALA-41>config>service>fpipe# spoke-sdp 1:1
A:ALA-41>config>service>fpipe>spoke-sdp# shutdown
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
A:ALA-41>config>service>fpipe>spoke-sdp# exit
A:ALA-41>config>service>fpipe# no spoke-sdp 1:1
A:ALA-41>config>service>fpipe# shutdown
A:ALA-41>config>service>fpipe# exit
A:ALA-41>config>service# no fpipe 1
2.16.11.15
Modifying Ipipe Service Parameters
The following example shows the command usage to modify Ipipe parameters,
supported on the 7450 ESS and 7750 SR only:
Example:
config>service# ipipe 202
config>service>ipipe# sap 1/1/2:444
config>service>ipipe>sap# shutdown
config>service>ipipe>sap# exit
config>service>ipipe# no sap 1/1/2:444
config>service>ipipe# sap 1/1/2:555 create
config>service>ipipe>sap$ description “eth_ipipe”
config>service>ipipe>sap$ ce-address 31.31.31.1
config>service>ipipe>sap$ no shutdown
config>service>ipipe>sap$ exit
config>service>ipipe# info
A:ALA-48>config>service# info
---------------------------------------------...
ipipe 202 customer 1 create
sap 1/1/2:445 create
description "eth_ipipe"
ce-address 31.31.31.2
exit
sap 1/1/2:555 create
description "eth_ipipe"
ce-address 31.31.31.1
exit
no shutdown
exit
...
---------------------------------------------A:ALA-48>config>service#
2.16.11.16
Disabling an Ipipe Service
An Ipipe service can be shut down without deleting any service parameters.
CLI Syntax:
Issue: 01
config>service#
ipipe service-id
3HE 11970 AAAA TQZZA 01
207
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
shutdown
Example:
A:ALA-41>config>service# ipipe 202
A:ALA-41>config>service>ipipe# shutdown
A:ALA-48>config>service# info
---------------------------------------------...
ipipe 202 customer 1 create
shutdown
sap 1/1/2:445 create
description "eth_ipipe"
ce-address 31.31.31.2
exit
sap 1/1/2:555 create
description "eth_ipipe"
ce-address 31.31.31.1
exit
exit
...
---------------------------------------------A:ALA-48>config>service#
2.16.11.17
Re-enabling an Ipipe Service
To re-enable an Ipipe service that was shut down.
2.16.11.18
CLI Syntax:
config>service#
ipipe service-id
no shutdown
Example:
A:ALA-41>config>service# ipipe 202
A:ALA-41>config>service>ipipe# no shutdown
Deleting an Ipipe Service
An Ipipe service cannot be deleted until the SAP is shut down. If protocols and/or a
spoke-SDP are defined, they must be shut down and removed from the configuration
as well.
Use the following CLI syntax to delete an Ipipe service:
CLI Syntax:
208
config>service#
no ipipe service-id
shutdown
no sap sap-id
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
shutdown
no spoke-sdp [sdp-id:vc-id]
shutdown
Example:
Issue: 01
config>service# ipipe 207
config>service>ipipe# sap 1/1/2:449
config>service>ipipe>sap# shutdown
config>service>ipipe>sap# exit
config>service>ipipe# no sap 1/1/2:449
config>service>ipipe# spoke-sdp 16:516
config>service>ipipe>spoke-sdp# shutdown
config>service>ipipe>spoke-sdp# exit
config>service>ipipe# no spoke-sdp 16:516
config>service>ipipe# exit
config>service# no ipipe 207
config>service#
3HE 11970 AAAA TQZZA 01
209
VLL Services
210
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
2.17
VLL Services
VLL Service Configuration Command
Reference
This chapter describes the VLL service configuration command reference.
2.17.1
2.17.1.1
Command Hierarchies
Apipe Service Configuration Commands
config
— service
— apipe service-id [customer customer-id] [vpn vpn-id] [vc-type {atm-vcc | atm-sdu |
atm-vpc | atm-cell}] [vc-switching] [test] [create]
— no apipe service-id
— description description-string
— no description
— [no] endpoint endpoint-name
— active-hold-delay active-hold-delay
— no active-hold-delay
— description description-string
— no description
— revert-time revert-time
— no revert-time
— interworking frf-5
— no interworking
— sap {port-id | aps-id}:[vpi/vci | vpi | vpi1.vpi2 | cp.conn-prof-id]
— sap sap-id [no-endpoint]
— sap sap-id [endpoint endpoint-name]
— no sap sap-id
— accounting-policy acct-policy-id
— no accounting-policy
— atm
— egress
— traffic-desc traffic-desc-profile-id
— no traffic-desc
— ingress
— traffic-desc traffic-desc-profile-id
— no traffic-desc
— [no] llf
— oam
— [no] alarm-cells
— [no] terminate
— [no] collect-stats
— cpu-protection policy-id [mac-monitoring] | [eth-cfm-monitoring
[aggregate] [car]]
Issue: 01
3HE 11970 AAAA TQZZA 01
211
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
—
—
—
—
—
—
212
no cpu-protection
description description-string
no description
dist-cpu-protection policy-name
no dist-cpu-protection
egress
— [no] agg-rate
— [no] limit-unused-bandwidth
— [no] queue-frame-based-accounting
— rate kilobits-per-second
— no rate
— policer-control-override [create]
— no policer-control-override
— max-rate {rate | max}
— priority-mbs-thresholds
— min-thresh-separation
— [no] priority level
— mbs-contribution size [{bytes |
kilobytes}]
— policer-control-policy policy-name
— no policer-control-policy
— [no] policer-override
— policer policer-id [create]
— no policer policer-id
— cbs size [{bytes | kilobytes}]
— no cbs
— mbs size [bytes | kilobytes]
— no mbs
— packet-byte-offset {add add-bytes | subtract
sub-bytes}
— percent-rate pir-percent [cir cir-percent]
— no percent-rate
— rate {rate | max} [cir {max | rate}]
— stat-mode stat-mode
— no stat-mode
— [no] qinq-mark-top-only
— qos policy-id [port-redirect-group queue-group-name instance
instance-id]
— no qos
— [no] queue-override
— [no] queue queue-id
— adaptation-rule [pir adaptation-rule] [cir
adaptation-rule]
— no adaptation-rule
— avg-frame-overhead percentage
— no avg-frame-overhead
— burst-limit size-in-kbytes
— no burst-limit
— drop-tail low
— percent-reduction-from-mbs
percent
— no percent-reduction-from-mbs
— mbs {size [bytes | kilobytes] | default}
— no mbs
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
— monitor-depth
— [no] monitor-depth
— parent {[weight weight] [cir-weight cirweight]}
— no parent
— percent-rate pir-percent [cir cir-percent]
— no percent-rate
— rate pir-rate [cir cir-rate]
— no rate
— [no] scheduler-override
— [no] scheduler scheduler-name
— parent [weight weight] [cir-weight cir-weight]
— no parent
— rate pir-rate [cir cir-rate]
— no rate
— scheduler-policy scheduler-policy-name
— no scheduler-policy
— frame-relay
— scheduling-class class-id
— no scheduling-class
— ingress
— policer-control-override [create]
— no policer-control-override
— max-rate {rate | max}
— priority-mbs-thresholds
— min-thresh-separation
— [no] priority level
— mbs-contribution size [bytes | kilobytes]
— [no] policer-override
— policer policer-id [create]
— no policer policer-id
— cbs size [bytes | kilobytes]
— no cbs
— mbs {size [bytes | kilobytes] | default}
— no mbs
— packet-byte-offset add add-bytes | subtract
sub-bytes}
— percent-rate pir-percent [cir cir-percent]
— no percent-rate
— rate {rate | max} [cir {max | rate}]
— stat-mode stat-mode
— no stat-mode
— qos policy-id [shared-queuing] [fp-redirect-group queuegroup-name instance instance-id]
— no qos
— [no] queue-override
— [no] queue queue-id
— adaptation-rule [pir adaptation-rule] [cir
adaptation-rule]
— no adaptation-rule
— burst-limit size-in-kbytes
— no burst-limit
— drop-tail low
Issue: 01
3HE 11970 AAAA TQZZA 01
213
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
—
—
—
—
—
—
—
—
—
—
214
— percent-reduction-from-mbs
percent
— no percent-reduction-from-mbs
— mbs {size [bytes | kilobytes] | default}
— no mbs
— monitor-depth
— [no] monitor-depth
— rate pir-rate [cir cir-rate]
— no rate
— [no] scheduler-override
— [no] scheduler scheduler-name
— parent [weight weight] [cir-weight cir-weight]
— no parent
— rate pir-rate [cir cir-rate]
— no rate
— scheduler-policy scheduler-policy-name
— no scheduler-policy
— multi-service-site customer-site-name
— no multi-service-site
— [no] shutdown
service-mtu octets
no service-mtu
service-name service-name
no service-name
[no] shutdown
signaled-vc-type-override {atm-vcc}
no signaled-vc-type-override
spoke-sdp [sdp-id[:vc-id] [no-endpoint]
spoke-sdp [sdp-id[:vc-id] endpoint endpoint-name [icb]
no spoke-sdp [sdp-id[:vc-id]
— [no] bandwidth
— bfd-enable
— no bfd-enable
— bfd-template name
— no bfd-template
— cell-concatenation
— [no] aal5-frame-aware
— [no] clp-change
— max-cells cell-count
— no max-cells [cell-count>]
— max-delay delay-time
— no max-delay [delay-time]
— [no] control-channel-status
— [no] acknowledgment
— refresh-timer value
— no refresh-timer
— request-timer timer1 retry-timer timer2 [timeout-multiplier
multiplier]
— no request-timer
— [no] control-word
— egress
— qos network-policy-id port-redirect-group queue-group-name
[instance instance-id]
— no qos
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
—
—
—
—
—
VLL Services
— vc-label ingress-vc-label
— no vc-label [ingress-vc-label]
ingress
— qos network-policy-id fp-redirect-group queue-group-name
instance instance-id
— no qos
— vc-label ingress-vc-label
— no vc-label [ingress-vc-label]
precedence [precedence-value | primary]
no precedence
[no] pw-path-id
— agi agi
— no agi
— saii-type2 global-id:node-id:ac-id
— no saii-type2
— taii-type2 global-id:node-id:ac-id
— no taii-type2
[no] shutdown
config
— connection-profile conn-prof-id [create]
— no connection-profile conn-prof-id
2.17.1.2
Related Apipe Commands
2.17.1.2.1
Connection Profile Commands
config
— connection-profile conn-prof-id [create]
— no connection-profile conn-prof-id
— description description-string
— no description
— member encap-value [create]
— no member encap-value
2.17.1.3
Cpipe Service Configuration Commands
config
— service
— cpipe service-id [customer customer-id] [vpn vpn-id] [vc-type {satop-e1 | satop-t1 |
cesopsn | cesopsn-cas}] [vc-switching] [test] [create]
— no cpipe service-id
— description description-string
— no description [description-string]
— endpoint endpoint-name [create]
Issue: 01
3HE 11970 AAAA TQZZA 01
215
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
— no endpoint endpoint-name
— active-hold-delay active-endpoint-delay
— no active-hold-delay
— description description-string
— no description [description-string]
— revert-time revert-time
— no revert-time
— sap sap-id [no-endpoint] [create]
— sap sap-id endpoint endpoint-name [create]
— no sap sap-id
— accounting-policy acct-policy-id
— no accounting-policy [acct-policy-id]
— cem
— packet jitter-buffer milliseconds [payload-size bytes]
— packet payload-size bytes
— no packet
— [no] report-alarm [stray] [malformed] [pktloss] [overrun]
[underrun] [rpktloss] [rfault] [rrdi]
— [no] rtp-header
— [no] collect-stats
— cpu-protection policy-id [mac-monitoring] | [eth-cfm-monitoring
[aggregate] [car]]
— description description-string
— no description [description-string]
— dist-cpu-protection policy-name
— no dist-cpu-protection
— egress
— [no] agg-rate
— rate kilobits-per-second
— no rate
— [no] limit-unused-bandwidth
— [no] queue-frame-based-accounting
— [no] policer-override
— policer policer-id [create]
— no policer policer-id
— cbs size [bytes | kilobytes]
— no cbs
— mbs {size [bytes | kilobytes] | default}
— no mbs
— packet-byte-offset add add-bytes | subtract
sub-bytes}
— percent-rate pir-percent [cir cir-percent]
— no percent-rate
— rate {rate | max} [cir {max | rate}]
— stat-mode stat-mode
— no stat-mode
— [no] qinq-mark-top-only
— [no] qos [policy-id]
— [no] queue-override
— queue queue-id [create]
— no queue queue-id
— adaptation-rule [pir adaptation-rule}] [cir
adaptation-rule}]
— no adaptation-rule
216
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
—
—
—
—
—
avg-frame-overhead percent
no avg-frame-overhead
burst-limit size-in-kbytes
no burst-limit
drop-tail
— low
— percent-reduction-from-mbs
percent
— no percent-reduction-from-mbs
— mbs {size [bytes | kilobytes] | default}
— no mbs
— monitor-depth
— no monitor-depth
— parent {[weight weight] [cir-weight cir-weight]}
— no parent
— percent-rate pir-percent [cir cir-percent]
— no percent-rate
— rate pir-rate [cir cir-rate]
— no rate
— [no] scheduler-override
— scheduler scheduler-name [create]
— no scheduler scheduler-name
— parent [weight weight] [cir-weight cir-weight]
— no parent
— rate pir-rate [cir cir-rate]
— no rate
— scheduler-policy scheduler-policy-name
— no scheduler-policy
— ingress
— [no] policer-override
— policer policer-id [create]
— no policer policer-id
— cbs size [bytes | kilobytes]
— no cbs
— mbs {size [bytes | kilobytes] | default}
— no mbs
— packet-byte-offset add add-bytes | subtract
sub-bytes}
— percent-rate pir-percent [cir cir-percent]
— no percent-rate
— rate {rate | max} [cir {max | rate}]
— stat-mode stat-mode
— no stat-mode
— [no] qos [policy-id]
— [no] queue-override
— queue queue-id [create]
— no queue queue-id
— adaptation-rule [pir adaptation-rule}] [cir
adaptation-rule}]
— no adaptation-rule
— avg-frame-overhead percent
— no avg-frame-overhead
— burst-limit size-in-kbytes
— no burst-limit
Issue: 01
3HE 11970 AAAA TQZZA 01
217
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
—
—
—
—
—
—
—
—
218
— drop-tail
— low
— percent-reduction-from-mbs
percent
— no percent-reduction-from-mbs
— mbs {size [bytes | kilobytes] | default}
— no mbs
— monitor-depth
— [no] monitor-depth
— rate pir-rate [cir cir-rate]
— no rate
— [no] scheduler-override
— scheduler scheduler-name [create]
— no scheduler scheduler-name
— parent [weight weight] [cir-weight cir-weight]
— no parent
— rate pir-rate [cir cir-rate]
— no rate
— scheduler-policy scheduler-policy-name
— no scheduler-policy
— multi-service-site customer-site-name
— no multi-service-site
service-mtu octets
no service-mtu
service-name service-name
no service-name
[no] shutdown
spoke-sdp sdp-id[:vc-id] [no-endpoint] [create]
spoke-sdp sdp-id:vc-id [create] endpoint endpoint-name [icb]
no spoke-sdp sdp-id[:vc-id]
— accounting-policy acct-policy-id
— no accounting-policy
— bandwidth bw-value
— bandwidth max
— no bandwidth
— bfd-enable
— no bfd-enable
— bfd-template name
— no bfd-template
— [no] collect-stats
— [no] control-channel-status
— [no] acknowledgment
— refresh-timer value
— no refresh-timer
— request-timer timer1 retry-timer timer2 [timeout-multiplier
multiplier]
— no request-timer
— [no] control-word
— egress
— qos network-policy-id port-redirect-group queue-group-name
[instance instance-id]
— no qos
— vc-label egress-vc-label
— no vc-label [egress-vc-label]
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
— ingress
— qos network-policy-id fp-redirect-group queue-group-name
instance instance-id
— no qos
— vc-label ingress-vc-label
— no vc-label [ingress-vc-label]
— [no] pw-path-id
— agi agi
— no agi
— saii-type2 global-id:node-id:ac-id
— no saii-type2
— taii-type2 global-id:node-id:ac-id
— no taii-type2
— precedence [precedence-value| primary]
— no precedence
— [no] shutdown
2.17.1.4
Epipe Service Configuration Commands
• Epipe Global Commands
• Epipe SAP Configuration Commands
• Epipe Spoke SDP Configuration Commands
2.17.1.4.1
Epipe Global Commands
config
— service
— [no] epipe service-id [customer customer-id] [test] [create] [vpn vpn-id] [vcswitching]
— [no] bgp
— pw-template-binding policy-id [import-rt {ext-community,.(upto 5
max)}]
— no pw-template-binding policy-id
— [no] bfd-enable
— bfd-template name
— no bfd-template
— [no] shutdown
— route-distinguisher auto-rd
— no route-distinguisher
— route-distinguisher rd
— route-target {ext-community | {[export ext-community] [import extcommunity]}}
— no route-target
— [no] bgp-vpws
— [no] remote-ve-name name
— ve-id value
— no ve-id
Issue: 01
3HE 11970 AAAA TQZZA 01
219
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
—
—
—
—
—
—
—
—
—
—
—
—
—
—
—
—
220
— [no] shutdown
— [no] ve-name name
— ve-id value
— no ve-id
description description-string
no description
[no] endpoint endpoint-name
— active-hold-delay active-endpoint-delay
— no active-hold-delay
— description description-string
— no description
— revert-time [revert-time | infinite]
— no revert-time
— [no] standby-signaling-master
— [no] standby-signaling-slave
load-balancing
— [no] per-service-hashing
pw-port pw-port-id fpe fpe-id [create]
no pw-port
— egress
— [no] shaper
— int-dest-id name
— no int-dest-id
— vport vport
— no vport
— monitor-oper-group group-name
— no monitor-oper-group
— [no] shutdown
service-mtu octets
no service-mtu
service-name service-name
no service-name
site name [create]
no site
— boot-timer seconds
— no boot-timer
— sap sap-id
— no sap
— site-activation-timer seconds
— no site-activation-timer
— site-min-down-timer min-down-time
— no site-min-down-timer
— site-id value
— no site-id
— site-preference preference-value
— no site-preference
[no] shutdown
spoke-sdp sdp-id[:vc-id] [vc-type {ether | vlan}] [create] [no-endpoint]
spoke-sdp sdp-id[:vc-id] [vc-type {ether | vlan}] [create] endpoint
no spoke-sdp sdp-id[:vc-id]
— [no] bfd-enable
— bfd-template name
— no bfd-template
— [no] control-channel-status
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
—
—
—
—
—
—
—
—
—
2.17.1.4.2
[no] acknowledgment
refresh-timer value
no refresh-timer
request-timer timer1 retry-timer timer2 [timeout-multiplier
multiplier]
— no request-timer
[no] control-word
hash-label
no hash-label
[no] standby-signaling-slave
[no] pw-path-id
— agi agi
— no agi
— saii-type2 global-id:node-id:ac-id
— no saii-type2
— taii-type2 global-id:node-id:ac-id
— no taii-type2
Epipe SAP Configuration Commands
config
— service
— epipe service-id
— sap sap-id [create] [no-endpoint]
— sap sap-id [create] endpoint endpoint-name
— no sap sap-id
— aarp aarpId type type
— accounting-policy acct-policy-id
— no accounting-policy acct-policy-id
— app-profile app-profile-name
— no app-profile
— atm
— egress
— traffic-desc traffic-desc-profile-id
— no traffic-desc
— encapsulation atm-encap-type
— ingress
— traffic-desc traffic-desc-profile-id
— no traffic-desc
— oam
— [no] alarm-cells
— cem
— local-ecid emulated circuit identifier
— no local-ecid
— packet jitter-buffer milliseconds [payload-size bytes]
— packet payload-size bytes
— no packet
— remote-ecid emulated circuit identifier
— no remote-ecid
— remote-mac ieee-address
— no remote-mac
Issue: 01
3HE 11970 AAAA TQZZA 01
221
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
—
—
—
—
—
—
—
—
—
222
— [no] report-alarm [stray] [malformed] [pktloss] [overrun]
[underrun] [rpktloss] [rfault] [rrdi]
— [no] rtp-header
[no] cflowd
[no] collect-stats
cpu-protection policy-id {[mac-monitoring] | [eth-cfm-monitoring
[aggregate] [car]]}
no cpu-protection
description description-string
no description
dist-cpu-protection policy-name
no dist-cpu-protection
egress
— [no] agg-rate
— [no] limit-unused-bandwidth
— [no] queue-frame-based-accounting
— rate kilobits-per-second
— no rate
— filter [ip ip-filter-id]
— filter [ipv6 ipv6-filter-id]
— filter [mac mac-filter-id]
— no filter [ip ip-filter-id] [ipv6 ipv6-filter-id] [mac mac-filter-id]
— [no] hsmda-queue-override
— packet-byte-offset {add add-bytes | subtract sub-bytes}
— no packet-byte-offset
— queue queue-id
— no queue queue-id
— mbs {size [bytes | kilobytes] | default}
— no mbs
— rate pir-rate
— no rate
— slope-policy hsmda-slope-policy-name
allowable
— no slope-policy
— wrr-weight weight
— no wrr-weight
— secondary-shaper secondary-shaper-name
— no secondary-shaper
— wrr-policy hsmda-wrr-policy-name
— no wrr-policy
— policer-control-override [create]
— no policer-control-override
— max-rate {rate | max}
— priority-mbs-thresholds
— min-thresh-separation
— [no] priority level
— mbs-contribution size [bytes | kilobytes]
— policer-control-policy policy-name
— no policer-control-policy
— [no] policer-override
— policer policer-id [create]
— no policer policer-id
— cbs size [bytes | kilobytes]
— no cbs
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
—
—
—
—
—
—
—
— mbs {size [bytes | kilobytes] | default}
— no mbs
— packet-byte-offset add add-bytes |
subtract sub-bytes}
— percent-rate pir-percent [cir cir-percent]
— no percent-rate
— rate {rate | max} [cir {max | rate}]
— stat-mode stat-mode
— no stat-mode
[no] qinq-mark-top-only
qos policy-id [port-redirect-group queue-group-name
instance instance-id]
no qos
[no] queue-override
— queue queue-id [create]
— no queue queue-id
— adaptation-rule [pir adaptation-rule] [cir
adaptation-rule]
— no adaptation-rule
— avg-frame-overhead percentage
— no avg-frame-overhead
— cbs size-in-kbytes
— no cbs
— drop-tail low
— percent-reduction-from-mbs
percent
— no percent-reduction-from-mbs
— mbs {size [bytes | kilobytes] | default}
— no mbs
— [no] monitor-depth
— parent {[weight weight] [cir-weight cirweight]}
— percent-rate pir-percent [cir cir-percent]
— no percent-rate
— rate pir-rate [cir cir-rate]
— no rate
[no] scheduler-override
— [no] scheduler scheduler-name
— parent [weight weight] [cir-weight cirweight]
— no parent
— rate pir-rate [cir cir-rate]
— no rate
scheduler-policy scheduler-policy-name
no scheduler-policy
— eth-cfm
— [no] ais-enable
— [no] collect-lmm-stats
— collect-lmm-fc-stats
— fc fc-name [fc-name ... (up to 8 max)]
— no fc
— fc-in-profile fc-name [fc-name ... (up to 8 max)]
— no fc-in-profile
Issue: 01
3HE 11970 AAAA TQZZA 01
223
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
— [no] mep mep-id domain md-index association ma-index
[direction {up | down}] primary-vlan-enable [vlan vlanid]
— [no] ais-enable
— [no] client-meg-level [[level [level ...]]
— low-priority-defect {allDef | macRemErrXcon}
— [no] interface-support-enable
— [no] interval {1 | 60}
— [no] priority priority-value
— [no] ccm-enable
— [no] ccm-ltm-priority priority
— ccm-padding-size ccm-padding
— no ccm-padding-size ccm-padding
— [no] csf-enable
— multiplier multiplier-value
— no multiplier
— [no] description description-string
— [no] eth-test-enable
— [no] bit-error-threshold bit-errors
— test-pattern {all-zeros | all-ones} [crc-enable]
— no test-pattern
— [no] fault-propagation-enable {use-if-tlv | suspendccm}
— grace
— eth-ed
— max-rx-defect-window seconds
— no max-rx-defect-window
— priority priority
— no priority
— [no] rx-eth-ed
— [no] tx-eth-ed
— eth-vsm-grace
— [no] rx-eth-vsm-grace
— [no] tx-eth-vsm-grace
— low-priority-defect {allDef | macRemErrXcon |
remErrXcon | errXcon | xcon | noXcon}
— one-way-delay-threshold mac-address
— no one-way-delay-threshold
— one-way-delay-threshold seconds
— [no] shutdown
— mip [mac mac-address] primary-vlan-enable [vlan vlan-id]
— mip default-mac
— no mip
— [no] squelch-ingress-levels [md-level [md-level…]]
— tunnel-fault [accept | ignore]
— eth-tunnel
— path path-index tag qtag[.qtag]
— no path path-index
— ethernet
— [no] llf
— frame-relay
— [no] frf-12
— ete-fragment-threshold threshold
— no ete-fragment-threshold
224
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
— [no] interleave
— scheduling-class class-id
— no scheduling-class
— [no] ignore-oper-down
— ingress
— filter [ip ip-filter-id]
— filter [ipv6 ipv6-filter-id]
— filter [mac mac-filter-id]
— no filter [ip ip-filter-id] [ipv6 ipv6-filter-id] [mac mac-filter-id]
— qos network-policy-id fp- redirect-group queue-group-name
instance instance-id
— no qos
— [no] hsmda-queue-override
— packet-byte-offset {add add-bytes | subtract sub-bytes}
— no packet-byte-offset
— [no] queue queue-id
— rate pir-rate
— no rate
— slope-policy hsmda-slope-policy-name
allowable
— no slope-policy
— match-qinq-dot1p {top | bottom}
— no match-qinq-dot1p
— policer-control-override [create]
— no policer-control-override
— max-rate {rate | max}
— priority-mbs-thresholds
— min-thresh-separation
— [no] priority level
— mbs-contribution size [bytes | kilobytes]
— policer-control-policy policy-name
— no policer-control-policy
— [no] policer-override
— policer policer-id [create]
— no policer policer-id
— cbs size-in-kilobytes
— no cbs
— mbs {size [bytes | kilobytes] | default}
— no mbs
— packet-byte-offset add add-bytes | subtract
sub-bytes}
— percent-rate pir-percent [cir cir-percent]
— no percent-rate
— rate {rate | max} [cir {max | rate}]
— stat-mode stat-mode
— no stat-mode
— qos policy-id [shared-queuing] [fp-redirect-group queuegroup-name instance instance-id]
— no qos
— [no] queue-override
— [no] queue queue-id
— adaptation-rule [pir adaptation-rule] [cir
adaptation-rule]
— no adaptation-rule
Issue: 01
3HE 11970 AAAA TQZZA 01
225
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
—
—
—
—
—
—
—
—
—
—
—
—
—
—
—
2.17.1.4.3
— cbs size-in-kilobytes
— no cbs
— drop-tail
— low
— percent-reduction-from-mbs
percent
— no percent-reduction-from-mbs
— mbs {size [bytes | kilobytes] | default}
— no mbs
— [no] monitor-depth
— parent {[weight weight] [cir-weight cir-weight]}
— no parent
— percent-rate pir-percent [cir cir-percent]
— no percent-rate
— rate pir-rate [cir cir-rate]
— no rate
— [no] scheduler-override
— [no] scheduler scheduler-name
— parent [weight weight] [cir-weight cir-weight]
— no parent
— rate pir-rate [cir cir-rate]
— no rate
— scheduler-policy scheduler-policy-name
— no scheduler-policy
— vlan-translation {vlan-id | copy-outer}
— no vlan-translation
lag-link-map-profile link-map-profile-id
no lag-link-map-profile
lag-per-link-hash class {1 | 2 | 3} weight [1 to 1024]
no lag-per-link-hash
monitor-oper-group group-name
no monitor-oper-group
multi-service-site customer-site-name
no multi-service-site
oper-group group-name
no oper-group
ring-node ring-node-name
no ring-node
[no] shutdown
transit-policy {ip ip-aasub-policy-id | prefix prefix-aasub-policy-id}
no transit-policy
Epipe Spoke SDP Configuration Commands
config
— service
— epipe service-id
— spoke-sdp sdp-id[:vc-id] [vc-type {ether | vlan}] [create] [no-endpoint]
— spoke-sdp sdp-id[:vc-id] [vc-type {ether | vlan}] [create] endpoint [icb]
— no spoke-sdp sdp-id[:vc-id]
— aarp aarpId type type
226
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
—
—
—
—
—
—
—
—
—
—
—
—
—
—
—
—
—
Issue: 01
VLL Services
accounting-policy acct-policy-id
no accounting-policy
app-profile app-profile-name
no app-profile
bandwidth bandwidth
no bandwidth
[no] bfd-enable
bfd-template name
no bfd-template
[no] collect-stats
[no] control-word
cpu-protection policy-id {[mac-monitoring] | [eth-cfm-monitoring
[aggregate] [car]}]
no cpu-protection
[no] description
[no] egress
— filter [ip ip-filter-id]
— filter [ipv6 ipv6-filter-id]
— filter [mac mac-filter-id]
— no filter [ip ip-filter-id] [ipv6 ipv6-filter-id] [mac mac-filter-id]
— l2tpv3
— cookie cookie
— no cookie
— qos network-policy-id port-redirect-group queue-group-name
[instance instance-id]
— no qos
— [no] vc-label egress-vc-label
[no] entropy-label
eth-cfm
— [no] ais-enable
— [no] client-meg-level [level [level ...]]
— [no] interface-support-enable
— [no] interval {1 | 60}
— low-priority-defect {allDef | macRemErrXcon}
— [no] priority priority-value
— [no] ccm-enable
— [no] ccm-ltm-priority priority
— ccm-padding-size ccm-padding
— no ccm-padding-size ccm-padding
— [no] collect-lmm-stats
— collect-lmm-fc-stats
— fc fc-name [fc-name ... (up to 8 max)]
— no fc
— fc-in-profile fc-name [fc-name ... (up to 8 max)]
— no fc-in-profile
— [no] csf-enable
— multiplier multiplier-value
— no multiplier
— [no] description
— [no] eth-test-enable
— [no] test-pattern {all-zeros | all-ones} [crc-enable]
— [no] fault-propagation-enable {use-if-tlv | suspend-ccm}
— [no] one-way-delay-threshold seconds
3HE 11970 AAAA TQZZA 01
227
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
—
—
—
—
—
—
—
—
—
—
—
—
—
—
228
— [no] mip [{mac mac-address | default-mac}] [primary-vlanenable vlan-id]
— mep mep-id domain md-index association ma-index [direction
{up | down}] [primary-vlan-enable]
— no mep mep-id domain md-index association ma-index
— [no] ccm-enable
— ccm-ltm-priority priority
— no ccm-ltm-priority
— [no] description
— [no] eth-test-enable
— ccm-padding-size ccm-padding
— no ccm-padding-size ccm-padding
— fault-propagation-enable {use-if-tlv | suspend-ccm}
— no fault-propagation-enable
— grace
— eth-ed
— max-rx-defect-window seconds
— no max-rx-defect-window
— priority priority
— no priority
— [no] rx-eth-ed
— [no] tx-eth-ed
— eth-vsm-grace
— [no] rx-eth-vsm-grace
— [no] tx-eth-vsm-grace
— low-priority-defect {allDef | macRemErrXcon |
remErrXcon | errXcon | xcon | noXcon}
— [no] shutdown
— [no] squelch-ingress-levels [md-level [md-level…]]
[no] force-qinq-vc-forwarding
[no] force-vlan-vc-forwarding
[no] hash-label
[no] ingress
— filter [ip ip-filter-id]
— filter [ipv6 ipv6-filter-id]
— filter [mac mac-filter-id]
— no filter [ip ip-filter-id] [ipv6 ipv6-filter-id] [mac mac-filter-id]
— l2tpv3
— cookie [cookie1] [cookie2]
— no cookie
— qos network-policy-id fp-redirect-group queue-group-name
instance instance-id
— no qos
— [no] vc-label egress-vc-label
monitor-oper-group group-name
no monitor-oper-group
precedence [precedence-value | primary]
no precedence
[no] pw-status-signaling
[no] shutdown
[no] standby-signaling-slave
transit-policy {ip ip-aasub-policy-id | prefix prefix-aasub-policy-id}
no transit-policy
[no] use-sdp-bmac
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
—
—
—
—
2.17.1.4.4
VLL Services
— vlan-vc-tag 0 to 4094
— no vlan-vc-tag [0 to 4094]
spoke-sdp-fec spoke-sdp-fec-id [fec fec-type] [aii-type aii-type] [create]
spoke-sdp-fec spoke-sdp-fec-id no-endpoint
spoke-sdp-fec spoke-sdp-fec-id [fec fec-type] [aii-type aii-type] [create]
endpoint name [icb]
no spoke-sdp-fec spoke-sdp-fec-id
— [no] auto-config
— path name
— no path
— precedence prec-value
— precedence primary
— no precedence
— pw-template-bind policy-id
— no pw-template-bind
— retry-count retry-count
— no retry-count
— retry-timer retry-timer
— no retry-timer
— saii-type2 global-id:prefix:ac-id
— no saii-type2
— [no] shutdown
— signaling signaling
— [no] standby-signaling-slave
— taii-type2 global-id:prefix:ac-id
— no taii-type2
Template Commands
configure
— service
— template
— epipe-sap-template name [create]
— no epipe-sap-template name
— egress
— [no] filter
— ip filter-id
— no ip
— ipv6 filter-id
— no ipv6
— mac filter-id
— no mac
— qos policy-id
— no qos
— ingress
— [no] filter
— ip filter-id
— no ip
— ipv6 filter-id
— no ipv6
— mac filter-id
Issue: 01
3HE 11970 AAAA TQZZA 01
229
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
— no mac
— qos policy-id {shared-queuing | multipoint-shared}
— qos policy-id
— no qos
2.17.1.5
Fpipe Service Configuration Commands
config
— service
— fpipe service-id [customer customer-id] [vpn vpn-id] [vc-type {fr-dlci}] [vc-switching]
— no fpipe service-id
— description description-string
— no description
— [no] endpoint endpoint-name
— active-hold-delay active-endpoint-delay
— no active-hold-delay
— description description-string
— no description
— revert-time revert-time
— no revert-time
— sap sap-id [no-endpoint]
— sap sap-id endpoint endpoint-name
— no sap sap-id
— accounting-policy acct-policy-id
— no accounting-policy
— [no] collect-stats
— cpu-protection policy-id {[mac-monitoring] | [eth-cfm-monitoring
[aggregate] [car]]}
— description description-string
— no description
— dist-cpu-protection policy-name
— no dist-cpu-protection
— egress
— [no] agg-rate
— rate kilobits-per-second
— no rate
— [no] limit-unused-bandwidth
— [no] queue-frame-based-accounting
— filter [ip ip-filter-id]
— filter [ipv6 ipv6-filter-id]
— no filter [ip ip-filter-id] [ipv6 ipv6-filter-id]
— policer-control-override [create]
— no policer-control-override
— max-rate {rate | max}
— priority-mbs-thresholds
— min-thresh-separation
— [no] priority level
— mbs-contribution size [bytes |
kilobytes]
— policer-control-policy policy-name
— no policer-control-policy
230
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
— [no] policer-override
— policer policer-id [create]
— no policer policer-id
— cbs size [bytes | kilobytes]
— no cbs
— mbs {size [bytes | kilobytes] | default}
— no mbs
— packet-byte-offset add add-bytes | subtract
sub-bytes}
— percent-rate pir-percent [cir cir-percent]
— no percent-rate
— rate {rate | max} [cir {max | rate}]
— stat-mode stat-mode
— no stat-mode
— [no] qinq-mark-top-only
— qos policy-id
— no qos
— [no] queue-override
— [no] queue queue-id
— adaptation-rule [pir adaptation-rule] [cir
adaptation-rule]
— no adaptation-rule
— avg-frame-overhead percent
— no avg-frame-overhead
— burst-limit size-in-kbytes
— no burst-limit
— drop-tail low
— percent-reduction-from-mbs
percent
— no percent-reduction-from-mbs
— mbs {size [bytes | kilobytes] | default}
— no mbs
— monitor-depth
— [no] monitor-depth
— parent {[weight weight] [cir-weight cirweight]}
— no parent
— percent-rate pir-percent [cir cir-percent]
— no percent-rate
— rate pir-rate [cir cir-rate]
— no rate
— [no] scheduler-override
— [no] scheduler scheduler-name
— parent [weight weight] [cir-weight cir-weight]
— no parent
— rate pir-rate [cir cir-rate]
— no rate
— scheduler-policy scheduler-policy-name
— no scheduler-policy
— frame-relay
— scheduling-class class-id
— no scheduling-class
— ingress
— filter [ip ip-filter-id]
Issue: 01
3HE 11970 AAAA TQZZA 01
231
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
—
—
—
—
232
— filter [ipv6 ipv6-filter-id]
— no filter [ip ip-filter-id] [ipv6 ipv6-filter-id]
— [no] policer-override
— policer policer-id [create]
— no policer policer-id
— cbs size [bytes | kilobytes]
— no cbs
— mbs {size [bytes | kilobytes] | default}
— no mbs
— packet-byte-offset add add-bytes | subtract
sub-bytes}
— percent-rate pir-percent [cir cir-percent]
— no percent-rate
— rate {rate | max} [cir {max | rate}]
— stat-mode stat-mode
— no stat-mode
— qos policy-id [shared-queuing]
— no qos
— [no] queue-override
— [no] queue queue-id
— adaptation-rule [pir adaptation-rule] [cir
adaptation-rule]
— no adaptation-rule
— avg-frame-overhead percent
— no avg-frame-overhead
— burst-limit size-in-kbytes
— no burst-limit
— drop-tail low
— percent-reduction-from-mbs
percent
— no percent-reduction-from-mbs
— mbs {size [bytes | kilobytes] | default}
— no mbs
— monitor-depth
— [no] monitor-depth
— rate pir-rate [cir cir-rate]
— no rate
— [no] scheduler-override
— [no] scheduler scheduler-name
— parent [weight weight] [cir-weight cir-weight]
— no parent
— rate pir-rate [cir cir-rate]
— no rate
— scheduler-policy scheduler-policy-name
— no scheduler-policy
— scheduler-policy scheduler-policy-name
— no scheduler-policy
— multi-service-site customer-site-name
— no multi-service-site
— [no] shutdown
service-mtu octets
no service-mtu
service-name service-name
no service-name
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
—
—
—
—
2.17.1.6
VLL Services
[no] shutdown
spoke-sdp sdp-id[:vc-id] [no-endpoint]
spoke-sdp sdp-id[:vc-id] endpoint endpoint-name [icb]
no spoke-sdp sdp-id[:vc-id]
— bandwidth bandwidth
— no bandwidth
— bfd-enable
— no bfd-enable
— bfd-template name
— no bfd-template
— egress
— filter [ip ip-filter-id]
— filter [ipv6 ipv6-filter-id]
— no filter [ip ip-filter-id] [ipv6 ipv6-filter-id]
— qos network-policy-id port-redirect-group queue-group-name
[instance instance-id]
— no qos
— vc-label ingress-vc-label
— no vc-label [ingress-vc-label]
— [no] entropy-label
— [no] hash-label
— ingress
— filter [ip ip-filter-id]
— filter [ipv6 ipv6-filter-id]
— no filter [ip ip-filter-id] [ipv6 ipv6-filter-id]
— qos network-policy-id fp-redirect-group queue-group-name
instance instance-id
— no qos
— vc-label ingress-vc-label
— no vc-label [ingress-vc-label]
— precedence [precedence-value| primary]
— no precedence
— [no] shutdown
Ipipe Service Configuration Commands
config
— service
— ipipe service-id [customer customer-id] [vpn vpn-id] [vc-switching]
— no ipipe service-id
— ce-address-discovery [ipv6] [keep]
— [no] ce-address-discovery
— description description-string
— no description
— [no] endpoint endpoint-name
— active-hold-delay active-endpoint-delay
— no active-hold-delay
— description description-string
— no description
— revert-time revert-time
— no revert-time
Issue: 01
3HE 11970 AAAA TQZZA 01
233
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
— eth-legacy-fault-notification
— recovery-timer timer-value
— [no] recovery-timer
— [no] shutdown
— sap sap-id [no-endpoint]
— sap sap-id endpoint endpoint-name
— [no] sap eth-tunnel-tunnel-id [:eth-tunnel-sap-id] [create]
— no sap sap-id
— accounting-policy acct-policy-id
— no accounting-policy
— atm
— egress
— traffic-desc traffic-desc-profile-id
— no traffic-desc
— encapsulation atm-encap-type
— ingress
— traffic-desc traffic-desc-profile-id
— no traffic-desc
— oam
— [no] alarm-cells
— ce-address ip-address
— no ce-address
— collect-stats
— no collect-stats
— cpu-protection policy-id {[mac-monitoring] | [eth-cfm-monitoring
[aggregate] [car]]}
— no cpu-protection
— description description-string
— no description
— dist-cpu-protection policy-name
— no dist-cpu-protection
— egress
— [no] agg-rate
— rate kilobits-per-second
— no rate
— [no] limit-unused-bandwidth
— [no] queue-frame-based-accounting
— filter {ip ip-filter-id | ipv6 ipv6-filter-id}
— no filter {ip ip-filter-id | ipv6 ipv6-filter-id}
— [no] hsmda-queue-override
— secondary-shaper secondary-shaper-name
— no secondary-shaper
— wrr-policy hsmda-wrr-policy-name
— no wrr-policy
— packet-byte-offset {add add-bytes | subtract sub-bytes}
— no packet-byte-offset
— queue queue-id
— no queue queue-id
— wrr-weight weight
— no wrr-weight
— mbs {size [bytes | kilobytes] | default}
— no mbs
— rate pir-rate
— no rate
234
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
— slope-policy hsmda-slope-policy-name
allowable
— no slope-policy
— [no] policer-override
— policer policer-id [create]
— no policer policer-id
— cbs size [bytes | kilobytes]
— no cbs
— mbs {size [bytes | kilobytes] | default}
— no mbs
— packet-byte-offset add add-bytes | subtract
sub-bytes}
— percent-rate pir-percent [cir cir-percent]
— no percent-rate
— rate {rate | max} [cir {max | rate}]
— stat-mode stat-mode
— no stat-mode
— qinq-mark-top-only
— qos policy-id
— no qos
— [no] queue-override
— [no] queue queue-id
— adaptation-rule [pir adaptation-rule] [cir
adaptation-rule]
— no adaptation-rule
— avg-frame-overhead percent
— no avg-frame-overhead
— burst-limit size-in-kbytes
— no burst-limit
— drop-tail low
— percent-reduction-from-mbs
percent
— no percent-reduction-from-mbs
— mbs {size [bytes | kilobytes] | default}
— no mbs
— monitor-depth
— [no] monitor-depth
— parent {[weight weight] [cir-weight cirweight]}
— no parent
— percent-rate pir-percent [cir cir-percent]
— no percent-rate
— rate pir-rate [cir cir-rate]
— no rate
— [no] scheduler-override
— [no] scheduler scheduler-name
— parent [weight weight] [cir-weight cir-weight]
— no parent
— rate pir-rate [cir cir-rate]
— no rate
— scheduler-policy scheduler-policy-name
— no scheduler-policy
— eth-cfm
— [no] collect-lmm-stats]
Issue: 01
3HE 11970 AAAA TQZZA 01
235
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
— collect-lmm-fc-stats
— fc fc-name [fc-name ... (up to 8 max)]
— no fc
— fc-in-profile fc-name [fc-name ... (up to 8 max)]
— no fc-in-profile
— [no] mep mep-id domain md-index association ma-index
[direction {up | down}]
— [no] ccm-enable
— [no] ccm-ltm-priority priority
— [no] description
— [no] eth-test-enable
— [no] bit-error-threshold bit-errors
— [no] test-pattern {all-zeros | all-ones} [crcenable]
— [no] fault-propagation-enable {use-if-tlv | suspendccm}
— grace
— eth-ed
— max-rx-defect-window seconds
— no max-rx-defect-window
— priority priority
— no priority
— [no] rx-eth-ed
— [no] tx-eth-ed
— eth-vsm-grace
— [no] rx-eth-vsm-grace
— [no] tx-eth-vsm-grace
— low-priority-defect {allDef | macRemErrXcon |
remErrXcon | errXcon | xcon | noXcon}
— [no] one-way-delay-threshold mac-address
— [no] one-way-delay-threshold <seconds>
— [no] shutdown
— [no] mip [{mac mac-address | default-mac}]
— [no] squelch-ingress-levels [md-level [md-level…]]
— tunnel-fault [accept | ignore]
— eth-tunnel
— path path-index tag qtag[.qtag]
— no path path-index
— ingress
— filter {ip ip-filter-id | ipv6 ipv6-filter-id}
— no filter {ip ip-filter-id | ipv6 ipv6-filter-id}
— match-qinq-dot1p {top | bottom}
— no match-qinq-dot1p
— [no] policer-override
— policer policer-id [create]
— no policer policer-id
— cbs size [bytes | kilobytes]
— no cbs
— mbs {size [bytes | kilobytes] | default}
— no mbs
— packet-byte-offset add add-bytes | subtract
sub-bytes}
— percent-rate pir-percent [cir cir-percent]
— no percent-rate
236
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
—
—
—
—
—
—
—
—
Issue: 01
VLL Services
— rate {rate | max} [cir {max | rate}]
— stat-mode stat-mode
— no stat-mode
— qos policy-id [shared-queuing]
— no qos
— [no] queue-override
— [no] queue queue-id
— adaptation-rule [pir adaptation-rule] [cir
adaptation-rule]
— no adaptation-rule
— burst-limit size-in-kbytes
— no burst-limit
— drop-tail
— low
— percent-reduction-from-mbs
percent
— no percent-reduction-from-mbs
— mbs {size [bytes | kilobytes] | default}
— no mbs
— monitor-depth
— [no] monitor-depth
— rate pir-rate [cir cir-rate]
— no rate
— [no] scheduler-override
— [no] scheduler scheduler-name
— parent [weight weight] [cir-weight cir-weight]
— no parent
— rate pir-rate [cir cir-rate]
— no rate
— scheduler-policy scheduler-policy-name
— no scheduler-policy
— lag-link-map-profile link-map-profile-id
— no lag-link-map-profile
— lag-per-link-hash class {1 | 2 | 3} weight [1 to 1024]
— no lag-per-link-hash
— mac [ieee-address]
— no mac
— mac-refresh [refresh interval]
— no mac-refresh
— multi-service-site customer-site-name
— no multi-service-site
— [no] shutdown
— [no] use-broadcast-mac
service-mtu octets
no service-mtu
service-name service-name
no service-name
[no] shutdown
spoke-sdp [sdp-id[:vc-id] [no-endpoint]
spoke-sdp [sdp-id[:vc-id] endpoint endpoint-name [icb]
no spoke-sdp sap-id
— bandwidth bandwidth
— no bandwidth
— bfd-enable
3HE 11970 AAAA TQZZA 01
237
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
—
—
—
—
—
—
—
no bfd-enable
bfd-template name
no bfd-template
ce-address ip-address
no ce-address
[no] control-word
egress
— filter {ip ip-filter-id | ipv6 ipv6-filter-id}
— no filter {ip ip-filter-id | ipv6 ipv6-filter-id}
— qos network-policy-id port-redirect-group queue-group-name
[instance instance-id]
— no qos
— [no] vc-label vc-label
— [no] entropy-label
— [no] hash-label
— ingress
— filter {ip ip-filter-id | ipv6 ipv6-filter-id}
— no filter {ip ip-filter-id | ipv6 ipv6-filter-id}
— qos network-policy-id fp-redirect-group queue-group-name
instance instance-id
— no qos
— vc-label ingress-vc-label
— no vc-label [ingress-vc-label]
— precedence [precedence-value| primary]
— no precedence
— [no] shutdown
— [no] stack-capability-signaling
238
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
2.17.2
VLL Services
Command Descriptions
• Generic Commands
• VLL Global Commands
• VLL SAP Commands
• VLL Frame Relay Commands
• VLL SDP Commands
• Service Commands
2.17.2.1
Generic Commands
shutdown
Syntax
Context
Description
[no] shutdown
config>service>apipe
config>service>apipe>sap
config>service>apipe>spoke-sdp
config>service>cpipe
config>service>cpipe>sap
config>service>cpipe>spoke-sdp
config>service>epipe
config>service>epipe>bgp-vpws
config>service>epipe>sap
config>service>epipe>spoke-sdp
config>service>epipe>sap>eth-cfm>mep
config>service>epipe>spoke-sdp>eth-cfm>mep
config>service>fpipe
config>service>fpipe>sap
config>service>fpipe>spoke-sdp
config>service>ipipe
config>service>ipipe>sap
config>service>ipipe>spoke-sdp
config>service>epipe>pw-port
This command administratively disables an entity. When disabled, an entity does not change,
reset, or remove any configuration settings or statistics.
The operational state of the entity is disabled as well as the operational state of any entities
contained within. Many objects must be shut down before they may be deleted.
Issue: 01
3HE 11970 AAAA TQZZA 01
239
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
Services are created in the administratively down (shutdown) state. When a no shutdown
command is entered, the service becomes administratively up and then tries to enter the
operationally up state. Default administrative states for services and service entities is
described below in Special Cases.
The no form of this command places the entity into an administratively enabled state.
Special Cases
Service Admin State — Bindings to an SDP within the service will be put into the outof-service state when the service is shutdown. While the service is shutdown, all
customer packets are dropped and counted as discards for billing and debugging
purposes.
Service Operational State — A service is regarded as operational providing that at
least one SAP and one SDP are operational or if two SAPs are operational.
SDP (global) — When an SDP is shutdown at the global service level, all bindings to that
SDP are put into the out-of-service state and the SDP itself is put into the
administratively and operationally down states. Packets that would normally be
transmitted using this SDP binding will be discarded and counted as dropped
packets.
SDP (service level) — Shutting down an SDP within a service only affects traffic on that
service from entering or being received from the SDP. The SDP itself may still be
operationally up for other services.
description
Syntax
Context
Description
240
description description-string
no description
config>service>apipe
config>service>apipe>sap
config>service>apipe>endpoint
config>service>cpipe
config>service>cpipe>endpoint
config>service>cpipe>sap
config>service>epipe
config>service>epipe>sap
config>service>epipe>spoke-sdp
config>service>epipe>endpoint
config>service>fpipe
config>service>fpipe>sap
config>service>fpipe>endpoint
config>service>ipipe
config>service>ipipe>sap
config>service>ipipe>endpoint
This command creates a text description stored in the configuration file for a configuration
context. The description command associates a text string with a configuration context to
help identify the content in the configuration file.
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
The no form of this command removes the string from the configuration.
Default
No description associated with the configuration context.
Parameters
description-string — The description character string. Allowed values are any string up to
80 characters long composed of printable, 7-bit ASCII characters. If the string
contains special characters (#, $, spaces, and so on), the entire string must be
enclosed within double quotes.
2.17.2.2
Service Commands
apipe
Syntax
Context
apipe service-id [customer customer-id] [vpn vpn-id] [vc-type {atm-vcc | atm-sdu | atmvpc | atm-cell}] [vc-switching] [test] [create]
no apipe service-id
config>service
Description
The Apipe service provides a point-to-point Layer 2 VPN connection to a remote SAP or to
another local SAP. An Apipe can connect an ATM or Frame Relay endpoint either locally or
over a PSN to a remote endpoint of the same type or of a different type and perform
interworking between the two access technologies.
Parameters
service-id — The unique service identification number or string identifying the service in
the service domain. This ID must be unique to this service and may not be used for
any other service of any type. The service-id must be the same number used for
every 7450 ESS or 7750 SR on which this service is defined.
Values
service-id:1 to 2147483648
svc-name: 64 characters maximum
customer-id — Specifies the customer ID number to be associated with the service. This
parameter is required on service creation and optional for service editing or deleting.
Values
1 to 2147483647
vpn vpn-id — Specifies the VPN ID number which allows you to identify virtual private
networks (VPNs) by a VPN identification number.
Issue: 01
Values
1 to 2147483647
Default
null (0)
3HE 11970 AAAA TQZZA 01
241
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
vc-type — Keyword that specifies a 15 bit value that defines the type of the VC signaled
to the peer. Its values are defined in draft-ietf-pwe3-iana-allocation and it defines
both the signaled VC type as well as the resulting datapath encapsulation over the
Apipe.
Values
atm-vcc, atm-sdu, atm-vpc, atm-cell
Default
atm-sdu
vc-switching — Specifies if the pseudowire switching signaling is used for the spoke
SDPs configured in this service.
test — Specifies a unique test service type for the service context which will contain only
a SAP configuration. The test service can be used to test the throughput and
performance of a path for MPLS-TP PWs. This parameter is not supported on the
7950 XRS.
cpipe
Syntax
Context
Description
cpipe service-id [customer customer-id] [vpn vpn-id] [vc-type {satop-e1 | satop-t1 | [vcswitching] |cesopsn | cesopsn-cas}] [vc-switching] [test] [create]
no cpipe service-id
config>service
This command configures a Circuit Emulation Services instance.
When a service is created, the customer keyword and customer-id must be specified and
associates the service with a customer. The customer-id must already exist having been
created using the customer command in the service context. Once a service has been
created with a customer association, it is not possible to edit the customer association. The
service must be deleted and recreated with a new customer association.
Once a service is created, the use of the customer customer-id is optional for navigating into
the service configuration context. Attempting to edit a service with the incorrect customer-id
specified will result in an error.
By default, no services exist until they are explicitly created with this command.
The no form of this command deletes the service instance with the specified service-id. The
service cannot be deleted until the service has been shutdown.
Parameters
service-id — The unique service identification number or string identifying the service in
the service domain. This ID must be unique to this service and may not be used for
any other service of any type. The service-id must be the same number used for
every router on which this service is defined.
Values
service-id: 1to 2147483648
svc-name: Specifies an existing service name up to 64 characters in
length.
242
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
customer-id — Specifies the customer ID number to be associated with the service. This
parameter is required on service creation and optional for service editing or deleting.
Values
1 to 2147483647
vpn vpn-id — Specifies the VPN ID number which allows you to identify virtual private
networks (VPNs) by a VPN ID. If this parameter is not specified, the VPN ID uses the
same service ID number.
Values
1 to 2147483647
Default
null (0)
vc-type — The vc-type defines the type of unstructured or structured circuit emulation
service to be configured.
Values
satop-e1: Unstructured E1 circuit emulation service.
satop-t1: Unstructured DS1 circuit emulation service.
cesopsn: Basic structured n*64 kbps circuit emulation service.
cesopsn-cas: Structured n*64 kbps circuit emulation service with
signaling.
vc-switching — Specifies if the pseudowire switching signaling is used for the spoke
SDPs configured in this service.
test — Specifies a unique test service type for the service context which will contain only
a SAP configuration. The test service can be used to test the throughput and
performance of a path for MPLS-TP PWs. This parameter applies to the 7450 ESS
and 7750 SR only.
create — Keyword used to create the service. The create keyword requirement can be
enabled/disabled in the environment>create context.
epipe
Syntax
Context
Description
epipe service-id customer customer-id [vpn vpn-id] [vc-switching] [create]
epipe service-id [test] [create]
no epipe service-id
config>service
This command configures an Epipe service instance. This command is used to configure a
point-to-point epipe service. An Epipe connects two endpoints defined as Service Access
Points (SAPs). Both SAPs may be defined in one 7450 ESS, 7750 SR, or 7950 XRS or they
may be defined in separate devices connected over the service provider network. When the
endpoint SAPs are separated by the service provider network, the far end SAP is generalized
into a Service Distribution Point (SDP). This SDP describes a destination and the
encapsulation method used to reach it.
No MAC learning or filtering is provided on an Epipe.
Issue: 01
3HE 11970 AAAA TQZZA 01
243
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
When a service is created, the customer keyword and customer-id must be specified and
associates the service with a customer. The customer-id must already exist having been
created using the customer command in the service context. Once a service has been
created with a customer association, it is not possible to edit the customer association. The
service must be deleted and recreated with a new customer association.
Once a service is created, the use of the customer customer-id is optional for navigating into
the service configuration context. Attempting to edit a service with the incorrect customer-id
specified will result in an error.
By default, no epipe services exist until they are explicitly created with this command.
The no form of this command deletes the epipe service instance with the specified serviceid. The service cannot be deleted until the service has been shutdown.
Cpipe services are enabled on the 7450 ESS in mixed mode.
Parameters
service-id — The unique service identification number or string identifying the service in
the service domain. This ID must be unique to this service and may not be used for
any other service of any type. The service-id must be the same number used for
every 7450 ESS, 7750 SR, or 7950 XRS on which this service is defined.
Values
service-id: 1 to 2147483648
svc-name: 64 characters maximum
customer-id — Specifies the customer ID number to be associated with the service. This
parameter is required on service creation and optional for service editing or deleting.
Values
1 to 2147483647
vpn vpn-id — Specifies the VPN ID number which allows you to identify virtual private
networks (VPNs) by a VPN ID. If this parameter is not specified, the VPN ID uses the
same service ID number.
Values
1 to 2147483647
Default
null (0)
vc-switching — Specifies if the pseudowire switching signaling is used for the spoke
SDPs configured in this service.
test — Specifies a unique test service type for the service context which will contain only
a SAP configuration. The test service can be used to test the throughput and
performance of a path for MPLS-TP PWs. This parameter applies to the 7450 ESS
and 7750 SR only.
create — Keyword used to create the service instance. The create keyword requirement
can be enabled/disabled in the environment>create context.
fpipe
Syntax
244
fpipe service-id [customer customer-id] [vpn vpn-id] [vc-type {fr-dlci}] [vc-switching]
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
no fpipe service-id
Context
config>service
Description
This command configures an Fpipe service. An Fpipe provides a point-to-point L2 VPN
connection to a remote SAP or to another local SAP. An Fpipe connects only Frame Relay
endpoints either locally or over a PSN to a remote endpoint of the same type.
Parameters
service-id — The unique service identification number or string identifying the service in
the service domain. This ID must be unique to this service and may not be used for
any other service of any type. The service-id must be the same number used for
every 7750 SR on which this service is defined.
Values
service-id: 1 to 2147483648
svc-name: 64 characters maximum
customer-id — Specifies the customer ID number to be associated with the service. This
parameter is required on service creation and optional for service editing or deleting.
Values
1 to 2147483647
vpn vpn-id — Specifies the VPN ID number which allows you to identify virtual private
networks (VPNs) by a VPN identification number.
Values
1 to 2147483647
Default
null (0)
vc-type — Specifies a 15 bit value that defines the type of the VC signaled to the peer.
Its values are defined in draft-ietf-pwe3-iana-allocation and it defines both the
signaled VC type as well as the resulting datapath encapsulation over the apipe.
Values
fr-dlci
vc-switching — Specifies if the pseudowire switching signaling is used for the spoke
SDPs configured in this service.
ipipe
Syntax
Context
ipipe service-id [customer customer-id] [create] [vpn vpn-id] [vc-switching]
no ipipe service-id
config>service
Description
This command configures an IP-Pipe service.
Parameters
service-id — The unique service identification number or string identifying the service in
the service domain. This ID must be unique to this service and may not be used for
any other service of any type. The service-id must be the same number used for
every 7450 ESS or 7750 SR on which this service is defined.
Values
service-id: 1 to 2147483648
svc-name: 64 characters maximum
Issue: 01
3HE 11970 AAAA TQZZA 01
245
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
customer-id — Specifies the customer ID number to be associated with the service. This
parameter is required on service creation and optional for service editing or deleting.
Values
1 to 2147483647
vpn vpn-id — Specifies the VPN ID number which allows you to identify virtual private
networks (VPNs) by a VPN identification number.
Values
1 to 2147483647
Default
null (0)
vc-switching — Specifies if the pseudowire switching signaling is used for the spoke
SDPs configured in this service.
create — Keyword used to create the Ipipe service instance. The create keyword
requirement can be enabled/disabled in the environment>create context.
2.17.2.3
VLL Global Commands
bgp
Syntax
Context
Description
bgp
config>service>epipe
This command enters the context to configure the BGP related parameters BGP used for
Multi-Homing and BGP VPWS.
The no form of this command removes the string from the configuration.
pw-template-binding
Syntax
Context
Description
pw-template-binding policy-id [import-rt {ext-community,.(upto 5 max)}]
no pw-template-binding policy-id
config>service>epipe>bgp
This command binds the advertisements received with the route targets (RT) that match the
configured list (either the generic or the specified import) to a specific pw-template. If the RT
list is not present, or if multiple matches are found, the numerically lowest pw-template is
used.
The pw-template-binding applies to BGP-VPWS when enabled in the Epipe.
For BGP VPWS, the following additional rules govern the use of pseudowire-template:
246
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
• On transmission, the settings for the L2-Info extended community in the BGP updates
are derived from the pseudowire template attributes. If multiple pseudowire template
bindings (with or without import-rt) are specified for the same VPWS instance the first
pw-template entry will be used.
• On reception, the values of the parameters in the L2-Info extended community of the
BGP updates are compared with the settings from the corresponding pseudowire
template bindings. The following steps are used to determine the local pw-template:
− The RT values are matched to determine the pw-template.
− If multiple pw-template-binding matches are found from the previous step, the first
(numerically lowest) configured pw-template entry will be considered.
− If the value used for Layer 2 MTU (unless the value zero is received) does not
match the pseudowire is created but with the oper state down.
− If the value used for the S (sequenced delivery) flags is not zero the pseudowire is
not created.
The tools perform commands can be used to control the application of changes in pwtemplate for BGP-VPWS.
The no form of the command removes the values from the configuration.
Parameters
policy-id — Specifies an existing policy ID.
Values
1 to 2147483647
import-rt ext-comm — Specifies the communities allowed to be accepted from remote
PE neighbors. An extended BGP community in the type:x:y format. The value x can
be an integer or IP address. The type can be the target or origin.
Values
target:{ip-addr:comm-val | 2byte-asnumber:ext-comm-val| 4bytesnumber:comm-val}
ip-addr
a.b.c.d
comm-val
0 to 65535
2byte-asnumber
0 to 65535
ext-comm-val
0 to 4294967295
4byte-asnumber
0 to 4294967295
route-distinguisher
Syntax
Context
Description
Issue: 01
route-distinguisher auto-rd
no route-distinguisher
route-distinguisher rd
config>service>epipe>bgp
This command configures the Route Distinguisher (RD) component that is signaled in the
MPBGP NLRI for L2VPN AFI. This value is used for BGP Multi-Homing and BGP-VPWS.
3HE 11970 AAAA TQZZA 01
247
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
An RD value must be configured under BGP node.
Alternatively, the auto-rd option allows the system to automatically generate an RD based
on the bgp-auto-rd-range command configured at the service level.
Format: Six bytes, other 2 bytes of type will be automatically generated.
Parameters
ip-addr:comm-val — Specifies the IP address.
Values
ip-addr: a.b.c.d
comm-val: 0 to 65535
as-number:
as-number:ext-comm-val — Specifies the AS number.
Values
as-number: 1 to 65535
ext-comm-val: 0 to 4294967295
auto-rd — The system will generate an RD for the service according to the IP address
and range configured in the bgp-auto-rd-range command.
rd — Specifies the route distinguisher.
Values
<rd>
<ip-addr:comm-val> | <2byte-asnumber:ext-comm-val>|<4byte-asnumber:commval>
ip-addr
a.b.c.d
comm-val
0 to 65535
2byte-asnumber
1 to 65535
ext-comm-val
0 to 4294967295
4byte-asnumber
0 to 4294967295
route-target
Syntax
Context
Description
route-target {ext-community | {[export ext-community] [import ext-community]}}
no route-target
config>service>epipe>bgp
This command configures the route target (RT) component that is signaled in the related
MPBGP attribute to be used for BGP Multi-Homing and BGP-VPWS when configured in the
Epipe service. The ext-comm can have two formats:
• A two-octet AS-specific extended community, IPv4 specific extended community.
• An RT value must be configured under BGP node when BGP Epipe is configured.
Parameters
248
export ext-community — Specifies communities allowed to be sent to remote PE
neighbors.
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
import ext-community — Specifies communities allowed to be accepted from remote PE
neighbors.
bgp-vpws
Syntax
Context
Description
Default
[no] bgp-vpws
config>service>epipe
This command enters the context to configure BGP-VPWS parameters and addressing.
no bgp-vpws
remote-ve-name
Syntax
Context
Description
[no] remote-ve-name name
config>service>epipe>bgp-vpws
This command creates or edits a remote-ve-name. A single remote-ve-name can be created
per BGP VPWS instance if the service is single-homed or uses a single pseudowire to
connect to a pair of dual-homed systems. When the service requires active/standby
pseudowires to be created to remote dual-homed systems then two remote-ve-names must
be configured.
This context defines the remote PE to which a pseudowire will be signaled.
remote-ve-name commands can be added even if bgp-vpws is not shutdown.
The no form of the command removes the configured remote-ve-name from the bgp vpws
node. It can be used when the BGP VPWS status is either shutdown or “no shutdown”.
Parameters
name — Specifies a site name up to 32 characters in length.
ve-id
Syntax
Context
Description
Issue: 01
ve-id value
no ve-id
config>service>epipe>bgp-vpws>ve-name
config>service>epipe>bgp-vpws>remote-ve-name
This command configures a ve-id for either the local VPWS instance when configured under
the ve-name, or for the remote VPWS instance when configured under the remote-ve-name.
3HE 11970 AAAA TQZZA 01
249
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
A single ve-id can be configured per ve-name or remote-ve-name. The ve-id can be changed
without shutting down the VPWS instance. When the ve-name ve-id changes, BGP
withdraws the previously advertised route and sends a route-refresh to all the peers which
would result in reception of all the remote routes again. The old PWs are removed and new
ones are instantiated for the new ve-id value.
When the remote-ve-name ve-id changes, BGP withdraws the previously advertised route
and send a new update matching the new ve-id. The old pseudowires are removed and new
ones are instantiated for the new ve-id value.
NLRIs received whose advertised ve-id does not match the list of ve-ids configured under the
remote ve-id will not have a spoke SDP binding auto-created but will remain in the BGP
routing table but not in the Layer 2 route table. A change in the locally configured ve-ids may
result in auto-sdp-bindings either being deleted or created, based on the new matching
results.
Each ve-id configured within a service must be unique.
The no form of the command removes the configured ve-id. It can be used just when the BGP
VPWS status is shutdown. The no shutdown command cannot be used if there is no ve-id
configured.
Default
Parameters
no ve-id
value — A two bytes identifier that represents the local or remote VPWS instance and is
advertised through the BGP NLRI.
Values
1 to 65535
ve-name
Syntax
Context
Description
[no] ve-name name
config>service>epipe>bgp-vpws
This command configures the name of the local VPWS instance in this service.
The no form of the command removes the ve-name.
Parameters
name — Specifies a site name up to 32 characters in length.
shutdown
Syntax
Context
Description
250
[no] shutdown
config>service>epipe>bgp-vpws
This command administratively enables/disables the local BGP VPWS instance. On deactivation an MP-UNREACH-NLRI is sent for the local NLRI.
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
The no form of the command enables the BGP VPWS addressing and the related BGP
advertisement. The associated BGP VPWS MP-REACH-NLRI will be advertised in an update
message and the corresponding received NLRIs must be considered to instantiate the data
plane.
Default
shutdown
Syntax
site name [create]
no site name
site
Context
Description
config>service>epipe
This command configures a Epipe site.
The no form of the command removes the name from the configuration.
Parameters
name — Specifies a site name up to 32 characters in length.
create — This keyword is mandatory while creating a Epipe service.
boot-timer
Syntax
Context
Description
boot-timer seconds
no boot-timer
config>service>epipe>site
This command configures for how long the service manger waits after a node reboot before
running the DF election algorithm. The boot-timer value should be configured to allow for the
BGP sessions to come up and for the NLRI information to be refreshed/exchanged.
The no form of the command reverts the default.
Default
Parameters
10
seconds — Specifies the site boot-timer in seconds.
Values
0 to 600
sap
Syntax
Context
Issue: 01
sap sap-id
no sap
config>service>epipe>site
3HE 11970 AAAA TQZZA 01
251
VLL Services
Description
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
This command configures a SAP for the site.
The no form of the command removes the SAP ID from the configuration.
Parameters
sap-id — Specifies the physical port identifier portion of the SAP definition.
site-activation-timer
Syntax
Context
Description
site-activation-timer seconds
no site-activation-timer
config>service>epipe>site
This command configures the time-period the system keeps the local sites in standby status,
waiting for BGP updates from remote PEs before running the DF (designated-forwarder)
election algorithm to decide whether the site should be unblocked. This timer is terminated if
an update is received for which the remote PE has transitioned from DF to non-DF.
The no form of the command removes the value from the configuration.
Default
Parameters
2
seconds — Specifies the site activation timer in seconds.
Values
0 to 100
site-min-down-timer
Syntax
Context
Description
site-min-down-timer min-down-time
no site-min-down-timer
config>service>epipe>site
This command configures the BGP multi-homing site minimum down time. When set to a
non-zero value, if the site goes operationally down it will remain operationally down for at
least the length of time configured for the site-min-down-timer, regardless of whether other
state changes would have caused it to go operationally up. This timer is restarted every time
that the site transitions from up to down. Setting this parameter to zero allows the minimum
down timer to be disabled for this service.
The above operation is optimized in the following circumstances:
• If the site goes down on the designated forwarder but there are no BGP multi-homing
peers with the same site in an UP state, then the site-min-down-timer is not started and
is not used.
• If the site goes down on the designated forwarder but there are no active BGP multihoming peers, then the site-min-down-timer is not started and is not used.
252
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
• If the site-min-down-timer is active and a BGP multi-homing update is received from
the designated forwarder indicating its site has gone down, the site-min-down-timer is
immediately terminated and this PE becomes the designated forwarder if the BGP multihoming algorithm determines it should be the designated forwarder.
The no form of the command reverts to default value.
Default
Parameters
Taken from the value of site-min-down-timer configured for Multi-Chassis BGP MultiHoming under the config>redundancy>bgp-multi-homing context.
min-down-time — Specifies the time, in seconds, that a BGP multi-homing site remains
operationally down after a transition from up to down.
Values
0 to 100
site-id
Syntax
Context
site-id value
no site-id
config>service>epipe>site
Description
This command configures the identifier for the site in this service. It must match between
services but it is local to the service.
Parameters
value — Specifies the site identifier.
Values
1 to 65535
site-preference
Syntax
Context
Description
site-preference preference-value
no site-preference
config>service>epipe>site
This command defines the value to advertise in the VPLS preference field of the BGP VPWS
and BGP Multi-homing NLRI extended community. This value can be changed without having
to shutdown the site itself. The site-preference is only applicable to VPWS services.
When not configured, the default is zero, indicating that the VPLS preference is not in use.
Default
Parameters
no site-preference, value=0
preference-value — Specifies the preference value to advertise in the NLRI L2 extended
community for this site.
Values
1 to 65535
primary — Sets the site-preference to 65535.
Issue: 01
3HE 11970 AAAA TQZZA 01
253
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
backup — Sets the site-preference to 1.
ce-address-discovery
Syntax
Context
Description
[no] ce-address-discovery [ipv6] [keep]
config>service>ipipe
This command specifies whether the service will automatically discover the CE IP addresses.
When enabled, the addresses will be automatically discovered on SAPs that support address
discovery, and on the spoke SDPs. When enabled, addresses configuration on the Ipipe SAP
and spoke SDPs will not be allowed.
If disabled, CE IP addresses must be manually configured for the SAPs to become
operationally up.
Default
Parameters
no ce-address-discovery
ipv6 — The ipv6 keyword enables IPv6 CE address discovery support on the Ipipe so
that both IPv4 and IPv6 address discovery are supported. If the ipv6 keyword is not
included, then only IPv4 address discovery is supported and IPv6 packets are
dropped. For the 7450 ESS platforms, it requires mixed mode support.
keep — The keep keyword is only applicable to eth-legacy-fault-notification. This option
maintains the CE address discovered even when the SAP on which the address was
learned fails. The ARP entry will not be maintained if the SAP is administratively
shutdown, the clear service id x {arp | neighbor} is used to remove the ARP entry or
the node reboots.
stack-capability-signaling
Syntax
Context
Description
[no] stack-capability-signaling
config>service>ipipe
This command enables stack capability signaling in the initial label mapping message of the
ipipe PW to indicate that IPv6 is supported.
When enabled, the 7750 SR includes the stack capability TLV with the IPv6 stack bit set
according to the ce-address-discovery ipv6 keyword, and also checks the value of the
stack-capability TLV received from the far end.
This command must be blocked if no ce-address-discovery is specified, or the ipv6
keyword is not included with the ce-address-discovery command.
This command if only applicable to the ipipe service and must be blocked for all other
services.
254
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
This command has no effect if both SAPs on the Ipipe service are local to the node.
For the 7450 ESS platforms, it requires mixed mode support.
Default
no stack-capability-signaling
endpoint
Syntax
Context
[no] endpoint endpoint-name
config>service>apipe
config>service>cpipe
config>service>fpipe
config>service>epipe
config>service>ipipe
Description
This command configures a service endpoint.
Parameters
endpoint-name — Specifies an endpoint name.
load-balancing
Syntax
Context
Description
Default
load-balancing
config>service>epipe
This command enables the load-balancing context to configure interface per-flow load
balancing options that will apply to traffic entering this interface and egressing over a LAG/
ECMP on system-egress. This is a per interface setting. For load-balancing options that can
also be enabled on the system level, the options enabled on the interface level overwrite
system level configurations.
not applicable
per-service-hashing
Syntax
Context
Description
[no] per-service-hashing
config>service>epipe>load-balancing
This command enables on a per service basis, consistent per-service hashing for Ethernet
services over LAG, over Ethernet tunnel (eth-tunnel) using loadsharing protection-type or
over CCAG. Specifically, it enables the new hashing procedures for Epipe, VPLS, regular or
PBB services.
The following algorithm describes the hash-key used for hashing when the new option is
enabled:
Issue: 01
3HE 11970 AAAA TQZZA 01
255
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
• If the packet is PBB encapsulated (contains an I-TAG ethertype) at the ingress side, use
the ISID value from the I-TAG
• If the packet is not PBB encapsulated at the ingress side
− For regular (non-PBB) VPLS and Epipe services, use the related service ID
− If the packet is originated from an ingress IVPLS or PBB Epipe SAP
− If there is an ISID configured use the related ISID value
− If there is no ISID yet configured use the related service ID
− For BVPLS transit traffic use the related flood list id
− Transit traffic is the traffic going between BVPLS endpoints
− An example of non-PBB transit traffic in BVPLS is the OAM traffic
− The above rules apply regardless of traffic type
− Unicast, BUM flooded without MMRP or with MMRP, IGMP snooped
The no form of this command implies the use of existing hashing options.
Default
no per-service-hashing
Syntax
tunnel service-id backbone-dest-mac ieee-address isid ISID
no tunnel
tunnel
Context
config>service>epipe>pbb
Description
This command configures a Provider Backbone Bridging (PBB) tunnel with Backbone VPLS
(B-VPLS) service information.
Parameters
service-id — Specifies the B-VPLS service for the PBB tunnel associated with this
service.
Values
service-id: 1 to 2147483648
svc-name: 64 characters maximum
backbone-dest-mac ieee-address — Specifies the backbone destination MACaddress for PBB packets.
isid ISID — Specifies a 24 bit service instance identifier for the PBB tunnel associated
with this service. As part of the PBB frames, it is used at the destination PE as a
demultiplexor field.
Values
0 to 16777215
active-hold-delay
Syntax
256
active-hold-delay active-hold-delay
no active-hold-delay
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
Context
Description
VLL Services
config>service>cpipe>endpoint
config>service>apipe>endpoint
config>service>fpipe>endpoint
config>service>ipipe>endpoint
config>service>epipe>endpoint
This command specifies that the node will delay sending the change in the T-LDP status bits
for the VLL endpoint when the MC-LAG transitions the LAG subgroup which hosts the SAP
for this VLL endpoint from active to standby or when any object in the endpoint. For
example, SAP, ICB, or regular spoke SDP, transitions from up to down operational state.
By default, when the MC-LAG transitioned the LAG subgroup which hosts the SAP for this
VLL endpoint from active to standby, the node sends immediately new T-LDP status bits
indicating the new value of “standby” over the spoke SDPs which are on the mate-endpoint
of the VLL. The same applies when any object in the endpoint changes an operational state
from up to down.
There is no delay applied to the VLL endpoint status bit advertisement when the MC-LAG
transitions the LAG subgroup which hosts the SAP from standby to active or when any
object in the endpoint transitions to an operationally up state.
Default
Parameters
0 — A value of zero means that when the MC-LAG transitioned the LAG subgroup which
hosts the SAP for this VLL endpoint from active to standby, the node sends immediately new
T-LDP status bits indicating the new value of standby over the spoke SDPs which are on the
mate-endpoint of the VLL. The same applies when any object in the endpoint changes an
operational state from up to down.
active-hold-delay — Specifies the active hold delay in 100s of milliseconds.
Values
0 to 60
revert-time
Syntax
Context
revert-time [revert-time | infinite]
no revert-time
config>service>apipe>endpoint
config>service>fpipe>endpoint
config>service>cpipe>endpoint
config>service>epipe>endpoint
config>service>ipipe>endpoint
Description
This command configures the time to wait before reverting back to the primary spoke SDP
defined on this service endpoint, after having failed over to a backup spoke SDP.
Parameters
revert-time — Specifies the time, in seconds, to wait before reverting to the primary SDP.
Issue: 01
Values
0 to 600
Default
0
3HE 11970 AAAA TQZZA 01
257
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
infinite — Causes the endpoint to be non-revertive.
eth-legacy-fault-notification
Syntax
Context
Description
eth-legacy-fault-notification
config>service>ipipe
This is the top level of the hierarchy containing Ethernet to Legacy fault notification
parameters. This context must activate using the no shutdown command before Ethernet to
legacy fault notification can occur for iPipe services that make use of PPP, MLPPP or HDLC.
This is only applicable to iPipe services with one legacy (PPP, MLPPP or HDLC) connection
and an Ethernet SAP. No other services, not other combinations are supported.
recovery-timer
Syntax
Context
recovery-timer timer-value
no recovery-timer
config>service>ipipe>eth-legacy-fault-notification
Description
This timer provides the legacy protocols PPP, MLPPP and HDLC time to establish after the
Ethernet fault condition has cleared. The legacy protocol is afforded this amount of time to
establish the connection before a fault is declared on the legacy side and propagated to the
Ethernet segment. This timer is started as a result of a clearing Ethernet failure. Faults that
may exist on the legacy side will not be detected until the expiration of this timer. Until the
legacy side connection is established or the timer expires the traffic arriving on the Ethernet
SAP from a peer will be discarded. The default value is unlikely to be a representative of all
operator requirements and must be evaluated on a case by case basis.
Parameters
timer-value — The value of the wait time in tenths of a second (100ms). Granularity is in
500ms increments, starting from 1s and up to 30 seconds.
Values
10 to 300
Default
100
shutdown
Syntax
Context
Description
258
[no] shutdown
config>service>ipipe>eth-legacy-fault-notification
This command enables or disables the propagation of fault from the Ethernet segment to the
legacy connection using PPP, MLPPP and HDLC for an iPipe service. Issuing a “no
shutdown” will activate the feature. Issuing a “shutdown” will deactivate the feature and stop
fault notification from the Ethernet to PPP, MLPPP and HDLC protocols.
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
The no form of the command activates the ethernet legacy fault propagation.
Default
shutdown
standby-signaling-master
Syntax
Context
Description
[no] standby-signaling-master
config>service>vll>endpoint
When this command is enabled, the pseudowire standby bit (value 0x00000020) will be sent
to T-LDP peer for each spoke SDP of the endpoint that is selected as a standby.
This command is mutually exclusive with a VLL mate SAP created on a mc-lag/mc-aps or
ICB. It is also mutually exclusive with vc-switching.
Default
standby-signaling-master
standby-signaling-slave
Syntax
Context
Description
[no] standby-signaling-slave
config>service>epipe>endpoint
config>service>epipe>spoke-sdp
When this command is enabled, the node will block the transmit forwarding direction of a
spoke SDP based on the pseudowire standby bit received from a T-LDP peer.
This command is present at the endpoint level as well as the spoke SDP level. If the spoke
SDP is part of an explicit-endpoint, it will not be possible to change this setting at the spoke
SDP level. An existing spoke SDP can be made part of the explicit endpoint only if the settings
do not conflict. A newly created spoke SDP, which is part of a given explicit-endpoint, will
inherit this setting from the endpoint configuration.
This command is mutually exclusive with an endpoint that is part of an mc-lag, mc-aps or an
ICB.
If the command is disabled, the node assumes the existing independent mode of behavior for
the forwarding on the spoke SDP.
Default
disabled
interworking
Syntax
Issue: 01
interworking frf-5
no interworking
3HE 11970 AAAA TQZZA 01
259
VLL Services
Context
Description
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
config>service>apipe
This command specifies the interworking function that should be applied for packets that
ingress/egress SAPs that are part of an Apipe service.
Interworking is applicable only when the two endpoints (i.e., the two SAPs or the SAP and the
spoke SDP) are of different types. Also, there are limitations on the combinations of SAP
type, vc-type, and interworking values as shown in Table 11.
Table 11
SAP types, VC-types and Interworking Values
SAP Type
Allowed VC-Type Value
Allowed Interworking Value
ATM VC
atm-vcc, atm-sdu
None
fr-dlci
Not Supported
fr-dlci
None
atm-sdu
frf-5
FR DLCI
Default
Parameters
none (Interworking must be configured before adding a Frame-Relay SAP to an Apipe
service.)
frf-5 — Specifies Frame Relay to ATM Network Interworking (FRF.5).
service-name
Syntax
Context
Description
service-name service-name
no service-name
config>service>apipe
config>service>cpipe
config>service>fpipe
config>service>ipipe
config>service>epipe
This command configures an optional service name, up to 64 characters in length, which
adds a name identifier to a given service to then use that service name in configuration
references as well as display and use service names in show commands throughout the
system. This helps the service provider/administrator to identify and manage services within
the SR OS platforms.
All services are required to assign a service ID to initially create a service. However, either
the service ID or the service name can be used o identify and reference a given service once
it is initially created.
Parameters
260
service-name — Specifies a unique service name to identify the service. Service names
may not begin with an integer (0 to 9).
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
service-mtu
Syntax
Context
Description
service-mtu octets
no service-mtu
config>service>epipe
config>service>ipipe
config>service>apipe
config>service>cpipe
config>service>fpipe
This command configures the service payload (Maximum Transmission Unit – MTU), in
bytes, for the service. This MTU value overrides the service-type default MTU. The servicemtu defines the payload capabilities of the service. It is used by the system to validate the
SAP and SDP binding’s operational state within the service.
The service MTU and a SAP’s service delineation encapsulation overhead (4 bytes for a
dot1q tag) is used to derive the required MTU of the physical port or channel on which the
SAP was created. If the required payload is larger than the port or channel MTU, then the
SAP will be placed in an inoperative state. If the required MTU is equal to or less than the port
or channel MTU, the SAP will be able to transition to the operative state.
When binding an SDP to a service, the service MTU is compared to the path MTU associated
with the SDP. The path MTU can be administratively defined in the context of the SDP. The
default or administrative path MTU can be dynamically reduced due to the MTU capabilities
discovered by the tunneling mechanism of the SDP or the egress interface MTU capabilities
based on the next hop in the tunnel path. If the service MTU is larger than the path MTU, the
SDP binding for the service will be placed in an inoperative state. If the service MTU is equal
to or less than the path MTU, then the SDP binding will be placed in an operational state.
In the event that a service MTU, port or channel MTU, or path MTU is dynamically or
administratively modified, then all associated SAP and SDP binding operational states are
automatically re-evaluated.
Binding operational states are automatically re-evaluated.
For i-VPLS and Epipes bound to a b-VPLS, the service-mtu must be at least 18 bytes smaller
than the b-VPLS service MTU to accommodate the PBB header.
Because this connects a Layer 2 to a Layer 3 service, adjust either the service-mtu under the
Epipe service. The MTU that is advertised from the Epipe side is service-mtu minus
EtherHeaderSize.
The no form of this command returns the default service-mtu for the indicated service type
to the default value.
By default if no service-mtu is configured it is (1514 - 14) = 1500.
Default
apipe, fpipe: 1508
ipipe: 1500
Issue: 01
3HE 11970 AAAA TQZZA 01
261
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
epipe: 1514
Table 12 shows MTU values for specific VC types.
Table 12
Parameters
MTU Values
SAP VC-Type
Example: Service
MTU
Advertised MTU
Ethernet
1514
1500
Ethernet (with preserved dot1q)
1518
1504
VPLS
1514
1500
VPLS (with preserved dot1q)
1518
1504
VLAN (dot1p transparent to MTU value)
1514
1500
VLAN (Q-in-Q with preserved bottom Qtag)
1518
1504
octets — The size of the MTU in octets, expressed as a decimal integer.
Values
1 to 9194
pw-port
Syntax
Context
Description
pw-port pw-port-id fpe fpe-id [create]
no pw-port
config>service>epipe
This command is used to associate the PW-port with the PXC ports or PXC based LAGs
referenced in the FPE. In other words, the PW-port becomes anchored by the PXC. This
enables an external PW that is mapped to the anchored PW-port to be seamlessly rerouted
between the I/O ports without interruption of service on the PW-port.
This mapping between the external PW (spoke SDP) and the PXC based PXC-port is
performed via an Epipe operating in vc-switching mode (creation time parameter).
Default
Parameters
no pw-port
pw-port-id — Specifies the PW-port associated with this service.
Values
1 to 10239
fpe fpe-id — Specifies the FPE object which contains the PXC-based ports or PXCbased LAGs.
Values
262
1 to 64
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
egress
Syntax
Context
Description
egress
config>service>epipe>pw-port
This command enters the context to configure PW-port egress-side parameters
Default
N/A
Syntax
[no] shaper
shaper
Context
Description
Default
config>service>epipe>pw-port>egress
This command enters the context to configure PW-port shaper parameters.
N/A
int-dest-id
Syntax
Context
Description
Default
Parameters
int-dest-id name
no int-dest-id
config>service>epipe>pw-port>egress>shaper
This command configures an intermediate destination identifier applicable to ESM PW SAPs.
N/A
name — Specifies the default intermediate destination identifier, up to 32 characters in
length, on the egress side for this PW-port entry.
vport
Syntax
Context
Description
Default
Parameters
Issue: 01
vport vport
no vport
config>service>epipe>pw-port>egress>shaper
This command configures specifies the virtual port name of the shaper on the egress side for
this PW-port entry.
N/A
vport — Specifies a virtual port applicable to all PW SAPs.
3HE 11970 AAAA TQZZA 01
263
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
monitor-oper-group
Syntax
Context
Description
Default
Parameters
monitor-oper-group group-name
no monitor-oper-group
config>service>epipe>pw-port
This command configures the monitoring operational group name, up to 32 characters in
length, associated with this PW-port entry.
N/A
group-name — Specifies an operational group to monitor.
signaled-vc-type-override
Syntax
Context
Description
signaled-vc-type-override {atm-vcc}
no signaled-vc-type-override
<root>
This command overrides the pseudowire type signaled to type 0x0009 N:1 VCC cell within
an Apipe VLL service of vc-type atm-cell. Normally, this service vc-type signals a pseudowire
of type 0x0003 ATM Transparent Cell.
This command is not allowed in an Apipe VLL of vc-type value atm-cell if a configured ATM
SAP is not using a connection profile. Conversely, if the signaling override command is
enabled, only an ATM SAP with a connection profile assigned will be allowed.
The override command is not allowed on Apipe VLL service of vc-type value other than atmcell. It is also not allowed on a VLL service with the vc-switching option enabled since
signaling of the PW FEC in a Multi-Segment PW (MS-PW) is controlled by the T-PE nodes.
Thus for this feature to be used on a MS-PW, it is required to configure an Apipe service of
vc-type atm-cell at the T-PE nodes with the signaled-vc-type-override enabled, and to
configure a Apipe VLL service of vc-type atm-vcc at the S-PE node with the vc-switching
option enabled.
The no form of this command returns the Apipe VLL service to signal its default pseudowire
type
Default
Parameters
none
atm-vcc — Specifies the pseudowire type to be signaled in the pseudowire
establishment
connection-profile
Syntax
264
connection-profile conn-prof-id [create]
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
no connection-profile conn-prof-id
Context
Description
<root>
This command creates a profile for the user to configure the list of discrete VPI/VCI values to
be assigned to an ATM SAP of an Apipe VLL of vc-type atm-cell.
A connection profile can only be applied to a SAP which is part of an Apipe VLL service of
vc-type atm-cell. The ATM SAP can be on a regular port or APS port.
A maximum of 8000 connection profiles can be created on the system.
The no form of this command deletes the profile from the configuration.
Default
Parameters
none
conn-prof-id — Specifies the profile number.
Values
1 to 8000
member
Syntax
Context
Description
member encap-value [create]
no member encap-value
config>connection-profile
This command allows the adding of discrete VPI/VCI values to an ATM connection profile for
assignment to an ATM SAP of an Apipe VLL of vc-type atm-cell.
Up to a maximum of 16 discrete VPI/VCI values can be configured in a connection profile.
The user can modify the content of a profile which triggers a re-evaluation of all the ATM
SAPs which are currently using the profile.
The no form of this command deletes the member from the configuration.
Default
Parameters
none
encap-value — Specifies the VPI and VCI values of this connection profile member.
Values
vpi: NNI: 0 to 4095
UNI: 0 to 255
vci: 1, 2, 5 to 65535
Issue: 01
3HE 11970 AAAA TQZZA 01
265
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
2.17.2.4
VLL SAP Commands
sap
Syntax
Context
Description
sap sap-id [create] [no-endpoint]
sap sap-id [create] endpoint endpoint-name
no sap sap-id
config>service>apipe
config>service>cpipe
config>service>fpipe
config>service>ipipe
config>service>epipe
This command creates a Service Access Point (SAP) within a service. A SAP is a
combination of port and encapsulation parameters which identifies the service access point
on the interface and within the device. Each SAP must be unique.
All SAPs must be explicitly created. If no SAPs are created within a service or on an IP
interface, a SAP will not exist on that object.
Enter an existing SAP without the create keyword to edit SAP parameters. The SAP is owned
by the service in which it was created.
A SAP can only be associated with a single service. A SAP can only be defined on a port that
has been configured as an access port. Channelized TDM ports are always access ports.
If a port is shutdown, all SAPs on that port become operationally down. When a service is
shutdown, SAPs for the service are not displayed as operationally down although all traffic
traversing the service will be discarded.
The operational state of a SAP is relative to the operational state of the port on which the SAP
is defined.
The following are supported on the 7750 SR only:
• ATM VPI/VCI on an ATM port for vc-type atm-vcc and atm-sdu
• ATM VPI on an ATM port for vc-type atm-vpc
• ATM virtual trunk - a range of VPIs on an ATM port for vc-type atm-cell
• ATM port for vc-type atm-cell
• ATM connection profile for vc-type atm-cell
• Frame Relay DLCI on a port for vc-type atm-sdu
• ATM SAP carries the IPv4 packet using RFC 2684, VC-Mux or LLC/SNAP routed PDU
encapsulation for an Ipipe service
• Frame Relay SAP RFC 2427, routed PDU encapsulation for an Ipipe service
• Ethernet SAP RFC 1332, PPP IPCP encapsulation of an IPv4 packet for an Ipipe service
266
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
• Ethernet SAP HDLC SAP uses the routed IPv4 encapsulation for an Ipipe service
• ATM - Frame Relay, PPP/IPCP - PPP/IPCP
• Frame Relay-Frame Relay, ATM - ATM
• Ethernet-Ethernet
• cHDLC-cHDLC
• An ATM SAP can be part of an IMA bundle.
• A PPP SAP can be part of an MLPPP bundle.
• A FR SAP can be part of a MLFR bundle.
Ethernet SAPs support null, dot1q, and qinq is supported for all routers.
The no form of this command deletes the SAP with the specified port. When a SAP is deleted,
all configuration parameters for the SAP will also be deleted. For Internet Enhanced Service
(IES), the IP interface must be shutdown before the SAP on that interface may be removed.
Default
Special Cases
No SAPs are defined
Special Cases — A SAP can be defined with Ethernet ports, SONET/SDH or TDM
channels. At most, only one sdp-id can be bound to an VLL service. Since a VLL is
a point-to-point service, it can have, at most, two end points. The two end points can
be one SAP and one SDP or two SAPs. Up to 49 SDPs can be associated with a
service in a single router. Each SDP must have a unique router destination or an error
will be generated.
A default SAP has the following format: port-id:*. This type of SAP is supported only
on Ethernet MDAs and its creation is allowed only in the scope of Layer 2 services
(Epipe and VPLS). This type of SAP is mutually exclusive with a SAP defined by
explicit null encapsulation (for example, 1/1/1:0).
Two Frame Relay SAPs cannot be configured on an Apipe service on the 7750 SR.
The limitation is for an Apipe service in local mode, which has two SAPs associated
with the service, as opposed to a configuration with a SAP and a SDP in remote case,
the only combination of the type of SAPs allowed is either two ATM SAPs or an ATM
SAP and a Frame Relay SAP. The CLI prevents adding two Frame Relay SAPs
under an Apipe service.
Parameters
sap-id — Specifies the physical port identifier portion of the SAP.
port-id — Specifies the physical port ID.
If the card in the slot has Media Dependent Adapters (MDAs) installed, the port-id
must be in the slot_number/MDA_number/port_number format. For example 6/2/3
specifies port 3 on MDA 2 in slot 6.
The port-id must reference a valid port type. When the port-id parameter represents
SONET/SDH and TDM channels, the port ID must include the channel ID. A period
“.” separates the physical port from the channel-id. The port must be configured as
an access port.
If the SONET/SDH port is configured as clear-channel then only the port is specified.
port-id
slot/mda/port [.channel]
eth-sat-id
Issue: 01
esat-id/slot/port
3HE 11970 AAAA TQZZA 01
267
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
pxc-id
esat
keyword
id
1 to 20
pxc-id.sub-port
pxc
keyword
id
1 to 64
sub-port
a, b
endpoint — Adds a SAP endpoint association.
no endpoint — Removes the association of a SAP or a spoke SDP with an explicit
endpoint name.
create — Keyword used to create a SAP instance. The create keyword requirement can
be enabled/disabled in the environment>create context.
Output
Sample Output
*A:bksim2801>config>service>apipe>sap$
=================================================================
ATM PVCs, Port 1/1/1
=================================================================
VPI/VCI
Owner
Type
Ing.TD
Egr.TD Adm OAM
Opr
----------------------------------------------------------------2/102
SAP
PVC
1
1
up
ETE-AIS dn
10/100
SAP
PVC
1
1
up
ETE-AIS dn
=================================================================
*A:bksim2801#
sap
Syntax
Context
Description
[no] sap eth-tunnel-tunnel-id[:eth-tunnel-sap-id] [create]
config>service>epipe
config>service>ipipe
config>service>vpls
This command configures an Ethernet tunnel SAP.
An Ethernet tunnel control SAP has the format eth-tunnel-tunnel-id and is not configured with
an Ethernet tunnel SAP ID. No Ethernet tunnel tags can be configured under a control SAP
since the control SAP uses the control tags configured under the Ethernet tunnel port. This
means that at least one member port and control tag must be configured under the Ethernet
tunnel port before this command is executed. The control SAP is needed for carrying G.8031
and 802.1ag protocol traffic. This SAP can also carry user data traffic.
268
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
An Ethernet tunnel same-fate SAP has the format eth-tunnel-tunnel-id:eth-tunnel-sap-id.
Same-fate SAPs carry only user data traffic. Multiple same-fate SAPs can be configured on
one Ethernet tunnel port and share the fate of that port, provided the SAPs are properly
configured with corresponding tags.
Ethernet tunnel SAPs are supported under VPLS, Epipe and Ipipe services only.
Default
Parameters
no sap
tunnel-id — Specifies the tunnel ID.
Values
1 to 1024
eth-tunnel-sap-id — Specifies a SAP ID of a same-fate SAP.
Values
0 to 4094
aarp
Syntax
Context
Description
aarp aarpId type type
no aarp
config>service>epipe>sap
config>service>epipe>spoke-sdp
This command associates an AARP instance with a multi-homed SAP or spoke SDP. This
instance uses the same AARP ID in the same node to provide traffic flow and packet
asymmetry removal for a multi-homed SAP or spoke SDP.
The type specifies the role of this service point in the AARP: either, primary (dual-homed) or
secondary (dual-homed-secondary). The AA service attributes (app-profile and transit-policy)
of the primary are inherited by the secondary endpoints. All endpoints within an AARP must
be of the same type (SAP or spoke), and all endpoints with an AARP must be within the same
service.
The no form of the command removes the association between an AARP instance and a
multi-homed SAP or spoke SDP.
Default
Parameters
no aarp
aarpid — Specifies the AARP instance associated with this SAP. If not configured, no
AARP instance is associated with this SAP.
Values
1 to 65535
type — Specifies the role of the SAP referenced by the AARP instance.
Values
Issue: 01
dual-homed — The primary dual-homed AA subscriber side
service-point of an AARP instance; only supported for Epipe, IES,
and VPRN SAP and spoke SDP.
3HE 11970 AAAA TQZZA 01
269
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
dual-homed-secondary — One of the secondary dual-homed AA
subscriber side service-points of an AARP instance; only supported
for Epipe, IES, and VPRN SAP and spoke SDP.
lag-link-map-profile
Syntax
Context
Description
lag-link-map-profile link-map-profile-id
no lag-link-map-profile
config>service>epipe>sap
config>service>ipipe>sap
This command assigns a pre-configured lag link map profile to a SAP/network interface
configured on a LAG or a PW port that exists on a LAG. Once assigned/de-assigned, the
SAP’s/network interface’s egress traffic will be re-hashed over LAG as required by the new
configuration.
The no form of this command reverts the SAP/network interface to use per-flow, service or
link hash as configured for the service/LAG.
Default
Parameters
no lag-link-map-profile
link-map-profile-id — An integer from 1 to 64 that defines a unique lag link map profile on
the LAG the SAP/network interface exists on.
lag-per-link-hash
Syntax
Context
Description
lag-per-link-hash class {1 | 2 | 3} weight [1 to 1024]
no lag-per-link-hash
config>service>epipe>sap
config>service>ipipe>sap
config>service>vpls>sap
config>service>ies>if>sap
config>service>vprn>if>sap
config>service>ies>sub-if>grp-if>sap
config>service>vprn>sub-if>grp-if>sap
This command configures weight and class to this SAP to be used on LAG egress when the
LAG uses weighted per-link-hash.
The no form of this command restores default configuration.
Default
270
no lag-per-link-hash (equivalent to weight 1 class 1)
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
monitor-oper-group
Syntax
Context
Description
monitor-oper-group group-name
no monitor-oper-group
config>service>if
config>service>ies>spoke-sdp
config>service>ies>sap
This command specifies the operational group to be monitored by the object under which it
is configured. The oper-group name must be already configured under the config>service
context before its name is referenced in this command.
The no form of the command removes the association.
agg-rate
Syntax
Context
Description
[no] agg-rate
config>service>apipe>sap>egress
config>service>cpipe>sap>egress
config>service>epipe>sap>egress
config>service>fpipe>sap>egress
config>service>ipipe>sap>egress
This command is used to control an HQoS aggregate rate limit. It is used in conjunction with
the following parameter commands: rate, limit-unused-bandwidth, and queue-framebased-accounting.
rate
Syntax
Context
rate kilobits-per-second
no rate
config>service>apipe>sap>egress>agg-rate
config>service>cpipe>sap>egress>agg-rate
config>service>epipe>sap>egress>agg-rate
config>service>fpipe>sap>egress>agg-rate
config>service>ipipe>sap>egress>agg-rate
Description
This command defines the enforced aggregate rate for all queues associated with the aggrate context. A rate must be specified for the agg-rate context to be considered to be active
on the context’s object (SAP, subscriber, Vport, and so on).
Parameters
kilobits-per-second — The enforced aggregate rate for all queues associated with the
agg-rate context, in kilobits per second.
Values
Issue: 01
1 to 3200000000 | max
3HE 11970 AAAA TQZZA 01
271
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
limit-unused-bandwidth
Syntax
Context
Description
[no] limit-unused-bandwidth
config>service>apipe>sap>egress>agg-rate
config>service>cpipe>sap>egress>agg-rate
config>service>epipe>sap>egress>agg-rate
config>service>fpipe>sap>egress>agg-rate
config>service>ipipe>sap>egress>agg-rate
This command is used to enable (or disable) aggregate rate overrun protection on the aggrate context.
queue-frame-based-accounting
Syntax
Context
Description
[no] queue-frame-based-accounting
config>service>apipe>sap>egress>agg-rate
config>service>cpipe>sap>egress>agg-rate
config>service>fpipe>sap>egress>agg-rate
config>service>ipipe>sap>egress>agg-rate
This command is used to enable (or disable) frame based accounting on all policers and
queues associated with the agg-rate context.
The command is supported on Ethernet ports only; it is not supported on HSMDA Ethernet
ports.
Packet byte offset settings are not included in the applied rate when queue frame based
accounting is configured; however the offsets are applied to the statistics.
policer-control-override
272
Syntax
policer-control-override [create]
no policer-control-override
Context
config>service>apipe>sap>egress
config>service>apipe>sap>ingress
config>service>cpipe>sap>egress
config>service>cpipe>sap>ingress
config>service>epipe>sap>egress
config>service>epipe>sap>ingress
config>service>fpipe>sap>egress
config>service>fpipe>sap>ingress
config>service>ipipe>sap>egress
config>service>ipipe>sap>ingress
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
Description
VLL Services
This command, within the SAP ingress or egress contexts, creates a CLI node for specific
overrides to the applied policer-control-policy. A policy must be applied for a policer-controloverrides node to be created. If the policer-control-policy is removed or changed, the policercontrol-overrides node is automatically deleted from the SAP.
The no form of the command removes any existing policer-control-policy overrides and the
policer-control-overrides node from the SAP.
Default
Parameters
no policer-control-override
create — The create keyword is required when the policer-control-overrides node is
being created and the system is configured to expect explicit confirmation that a new
object is being created. When the system is not configured to expect explicit
confirmation, the create keyword is not required.
max-rate
Syntax
Context
Description
max-rate {rate | max}
config>service>apipe>sap>egress>policer-control-override
config>service>apipe>sap>ingress>policer-control-override
config>service>cpipe>sap>egress>policer-control-override
config>service>cpipe>sap>ingress>policer-control-override
config>service>epipe>sap>egress>policer-control-override
config>service>epipe>sap>ingress>policer-control-override
config>service>fpipe>sap>egress>policer-control-override
config>service>fpipe>sap>ingress>policer-control-override
config>service>ipipe>sap>egress>policer-control-override
config>service>ipipe>sap>ingress>policer-control-override
This command, within the SAP ingress and egress contexts, overrides the root arbiter parent
policer max-rate that is defined within the policer-control-policy applied to the SAP.
When the override is defined, modifications to the policer-control-policy max-rate parameter
have no effect on the SAP’s parent policer until the override is removed using the no maxrate command within the SAP.
Parameters
rate — Specifies the rate override in kilobits per second.
Values
1 to 2000000000
max — Specifies the maximum rate override.
priority-mbs-thresholds
Syntax
Context
Issue: 01
priority-mbs-thresholds
config>service>apipe>sap>egress>policer-control-override
config>service>apipe>sap>ingress>policer-control-override
3HE 11970 AAAA TQZZA 01
273
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
config>service>cpipe>sap>egress>policer-control-override
config>service>cpipe>sap>ingress>policer-control-override
config>service>epipe>sap>egress>policer-control-override
config>service>epipe>sap>ingress>policer-control-override
config>service>fpipe>sap>egress>policer-control-override
config>service>fpipe>sap>ingress>policer-control-override
config>service>ipipe>sap>egress>policer-control-override
config>service>ipipe>sap>ingress>policer-control-override
Description
This command overrides the CLI node contains the configured min-thresh-separation and the
various priority level mbs-contribution override commands.
min-thresh-separation
Syntax
Context
Description
min-thresh-separation size [bytes | kilobytes]
config>service>apipe>sap>egress>policer-control-override>priority-mbs-threshold
config>service>apipe>sap>ingress>policer-control-override>priority-mbs-threshold
config>service>cpipe>sap>egress>policer-control-override>priority-mbs-threshold
config>service>cpipe>sap>ingress>policer-control-override>priority-mbs-threshold
config>service>epipe>sap>egress>policer-control-override>priority-mbs-threshold
config>service>epipe>sap>ingress>policer-control-override>priority-mbs-threshold
config>service>fpipe>sap>egress>policer-control-override>priority-mbs-threshold
config>service>fpipe>sap>ingress>policer-control-override>priority-mbs-threshold
config>service>ipipe>sap>egress>policer-control-override>priority-mbs-threshold
config>service>ipipe>sap>ingress>policer-control-override>priority-mbs-threshold
This command, within the SAP ingress and egress contexts, is used to override the root
arbiter’s parent policer min-thresh-separation parameter that is defined within the policercontrol-policy applied to the SAP.
When the override is defined, modifications to the policer-control-policy min-threshseparation parameter have no effect on the SAP’s parent policer until the override is removed
using the no min-thresh-separation command within the SAP.
The no form of the command removes the override and allows the min-thresh-separation
setting from the policer-control-policy to control the root arbiter’s parent policer’s minimum
discard threshold separation size.
Default
Parameters
no min-thresh-separation
size — The minimum discard threshold separation override value.
Values
1 to 16777216 | default
bytes — Signifies that size is expressed in bytes. The bytes and kilobytes keywords are
mutually exclusive and optional. The default is kilobytes.
kilobytes — Signifies that size is expressed in kilobytes. The bytes and kilobytes
keywords are mutually exclusive and optional. The default is kilobytes.
274
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
priority
Syntax
Context
Description
[no] priority level
config>service>apipe>sap>egress>policer-control-override>priority-mbs-threshold
config>service>apipe>sap>ingress>policer-control-override>priority-mbs-threshold
config>service>cpipe>sap>egress>policer-control-override>priority-mbs-threshold
config>service>cpipe>sap>ingress>policer-control-override>priority-mbs-threshold
config>service>epipe>sap>egress>policer-control-override>priority-mbs-thresholds
config>service>epipe>sap>ingress>policer-control-override>priority-mbs-thresholds
config>service>fpipe>sap>egress>policer-control-override>priority-mbs-threshold
config>service>fpipe>sap>ingress>policer-control-override>priority-mbs-threshold
config>service>ipipe>sap>egress>policer-control-override>priority-mbs-threshold
config>service>ipipe>sap>ingress>policer-control-override>priority-mbs-threshold
The priority-level level override CLI node contains the specified priority level’s mbscontribution override value.
This node does not need to be created and will not be output in show or save configurations
unless an mbs-contribution override exist for level.
Parameters
level — The level parameter is required when specifying priority-level and identifies
which of the parent policer instances priority level’s the mbs-contribution is
overriding.
Values
1 to 8
mbs-contribution
Syntax
mbs-contribution size [bytes | kilobytes]
Context
config>service>apipe>sap>egress>policer-control-override>priority-mbs-threshold>priority
config>service>apipe>sap>ingress>policer-control-override>priority-mbs-threshold>priority
config>service>cpipe>sap>egress>policer-control-override>priority-mbs-threshold>priority
config>service>cpipe>sap>ingress>policer-control-override>priority-mbs-threshold>priority
config>service>epipe>sap>egress>policer-control-override>priority-mbs-threshold>priority
config>service>epipe>sap>ingress>policer-control-override>priority-mbs-threshold>priority
config>service>fpipe>sap>egress>policer-control-override>priority-mbs-threshold>priority
config>service>fpipe>sap>ingress>policer-control-override>priority-mbs-threshold>priority
config>service>ipipe>sap>egress>policer-control-override>priority-mbs-threshold>priority
config>service>ipipe>sap>ingress>policer-control-override>priority-mbs-threshold>priority
Description
The mbs-contribution override command within the SAP ingress and egress contexts is used
to override a parent policer’s priority level’s mbs-contribution parameter that is defined within
the policer-control-policy applied to the SAP. This override allow the priority level’s burst
tolerance to be tuned based on the needs of the SAP’s child policers attached to the priority
level.
Issue: 01
3HE 11970 AAAA TQZZA 01
275
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
When the override is defined, modifications to the policer-control-policy priority level’s mbscontribution parameter have no effect on the SAP’s parent policer priority level until the
override is removed using the no mbs-contribution command within the SAP.
The no form of the command removes the override and allows the mbs-contribution setting
from the policer-control-policy to control the parent policer’s priority level’s burst tolerance.
Default
Parameters
no mbs-contribution
size — The mbs-contribution override value.
Values
1 to 16777216 | default
bytes — Signifies that size is expressed in bytes. The bytes and kilobytes keywords are
mutually exclusive and optional. The default is kilobytes.
kilobytes — Signifies that size is expressed in kilobytes. The bytes and kilobytes
keywords are mutually exclusive and optional. The default is kilobytes.
policer-control-policy
Syntax
Context
Description
policer-control-policy policy-name [create]
no policer-control-policy
config>service>apipe>sap>egress
config>service>apipe>sap>ingress
config>service>fpipe>sap>egress
config>service>fpipe>sap>ingress
config>service>epipe>sap>egress
This command, within the QoS CLI node, is used to create, delete or modify policer control
policies. A policer control policy is very similar to the scheduler-policy which is used to
manage a set of queues by defining a hierarchy of virtual schedulers and specifying how the
virtual schedulers interact to provide an aggregate SLA. In a similar fashion, the policercontrol-policy controls the aggregate bandwidth available to a set of child policers. Once
created, the policy can be applied to ingress or egress SAPs.
Policer Control Policy Instances
On the SAP side, an instance of a policy is created each time a policy is applied.
When applied to a sub-profile on a 7450 ESS and 7750 SR, an instance of the policy is
created each time a subscriber successfully maps one or more hosts to the profile per ingress
SAP.
Each instance of the policer-control-policy manages the policers associated with the object
that owns the policy instance (SAP or subscriber). If a policer on the object is parented to an
appropriate arbiter name that exists within the policy, the policer will be managed by the
instance. If a policer is not parented or is parented to a non-existent arbiter, the policer will be
orphaned and will not be subject to bandwidth control by the policy instance.
276
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
Maximum Rate and Root Arbiter
The policer-control-policy supports an overall maximum rate (max-rate) that defines the total
amount of bandwidth that may be distributed to all associated child policers. By default, that
rate is set to max which provides an unlimited amount of bandwidth to the policers. Once the
policy is created, an actual rate should be configured in order for the policy instances to be
effective. At the SAP level, the maximum rate may be overridden on a per instance basis.
For subscribers, the maximum rate may only be overridden on the subscriber profile which
will then be applied to all instances associated with the profile.
The maximum rate is defined within the context of the root arbiter which is always present in
a policer-control-policy. The system creates a parent policer which polices the output of all
child policers attached to the policy instance to the configured rate. Child policers may be
parented directly to the root arbiter (parent root) or parented to one of the tiered arbiters
(parent arbiter-name). Since each tiered arbiter must be parented to either another tiered
arbiter or the root arbiter (default), every parented child policer is associated with the root
arbiter and thus the root arbiter’s parent policer.
Parent Policer PIR Leaky Bucket Operation
The parent policer is a single leaky bucket that monitors the aggregate throughput rate of the
associated child policers. Forwarded packets increment the bucket by the size of each
packet. The rate of the parent policer is implemented as a bucket decrement function which
attempts to drain the bucket. If the rate of the packets flowing through the bucket is less than
the decrement rate, the bucket does not accumulate depth. Each packet that flows through
the bucket is accompanied by a derived discard threshold. If the current depth of the bucket
is less than the discard threshold, the packet is allowed to pass through, retaining the colors
derived from the packet’s child policer. If the current depth is equal to or greater than the
threshold value, the packet is colored red and the bucket depth is not incremented by the
packet size. Also, any increased bucket depths in the child policer are canceled making any
discard event an atomic function between the child and the parent.
Due to the fact that multiple thresholds are supported by the parent policer, the policer control
policy is able to protect the throughput of higher priority child policers from the throughput of
the lower priority child policers within the aggregate rate.
Tier 1 and Tier 2 Arbiters
As stated above, each child is attached either to the always available root arbiter or to an
explicitly created tier 1 or tier 2 arbiter. Unlike the hardware parent policer based root arbiter,
the arbiters at tier 1 and tier 2 are only represented in software and are meant to provide an
arbitrary hierarchical bandwidth distribution capability. An arbiter created on tier 2 must
parent to either to an arbiter on tier 1 or to the root arbiter. Arbiters created on tier 1 always
parent to the root arbiter. In this manner, every arbiter ultimately is parented or grandparented by the root arbiter.
Issue: 01
3HE 11970 AAAA TQZZA 01
277
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
Each tiered arbiter supports an optional rate parameter that defines a rate limit for all child
arbiters or child policers associated with the arbiter. Child arbiters and policers attached to
the arbiter have a level attribute that defines the strict level at which the child is given
bandwidth by the arbiter. Level 8 is the highest and 1 is the lowest. Also a weight attribute
defines each child’s weight at that strict level in order to determine how bandwidth is
distributed to multiple children at that level when insufficient bandwidth is available to meet
each child’s required bandwidth.
Fair and Unfair Bandwidth Control
Each child policer supports three leaky buckets. The PIR bucket manages the policer’s peak
rate and maximum burst size, the CIR leaky bucket manages the policer’s committed rate and
committed burst size. The third leaky bucket is used by the policer control policy instance to
manage the child policer’s fair rate (FIR). When multiple child policers are attached to the root
arbiter at the same priority level, the policy instance uses each child’s FIR bucket rate to
control how much of the traffic forwarded by the policer is fair and how much is unfair.
In the simplest case where all the child policers in the same priority level are directly attached
to the root arbiter, each child’s FIR rate is set according to the child’s weight divided by the
sum of the active children’s weights multiplied by the available bandwidth at the priority level.
The result is that the FIR bucket will mark the appropriate amount of traffic for each child as
fair-based on the weighted fair output of the policy instance.
The fair/unfair forwarding control in the root parent policer is accomplished by implementing
two different discard thresholds for the priority. The first threshold is discard-unfair and the
second is discard-all for packet associated with the priority level. As the parent policer PIR
bucket fills (due the aggregate forwarded rate being greater than the parent policers PIR
decrement rate) and the bucket depth reaches the first threshold, all unfair packets within the
priority are discarded. This leaves room in the bucket for the fair packets to be forwarded.
In the more complex case where one or more tiered arbiters are attached at the priority level,
the policer control policy instance must consider more than just the child policer weights
associated with the attached arbiter. If the arbiter is configured with an aggregate rate limit
that its children cannot exceed, the policer control policy instance will switch to calculating the
rate each child serviced by the arbiter should receive and enforces that rate using each child
policers PIR leaky bucket.
When the child policer PIR leaky bucket is used to limit the bandwidth for the child policer and
the child’s PIR bucket discard threshold is reached, packets associated with the child policer
are discarded. The child policer’s discarded packets do not consume depth in the child
policer’s CIR or FIR buckets. The child policers discarded packets are also prevented from
impacting the parent policer and will not consume the aggregate bandwidth managed by the
parent policer.
Parent Policer Priority Level Thresholds
278
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
As stated above, each child policer is attached either to the root arbiter or explicitly to one of
the tier 1 or tier 2 arbiters. When attached directly to the root arbiter, its priority relative to all
other child policers is indicated by the parenting level parameter. When attached through one
of the tiered arbiters, the parenting hierarchy of the arbiters must be traced through to the
ultimate attachment to the root arbiter. The parenting level parameter of the arbiter parented
to the root arbiter defines the child policer’s priority level within the parent policer.
The priority level is important since it defines the parent policer discard thresholds that will be
applied at the parent policer. The parent policer has 8 levels of strict priority and each priority
level has its own discard-unfair and discard-all thresholds. Each priority’s thresholds are
larger than the thresholds of the lower priority levels. This ensures that when the parent
policer is discarding, it will be priority sensitive.
To visualize the behavior of the parent policer, picture that when the aggregate forwarding
rate of all child policers is currently above the decrement rate of the parent PIR leaky bucket,
the bucket depth will increase over time. As the bucket depth increases, it will eventually
cross the lowest priority’s discard-unfair threshold. If this amount of discard sufficiently lowers
the remaining aggregate child policer rate, the parent PIR bucket will hover around this
bucket depth. If however, the remaining aggregate child rate is still greater than the
decrement rate, the bucket will continue to rise and eventually reach the lowest priority’s
discard-all threshold which will cause all packets associated with the priority level to be
discarded (fair and unfair). Again, if the remaining aggregate child rate is less than or equal
to the bucket decrement rate, the parent PIR bucket will hover around this higher bucket
depth. If the remaining aggregate child rate is still higher than the decrement rate, the bucket
will continue to rise through the remaining priority level discards until equilibrium is achieved.
As noted above, each child’s rate feeding into the parent policer is governed by the child
policer’s PIR bucket decrement rate. The amount of bandwidth the child policer offers to the
parent policer will not exceed the child policer’s configured maximum rate.
Root Arbiter’s Parent Policer’s Priority Aggregate Thresholds
Each policer-control-policy root arbiter supports configurable aggregate priority thresholds
which are used to control burst tolerance within each priority level. Two values are maintained
per priority level; the shared-portion and the fair-portion. The shared-portion represents the
amount of parent PIR bucket depth that is allowed to be consumed by both fair and unfair
child packets at the priority level. The fair-portion represents the amount of parent PIR bucket
depth that only the fair child policer packets may consume within the priority level. It should
be noted that the fair and unfair child packets associated with a higher parent policer priority
level may also consume the bucket depth set aside for this priority.
While the policy maintains a parent policer default or explicit configurable values for sharedportion and fair-portion within each priority level, it is possible that some priority levels will not
be used within the parent policer. Most parent policer use cases require fewer than eight strict
priority levels.
Issue: 01
3HE 11970 AAAA TQZZA 01
279
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
In order to derive the actual priority level discard-unfair and discard-all thresholds while only
accounting for the actual in-use priority levels, the system maintains a child policer to parent
policer association counter per priority level for each policer control policy instance. As a child
policer is parented to either the root or a tiered arbiter, the system determines the parent
policer priority level for the child policer and increments the association counter for that
priority level on the parent policer instance.
The shared-portion for each priority level is affected by the parent policer global min-threshseparation parameter that defines the minimum separation between any in-use discard
thresholds. When more than one child policer is associated with a parent policer priority level,
the shared-portion for that priority level will be the current value of min-thresh-separation.
When only a single child policer is associated, the priority level’s shared-portion is zero since
all packets from the child will be marked fair and the discard-unfair threshold is meaningless.
When the association counter is zero, both the shared-portion and the fair-portion for that
priority level are zero since neither discard thresholds will be used. Whenever the association
counter is greater than 0, the fair-portion for that priority level will be derived from the current
value of the priority’s mbs-contribution parameter and the global min-thresh-separation
parameter.
Each priority level’s discard-unfair and discard-all thresholds are calculated based on an
accumulation of lower priorities shared-portions and fair-portions and the priority level’s own
shared-portion and fair-portion. The base threshold value for each priority level is equal to the
sum of all lower priority level’s shared-portions and fair-portions. The discard-unfair threshold
is the priority level’s base threshold plus the priority level’s shared-portion. The discard-all
threshold for the priority level is the priority level’s base threshold plus both the shared-portion
and fair-portion values of the priority. As can be seen, an in-use priority level’s thresholds are
always greater than the thresholds of lower priority levels.
Policer Control Policy Application
A policer-control-policy may be applied on any Ethernet ingress or egress SAP that is
associated with a port (or ports in the case of LAG).
The no form of the command removes a non-associated policer control policy from the
system. The command will not execute when policer-name is currently associated with any
SAP context.
Default
Parameters
none
policy-name — Each policer-control-policy must be created with a unique policy name.
The name must given as policy-name must adhere to the system policy ASCII
naming requirements. If the defined policy-name already exists, the system will enter
that policy’s context for editing purposes. If policy-name does not exist, the system
will attempt to create a policy with the specified name. Creating a policy may require
use of the create parameter when the system is configured for explicit object creation
mode.
create — The keyword is required when a new policy is being created and the system is
configured for explicit object creation mode.
280
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
policer-override
Syntax
Context
Description
[no] policer-override
config>service>apipe>sap>egress
config>service>apipe>sap>ingress
config>service>cpipe>sap>egress
config>service>cpipe>sap>ingress
config>service>epipe>sap>egress
config>service>epipe>sap>ingress
config>service>fpipe>sap>egress
config>service>fpipe>sap>ingress
config>service>ipipe>sap>egress
config>service>ipipe>sap>ingress
This command, within the SAP ingress or egress contexts, is used to create a CLI node for
specific overrides to one or more policers created on the SAP through the sap-ingress or sapegress QoS policies.
The no form of the command is used to remove any existing policer overrides.
Default
no policer-overrides
Syntax
policer policer-id [create]
no policer policer-id
policer
Context
Description
config>service>apipe>sap>egress>policer-override
config>service>apipe>sap>ingress>policer-override
config>service>cpipe>sap>egress>policer-override
config>service>cpipe>sap>ingress>policer-override
config>service>fpipe>sap>egress>policer-override
config>service>fpipe>sap>ingress>policer-override
config>service>ipipe>sap>egress>policer-override
config>service>ipipe>sap>ingress>policer-override
config>service>epipe>sap>egress>policer-override
This command, within the SAP ingress or egress contexts, is used to create a CLI node for
specific overrides to a specific policer created on the SAP through a sap-ingress or sapegress QoS policy.
The no form of the command is used to remove any existing overrides for the specified
policer-id.
Issue: 01
3HE 11970 AAAA TQZZA 01
281
VLL Services
Parameters
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
policer-id — The policer-id parameter is required when executing the policer command
within the policer-overrides context. The specified policer-id must exist within the
sap-ingress or sap-egress QoS policy applied to the SAP. If the policer is not
currently used by any forwarding class or forwarding type mappings, the policer will
not actually exist on the SAP. This does not preclude creating an override context for
the policer-id.
create — The create keyword is required when a policer policer-id override node is being
created and the system is configured to expect explicit confirmation that a new object
is being created. When the system is not configured to expect explicit confirmation,
the create keyword is not required.
cbs
Syntax
Context
Description
cbs size [{bytes | kilobytes}]
no cbs
config>service>apipe>sap>egress>policer-override>policer
config>service>apipe>sap>ingress>policer-override>policer
config>service>cpipe>sap>egress>policer-override>policer
config>service>cpipe>sap>ingress>policer-override>policer
config>service>ipipe>sap>egress>policer-override>policer
config>service>ipipe>sap>ingress>policer-override>policer
config>service>epipe>sap>egress>policer-override>policer
This command, within the SAP ingress and egress policer-overrides contexts, is used to
override the sap-ingress and sap-egress QoS policy configured CBS parameter for the
specified policer-id.
The no form of this command returns the CBS size to the default value.
Default
Parameters
no cbs
size — The size parameter is required when specifying cbs override and is expressed
as an integer representing the required size in either bytes or kilobytes. The default
is kilobytes. The optional byte and kilobyte keywords are mutually exclusive and are
used to explicitly define whether size represents bytes or kilobytes.
Values
0 to 16777216 | default
bytes — When bytes is defined, the value given for size is interpreted as the policer’s
MBS value in bytes.
kilobytes — When kilobytes is defined, the value given for size is interpreted as the
policer’s MBS value in kilobytes.
mbs
Syntax
282
mbs {size [bytes | kilobytes] | default}
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
no mbs
Context
Description
config>service>apipe>sap>egress>policer-override>policer
config>service>apipe>sap>ingress>policer-override>policer
config>service>cpipe>sap>egress>policer-override>policer
config>service>cpipe>sap>ingress>policer-override>policer
config>service>ipipe>sap>egress>policer-override>policer
config>service>ipipe>sap>ingress>policer-override>policer
config>service>epipe>sap>egress>policer-override>policer
config>service>epipe>sap>ingress>policer-override>policer
This command, within the SAP ingress and egress policer-overrides contexts, is used to
override the sap-ingress and sap-egress QoS policy configured mbs parameter for the
specified policer-id.
The no form of the command is used to restore the policer’s mbs setting to the policy defined
value.
Default
Parameters
no mbs
size — The size parameter is required when specifying mbs override and is expressed
as an integer representing the required size in either bytes or kilobytes. The default
is kilobytes. The optional byte and kilobyte keywords are mutually exclusive and are
used to explicitly define whether size represents bytes or kilobytes.
Values
0 to 16777216 | default
bytes — When bytes is defined, the value given for size is interpreted as the policer’s
MBS value in bytes.
kilobytes — When kilobytes is defined, the value given for size is interpreted as the
policer’s MBS value in kilobytes.
packet-byte-offset
Syntax
Context
Description
Issue: 01
packet-byte-offset {add add-bytes | subtract sub-bytes}
config>service>apipe>sap>egress>policer-override>policer
config>service>apipe>sap>ingress>policer-override>policer
config>service>cpipe>sap>egress>policer-override>policer
config>service>cpipe>sap>ingress>policer-override>policer
config>service>ipipe>sap>egress>policer-override>policer
config>service>ipipe>sap>ingress>policer-override>policer
config>service>epipe>sap>egress>policer-override>policer
This command, within the SAP ingress and egress policer-overrides contexts, is used to
override the sap-ingress and sap-egress QoS policy configured packet-byte-offset parameter
for the specified policer-id. Packet byte offset settings are not included in the applied rate
when (queue) frame based accounting is configured; however, the offsets are applied to the
statistics.
3HE 11970 AAAA TQZZA 01
283
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
The no packet-byte-offset command is used to restore the policer’s packet-byte-offset setting
to the policy defined value.
Default
Parameters
no packet-byte-offset
add-bytes — Specifies the number of bytes that are added to the size each packet
associated with the policer for rate metering, profiling and accounting purposes.
From the policer’s perspective, the maximum packet size is increased by the amount
being added to the size of each packet.
Values
1 to 31
sub-bytes — Specifies the number of bytes that are subtracted from the size of each
packet associated with the policer for rate metering, profiling and accounting
purposes. From the policer’s perspective, the maximum packet size is reduced by the
amount being subtracted from the size of each packet.
Values
1 to 64
percent-rate
Syntax
Context
percent-rate pir-percent [cir cir-percent]
no percent-rate
config>service>apipe>sap>egress>policer-override>policer
config>service>apipe>sap>ingress>policer-override>policer
config>service>cpipe>sap>egress>policer-override>policer
config>service>cpipe>sap>ingress>policer-override>policer
config>service>ipipe>sap>egress>policer-override>policer
config>service>ipipe>sap>ingress>policer-override>policer
config>service>epipe>sap>egress>policer-override>policer
Description
This command configures the percent rates (CIR and PIR) override.
Parameters
pir-percent — Specifies the policer’s PIR as a percentage of the policers’s parent arbiter
rate.
Values
0.01 to 100.00
Default
100.00
cir-percent — Specifies the policer’s CIR as a percentage of the policers’s parent arbiter
rate.
Values
0.00 to 100.00
percent-rate
Syntax
284
percent-rate pir-percent [cir cir-percent] [
no percent-rate
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
Context
Description
VLL Services
config>service>epipe>sap>egress>queue-override>queue
The percent-rate command within the SAP ingress and egress QoS policy enables supports
for a queue’s PIR and CIR rate to be configured as a percentage of the egress port’s line rate
or of its parent scheduler’s rate.
When the rates are expressed as a port-limit, the actual rates used per instance of the queue
will vary based on the port speed. For example, when the same QoS policy is used on a 1Gigabit and a 10-Gb Ethernet port, the queue’s rates will be 10 times greater on the 10 Gb
port due to the difference in port speeds. This enables the same QOS policy to be used on
SAPs on different ports without needing to use SAP based queue overrides to modify a
queue’s rate to get the same relative performance from the queue.
If the port’s speed changes after the queue is created, the queue’s PIR and CIR rates will be
recalculated based on the defined percentage value.
When the rates are expressed as a local-limit, the actual rates used per instance of the queue
are relative to the queue’s parent scheduler rate. This enables the same QOS policy to be
used on SAPs with different parent scheduler rates without needing to use SAP based queue
overrides to modify a queue’s rate to get the same relative performance from the queue.
If the parent scheduler rate changes after the queue is created, the queue’s PIR and CIR
rates will be recalculated based on the defined percentage value.
Queue rate overrides can only be specified in the form as configured in the QoS policy (a SAP
override can only be specified as a percent-rate if the associated QoS policy was also defined
as percent-rate). Likewise, a SAP override can only be specified as a rate (kbps) if the
associated QoS policy was also defined as a rate. Queue-overrides are relative to the limit
type specified in the QOS policy.
When no percent-rate is defined within a SAP ingress or egress queue-override, the queue
reverts to the defined shaping and CIR rates within the SAP ingress and egress QOS policy
associated with the queue.
Parameters
percent-of-line-rate — The percent-of-line-rate parameter is used to express the
queue’s shaping rate as a percentage of line rate. The line rate associated with the
queue’s port may dynamically change due to configuration or auto-negotiation. The
line rate may also be affected by an egress port scheduler defined max-rate.
pir-percent — Specifies the queue’s PIR as a percentage dependent on the use of the
port-limit or local-limit.
Values
0.01 to 100.00
Default
100.00
cir-percent — Specifies the queue’s CIR as a percentage dependent on the use of the
port-limit or local-limit.
Issue: 01
Values
0.00 to 100.00
Default
100.00
3HE 11970 AAAA TQZZA 01
285
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
rate
Syntax
Context
Description
rate {rate | max} [cir {rate | max}]
config>service>apipe>sap>egress>policer-override>policer
config>service>apipe>sap>ingress>policer-override>policer
config>service>cpipe>sap>egress>policer-override>policer
config>service>cpipe>sap>ingress>policer-override>policer
config>service>epipe>sap>egress>policer-override>policer
config>service>epipe>sap>ingress>policer-override>policer
config>service>ipipe>sap>egress>policer-override>policer
config>service>ipipe>sap>ingress>policer-override>policer
This command within the SAP ingress and egress policer-overrides contexts is used to
override the sap-ingress and sap-egress QoS policy configured rate parameters for the
specified policer-id.
The no rate command is used to restore the policy defined metering and profiling rate to a
policer.
Parameters
rate rate — Specifies the policer instance metering rate for the PIR leaky bucket, in
kilobits per second. The integer value is multiplied by 1000 to derive the actual rate
in bits per second.
Values
1 to 2000000000
cir rate — Specifies the overriding value for the policy-derived profiling rate of the policer,
in kilobits per second. The integer value is multiplied by 1000 to derive the actual rate
in bits per second.
Values
0 to 2000000000
max — Uses the maximum policer rate, equal to the maximum capacity of the card on
which the policer is configured. If the policer rate is set to a value larger than the
maximum rate possible for the card, then the PIR or CIR used is equivalent to max.
stat-mode
Syntax
Context
286
stat-mode stat-mode
no stat-mode
config>service>apipe>sap>egress>policer-override>policer
config>service>apipe>sap>ingress>policer-override>policer
config>service>cpipe>sap>egress>policer-override>policer
config>service>cpipe>sap>ingress>policer-override>policer
config>service>epipe>sap>egress>policer-override>policer
config>service>epipe>sap>ingress>policer-override>policer
config>service>fpipe>sap>egress>policer-override>policer
config>service>fpipe>sap>ingress>policer-override>policer
config>service>ipipe>sap>egress>policer-override>policer
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
config>service>ipipe>sap>ingress>policer-override>policer
Description
The SAP QoS policy’s policer stat-mode command is used to configure the forwarding plane
counters that allow offered, output, and discard accounting to occur for the policer. A policer
has multiple types of offered packets (for example, soft in-profile and out-of-profile from
ingress and hard in-profile and out-of-profile due to egress profile overrides) and each of
these offered types is interacting with the policers metering and profiling functions resulting
in colored output packets (green, yellow, and red). Due to the potentially large number of
egress policers, it is not economical to allocate counters in the forwarding plane for all
possible offered packet types and output conditions. Many policers will not be configured with
a CIR profiling rate and not all policers will receive explicitly re-profiled offered packets. The
stat-mode command allows provisioning of the number of counters each policer requires and
indicates how the offered packet types and output conditions should be mapped to the
counters.
While a no-stats mode is supported that prevents any packet accounting, the use of the
policer’s parent command requires that the policer’s stat-mode to be set at least to the
minimal setting so that offered statistics are available for the policer’s Fair Information Rate
(FIR) to be calculated.
Each time the policer’s stat mode is changed, any previous counter values are lost and any
new counters are set to zero.
Each mode uses a certain number of counters per policer instance that are allocated from the
forwarding plane’s policer counter resources.The total/allocated/free statistics can be viewed
by using the tools dump resource-usage card fp command. If insufficient counters exist to
implement a mode on any policer instance, the stat-mode change will fail and the previous
mode will continue unaffected for all instances of the policer.
The stat-mode setting defined for the policer in the QoS policy may be overridden on a SAP
where the policy is applied. If insufficient policer counter resources exist to implement the
override, the stat-mode override command will fail. The current active stat mode setting will
continue to be used by the policer.
The no stat-mode command attempts to return the policer’s stat-mode setting to minimal.
The command will fail if insufficient policer counter resources exist to implement minimal
where the QoS policer is currently applied and has a forwarding class mapping.
Refer to the 7750 SR OS Quality of Service Guide for detailed information about the
supported parameters for the policer stat-mode command.
ce-address
Syntax
Context
Issue: 01
ce-address ip-address
no ce-address
config>service>ipipe>sap
config>service>ipipe>spoke-sdp
3HE 11970 AAAA TQZZA 01
287
VLL Services
Description
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
This command specifies the IP address of the CE device associated with an Ipipe SAP or
spoke SDP. In the case of a SAP, it is the address of the CE device directly attached to the
SAP. For a spoke SDP, it is the address of the CE device reachable through that spoke SDP
(for example, attached to the SAP on the remote node). The address must be a host address
(no subnet addresses are accepted) as there must be only one CE device attached to an
Ipipe SAP. The CE address specified at one end of an Ipipe will be used in processing ARP
messages at the other endpoint, as the router acts as a proxy for ARP messages.
On a 7450 ESS, this command specifies the IP address of the CE device associated with an
Ipipe SAP. In the case of a SAP, it is the address of the CE device directly attached to the
SAP. The address must be a host address (no subnet addresses are accepted) as there must
be only one CE device attached to an Ipipe SAP. The CE address specified at one end of an
Ipipe will be used in processing ARP messages at the other endpoint, as the router acts as a
proxy for ARP messages.
Parameters
ip-address — Specifies the IP address of the CE device associated with an Ipipe SAP.
qinq-mark-top-only
Syntax
Context
Description
Default
[no] qinq-mark-top-only
config>service>cpipe>sap>egress
config>service>apipe>sap>egress
config>service>epipe>sap>egress
config>service>fpipe>sap>egress
config>service>apipe>sap>egress
When enabled (the encapsulation type of the access port where this SAP is defined as qinq),
the qinq-mark-top-only command specifies which P-bits/DEI bit to mark during packet
egress. When disabled, both set of P-bits/DEI bit are marked. When the enabled, only the Pbits/DEI bit in the top Q-tag are marked.
no qinq-mark-top-only
multi-service-site
Syntax
Context
288
multi-service-site customer-site-name
no multi-service-site
config>service>ipipe>sap
config>service>apipe>sap
config>service>cpipe>sap
config>service>fpipe>sap
config>service>epipe>sap
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
Description
VLL Services
This command associates the SAP with a customer-site-name. If the specified customer-sitename does not exist in the context of the service customer ID an error occurs and the
command will not execute. If customer-site-name exists, the current and future defined
queues on the SAP (ingress and egress) will attempt to use the scheduler hierarchies created
within customer-site-name as parent schedulers.
The no form of the command removes the SAP from any multi-service customer site the SAP
belongs to. Removing the site can cause existing or future queues to enter an orphaned state.
Default
Parameters
None
customer-site-name — The customer-site-name must exist in the context of the
customer-id defined as the service owner. If customer-site-name exists and local
scheduler policies have not been applied to the SAP, the current and future queues
defined on the SAP will look for their parent schedulers within the scheduler
hierarchies defined on customer-site-name.
Values
Any valid customer-site-name created within the context of the
customer-id.
ring-node
Syntax
ring-node ring-node-name
no ring-node
Context
config>service>epipe>sap
Description
This command configures a multi-chassis ring-node for this SAP.
The no form of the command removes the name from the configuration.
Default
none
transit-policy
Syntax
Context
Description
transit-policy {ip ip-aasub-policy-id | prefix prefix-aasub-policy-id}
no transit-policy
config>service>epipe>sap
config>service>epipe>spoke-sdp
This command associates an AA transit policy to the service. The transit IP policy must be
defined prior to associating the policy with a SAP in the config>application
assurance>group>policy>transit-ip-policy context.
Transit AA subscribers are managed by the system through this service policy, which
determines how transit subs are created and removed for that service.
The no form of the command removes the association of the policy to the service.
Issue: 01
3HE 11970 AAAA TQZZA 01
289
VLL Services
Default
Parameters
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
no transit-policy
ip-aasub-policy-id — Specifies an integer identifying an IP transit IP profile entry.
Values
1 to 65535
prefix-aasub-policy-id — Specifies an integer identifying a prefix transit profile entry.
Values
1 to 65535
use-broadcast-mac
Syntax
[no] use-broadcast-mac
Context
config>service>ipipe>sap
Description
This command enables the user of a of broadcast MAC on SAP.
An Ipipe VLL service with the ce-address-discovery command enabled forwards unicast IP
packets using the broadcast MAC address until the ARP cache is populated with a valid entry
for the CE IP and MAC addresses.
The no form of this command enables the user of a of broadcast MAC on SAP.
Default
no use-broadcast-mac
Syntax
[no] mac ieee-address
mac
Context
Description
config>service>ipipe>sap
This command assigns a specific MAC address to an Ipipe SAP.
The no form of this command returns the MAC address of the SAP to the default value.
Default
Parameters
The physical MAC address associated with the Ethernet interface where the SAP is
configured.
ieee-address — Specifies the 48-bit MAC address in the form aa:bb:cc:dd:ee:ff or aa-bbcc-dd-ee-ff where aa, bb, cc, dd, ee, and ff are hexadecimal numbers.
mac-refresh
Syntax
Context
290
mac-refresh refresh interval
no mac-refresh
config>service>ipipe>sap
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
Description
VLL Services
This command specifies the interval between ARP requests sent on this Ipipe SAP. When the
SAP is first enabled, an ARP request will be sent to the attached CE device and the received
MAC address will be used in addressing unicast traffic to the CE. Although this MAC address
will not expire while the Ipipe SAP is enabled and operational, it is verified by sending periodic
ARP requests at the specified interval.
The no form of this command restores mac-refresh to the default value.
Default
Parameters
14400
refresh interval — Specifies the interval, in seconds, between ARP requests sent on this
Ipipe SAP.
Values
0 to 65535
accounting-policy
Syntax
accounting-policy acct-policy-id
no accounting-policy
Context
config>service>apipe>sap
config>service>cpipe>sap
config>service>epipe>sap
config>service>fpipe>sap
config>service>ipipe
config>service>epipe>spoke-sdp
Description
This command creates the accounting policy context that can be applied to a SAP.
An accounting policy must be defined before it can be associated with a SAP. If the policy-id
does not exist, an error message is generated.
A maximum of one accounting policy can be associated with a SAP at one time. Accounting
policies are configured in the config>log context.
The no form of this command removes the accounting policy association from the SAP, and
the accounting policy reverts to the default.
Default
Parameters
Default accounting policy.
acct-policy-id — Enter the accounting policy-id as configured in the
config>log>accounting-policy context.
Values
1 to 99
app-profile
Syntax
Issue: 01
app-profile app-profile-name
no app-profile
3HE 11970 AAAA TQZZA 01
291
VLL Services
Context
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
config>service>epipe>sap
config>service>epipe>spoke-sdp
Description
This command configures the application profile name.
Parameters
app-profile-name — Specifies an existing application profile name configured in the
config>app-assure>group>policy context.
bandwidth
Syntax
Context
Description
bandwidth bandwidth
no bandwidth
config>service>epipe>spoke-sdp
config>service>fpipe>spoke-sdp
config>service>apipe>spoke-sdp
config>service>ipipe>spoke-sdp
config>service>cpipe>spoke-sdp
This command specifies the bandwidth to be used for VLL bandwidth accounting by the VLL
CAC feature.
The service manager keeps track of the available bandwidth for each SDP. The maximum
value is the sum of the bandwidths of all constituent LSPs in the SDP. The SDP available
bandwidth is adjusted by the user configured booking factor.
If an LSP consists of a primary and many secondary standby LSPs, then the bandwidth used
in the maximum SDP available bandwidth is that of the active path. Any change to and LSP
active path bandwidth will update the maximum SDP available bandwidth. Note however that
a change to any constituent LSP bandwidth due to re-signaling of the primary LSP path or the
activation of a secondary path which causes overbooking of the maximum SDP available
bandwidth causes a warning and a trap to be issued but no further action is taken. The
activation of a bypass or detour LSP in the path of the primary LSP does not change the
maximum SDP available bandwidth.
When the user binds a VLL service to this SDP, an amount of bandwidth equal to bandwidth
is subtracted from the SDP available bandwidth adjusted by the booking factor. When the
user deletes this VLL service binding from this SDP, an amount of bandwidth equal to
bandwidth is added back into the SDP available bandwidth.
If the total SDP available bandwidth when adding this VLL service is about to overbook, a
warning is issued and the binding is rejected. This means that the spoke SDP bandwidth does
not update the maximum SDP available bandwidth. In this case, the spoke SDP is put in
operational down state and a status message of “pseudowire not forwarding” is sent to the
remote SR-Series PE node. A trap is also generated. The service manager will not put the
spoke SDP into operational UP state until the user executes a shutdown command and then
a no-shutdown command of the spoke SDP and the bandwidth check succeeds. Thus, the
service manager will not automatically audit spoke SDPs subsequently to their creation to
check if bandwidth is available.
292
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
If the VLL service contains an endpoint with multiple redundant spoke SDPs, each spoke
SDP will have its bandwidth checked against the available bandwidth of the corresponding
SDP.
If the VLL service performs a pseudowire switching (VC switching) function, each spoke SDP
is separately checked for bandwidth against the corresponding SDP.
Note that this feature does not alter the way service packets are sprayed over multiple RSVP
LSPs, which are part of the same SDP. In other words, by default load balancing of service
packets occurs over the SDP LSPs based on service-id, or based on a hash of the packet
header if ingress SAP shared queuing is enabled. In both cases, the VLL bandwidth is not
checked against the selected LSP(s) available bandwidth but on the total SDP available
bandwidth. Thus, if there is a single LSP per SDP, these two match.
If class-forwarding is enabled on the SDP, VLL service packets are forwarded to the SDP
LSP which the packet forwarding class maps to, or if this is down to the default LSP. However,
the VLL bandwidth is not checked against the selected LSP available bandwidth but on the
total SDP available bandwidth. If there is a single LSP per SDP, these two match.
If a non-zero bandwidth is specified for a VLL service and attempts to bind the service to an
LDP or a GRE SDP, a warning is issued that CAC failed but the VLL is established. A trap is
also generated.
The no form of the command reverts to the default value.
Parameters
bandwidth — The bandwidth to be used for VLL bandwidth accounting by the VLL CAC
feature, in kilobits per second.
Values
0 to 100000000
Default
0
bfd-enable
Syntax
Context
Description
Issue: 01
[no] bfd-enable
config>service>epipe>spoke-sdp
config>service>epipe>bgp>pw-template-binding
config>service>fpipe>spoke-sdp
config>service>apipe>spoke-sdp
config>service>ipipe>spoke-sdp
config>service>cpipe>spoke-sdp
This command enables VCCV BFD on the PW associated with the VLL, BGP VPWS, or
VPLS service. The parameters for the BFD session are derived from the named BFD
template, which must have been first configured using the bfd-template command.
3HE 11970 AAAA TQZZA 01
293
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
bfd-template
Syntax
Context
Description
Default
Parameters
bdf-template name
no bfd-template
config>service>epipe>spoke-sdp
config>service>epipe>bgp>pw-template-binding
config>service>fpipe>spoke-sdp
config>service>apipe>spoke-sdp
config>service>ipipe>spoke-sdp
config>service>cpipe>spoke-sdp
This command configures a named BFD template to be used by VCCV BFD on PWs
belonging to the VLL, BGP VPWS, or VPLS service. The template specifies parameters, such
as the minimum transmit and receive control packet timer intervals, to be used by the BFD
session. Template parameters are configured under the config>router>bfd context.
no bfd-template
name — A text string name for the template of up to 32 characters in printable 7-bit
ASCII, enclosed in double quotes.
block-on-peer-fault
Syntax
Context
Description
[no] block-on-peer-fault
config>service>epipe>spoke-sdp
When enabled, this command blocks the transmit direction of a PW when any of the following
PW status codes is received from the far end PE:
0x00000001
Pseudowire Not Forwarding
0x00000002
Local Attachment Circuit (ingress) Receive Fault
0x00000004
Local Attachment Circuit (egress) Transmit Fault
0x00000008
Local PSN-facing PW (ingress) Receive Fault
0x00000010
Local PSN-facing PW (egress) Transmit Fault
The transmit direction is unblocked when the following PW status code is received:
0x00000000
Pseudowire forwarding (clear all failures)
This command is mutually exclusive with no pw-status-signaling, and standby-signalingslave. It is not applicable to spoke SDPs forming part of an MC-LAG or spoke SDPs in an
endpoint.
Default
294
no block-on-peer-fault
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
cflowd
Syntax
Context
Description
[no] cflowd
config>service>epipe>sap
This command enables cflowd to collect traffic flow samples through a service interface
(SAP) for analysis. When cflowd is enabled on an Ethernet service SAP, the Ethernet traffic
can be sampled and processed by the system’s cflowd engine and exported to IPFIX
collectors with the l2-ip template enabled.
cflowd is used for network planning and traffic engineering, capacity planning, security,
application and user profiling, performance monitoring, usage-based billing, and SLA
measurement. When cflowd is enabled at the SAP level, all packets forwarded by the
interface are subjected to analysis according to the cflowd configuration.
For L2 services, only ingress sampling is supported.
Default
no cflowd
collect-stats
Syntax
Context
Description
[no] collect-stats
config>service>cpipe>sap
config>service>cpipe>spoke-sdp
config>service>epipe>spoke-sdp
config>service>apipe>sap
config>service>fpipe>sap
config>service>epipe>sap
This command enables accounting and statistical data collection for either the SAP, network
port, or IP interface. When applying accounting policies the data, by default, is collected in
the appropriate records and written to the designated billing file.
When the no collect-stats command is issued the statistics are still accumulated by the
cards. However, the CPU will not obtain the results and write them to the billing file. If a
subsequent collect-stats command is issued then the counters written to the billing file
include all the traffic while the no collect-stats command was in effect.
Default
no collect-stats
cpu-protection
Syntax
Context
Issue: 01
cpu-protection policy-id [mac-monitoring] | [eth-cfm-monitoring [aggregate] [car]]
no cpu-protection
config>service>apipe>sap
3HE 11970 AAAA TQZZA 01
295
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
config>service>epipe>spoke-sdp
config>service>epipe>sap
Description
Default
This command assigns an existing CPU protection policy to the associated service. The CPU
protection policies are configured in the config>sys>security>cpu-protection>policy cpuprotection-policy-id context.
cpu-protection 254 (for access interfaces)
cpu-protection 255 (for network interfaces)
The configuration of no cpu-protection returns the interface/SAP to the default policies as
shown above.
If no CPU protection policy is assigned to a service SAP then a the default policy is used to
limit the overall-rate.
Parameters
policy-id — Specifies an existing CPU protection policy.
Values
1 to 255
mac-monitoring — This keyword enables MAC monitoring.
eth-cfm-monitoring — This keyword enables Ethernet Connectivity Fault Management
monitoring.
aggregate — This keyword applies the rate limit to the sum of the per peer packet rates.
car — (Committed Access Rate) This keyword causes Eth-CFM packets to be ignored
when enforcing the overall-rate.
dist-cpu-protection
Syntax
Context
Description
dist-cpu-protection policy-name
no dist-cpu-protection
config>service>apipe>sap
config>service>cpipe>sap
config>service>epipe>sap
config>service>fpipe>sap
config>service>ipipe>sap
This command assigns a Distributed CPU Protection (DCP) policy to the SAP. Only a valid
existing DCP policy can be assigned to a SAP or a network interface (this rule does not apply
to templates, such as an msap-policy template).
If no dist-cpu-protection policy is assigned to a SAP, then the default access DCP policy
(_default-access-policy) is used.
If no DCP functionality is required on the SAP then an empty DCP policy can be created and
explicitly assigned to the SAP
296
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
Parameters
VLL Services
policy-name — Specifies the name of the DCP policy up to 32 characters in length
ethernet
Syntax
Context
Description
ethernet
config>service>epipe>sap
This command enters the context to configure Ethernet properties in this SAP.
llf
Syntax
Context
Description
[no] llf
config>service>apipe>sap>atm
config>service>epipe>sap>ethernet
This command enables Link Loss Forwarding (LLF) on an Ethernet port or an ATM port. This
feature provides an end-to-end OAM fault notification for Ethernet VLL service and for ATM
VLL service of vc-type atm-cell. It brings down the Ethernet port (Ethernet LLF) or sends a
SONET/SDH Path AIS (ATM LLF) towards the attached CE when there is a local fault on the
Pseudowire or service, or a remote fault on the SAP or pseudowire, signaled with label
withdrawal or T-LDP status bits. It ceases when the fault disappears.
The Ethernet port must be configured for null encapsulation.
For the 7750 SR, the ATM port must be configured as a SAP on an apipe service of vc-type
atm-cell. The ATM port must also be configured on the following MDAs:
• 1-port OC12/STM4 ASAP MDA. At OC3/STM1 port level
• 4-port ATM MDA at OC12/STM4 or OC3/STM1 port level
• 16-port ATM MDA at OC3/STM1 port level
The ATM port must be configured as a SAP on an apipe service of vc-type atm-cell. The ATM
port must also be configured on the following MDAs:
• 1-port OC12/STM4 ASAP MDA. At OC3/STM1 port level
• 4-port ATM MDA at OC12/STM4 or OC3/STM1 port level
• 16-port ATM MDA at OC3/STM1 port level
Issue: 01
3HE 11970 AAAA TQZZA 01
297
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
2.17.2.5
Circuit Emulation Commands
cem
Syntax
Context
Description
cem
config>service>cpipe>sap
config>service>epipe>sap
This command enters the context to specify circuit emulation (CEM) properties.
local-ecid
Syntax
Context
Description
local-ecid emulated circuit identifier
no local-ecid
config>service>epipe>sap>cem
This command defines the Emulated Circuit Identifiers (ECID) to be used for the local
(source) end of the circuit emulation service.
The no form of the command removes the ECID from the configuration.
Default
Parameters
65535
emulated circuit identifier — Specifies the value to be used as the local (source) ECID for
the circuit emulation service. On CES packet reception, the ECID in the packet will
be compared to the configured local-ecid value. These must match for the packet
payload to be used for the TDM circuit. The remote-ecid value is inserted into the
MEF-8 CES packet to be transmitted.
Values
0 to 1048575
packet
Syntax
Context
Description
Default
298
packet jitter-buffer milliseconds [payload-size bytes]
packet payload-size bytes
no packet bytes
config>service>cpipe>sap
config>service>epipe>sap>cem
This command specifies the jitter buffer size, in milliseconds, and payload size, in bytes.
The default value depends on the CEM SAP endpoint type, and if applicable, the number of
timeslots as shown in Table 13.
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
Table 13
Parameters
VLL Services
packet CEM SAP Endpoint Types
Endpoint Type
Timeslots
Default Jitter Buffer (in ms)
unstructuredE1
n/a
5
unstructuredT1
n/a
5
nxDS0 (E1/T1)
—
32
N=1
16
N = 2 to 4
8
N = 5 to 15
5
nxDS0WithCas (E1)
N
8
nxDS0WithCas (T1)
N
12
milliseconds — Specifies the jitter buffer size in milliseconds (ms).
Configuring the payload size and jitter buffer to values that result in less than 2 packet
buffers or greater than 32 packet buffers is not allowed. Setting the jitter butter value
to 0 sets it back to the default value.
Values
1 to 250
payload-size bytes — Specifies the payload size (in bytes) of packets transmitted to the
packet service network (PSN) by the CEM SAP. This determines the size of the data
that will be transmitted over the service. If the size of the data received is not
consistent with the payload size then the packet is considered malformed.
Values
0 | 16 to 2048
Default
The default value depends on the CEM SAP endpoint type, and if
applicable, the number of timeslots as shown in Table 14.
Table 14
CEM SAP Endpoint Types
Endpoint Type
Timeslots
Default Payload Size (in bytes)
unstructuredE1
n/a
256
unstructuredT1
n/a
192
nxDS0 (E1/T1)
N=1
64
N = 2 to 4
N x 32
N = 5 to 15
N x 16
N >= 16
Nx8
N
N x 16
nxDS0WithCas (E1)
Issue: 01
3HE 11970 AAAA TQZZA 01
299
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
Table 14
CEM SAP Endpoint Types (Continued)
Endpoint Type
Timeslots
Default Payload Size (in bytes)
nxDS0WithCas (T1)
N
N x 24
For all endpoint types except for nxDS0WithCas, the valid payload size range is from
the default to 2048 bytes.
For nxDS0WithCas, the payload size divide by the number of timeslots must be an
integer factor of the number of frames per trunk multi-frame (for example, 16 for E1
trunk and 24 for T1 trunk).
For 1xDS0, the payload size must be a multiple of 2.
For NxDS0, where N > 1, the payload size must be a multiple of the number of
timeslots.
For unstructuredE1 and unstructuredT1, the payload size must be a multiple of 32
bytes.
Configuring the payload size and jitter buffer to values that result in less than 2 packet
buffers or greater than 32 packet buffer is not allowed.
Setting the payload size to 0 sets it back to the default value.
remote-ecid
Syntax
Context
remote-ecid emulated circuit identifier
no remote-ecid
config>service>epipe>sap>cem
Description
This command defines the Emulated Circuit Identifiers (ECID) to be used for the remote
(destination) end of the circuit emulation service.
Parameters
emulated circuit identifier — Specifies the value to be used as the remote (destination)
ECID for the circuit emulation service. Upon CES packet reception, the ECID in the
packet will be compared to the configured local-ecid value. These must match for the
packet payload to be used for the TDM circuit. The remote-ecid value is inserted into
the MEF-8 CES packet to be transmitted.
Values
0 to 1048575
remote-mac
Syntax
Context
300
remote-mac ieee-address
no remote-mac
config>service>epipe>sap>cem
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
Description
Default
Parameters
VLL Services
This command defines the destination IEEE MAC address to be used to reach the remote
end of the circuit emulation service.
00:00:00:00:00:00
ieee-address — Specifies the 48-bit MAC address in the form aa:bb:cc:dd:ee:ff or aa-bbcc-dd-ee-ff where aa, bb, cc, dd, ee and ff are hexadecimal numbers. Allowed values
are any non-broadcast, non-multicast MAC and non-IEEE reserved MAC addresses.
report-alarm
Syntax
Context
Description
[no] report-alarm [stray] [malformed] [pktloss] [overrun] [underrun] [rpktloss] [rfault]
[rrdi]
config>service>epipe>sap>cem
This command indicates the type of CEM SAP alarm.
The no form of the command removes the parameter from the configuration.
Default
On: stray, malformed, pktloss and overrun
Off: rpktloss, rfault, rrdi
Parameters
stray — Reports the reception of packets not destined for this CES circuit.
malformed — Reports the reception of packet not properly formatted as CES packets.
pktloss — Reports the lack of reception of CES packets.
overrun — Reports the reception of too many CES packets resulting in a overrun of the
receive jitter buffer.
underrun — Reports the reception of too few CES packets resulting in a overrun of the
receive jitter buffer.
rpktloss — Reports hat the remote peer is currently in packet loss status.
rfault — Reports that the remote TDM interface is currently not in service.
rrdi — Reports that the remote TDM interface is currently in RDI status.
rtp-header
Syntax
Context
Description
Issue: 01
[no] rtp-header
config>service>epipe>sap>cem
config>service>cpipe>sap>cem
This command specifies whether an RTP header is used when packets are transmitted to the
packet service network (PSN) by the CEM SAP. This mode must be enabled for differentialtimed DS1/E1s. It can optionally be enabled for other DS1/E1s for interoperability purposes.
3HE 11970 AAAA TQZZA 01
301
VLL Services
Default
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
no rtp-header
2.17.2.6
ETH-CFM Service Commands
eth-cfm
Syntax
Context
Description
eth-cfm
config>service>epipe>spoke-sdp
config>service>epipe
config>service>epipe>sap
config>service>ipipe>sap
This command enters the context to configure ETH-CFM parameters.
ais-enable
Syntax
Context
Description
[no] ais-enable
config>service>epipe>sap>eth-cfm
config>service>epipe>sap>eth-cfm>mep
config>service>epipe>spoke-sdp>eth-cfm>mep
This command enables the generation and the reception of AIS messages.
low-priority-defect
Syntax
Context
low-priority-defect {allDef | macRemErrXcon}
config>lag>eth-cfm>mep>ais
config>lag>eth-cfm>mep>ais
config>port>ethernet>eth-cfm>mep>ais
config>service>epipe>sap>eth-cfm>mep>ais
config>service>epipe>spoke-sdp>eth-cfm>mep>ais
config>service>vpls>mesh-sdp>eth-cfm>mep>ais
Description
This command allows the operator to include all CCM Defect conditions or exclude the
Remote Defect Indication CCM (DefRDICCM) as a trigger for generating AIS. AIS generation
can only occur when the client-meg-level configuration option has been included. Changing
this parameter will evaluate the MEP for AIS triggers based on the new criteria.
Parameters
allDef — Keyword that includes any CCM defect condition to trigger AIS generation.
macRemErrXcon — Keyword that excludes RDI CCM Defect condition to trigger AIS
generation.
302
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
collect-lmm-stats
Syntax
Context
Description
collect-lmm-stats
no collect-lmm-stats
config>service>epipe>sap>eth-cfm
config>service>epipe>spoke-sdp>eth-cfm
config>service>vpls>sap>eth-cfm
config>service>vpls>spoke-sdp>eth-cfm
config>service>vpls>mesh-sdp>eth-cfm
config>service>ies>if>sap>eth-cfm
config>service>ies>if>spoke-sdp>eth-cfm
config>service>ies>sub-if>grp-if>sap>eth-cfm
config>service>vprn>if>sap>eth-cfm
config>service>vprn>if>spoke-sdp>eth-cfm
config>service>vprn>sub-if>grp-if>sap>eth-cfm
config>service>ipipe>sap>eth-cfm
This command enables the collection of statistics on the SAP or MPLS SDP binding on which
the ETH- LMM test is configured. The collection of LMM statistics must be enabled if a MEP
is launching or responding to ETH-LMM packets. If LMM statistics collection is not enabled,
the counters in the LMM and LMR PDU do not represent accurate measurements and all
measurements should be ignored. The show sap-using eth-cfm collect-lmm-stats
command and the show sdp-using eth-cfm collect-lmm-stats command can be used to
display which entities are collecting stats.
The no form of the command disables and deletes the counters for this SAP or MPLS SDP
binding.
Default
no collect-lmm-stats
collect-lmm-fc-stats
Syntax
Context
Description
collect-lmm-fc-stats
config>service>epipe>sap>eth-cfm
config>service>epipe>spoke-sdp>eth-cfm
config>service>ipipe>sap>eth-cfm
This command enters the context to configure per-forwarding class (FC) LMM information
collection.
This command is mutually exclusive with the collect-lmm-stats command when there is
entity resource contention.
Issue: 01
3HE 11970 AAAA TQZZA 01
303
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
fc
Syntax
Context
Description
fc fc-name [fc-name ... (up to 8 max)]
no fc
config>service>epipe>sap>eth-cfm>collect-lmm-fc-stats
config>service>epipe>spoke-sdp>eth-cfm>collect-lmm-fc-stats
config>service>ipipe>sap>eth-cfm>collect-lmm-fc-stats
This command creates individual counters for the specified FCs without regard for profile. All
countable packets that match a configured FC, regardless of profile, will be included in this
counter.
A differential is performed when this command is re-entered. Omitted FCs will stop counting,
newly added FCs will start counting, and unchanged FCs will continue to count.
Up to eight FCs may be specified. An FC that is specified as part of this command for this
specific context cannot be specified as a profile-aware FC using the fc-in-profile command
under the same context.
The no form of the command removes all previously defined FCs and stops counting for
those FCs.
Default
Parameters
no fc
fc-name — Specifies the name of the FC for which to create an individual profile-unaware
counter. In order for the counter to be used, the config>oam-pm>session>
ethernet>priority command must be configured with a numerical value representing
the FC name (7 = NC, 6 = H1, 5 = EF, 4 = H2, 3 = L1, 2 = AF, 1 = L2, 0 = BE), and
the config>oam-pm>session>ethernet>lmm>enable-fc-collection command
must be enabled.
Values
nc, h1, ef, h2, l1, af, l2, be
fc-in-profile
Syntax
Context
Description
fc-in-profile fc-name [fc-name ... (up to 8 max)]
no fc-in-profile
config>service>epipe>sap>eth-cfm>collect-lmm-fc-stats
config>service>epipe>spoke-sdp>eth-cfm>collect-lmm-fc-stats
config>service>ipipe>sap>eth-cfm>collect-lmm-fc-stats
This command creates individual counters for the specified FCs with regard for profile. All
countable packets that match a configured FC and are deemed to be in-profile will be
included in this counter.
A differential is performed when this command is re-entered. Omitted FCs will stop counting,
newly added FCs will start counting, and unchanged FCs will continue to count.
304
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
Up to eight FCs may be specified. An FC that is specified as part of this command for this
specific context cannot be specified as a profile-unaware FC using the fc command under the
same context.
The no form of the command removes all previously defined FCs and stops counting for
those FCs.
Default
Parameters
no fc-in-profile
fc-name — Specifies the name of the FC for which to create an individual profile-aware
counter. In order for the counter to be used, the config>oam-pm>session>
ethernet>priority command must be configured with a numerical value representing
the FC name (7 = NC, 6 = H1, 5 = EF, 4 = H2, 3 = L1, 2 = AF, 1 = L2, 0 = BE), and
the config>oam-pm>session>ethernet>lmm>enable-fc-collection command
must be enabled.
Values
nc, h1, ef, h2, l1, af, l2, be
interface-support-enable
Syntax
Context
[no] interface-support-enable
config>service>epipe>sap>eth-cfm>mep>ais
config>service>epipe>spoke-sdp>eth-cfm>mep>ais
Description
This command enables the AIS function to consider the operational state of the entity on
which it is configured. With this command, ETH-AIS on DOWN MEPs will be triggered and
cleared based on the operational status of the entity on which it is configured. If CCM is also
enabled then transmission of the AIS PDU will be based on either the non-operational state
of the entity or on ANY CCM defect condition. AIS generation will cease if BOTH operational
state is UP and CCM has no defect conditions. If the MEP is not CCM enabled then the
operational state of the entity is the only consideration assuming this command is present for
the MEP.
Default
no interface-support-enabled (AIS will not be generated or stopped based on the state of the
entity on) which the DOWN MEP is configured.
client-meg-level
Syntax
Context
Description
Issue: 01
client-meg-level [[level [level ...]]
no client-meg-level
config>service>epipe>sap>eth-cfm>mep
config>service>epipe>spoke-sdp>eth-cfm>aid-enable
This command configures the client maintenance entity group (MEG) level(s) to use for AIS
message generation. Up to 7 levels can be provisioned with the restriction that the client MEG
level must be higher than the local MEG level.
3HE 11970 AAAA TQZZA 01
305
VLL Services
Parameters
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
level — Specifies the client MEG level.
Values
1 to 7
Default
1
interval
Syntax
Context
interval {1 | 60}
no interval
config>service>epipe>sap>eth-cfm>mep>ais-enable
config>service>epipe>spoke-sdp>eth-cfm>ais-enable
Description
This command specifies the transmission interval of AIS messages in seconds.
Parameters
1 | 60 — Specifies the transmission interval of AIS messages in seconds.
Default
1
priority
Syntax
Context
priority priority-value
no priority
config>service>epipe>sap>eth-cfm>mep
config>service>epipe>spoke-sdp>eth-cfm>aid-enable
Description
This command specifies the priority of AIS messages originated by the node.
Parameters
priority-value — Specifies the priority value of the AIS messages originated by the node.
Values
0 to 7
Default
1
eth-tunnel
Syntax
Context
Description
306
eth-tunnel
config>service>epipe>sap
config>service>ipipe>sap
The command enables the context to configure Ethernet Tunnel SAP parameters.
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
path
Syntax
Context
Description
path path-index tag qtag[.qtag]
no path path-index
config>service>epipe>sap>eth-tunnel
config>service>ipipe>sap>eth-tunnel
This command configures Ethernet tunnel SAP path parameters.
The no form of the command removes the values from the configuration.
Default
Parameters
none
path-index — Specifies the path index value.
Values
1 to 16
qtag[.qtag] — Specifies the qtag value.
Values
0 to 4094 | *
mep
Syntax
Context
Description
mep mep-id domain md-index association ma-index [direction {up | down}] [primaryvlan-enable]
no mep mep-id domain md-index association ma-index
config>service>epipe>sap>eth-cfm
config>service>ies>sub-if>eth-cfm
config>service>epipe>spoke-sdp>eth-cfm
config>service>ipipe>sap>eth-cfm
This command provisions the maintenance endpoint (MEP).
The no form of the command reverts to the default values.
Parameters
mep-id — Specifies the maintenance endpoint identifier.
Values
1 to 8191
md-index — Specifies the maintenance domain (MD) index value.
Values
1 to 4294967295
ma-index — Specifies the maintenance association (MA) index value.
Values
1 to 4294967295
direction {up | down} — Indicates the direction in which the MEP faces on the bridge
port. The UP direction is not supported for all Fpipe services. For example, Ipipe does
not support the direction of UP for MEPs.
up — Sends ETH-CFM messages towards the MAC relay entity.
Issue: 01
3HE 11970 AAAA TQZZA 01
307
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
down — Sends ETH-CFM messages away from the MAC relay entity.
primary-vlan-enable — Provides a method for linking the MEP with the primary VLAN
configured under the bridge-identifier for the MA. This must be configured as part of
the creation step and can only be changed by deleting the MEP and recreating it.
Primary VLANs are only supported under Layer 2 Epipe and VPLS services.
ccm-enable
Syntax
Context
Description
[no] ccm-enable
config>service>epipe>spoke-sdp>eth-cfm>mep
config>service>epipe>sap>eth-cfm>mep
config>service>ipipe>sap>eth-cfm>mep
This command enables the generation of CCM messages.
The no form of the command disables the generation of CCM messages.
ccm-ltm-priority
Syntax
Context
Description
ccm-ltm-priority priority
no ccm-ltm-priority
config>service>epipe>spoke-sdp>eth-cfm>mep
config>service>epipe>sap>eth-cfm>mep
config>service>ipipe>sap>eth-cfm>mep
This command specifies the priority value for CCMs and LTMs transmitted by the MEP.
The no form of the command removes the priority value from the configuration.
Default
Parameters
The highest priority on the bridge-port.
priority — Specifies the priority of CCM and LTM messages.
Values
0 to 7
ccm-padding-size
Syntax
Context
308
ccm-padding-size ccm-padding
no ccm-padding-size ccm-padding
config>service>epipe>sap>eth-cfm>mep
config>service>ipipe>sap>eth-cfm>mep
config>service>epipe>sdp>eth-cfm>mep
config>service>epipe>spoke-sdp>eth-cfm>mep
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
config>service>vpls>sap>eth-cfm>mep
config>service>vpls>spoke-sdp>eth-cfm>mep
config>service>vpls>mesh-sdp>eth-cfm>mep
config>service>vpls>sap>eth-cfm>mep
config>service>vpls>spoke-sdp>eth-cfm>mep
config>service>vpls>mesh-sdp>eth-cfm>mep
config>service>ies>if>sap>eth-cfm>mep>
config>service>ies>if>spoke-sdp>eth-cfm>mep
config>service>ies>sub-if>grp-if>sap>eth-cfm>mep
config>service>vprn>if>sap>eth-cfm>mep
config>service>vprn>if>spoke-sdp>eth-cfm>mep
config>service>vprn>sub-if>grp-if>sap>eth-cfm>mep
config>port>ethernet>eth-cfm>mep
config>lag>eth-cfm>eth-cfm>mep
config>router>if>eth-cfm>mep
Description
Default
Parameters
Set the byte size of the optional Data TLV to be included in the ETH-CC PDU. This will
increase the size of the ETH-CC PDU by the configured value. The base size of the ETH-CC
PDU, including the Interface Status TLV and Port Status TLV, is 83 bytes not including the
Layer Two encapsulation. CCM padding is not supported when the CCM-Interval is less than
one second.
[no] ccm-padding-size
ccm-padding — Specifies the byte size of the Optional Data TLV.
Values
3 to 1500
csf-enable
Syntax
Context
Description
[no] csf-enable
config>service>epipe>sap>eth-cfm>mep
config>service>epipe>spoke-sdp>eth-cfm>mep
This command enables the reception and local processing of ETH-CSF frames.
multiplier
Syntax
Context
Description
Issue: 01
multiplier multiplier-value
no multiplier
config>service>epipe>sap>eth-cfm>mep>cfs-enable
config>service>epipe>spoke-sdp>eth-cfm>mep>cfs-enable
This command enables the multiplication factor applied to the receive time used to clear the
CSF condition in increments of .5.
3HE 11970 AAAA TQZZA 01
309
VLL Services
Default
Parameters
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
3.5
multiplier-value — Specifies the multiplier used for timing out CSF.
Values
0.0 | 2.0 to 30.0
ccm-tlv-ignore
Syntax
Context
Description
ccm-tlv-ignore [interface-status] [port-status]
no ccm-tlv-ignore
config>port>ethernet>eth-cfm>mep
config>lag>eth-cfm>mep
config>router>if>eth-cfm>mep
This command allows the receiving MEP to ignore the specified TLVs in CCM PDU. Ignored
TLVs will be reported as absent and will have no impact on the MEP state machine.
The no form of the command means the receiving MEP will process all recognized TLVs in
the CCM PDU.
Default
Parameters
no ccm-tlv-ignore
interface-status — Ignores the interface status TLV on reception.
port-status — Ignores the port status TVL on reception.
eth-test-enable
Syntax
Context
Description
[no] eth-test-enable
config>service>epipe>spoke-sdp>eth-cfm>mep
config>service>epipe>sap>eth-cfm>mep
config>service>ipipe>sap>eth-cfm>mep
For this test to work, operators need to configure ETH-test parameters on both sender and
receiver nodes. The ETH-test then can be done using the following OAM commands:
oam eth-cfm eth-test mac-address mep mep-id domain md-index association ma-index
[priority priority] [data-length data-length]
A check is performed for both the provisioning and test to ensure the MEP is an Y.1731 MEP
(MEP provisioned with domain format none, association format icc-based). If not, the
operation fails. An error message in the CLI and SNMP indicates the problem.
310
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
bit-error-threshold
Syntax
Context
bit-error-threshold errors
no bit-error-threshold
config>service>epipe>sap>eth-cfm>mep>eth-test-enable
Description
This command is used to specify the threshold value of bit errors.
Parameters
errors — The threshold value of bit errors.
Values
0 to 11840
Default
1
test-pattern
Syntax
Context
Description
test-pattern {all-zeros | all-ones} [crc-enable]
no test-pattern
config>service>epipe>spoke-sdp>eth-cfm>mep>eth-test-enable
config>service>epipe>sap>eth-cfm>mep>eth-test-enable
config>service>ipipe>sap>eth-cfm>mep>eth-test-enable
This command configures the test pattern for eth-test frames.
The no form of the command removes the values from the configuration.
Default
Parameters
all-zeros
all-zeros — Specifies to use all zeros in the test pattern.
all-ones — Specifies to use all ones in the test pattern.
crc-enable — Generates a CRC checksum.
fault-propagation-enable
Syntax
Context
fault-propagation-enable {use-if-tlv | suspend-ccm}
no fault-propagation-enable
config>service>epipe>sap>eth-cfm>mep
config>service>epipe>spoke-sdp>eth-cfm>mep
config>service>ipipe>sap>eth-cfm>mep
Description
This command configures the fault propagation for the MEP.
Parameters
use-if-tlv — Specifies to use the interface TLV.
suspend-ccm — Specifies to suspend continuity check messages.
Issue: 01
3HE 11970 AAAA TQZZA 01
311
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
grace
Syntax
Context
Description
grace
config>service>epipe>sap>eth-cfm>mep
config>service>epipe>spoke-sdp>eth-cfm>mep
config>service>ipipe>sap>eth-cfm>mep
This command enters the context to configure Nokia ETH-CFM Grace and ITU-T Y.1731
ETH-ED expected defect functional parameters.
eth-ed
Syntax
Context
Description
eth-ed
config>service>epipe>sap>eth-cfm>mep>grace
config>service>epipe>spoke-sdp>eth-cfm>mep>grace
config>service>ipipe>sap>eth-cfm>mep>grace
This command enters the context to configure ITU-T Y.1731 ETH-ED expected defect
functional parameters.
max-rx-defect-window
Syntax
Context
Description
max-rx-defect-window seconds
no max-rx-defect-window
config>service>epipe>sap>eth-cfm>mep>grace>eth-ed
config>service>epipe>spoke-sdp>eth-cfm>mep>grace>eth-ed
config>service>ipipe>sap>eth-cfm>mep>grace>eth-ed
This command limits the duration of the received ETH-ED expected defect window to the
lower value of either the received value from the peer or this parameter.
The no form of the command removes the limitation, and any valid defect window value
received from a peer MEP in the ETH-ED PDU will be used.
Default
Parameters
no max-rx-defect-window
seconds — Specifies the duration, in seconds, of the maximum expected defect window.
Values
1 to 86400
priority
Syntax
312
priority priority
no priority
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
Context
Description
VLL Services
config>service>epipe>sap>eth-cfm>mep>grace>eth-ed
config>service>epipe>spoke-sdp>eth-cfm>mep>grace>eth-ed
config>service>ipipe>sap>eth-cfm>mep>grace>eth-ed
This command sets the priority bits and determines the forwarding class based on the
mapping of priority to FC.
The no form of the command disables the local priority configuration and sets the priority to
the ccm-ltm-priority associated with this MEP.
Default
Parameters
no priority
priority — Specifies the priority bit.
Values
0 to 7
rx-eth-ed
Syntax
Context
Description
[no] rx-eth-ed
config>service>epipe>sap>eth-cfm>mep>grace>eth-ed
config>service>epipe>spoke-sdp>eth-cfm>mep>grace>eth-ed
config>service>ipipe>sap>eth-cfm>mep>grace>eth-ed
This command enables the reception and processing of the ITU-T Y.1731 ETH-ED PDU on
the MEP.
The no form of the command disables the reception of the ITU-T Y.1731 ETH-ED PDU on
the MEP.
Default
rx-eth-ed
tx-eth-ed
Syntax
Context
Description
[no] tx-eth-ed
config>service>epipe>sap>eth-cfm>mep>grace>eth-ed
config>service>epipe>spoke-sdp>eth-cfm>mep>grace>eth-ed
config>service>ipipe>sap>eth-cfm>mep>grace>eth-ed
This command enables the transmission of the ITU-T Y.1731 ETH-ED PDU from the MEP
when a system soft reset notification is received for one or more cards.
The config>eth-cfm>system>grace-tx-enable command must be configured to instruct the
system that the node is capable of transmitting expected defect windows to the peers. Only
one form of ETH-CFM grace (Nokia ETH-CFM Grace or ITU-T Y.1731 ETH-ED) may be
transmitted.
Issue: 01
3HE 11970 AAAA TQZZA 01
313
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
The no form of the command disables the transmission of the ITU-T Y.1731 ETH-ED PDU
from the MEP.
Default
no tx-eth-ed
eth-vsm-grace
Syntax
Context
Description
eth-vsm-grace
config>service>epipe>sap>eth-cfm>mep>grace
config>service>epipe>spoke-sdp>eth-cfm>mep>grace
config>service>ipipe>sap>eth-cfm>mep>grace
This command enters the context to configure Nokia ETH-CFM Grace functional parameters.
rx-eth-vsm-grace
Syntax
Context
Description
[no] rx-eth-vsm-grace
config>service>epipe>sap>eth-cfm>mep>grace>eth-vsm-grace
config>service>epipe>spoke-sdp>eth-cfm>mep>grace>eth-vsm-grace
config>service>ipipe>sap>eth-cfm>mep>grace>eth-vsm-grace
This command enables the reception and processing of the Nokia ETH-CFM Grace PDU on
the MEP.
The Nokia Grace function is a vendor-specific PDU that informs MEP peers that the local
node may be entering a period of expected defect.
The no form of the command disables the reception of the Nokia ETH-CFM Grace PDU on
the MEP.
Default
rx-eth-vsm-grace
tx-eth-vsm-grace
Syntax
Context
Description
[no] tx-eth-vsm-grace
config>service>epipe>sap>eth-cfm>mep>grace>eth-vsm-grace
config>service>epipe>spoke-sdp>eth-cfm>mep>grace>eth-vsm-grace
config>service>ipipe>sap>eth-cfm>mep>grace>eth-vsm-grace
This command enables the transmission of the Nokia ETH-CFM Grace PDU from the MEP
when a system soft reset notification is received for one or more cards.
The Nokia Grace function is a vendor-specific PDU that informs MEP peers that the local
node may be entering a period of expected defect.
314
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
The config>eth-cfm>system>grace-tx-enable command must be configured to instruct the
system that the node is capable of transmitting expected defect windows to the peers. Only
one form of ETH-CFM grace (Nokia ETH-CFM Grace or ITU-T Y.1731 ETH-ED) may be
transmitted.
The no form of the command disables the transmission of the Nokia ETH-CFM Grace PDU
from the MEP.
Default
tx-eth-vsm-grace
low-priority-defect
Syntax
Context
Description
Default
Parameters
low-priority-defect {allDef | macRemErrXcon | remErrXcon | errXcon | xcon | noXcon}
config>service>epipe>spoke-sdp>eth-cfm>mep
config>service>epipe>sap>eth-cfm>mep
config>service>ipipe>sap>eth-cfm>mep
This command specifies the lowest priority defect that is allowed to generate a fault alarm.
macRemErrXcon
low-priority-defect — The low priority defect values are defined below.
Values
allDef
DefRDICCM, DefMACstatus, DefRemoteCCM,
DefErrorCCM, and DefXconCCM
macRemErrXcon
Only DefMACstatus, DefRemoteCCM, DefErrorCCM, and
DefXconCCM
remErrXcon
Only DefRemoteCCM, DefErrorCCM, and DefXconCCM
errXcon
Only DefErrorCCM and DefXconCCM
xcon
Only DefXconCCM
noXcon
No defects DefXcon or lower are to be reported
one-way-delay-threshold
Syntax
Context
one-way-delay-threshold seconds
config>service>vpls>sap>eth-cfm>mep
Description
This command enables/disables eth-test functionality on MEP.
Parameters
seconds — Specifies the one way-delay threshold in seconds.
Issue: 01
Values
0 to 600
Default
3
3HE 11970 AAAA TQZZA 01
315
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
mip
Syntax
Context
Description
mip [mac mac-address] [primary-vlan-enable vlan-id]
mip default-mac [primary-vlan-enable vlan-id]
no mip
config>service>epipe>sap>eth-cfm
config>service>epipe>spoke-sdp>eth-cfm
This command allows Maintenance Intermediate Points (MIPs). The creation rules of the MIP
are dependent on the mhf-creation configuration for the MA.
The no form of the command removes the MIP creation request.
Default
Parameters
no mip
mac — Provides a method for manually configuring the MIP MAC address.
mac-address — Specifies the MAC address of the MIP.
Values
6-byte mac-address in the form of xx:xx:xx:xx:xx:xx or xx-xx-xx-xxxx-xx of the MIP. The MAC address must be unicast. Using the allzeros address is equivalent to the no form of this command.
default-mac — Using the no command deletes the MIP. This parameter should be used
if the operator wants to change the MAC address back to the default MAC without
having to delete and reconfigure the MIP.
primary-vlan-enable — Provides a method for linking the MIP with the primary VLAN
configured under the bridge-identifier for the MA. This is only allowed if the mhfcreation method is static. MIPs cannot be changed from or to primary VLAN functions
without first being deleted. This must be configured as part of the creation step and
can only be changed by deleting the MIP and recreating it. Primary VLANs are only
supported under Layer 2 Epipe and VPLS services.
vlan-id — Must match the vlan-id under the bridge-identifier for the MA that is appropriate
for this service.
Values
0 to 4094
squelch-ingress-levels
Syntax
Context
316
squelch-ingress-levels [md-level [md-level…]]
no squelch-ingress-levels
config>service>epipe>sap>eth-cfm
config>service>epipe>spoke-sdp>eth-cfm
config>service>vpls>sap>eth-cfm
config>service>vpls>spoke-sdp>eth-cfm
config>service>vpls>mesh-sdp>eth-cfm
config>service>ies>if>sap>eth-cfm
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
config>service>ies>if>spoke-sdp>eth-cfm
config>service>ies>sub-if>grp-if>sap>eth-cfm
config>service>vprn>if>sap>eth-cfm
config>service>vprn>if>spoke-sdp>eth-cfm
config>service>vprn>sub-if>grp-if>sap>eth-cfm
config>service>ipipe>sap>eth-cfm
config>service>template>vpls-sap-template>eth-cfm
Description
This command defines the levels of the ETH-CFM PDUs that will silently be discarded on
ingress into the SAP or SDP binding from the wire. All ETH-CFM PDUs inbound to the SAP
or SDP binding will be dropped that match the configured levels without regard for any other
ETH-CFM criteria. No statistical information or drop count will be available for any ETH-PDU
that is silently discarded by this option. The operator must configure a complete contiguous
list of md-levels up to the highest level that will be dropped. The command must be retyped
in complete form to modify a previous configuration, if the operator does not want to delete it
first.
The no form of the command removes the silent discarding of previously matching ETH-CFM
PDUs.
Default
Parameters
no squelch-ingress-levels
md-level — Identifies the level.
Values
0 to 7
tunnel-fault
Syntax
Context
Description
Default
Issue: 01
tunnel-fault {accept | ignore}
config>service>epipe>eth-cfm
config>service>epipe>sap>eth-cfm
config>service>ipipe>eth-cfm
config>service>ipipe>sap>eth-cfm
Allows the individual service SAPs to react to changes in the tunnel MEP state. When tunnelfault accept is configured at the service level, the SAP will react according to the service type,
Epipe will set the operational flag and VPLS, IES and VPRN SAP operational state will
become down on failure or up on clear. This command triggers the OAM mapping functions
to mate SAPs and bindings in an Epipe service as well as setting the operational flag. If AIS
generation is the requirement for the Epipe services this command is not required. See the
ais-enable command under config>service>epipe>sap>eth-cfm>ais-enable context for
more details. This works in conjunction with the tunnel-fault accept on the individual SAPs.
Both must be set to accept to react to the tunnel MEP state. By default the service level
command is “ignore” and the sap level command is “accept”. This means simply changing the
service level command to “accept” will enable the feature for all SAPs. This is not required for
Epipe services that only wish to generate AIS on failure.
ignore (Service Level)
3HE 11970 AAAA TQZZA 01
317
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
accept (SAP Level for Epipe and VPLS)
Parameters
accept — Shares fate with the facility tunnel MEP.
ignore — Does not share fate with the facility tunnel MEP.
2.17.2.7
Service Filter and QoS Policy Commands
egress
Syntax
Context
Description
egress
config>service>apipe>sap
config>service>cpipe>sap
config>service>cpipe>spoke-sdp
config>service>epipe>spoke-sdp
config>service>fpipe>sap
config>service>ipipe>sap
config>service>epipe>sap
This command enters the context to configure egress SAP parameters.
If no sap-egress QoS policy is defined, the system default sap-egress QoS policy is used for
egress processing.
force-qinq-vc-forwarding
Syntax
Context
Description
[no] force-qinq-vc-forwarding
config>service>epipe>spoke-sdp
config>service>vpls>mesh-sdp
config>service>vpls>spoke-sdp
config>service>pw-template
This command forces the data path to insert and remove two VLAN tags for spoke and mesh
SDPS that have either vc-type ether or vc-type vlan. The use of this command is mutually
exclusive with the force-vlan-vc-forwarding command.
The VLAN identifiers and dot 1p/DE bits used in the two VLAN tags are taken from the inner
tag received on a qinq SAP or qinq mesh/spoke SDP, or from the VLAN tag received on a
dot1q SAP or mesh/spoke SDP (with vc-type vlan or force-vlan-vc-forwarding), or 0 if
there is no service delimiting VLAN tag at the ingress SAP or mesh/spoke SDP. Alternatively,
the VLAN identifiers in both VLAN tags can be set to the value configured in the vlan-vc-tag
parameter in the pw-template or under the mesh or spoke SDP configuration.
318
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
The Ethertype used for both VLAN tags is 0x8100. A different Ethertype can be used for the
outer VLAN tag by configuring the pseudowire template with the use-provisioned-sdp or
prefer-provisioned-sdp options and setting the Ethertype using the sdp vlan-vc-etype
parameter (this Ethertype value is then used for all mesh and spoke SDPs using that SDP).
The no version of this command sets the default behavior.
force-vlan-vc-forwarding
Syntax
Context
Description
[no] force-vlan-vc-forwarding
config>service>epipe>spoke-sdp
config>service>vpls>mesh-sdp
config>service>vpls>spoke-sdp
This command forces vc-vlan-type forwarding in the data path for spoke and mesh SDPs
which have either vc-type. This command is not allowed on vlan-vc-type SDPs.
The no version of this command sets default behavior.
Default
By default this feature is disabled.
Syntax
ingress
ingress
Context
Description
config>service>apipe>sap
config>service>cpipe>sap
config>service>cpipe>spoke-sdp
config>service>epipe>spoke-sdp
config>service>fpipe>sap
config>service>ipipe>sap
config>service>epipe>sap
config>service>epipe>sap
This command enters the context to configure ingress SAP Quality of Service (QoS) policies.
If no sap-ingress QoS policy is defined, the system default sap-ingress QoS policy is used for
ingress processing.
filter
Syntax
Issue: 01
filter [ip ip-filter-id]
filter [ipv6 ipv6-filter-id]
filter [mac mac-filter-id]
no filter [ip ip-filter-id]
3HE 11970 AAAA TQZZA 01
319
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
no filter [ipv6 ipv6-filter-id]
no filter [mac mac-filter-id]
Context
Description
config>service>epipe>sap>egress
config>service>epipe>sap>ingress
config>service>epipe>spoke-sdp>egress
config>service>epipe>spoke-sdp>ingress
config>service>ipipe>spoke-sdp>egress
config>service>ipipe>sap>ingress
config>service>ipipe>sap>egress
config>service>ipipe>spoke-sdp>ingress
config>service>epipe>sap>egress
config>service>epipe>sap>ingress
This command associates an IP filter policy with an ingress or egress Service Access Point
(SAP) or IP interface.
Filter policies control the forwarding and dropping of packets based on IP matching criteria.
Only one filter can be applied to a SAP at a time.
The filter command is used to associate a filter policy with a specified filter-id with an ingress
or egress SAP. The filter-id must already be defined before the filter command is executed.
If the filter policy does not exist, the operation will fail and an error message returned.
IP filters apply only to RFC 2427-routed IP packets. Frames that do not contain IP packets
will not be subject to the filter and will always be passed, even if the filter's default action is to
drop.
The no form of this command removes any configured filter ID association with the SAP or
IP interface. The filter ID itself is not removed from the system unless the scope of the created
filter is set to local. To avoid deletion of the filter ID and only break the association with the
service object, use scope command within the filter definition to change the scope to local
or global. The default scope of a filter is local.
Note that IPv6 filters are only supported by the 7450 ESS and 7750 SR but are not supported
on a Layer 2 SAP that is configured with QoS MAC criteria. Also, MAC filters are not
supported on a Layer 2 SAP that is configured with QoS IPv6 criteria.
Special Cases
Parameters
Epipe — Both MAC and IP filters are supported on an Epipe service SAP.
ip-filter-id — Specifies IP filter policy. The filter ID must already exist within the created
IP filters.
Values
1 to 65535
ipv6-filter-id — Specifies the IPv6 filter policy for 7450 ESS or 7750 SR. The filter ID must
already exist within the created IPv6 filters.
Values
320
1 to 65535
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
mac-filter-id — Specifies the MAC filter policy. The specified filter ID must already exist
within the created MAC filters. The filter policy must already exist within the created
MAC filters.
Values
1 to 65535
l2tpv3
Syntax
Context
Description
l2tpv3
config>service>epipe>spoke-sdp>egress
config>service>epipe>spoke-sdp>ingress
This command enters the context to configure L2TPv3 spoke-SDPs for Epipe services.
cookie
Syntax
Context
Description
cookie [cookie1] [cookie2]
no cookie
config>service>epipe>spoke-sdp>egress>l2tpv3
config>service>epipe>spoke-sdp>ingress>l2tpv3
This command configures the RX/TX cookie for L2TPv3 spoke-SDPs for Epipe services. The
RX cookie must match the configured TX cookie on a far-end node, while the TX cookie must
match the configured RX cookie on a far-end node. If a mismatch is detected between the
configured (far-end binding cookie) to what is received by the local IP address of the SDP a
flag is set and must be manually cleared by an operator.
The purpose of the cookie is to provide validation against misconfiguration of service
endpoints, and to ensure that the right service egress is being used.
One egress cookie and up to two ingress cookies may be configured per spoke-SDP binding.
One or two cookies can be configured for matching ingress packets from the far-end node, in
order to support cookie rollover without dropping packets. When a cookie is not configured,
SR-OS assumes a value of 00:00:00:00:00:00:00:00.
A cookie is not mandatory. An operator may delete an egress cookie or either or both ingress
cookies.
Default
Parameters
no cookie1 cookie2
cookie1 — Specifies the first cookie, in the form of a 64-bit colon-separated hex value.
cookie2 — Specifies the second cookie, in the form of a 64-bit colon-separated hex
value.
Issue: 01
3HE 11970 AAAA TQZZA 01
321
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
hsmda-queue-override
Syntax
Context
Description
[no] hsmda-queue-override
config>service>epipe>sap>egress
config>service>ipipe>sap>egress
This command configures HSMDA egress and ingress queue overrides.
packet-byte-offset
Syntax
Context
Description
packet-byte-offset {add add-bytes | subtract sub-bytes}
no packet-byte-offset
config>service>epipe>sap>egress>hsmda-queue-over
config>service>ipipe>sap>egress>hsmda-queue-over
This command adds or subtracts the specified number of bytes to the accounting function for
each packet handled by the HSMDA queue. Normally, the accounting and leaky bucket
functions are based on the Ethernet DLC header, payload and the 4-byte CRC (everything
except the preamble and inter-frame gap). For example, this command can be used to add
the frame encapsulation overhead (20 bytes) to the queues accounting functions.
The accounting functions affected include:
• Offered High Priority / In-Profile Octet Counter
• Offered Low Priority / Out-of-Profile Octet Counter
• Discarded High Priority / In-Profile Octet Counter
• Discarded Low Priority / Out-of-Profile Octet Counter
• Forwarded In-Profile Octet Counter
• Forwarded Out-of-Profile Octet Counter
• Peak Information Rate (PIR) Leaky Bucket Updates
• Committed Information Rate (CIR) Leaky Bucket Updates
• Queue Group Aggregate Rate Limit Leaky Bucket Updates
The secondary shaper leaky bucket, scheduler priority level leaky bucket and the port
maximum rate updates are not affected by the configured packet-byte-offset. Each of these
accounting functions are frame based and always include the preamble, DLC header,
payload and the CRC regardless of the configured byte offset.
322
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
The packet-byte-offset command accepts either add or subtract as valid keywords which
define whether bytes are being added or removed from each packet traversing the queue. Up
to 20 bytes may be added to the packet and up to 43 bytes may be removed from the packet.
An example use case for subtracting bytes from each packet is an IP based accounting
function. Given a Dot1Q encapsulation, the command packet-byte-offset subtract 14 would
remove the DLC header and the Dot1Q header from the size of each packet for accounting
functions only. The 14 bytes are not actually removed from the packet, only the accounting
size of the packet is affected.
As mentioned above, the variable accounting size offered by the packet-byte-offset
command is targeted at the queue and queue group level. When the queue group represents
the last-mile bandwidth constraints for a subscriber, the offset allows the HSMDA queue
group to provide an accurate accounting to prevent overrun and underrun conditions for the
subscriber. The accounting size of the packet is ignored by the secondary shapers, the
scheduling priority level shapers and the scheduler maximum rate. The actual on-the-wire
frame size is used for these functions to allow an accurate representation of the behavior of
the subscriber’s packets on an Ethernet aggregation network.
The packet-byte-offset value can be overridden for the HSMDA queue at the SAP or
subscriber profile level.
The no form of the command removes any accounting size changes to packets handled by
the queue. The command does not effect overrides that may exist on SAPs or subscriber
profiles associated with the queue.
Parameters
add-bytes — Specifies a byte value to add to packets for queue and queue group-level
accounting functions. The corresponding byte value must be specified when
executing the packet-byte-offset command.
Values
0 to 31
sub-bytes — Specifies a byte value to subtract from packets for queue and queue grouplevel accounting functions. The corresponding byte value must be specified when
executing the packet-byte-offset command.
Values
1 to 64
queue
Syntax
Context
Issue: 01
queue queue-id [create]
no queue queue-id
config>service>epipe>sap>egress>hsmda-queue-over
config>service>ipipe>sap>egress>hsmda-queue-over
3HE 11970 AAAA TQZZA 01
323
VLL Services
Description
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
This command, within the QoS policy hsmda-queue context, is a container for the
configuration parameters controlling the behavior of an HSMDA queue. Unlike the standard
QoS policy queue command, this command is not used to actually create or dynamically
assign the queue to the object which the policy is applied. The queue identified by queue-id
always exists on the SAP or subscriber context whether the command is executed or not. In
the case of HSMDA SAPs and subscribers, all eight queues exist at the moment the system
allocates an HSMDA queue group to the object (both ingress and egress).
Best-Effort, Expedited and Auto-Expedite Queue Behavior Based on Queue-ID
With standard service queues, the scheduling behavior relative to other queues is based on
two items, the queues Best-Effort or Expedited nature and the dynamic rate of the queue
relative to the defined CIR. HSMDA queues are handled differently. The create time autoexpedite and explicit expedite and best-effort qualifiers have been eliminated and instead the
scheduling behavior is based solely on the queues identifier. Queues with a queue-id equal
to 1 are placed in scheduling class 1. Queues with queue-id 2 are placed in scheduling class
2. And so on up to scheduling class 8. Each scheduling class is either mapped directly to a
strict scheduling priority level based on the class ID, or the class may be placed into a
weighted scheduling class group providing byte fair weighted round robin scheduling
between the members of the group. Two weighted groups are supported and each may
contain up to three consecutive scheduling classes. The weighted group assumes its highest
member class inherent strict scheduling level for scheduling purposes. Strict priority level 8
has the highest priority while strict level 1 has the lowest. When grouping of scheduling
classes is defined, some of the strict levels will not be in use.
Single Type of HSMDA Queues
Another difference between HSMDA queues and standard service queues is the lack of
Multipoint queues. At ingress, an HSMDA SAP or subscriber does not require Multipoint
queues since all forwarding types (broadcast, multicast, unicast and unknown) forward to a
single destination ñ the ingress forwarding plane on the IOM. Instead of a possible eight
queues per forwarding type (for a total of up to 32) within the SAP ingress QoS policy, the
hsmda-queues node supports a maximum of eight queues.
Every HSMDA Queue Supports Profile Mode Implicitly
Unlike standard service queues, the HSMDA queues do not need to be placed into the
special mode profile at create time in order to support ingress color aware policing. Each
queue may handle in-profile, out-of-profile and profile undefined packets simultaneously. As
with standard queues, the explicit profile of a packet is dependent on ingress sub-forwarding
class to which the packet is mapped.
The no form of the command restores the defined queue-id to its default parameters. All
HSMDA queues having the queue-id and associated with the QoS policy are re-initialized to
default parameters.
Parameters
queue-id — Specifies the HSMDA queue to use for packets in this forwarding class. This
mapping is used when the SAP is on a HSMDA MDA.
Values
324
1 to 8
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
rate
Syntax
Context
rate pir-rate
no rate
config>service>epipe>sap>egress>hsmda-queue-over
config>service>ipipe>sap>egress>hsmda-queue-over
Description
This command specifies the administrative PIR by the user.
Parameters
pir-rate — Configures the administrative PIR specified by the user.
Values
1 to 40000000, max
wrr-weight
Syntax
wrr-weight value
no wrr-weight
Context
config>service>epipe>sap>egress>hsmda-queue-over>queue
config>service>ipipe>sap>egress>hsmda-queue-over>queue
Description
This command assigns the weight value to the HSMDA queue.
The no form of the command returns the weight value for the queue to the default value.
Parameters
value — Specifies the weight for the HSMDA queue.
Values
1 to 32
wrr-policy
Syntax
Context
wrr-policy hsmda-wrr-policy-name
no wrr-policy
config>service>epipe>sap>egress>hsmda-queue-over
config>service>ipipe>sap>egress>hsmda-queue-over
Description
This command associates an existing HSMDA weighted-round-robin (WRR) scheduling loop
policy to the HSMDA queue.
Parameters
hsmda-wrr-policy-name — Specifies the existing HSMDA WRR policy name to associate
to the queue.
slope-policy
Syntax
Issue: 01
slope-policy hsmda-slope-policy-name
3HE 11970 AAAA TQZZA 01
325
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
no slope-policy
Context
Description
config>service>epipe>sap>egress>hsmda-queue-over
config>service>ipipe>sap>egress>hsmda-queue-over
This command assigns an HSMDA slope policy to the SAP. The policy may be assigned to
an ingress or egress HSMDA queue. The policy contains the Maximum Buffer Size (MBS)
that will be applied to the queue and the high and low priority RED slope definitions. The
function of the MBS and RED slopes is to provide congestion control for an HSMDA queue.
The MBS parameter defines the maximum depth a queue may reach when accepting
packets. The low and high priority RED slopes provides for random early detection of
congestion and slope based discards based on queue depth.
An HSMDA slope policy can be applied to queues defined in the SAP ingress and SAP egress
QoS policy HSMDA queues context. Once an HSMDA slope policy is applied to a SAP QoS
policy queue, it cannot be deleted. Any edits to the policy are updated to all HSMDA queues
indirectly associated with the policy.
Default HSMDA Slope Policy
An HSMDA slope policy named “default” always exists on the system and does not need to
be created. The default policy is automatically applied to all HSMDA queues unless another
HSMDA slope policy is specified for the queue. The default policy cannot be modified or
deleted. Attempting to execute the no hsmda-slope-policy default command results in an
error.
The no form of the command removes the specified HSMDA slope policy from the
configuration. If the HSMDA slope policy is currently associated with an HSMDA queue, the
command will fail.
Parameters
hsmda-slope-policy-name — Specifies a HSMDA slope policy up to 32 characters in
length. The HSMDA slope policy must be exist prior to applying the policy name to
an HSMDA queue.
secondary-shaper
Syntax
Context
326
secondary-shaper secondary-shaper-name
no secondary-shaper
config>service>epipe>sap>egress>hsmda-queue-over
config>service>ipipe>sap>egress>hsmda-queue-over
Description
This command configures an HSMDA egress secondary shaper.
Parameters
secondary-shaper-name — Specifies a secondary shaper name up to 32 characters in
length.
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
filter
Syntax
filter [ip ip-filter-id]
filter [ipv6 ipv6-filter-id]
no filter [ip ip-filter-id] [ipv6 ipv6-filter-id]
no filter [ip ip-filter-id]
Context
config>service>fpipe>sap>egress
config>service>fpipe>sap>ingress
config>service>cpipe>spoke-sdp>egress
config>service>cpipe>spoke-sdp>ingress
config>service>fpipe>spoke-sdp>egress
config>service>fpipe>spoke-sdp>ingress
config>service>ipipe>spoke-sdp>egress
config>service>ipipe>sap>ingress
config>service>ipipe>sap>egress
config>service>ipipe>spoke-sdp>ingress
Description
This command associates a filter policy with an ingress or egress Service Access Point (SAP)
or IP interface.
Filter policies control the forwarding and dropping of packets based on IP matching criteria.
Only one filter can be applied to a SAP at a time.
The filter command is used to associate a filter policy with a specified ip-filter-id with an
ingress or egress SAP. The ip-filter-id must already be defined before the filter command is
executed. If the filter policy does not exist, the operation will fail and an error message
returned.
IP filters apply only to RFC 2427-routed IP packets. Frames that do not contain IP packets
will not be subject to the filter and will always be passed, even if the filter's default action is to
drop.
The no form of this command removes any configured filter ID association with the SAP or
IP interface. The filter ID itself is not removed from the system unless the scope of the created
filter is set to local. To avoid deletion of the filter ID and only break the association with the
service object, use scope command within the filter definition to change the scope to local
or global. The default scope of a filter is local.
Parameters
ip-filter-id — Specifies IP filter policy. The filter ID must already exist within the created
IP filters.
Values
1 to 65535
ipv6-filter-id — Specifies the IPv6 filter policy. The filter ID must already exist within the
created IPv6 filters.
Values
Issue: 01
1 to 65535
3HE 11970 AAAA TQZZA 01
327
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
qos
Syntax
Context
Description
qos policy-id [shared-queuing] [fp-redirect-group queue-group-name instance instanceid]
no qos
config>service>apipe>sap>ingress
config>service>fpipe>sap>ingress
config>service>ipipe>sap>ingress
config>service>epipe>sap>ingress
This command associates a Quality of Service (QoS) policy with an ingress Service Access
Point (SAP).
QoS ingress and egress policies are important for the enforcement of SLA agreements. The
policy ID must be defined prior to associating the policy with a SAP. If the policy-id does not
exist, an error will be returned.
The qos command, when used under the ingress context, is used to associate ingress QoS
policies. The qos command only allows ingress policies to be associated on SAP ingress and
egress policies on SAP egress. Attempts to associate a QoS policy of the wrong type returns
an error.
Only one ingress and one egress QoS policy can be associated with a SAP at one time.
Attempts to associate a second QoS policy of a given type will return an error.
By default, if no specific QoS policy is associated with the SAP for ingress or egress, so the
default QoS policy is used.
The no form of this command removes the QoS policy association from the SAP, and the
QoS policy reverts to the default.
Default
Parameters
none
policy-id — The ingress policy ID to associate with SAP or IP interface on ingress. The
policy ID must already exist.
Values
1 to 65535
shared-queuing — This keyword can only be specified on SAP ingress. The sharedqueuing keyword specifies the shared queue policy will be used by this SAP. When
the value of this object is null, the SAP will use individual ingress QoS queues,
instead of the shared ones.
fp-redirect-group — This keyword can only be used on SAP ingress and associates a
SAP ingress with an instance of a named queue group template on the ingress
forwarding plane of a given IOM/IMM/XMA. The queue-group-name and instance
instance-id are mandatory parameters when executing the command.
queue-group-name — Specifies the name of the queue group to be instance on the
forwarding plane of the IOM/IMM/XMA, up to 32 characters in length. The queuegroup-name must correspond to a valid ingress forwarding plane queue group,
created under config>card>fp>ingress>access.
328
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
instance-id — Specifies the instance of the named queue group on the IOM/IMM/XMA
ingress forwarding plane.
qos
Syntax
Context
Description
qos policy-id port-redirect-group queue-group-name instance instance-id
qos policy-id
no qos [policy-id]
config>service>apipe>sap>egress
config>service>cpipe>sap>egress
config>service>fpipe>sap>egress
config>service>ipipe>sap>egress
config>service>epipe>sap>egress
This command associates a Quality of Service (QoS) policy with an egress Service Access
Point (SAP).
QoS ingress and egress policies are important for the enforcement of SLA agreements. The
policy ID must be defined prior to associating the policy with a SAP. If the policy-id does not
exist, an error will be returned.
The qos command, when used under the egress context, is used to associate egress QoS
policies.
The qos command only allows ingress policies to be associated on SAP ingress and egress
policies on SAP egress. Attempts to associate a QoS policy of the wrong type returns an
error.
Only one ingress and one egress QoS policy can be associated with a SAP at one time.
Attempts to associate a second QoS policy of a given type will return an error.
By default, if no specific QoS policy is associated with the SAP for ingress or egress, so the
default QoS policy is used.
The no form of this command removes the QoS policy association from the SAP, and the
QoS policy reverts to the default.
Default
Parameters
none
policy-id — The egress policy ID to associate with SAP on egress. The policy ID must
already exist.
Values
1 to 65535
queue-group-name — Specifies the name of the egress port queue group of the IOM/
IMM/XMA, up to 32 characters in length. The queue-group-name must correspond to
a valid egress queue group, created under config>port>ethernet>access>egress.
Issue: 01
3HE 11970 AAAA TQZZA 01
329
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
instance-id — Specifies the instance of the named egress port queue group on the IOM/
IMM/XMA.
Values
1 to 40960
Default
1
queue-override
Syntax
Context
Description
[no] queue-override
config>service>apipe>sap>egress
config>service>apipe>sap>ingress
config>service>cpipe>sap>egress
config>service>cpipe>sap>ingress
config>service>fpipe>sap>egress
config>service>fpipe>sap>ingress
config>service>ipipe>sap>egress
config>service>ipipe>sap>ingress
config>service>epipe>sap>egress
config>service>epipe>sap>ingress
This command enters the context to configure override values for the specified SAP egress
or ingress QoS queue. These values override the corresponding ones specified in the
associated SAP egress or ingress QoS policy. If the policy was created as a template policy,
this command overrides the parameter and its description and queue parameters in the
policy.
queue
Syntax
Context
queue queue-id [create]
no queue queue-id
config>service>apipe>sap>egress>queue-override
config>service>apipe>sap>ingress>queue-override
config>service>cpipe>sap>egress>queue-override
config>service>cpipe>sap>ingress>queue-override
config>service>fpipe>sap>egress>queue-override
config>service>fpipe>sap>ingress>queue-override
config>service>ipipe>sap>egress>queue-override
config>service>ipipe>sap>ingress>queue-override
config>service>epipe>sap>egress>queue-override
config>service>epipe>sap>ingress>queue-override
Description
This command specifies the ID of the queue whose parameters are to be overridden.
Parameters
queue-id — The queue ID whose parameters are to be overridden.
Values
330
1 to 32
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
create — This keyword is mandatory when creating a queue.
adaptation-rule
Syntax
adaptation-rule [pir adaptation-rule}] [cir adaptation-rule}]
no adaptation-rule
Context
config>service>apipe>sap>egress>queue-override>queue
config>service>apipe>sap>ingress>queue-override>queue
config>service>fpipe>sap>egress>queue-override>queue
config>service>fpipe>sap>ingress>queue-override>queue
config>service>ipipe>sap>egress>queue-override>queue
config>service>ipipe>sap>ingress>queue-override>queue
config>service>epipe>sap>egress>queue-override>queue
config>service>epipe>sap>ingress>queue-override>queue
Description
This command can be used to override specific attributes of the specified queue’s adaptation
rule parameters. The adaptation rule controls the method used by the system to derive the
operational CIR and PIR settings when the queue is provisioned in hardware. For the CIR
and PIR parameters individually, the system attempts to find the best operational rate
depending on the defined constraint.
The no form of the command removes any explicitly defined constraints used to derive the
operational CIR and PIR created by the application of the policy. When a specific adaptationrule is removed, the default constraints for rate and cir apply.
Default
Parameters
no adaptation-rule
pir — The pir parameter defines the constraints enforced when adapting the PIR rate
defined within the queue queue-id rate command. The pir parameter requires a
qualifier that defines the constraint used when deriving the operational PIR for the
queue. When the rate command is not specified, the default applies.
cir — The cir parameter defines the constraints enforced when adapting the CIR rate
defined within the queue queue-id rate command. The cir parameter requires a
qualifier that defines the constraint used when deriving the operational CIR for the
queue. When the cir parameter is not specified, the default constraint applies.
adaptation-rule — Specifies the criteria to use to compute the operational CIR and PIR
values for this queue, while maintaining a minimum offset.
Values
max — The max (maximum) keyword is mutually exclusive with the
min and closest options. When max is defined, the operational PIR
for the queue will be equal to or less than the administrative rate
specified using the rate command.
min — The min (minimum) keyword is mutually exclusive with the
max and closest options. When min is defined, the operational PIR
for the queue will be equal to or greater than the administrative rate
specified using the rate command.
Issue: 01
3HE 11970 AAAA TQZZA 01
331
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
closest — The closest parameter is mutually exclusive with the
min and max parameter. When closest is defined, the operational
PIR for the queue will be the rate closest to the rate specified using
the rate command.
avg-frame-overhead
Syntax
Context
Description
avg-frame-overhead percent
no avg-frame-overhead
config>service>apipe>sap>egress>queue-override>queue
config>service>cpipe>sap>egress>queue-override>queue
config>service>epipe>sap>egress>queue-override>queue
This command configures the average frame overhead to define the average percentage that
the offered load to a queue will expand during the frame encapsulation process before
sending traffic on-the-wire. While the avg-frame-overhead value may be defined on any
queue, it is only used by the system for queues that egress a SONET or SDH port or channel.
Queues operating on egress Ethernet ports automatically calculate the frame encapsulation
overhead based on a 20 byte per packet rule (8 bytes for preamble and 12 bytes for InterFrame Gap).
When calculating the frame encapsulation overhead for port scheduling purposes, the
system determines the following values:
• Offered-load — The offered-load of a queue is calculated by starting with the queue
depth in octets, adding the received octets at the queue and subtracting queue discard
octets. The result is the number of octets the queue has available to transmit. This is the
packet based offered-load.
• Frame encapsulation overhead — Using the avg-frame-overhead parameter, the frame
encapsulation overhead is simply the queue’s current offered-load (how much has been
received by the queue) multiplied by the avg-frame-overhead. If a queue had an offered
load of 10000 octets and the avg-frame-overhead equals 10%, the frame encapsulation
overhead would be 10000 x 0.1 or 1000 octets.
For egress Ethernet queues, the frame encapsulation overhead is calculated by
multiplying the number of offered-packets for the queue by 20 bytes. If a queue was
offered 50 packets then the frame encapsulation overhead would be 50 x 20 or 1000
octets.
• Frame based offered-load — The frame based offered-load is calculated by adding the
offered-load to the frame encapsulation overhead. If the offered-load is 10000 octets and
the encapsulation overhead was 1000 octets, the frame based offered-load would equal
11000 octets.
332
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
• Packet to frame factor — The packet to frame factor is calculated by dividing the frame
encapsulation overhead by the queue’s offered-load (packet based). If the frame
encapsulation overhead is 1000 octets and the offered-load is 10000 octets then the
packet to frame factor would be 1000 / 10000 or 0.1. When in use, the avg-frameoverhead will be the same as the packet to frame factor making this calculation
unnecessary.
• Frame based CIR — The frame based CIR is calculated by multiplying the packet to
frame factor with the queue’s configured CIR and then adding that result to that CIR. If
the queue CIR is set at 500 octets and the packet to frame factor equals 0.1, the frame
based CIR would be 500 x 1.1 or 550 octets.
• Frame based within-cir offered-load — The frame based within-cir offered-load is the
portion of the frame based offered-load considered to be within the frame-based CIR.
The frame based within-cir offered-load is the lesser of the frame based offered-load and
the frame based CIR. If the frame based offered-load equaled 11000 octets and the
frame based CIR equaled 550 octets, the frame based within-cir offered-load would be
limited to 550 octets. If the frame based offered-load equaled 450 octets and the frame
based CIR equaled 550 octets, the frame based within-cir offered-load would equal 450
octets (or the entire frame based offered-load).
As a special case, when a queue or associated intermediate scheduler is configured with
a CIR-weight equal to 0, the system automatically sets the queue’s frame based withincir offered-load to 0, preventing it from receiving bandwidth during the port scheduler’s
within-cir pass.
• Frame based PIR — The frame based PIR is calculated by multiplying the packet to
frame factor with the queue’s configured PIR and then adding the result to that PIR. If
the queue PIR is set to 7500 octets and the packet to frame factor equals 0.1, the frame
based PIR would be 7500 x 1.1 or 8250 octets.
• Frame based within-pir offered-load — The frame based within-pir offered-load is the
portion of the frame based offered-load considered to be within the frame based PIR.
The frame based within-pir offered-load is the lesser of the frame based offered-load and
the frame based PIR. If the frame based offered-load equaled 11000 octets and the
frame based PIR equaled 8250 octets, the frame based within-pir offered-load would be
limited to 8250 octets. If the frame based offered-load equaled 7000 octets and the
frame based PIR equaled 8250 octets, the frame based within-pir offered load would
equal 7000 octets.
Port scheduler operation using frame transformed rates — The port scheduler uses the frame
based rates to figure the maximum rates that each queue may receive during the within-cir
and above-cir bandwidth allocation passes. During the within-cir pass, a queue may receive
up to its frame based within-cir offered-load. The maximum it may receive during the abovecir pass is the difference between the frame based within-pir offered load and the amount of
actual bandwidth allocated during the within-cir pass.
On the 7450 ESS and 7750 SR, SAP and subscriber SLA-profile average frame overhead
override — The average frame overhead parameter on a sap-egress may be overridden at
an individual egress queue basis. On each SAP and within the sla-profile policy used by
subscribers an avg-frame-overhead command may be defined under the queue-override
context for each queue. When overridden, the queue instance will use its local value for the
average frame overhead instead of the sap-egress defined overhead.
Issue: 01
3HE 11970 AAAA TQZZA 01
333
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
The no form of this command restores the average frame overhead parameter for the queue
to the default value of 0 percent. When set to 0, the system uses the packet based queue
statistics for calculating port scheduler priority bandwidth allocation. If the no avg-frameoverhead command is executed in a queue-override queue id context, the avg-frameoverhead setting for the queue within the sap-egress QoS policy takes effect.
Default
Parameters
0
percent — This parameter sets the average amount of packet-to-frame encapsulation
overhead expected for the queue. This value is not used by the system for egress
Ethernet queues.
Values
0.00 to 100.00
burst-limit
Syntax
Context
Description
burst-limit {default | size [byte | kilobyte]}
no burst-limit
config>service>apipe>sap>egress>queue-override>queue
config>service>apipe>sap>ingress>queue-override>queue
config>service>cpipe>sap>egress>queue-override>queue
config>service>cpipe>sap>ingress>queue-override>queue
config>service>fpipe>sap>egress>queue-override>queue
config>service>fpipe>sap>ingress>queue-override>queue
config>service>ipipe>sap>egress>queue-override>queue
config>service>ipipe>sap>ingress>queue-override>queue
config>service>epipe>sap>egress>queue-override>queue
config>service>epipe>sap>ingress>queue-override>queue
The queue burst-limit command is used to define an explicit shaping burst size for a queue.
The configured size defines the shaping leaky bucket threshold level that indicates the
maximum burst over the queue’s shaping rate.
The burst-limit command is supported under the sap-ingress and sap-egress QoS policy
queues. The command is also supported under the ingress and egress queue-grouptemplates queues.
The no form of this command is used to restore the default burst limit to the specified queue.
This is equivalent to specifying burst-limit default within the QoS policies or queue group
templates. When specified within a queue-override queue context, any current burst limit
override for the queue will be removed and the queue’s burst limit will be controlled by its
defining policy or template.
Parameters
334
default — The default parameter is mutually exclusive to specifying an explicit size
value. When burst-limit default is executed, the queue is returned to the system
default value.
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
size — When a numeric value is specified (size), the system interprets the value as an
explicit burst limit size. The value is expressed as an integer and by default is
interpreted as the burst limit in kilobytes. If the value is intended to be interpreted in
bytes, the byte qualifier must be added following size.
Values
1 to 14000 (14000 or 14000000 depending on bytes or kilobytes)
Default
No default for size, use the default keyword to specify default burst
limit
byte — The bytes qualifier is used to specify that the value given for size must be
interpreted as the burst limit in bytes. The byte qualifier is optional and mutually
exclusive with the kilobytes qualifier.
kilobyte — The kilobyte qualifier is used to specify that the value given for size must be
interpreted as the burst limit in kilobytes. The kilobyte qualifier is optional and
mutually exclusive with the bytes qualifier. If neither bytes nor kilobytes is specified,
the default qualifier is kilobytes.
cbs
Syntax
Context
Description
cbs size-in-kbytes
no cbs
config>service>apipe>sap>egress>queue-override>queue
config>service>apipe>sap>ingress>queue-override>queue
config>service>cpipe>sap>egress>queue-override>queue
config>service>cpipe>sap>ingress>queue-override>queue
config>service>fpipe>sap>egress>queue-override>queue
config>service>fpipe>sap>ingress>queue-override>queue
config>service>ipipe>sap>egress>queue-override>queue
config>service>ipipe>sap>ingress>queue-override>queue
config>service>epipe>sap>egress>queue-override>queue
config>service>epipe>sap>ingress>queue-override>queue
This command can be used to override specific attributes of the specified queue’s CBS
parameters.
It is permissible, and possibly desirable, to oversubscribe the total CBS reserved buffers for
a given access port egress buffer pool. Oversubscription may be desirable due to the
potential large number of service queues and the economy of statistical multiplexing the
individual queue’s CBS setting into the defined reserved total.
When oversubscribing the reserved total, it is possible for a queue depth to be lower than its
CBS setting and still not receive a buffer from the buffer pool for an ingress frame. As more
queues are using their CBS buffers and the total in use exceeds the defined reserved total,
essentially the buffers are being removed from the shared portion of the pool without the
shared in use average and total counts being decremented. This can affect the operation of
the high and low priority RED slopes on the pool, causing them to miscalculate when to start
randomly to drop packets.
Issue: 01
3HE 11970 AAAA TQZZA 01
335
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
The no form of this command returns the CBS size to the default value.
Default
Parameters
no cbs
size-in-kbytes — The size parameter is an integer expression of the number of kilobytes
reserved for the queue. If a value of 10KBytes is desired, enter the value 10. A value
of 0 specifies that no reserved buffers are required by the queue (a minimal reserved
size can still be applied for scheduling purposes).
Values
0 to 131072, default
drop-tail
Syntax
Context
Description
drop-tail
config>service>apipe>sap>egress>queue-override>queue
config>service>apipe>sap>ingress>queue-override>queue
config>service>cpipe>sap>egress>queue-override>queue
config>service>cpipe>sap>ingress>queue-override>queue
config>service>fpipe>sap>egress>queue-override>queue
config>service>fpipe>sap>ingress>queue-override>queue
config>service>ipipe>sap>egress>queue-override>queue
config>service>ipipe>sap>ingress>queue-override>queue
config>service>epipe>sap>egress>queue-override>queue
config>service>epipe>sap>ingress>queue-override>queue
This command enters the context to configure queue drop tail parameters.
low
Syntax
Context
Description
336
low
config>service>apipe>sap>egress>queue-override>queue>drop-tail
config>service>apipe>sap>ingress>queue-override>queue>drop-tail
config>service>cpipe>sap>egress>queue-override>queue>drop-tail
config>service>cpipe>sap>ingress>queue-override>queue>drop-tail
config>service>fpipe>sap>egress>queue-override>queue>drop-tail
config>service>fpipe>sap>ingress>queue-override>queue>drop-tail
config>service>ipipe>sap>egress>queue-override>queue>drop-tail
config>service>ipipe>sap>ingress>queue-override>queue>drop-tail
config>service>epipe>sap>egress>queue-override>queue>drop-tail
config>service>epipe>sap>ingress>queue-override>queue>drop-tail
This command enters the context to configure the queue low drop-tail parameters. The low
drop tail defines the queue depth beyond which out-of-profile packets are not accepted into
the queue and will be discarded.
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
percent-reduction-from-mbs
Syntax
Context
percent-reduction-from-mbs percent
no percent-reduction-from-mbs
config>service>apipe>sap>egress>queue-override>queue>drop-tail>low
config>service>apipe>sap>ingress>queue-override>queue>drop-tail>low
config>service>cpipe>sap>egress>queue-override>queue>drop-tail>low
config>service>cpipe>sap>ingress>queue-override>queue>drop-tail>low
config>service>fpipe>sap>egress>queue-override>queue>drop-tail>low
config>service>fpipe>sap>ingress>queue-override>queue>drop-tail>low
config>service>ipipe>sap>egress>queue-override>queue>drop-tail>low
config>service>ipipe>sap>ingress>queue-override>queue>drop-tail>low
config>service>epipe>sap>egress>queue-override>queue>drop-tail>low
config>service>epipe>sap>ingress>queue-override>queue>drop-tail>low
Description
This command overrides the low queue drop tail as a percentage reduction from the MBS of
the queue. For example, if a queue has an MBS of 600 kbytes and the percentage reduction
is configured to be 30% for the low drop tail, then the low drop tail will be at 420 kbytes. Any
out-of-profile packets will not be accepted into the queue if its depth is greater than this value,
and so will be discarded.
Parameters
percent — Specifies the percentage reduction from the MBS for a queue drop tail.
Values
0 to 100, default
mbs
Syntax
Context
Description
Issue: 01
mbs {size [bytes | kilobytes] | default}
no mbs
config>service>apipe>sap>egress>queue-override>queue
config>service>apipe>sap>ingress>queue-override>queue
config>service>cpipe>sap>egress>queue-override>queue
config>service>cpipe>sap>egress>queue-override>queue
config>service>cpipe>sap>ingress>queue-override>queue
config>service>fpipe>sap>egress>queue-override>queue
config>service>fpipe>sap>ingress>queue-override>queue
config>service>ipipe>sap>egress>queue-override>queue
config>service>ipipe>sap>ingress>queue-override>queue
config>service>epipe>sap>egress>queue-override>queue
config>service>epipe>sap>ingress>queue-override>queue
This command overrides specific attributes of the specified queue’s MBS parameters. A
queue uses its MBS value to determine whether it has exhausted all of its buffers while
enqueuing packets. Once the queue has exceeded the number of buffers allowed by the
MBS, all packets are discarded until packets have been drained from the queue.
3HE 11970 AAAA TQZZA 01
337
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
The sum of the MBS for all queues on an ingress access port can oversubscribe the total
amount of buffering available. When congestion occurs and buffers become scarce, access
to buffers is controlled by the RED slope associated with a packet. A queue that has not
exceeded its MBS is not guaranteed to have buffer available when needed or that the
packet’s RED slope will not force the discard of the packet. Setting proper CBS parameters
and controlling CBS oversubscription is one major safeguard to queue starvation (when a
queue does not receive its fair share of buffers). Another is properly setting the RED slope
parameters for the needs of services on this port or channel.
The no form of this command returns the MBS assigned to the queue to the default value.
Default
Parameters
default
size — The size parameter is an integer expression of the maximum number of kilobytes
or bytes of buffering allowed for the queue. A value of 0 causes the queue to discard
all packets.
Values
0 to 1073741824, default
bytes — Indicates that the size parameter value is expressed in bytes.
kilobytes — Indicates that the size parameter is expressed in kilobytes.
monitor-depth
Syntax
Context
Description
[no] monitor-depth
config>service>apipe>sap>egress>queue-override>queue
config>service>apipe>sap>ingress>queue-override>queue
config>service>cpipe>sap>egress>queue-override>queue
config>service>cpipe>sap>ingress>queue-override>queue
config>service>epipe>sap>egress>queue-override>queue
config>service>epipe>sap>ingress>queue-override>queue
config>service>fpipe>sap>egress>queue-override>queue
config>service>fpipe>sap>ingress>queue-override>queue
config>service>ipipe>sap>egress>queue-override>queue
config>service>ipipe>sap>ingress>queue-override>queue
This command enables queue depth monitoring for the specified queue.
The no form of the command removes queue depth monitoring for the specified queue.
parent
Syntax
Context
338
parent {[weight weight] [cir-weight cir-weight]}
no parent
config>service>epipe>sap>egress>queue-override>queue
config>service>epipe>sap>ingress>queue-override>queue
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
config>service>apipe>sap>egress>queue-override>queue
config>service>apipe>sap>ingress>queue-override>queue
Description
This command defines an optional parent scheduler that further governs the available
bandwidth given the queue aside from the queue’s PIR setting. When multiple schedulers
and/or queues share a child status with the parent scheduler, the weight or level parameters
define how this queue contends with the other children for the parent’s bandwidth.
Checks are not performed to see if a scheduler-name exists when the parent command is
defined on the queue. Scheduler names are configured in the config>qos>schedulerpolicy>tier level context. Multiple schedulers can exist with the scheduler-name and the
association pertains to a scheduler that should exist on the egress SAP as the policy is
applied and the queue created. When the queue is created on the egress SAP, the existence
of the scheduler-name is dependent on a scheduler policy containing the scheduler-name
being directly or indirectly applied (through a multi-service customer site) to the egress SAP.
If the scheduler-name does not exist, the queue is placed in the orphaned operational state.
The queue will accept packets but will not be bandwidth limited by a virtual scheduler or the
scheduler hierarchy applied to the SAP. The orphaned state must generate a log entry and a
trap message. The SAP which the queue belongs to must also depict an orphan queue
status. The orphaned state of the queue is automatically cleared when the scheduler-name
becomes available on the egress SAP.
The parent scheduler can be made unavailable due to the removal of a scheduler policy or
scheduler. When an existing parent scheduler is removed or inoperative, the queue enters
the orphaned state mentioned above and automatically return to normal operation when the
parent scheduler is available again.
When a parent scheduler is defined without specifying weight or strict parameters, the default
bandwidth access method is weight with a value of 1.
The no form of the command removes a child association with a parent scheduler. If a parent
association does not currently exist, the command has no effect and returns without an error.
Once a parent association has been removed, the former child queue attempts to operate
based on its configured rate parameter. Removing the parent association on the queue within
the policy takes effect immediately on all queues using the SAP egress QoS policy.
Parameters
Issue: 01
weight — These optional keywords are mutually exclusive to the level keyword. The
weight defines the relative weight of this queue in comparison to other child
schedulers, policers, and queues while vying for bandwidth on the parent schedulername. Any policers, queues, or schedulers defined as weighted receive no parental
bandwidth until all policers, queues, and schedulers with a higher (numerically larger)
priority on the parent have reached their maximum bandwidth or are idle.
3HE 11970 AAAA TQZZA 01
339
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
All weight values from all weighted active policers, queues, and schedulers with a
common parent scheduler are added together. Then, each individual active weight is
divided by the total, deriving the percentage of remaining bandwidth provided to the
policer, queue, or scheduler. A weight is considered to be active when the pertaining
policer, queue, or scheduler has not reached its maximum rate and still has packets
to transmit. All child policers, queues, and schedulers with a weight of 0 are
considered to have the lowest priority level and are not serviced until all non-zero
weighted policers, queues, and schedulers at that level are operating at the
maximum bandwidth or are idle.
Values
0 to 100
Default
1
cir-weight — Defines the weight the queue or scheduler will use at the within-cir port
priority level (defined by the cir-level parameter). The weight is specified as an
integer value from 0 to 100 with 100 being the highest weight. When the cir-weight
parameter is set to a value of 0 (the default value), the policer, queue, or scheduler
does not receive bandwidth during the port schedulers within-cir pass and the cirlevel parameter is ignored. If the cir-weight parameter is 1 or greater, the cir-level
parameter comes into play.
Values
0 to 100
percent-rate
Syntax
Context
Description
percent-rate pir-percent [cir cir-percent]
config>service>epipe>sap>egress>queue-override>queue
The percent-rate command supports a queue’s shaping rate and CIR rate as a percentage
of the egress port’s line rate. When the rates are expressed as a percentage within the
template, the actual rate used per instance of the queue group queue-id will vary based on
the port speed. For example, when the same template is used to create a queue group on a
1-Gb and a 10-Gb Ethernet port, the queue’s rates will be 10 times greater on the 10 Gb port
due to the difference in port speeds. This enables the same template to be used on multiple
ports without needing to use port based queue overrides to modify a queue’s rate to get the
same relative performance from the queue.
If the port’s speed changes after the queue is created, the queue’s shaping and CIR rates will
be recalculated based on the defined percentage value.
The rate and percent-rate commands override one another. If the current rate for a queue is
defined using the percent-rate command and the rate command is executed, the percent-rate
values are deleted. In a similar fashion, the percent-rate command causes any rate command
values to be deleted. A queue’s rate may dynamically be changed back and forth from a
percentage to an explicit rate at anytime.
An egress port queue group queue rate override may be expressed as either a percentage
or an explicit rate independent on how the queue's template rate is expressed.
340
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
The no form of this command returns the queue to its default shaping rate and cir rate. When
no percent-rate is defined within a port egress queue group queue override, the queue
reverts to the defined shaping and CIR rates within the egress queue group template
associated with the queue.
Parameters
pir-percent — Specifies the queue’s shaping rate as a percentage of line rate. The line
rate associated with the queue’s port may dynamically change due to configuration
or auto-negotiation. The line rate may also be affected by an egress port scheduler
defined max-rate.
Values
0.01 to 100.00
Default
100.00
cir-percent — Specifies the queue’s committed scheduling rate as a percentage of line
rate. The line rate associated with the queue’s port may dynamically change due to
configuration or auto-negotiation. The line rate may also be affected by an egress
port scheduler defined max-rate.
Values
0.00 to 100.00
Default
100.00
rate
Syntax
Context
Description
rate pir-rate [cir cir-rate]
no rate
config>service>apipe>sap>egress>queue-override>queue
config>service>apipe>sap>ingress>queue-override>queue
config>service>cpipe>sap>egress>queue-override>queue
config>service>cpipe>sap>ingress>queue-override>queue
config>service>fpipe>sap>egress>queue-override>queue
config>service>fpipe>sap>ingress>queue-override>queue
config>service>ipipe>sap>egress>queue-override>queue
config>service>ipipe>sap>ingress>queue-override>queue
config>service>epipe>sap>egress>queue-override>queue
config>service>epipe>sap>ingress>queue-override>queue
This command can be used to override specific attributes of the specified queue’s Peak
Information Rate (PIR) and the Committed Information Rate (CIR) parameters.
The PIR defines the maximum rate that the queue can transmit packets out an egress
interface (for SAP egress queues). Defining a PIR does not necessarily guarantee that the
queue can transmit at the intended rate. The actual rate sustained by the queue can be
limited by oversubscription factors or available egress bandwidth.
Issue: 01
3HE 11970 AAAA TQZZA 01
341
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
The CIR defines the rate at which the system prioritizes the queue over other queues
competing for the same bandwidth. In-profile and then out-of-profile packets are preferentially
queued by the system at egress and at subsequent next hop nodes where the packet can
traverse. To be properly handled throughout the network, the packets must be marked
accordingly for profiling at each hop.
The CIR can be used by the queue’s parent commands cir-level and cir-weight parameters
to define the amount of bandwidth considered to be committed for the child queue during
bandwidth allocation by the parent scheduler.
The rate command can be executed at any time, altering the PIR and CIR rates for all queues
created through the association of the SAP egress QoS policy with the queue-id.
The no form of the command returns all queues created with the queue-id by association with
the QoS policy to the default PIR and CIR parameters (max, 0).
Default
Parameters
rate max cir 0 — The max default specifies the amount of bandwidth in kilobits per second
(thousand bits per second). The max value is mutually exclusive to the pir-rate value.
pir-rate — Defines the administrative PIR rate, in kilobits per second, for the queue.
When the rate command is executed, a valid PIR setting must be explicitly defined.
When the rate command has not been executed, the default PIR of max is assumed.
Fractional values are not allowed and must be given as a positive integer.
The actual PIR rate is dependent on the queue’s adaptation-rule parameters and
the actual hardware where the queue is provisioned.
Values
1 to 3200000000, max
Default
max
cir-rate — The cir parameter overrides the default administrative CIR used by the queue.
When the rate command is executed, a CIR setting is optional. When the rate
command has not been executed or the cir parameter is not explicitly specified, the
default CIR (0) is assumed.
Fractional values are not allowed and must be given as a positive integer. The sum
keyword specifies that the CIR be used as the summed CIR values of the children
schedulers, policers, or queues.
Values
0 to 3200000000, max, sum
Default
0
scheduler-override
Syntax
Context
342
[no] scheduler-override
config>service>apipe>sap>egress
config>service>apipe>sap>ingress
config>service>cpipe>sap>egress
config>service>cpipe>sap>ingress
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
config>service>fpipe>sap>egress
config>service>fpipe>sap>ingress
config>service>ipipe>sap>egress
config>service>ipipe>sap>ingress
config>service>epipe>sap>egress
config>service>epipe>sap>ingress
Description
This command specifies the set of attributes whose values have been overridden by
management on this virtual scheduler. Clearing a given flag will return the corresponding
overridden attribute to the value defined on the SAP's ingress scheduler policy.
scheduler
Syntax
Context
Description
[no] scheduler scheduler-name [create]
config>service>apipe>sap>egress>sched-override
config>service>apipe>sap>ingress>sched-override
config>service>cpipe>sap>egress>sched-override
config>service>cpipe>sap>ingress>sched-override
config>service>fpipe>sap>egress>sched-override
config>service>fpipe>sap>ingress>sched-override
config>service>ipipe>sap>egress>sched-override
config>service>ipipe>sap>ingress>sched-override
config>service>epipe>sap>egress>sched-override
config>service>epipe>sap>ingress>sched-override
This command can be used to override specific attributes of the specified scheduler name. A
scheduler defines bandwidth controls that limit each child (other schedulers, policers, and
queues) associated with the scheduler. Scheduler objects are created within the hierarchical
tiers of the policy. It is assumed that each scheduler created will have policers, queues or
other schedulers defined as child associations. The scheduler can be a child (take bandwidth
from a scheduler in a higher tier, except for schedulers created in tier 1). A total of 32
schedulers can be created within a single scheduler policy with no restriction on the
distribution between the tiers.
Each scheduler must have a unique name within the context of the scheduler policy; however
the same name can be reused in multiple scheduler policies. If scheduler-name already
exists within the policy tier level (regardless of the inclusion of the keyword create), the
context changes to that scheduler name for the purpose of editing the scheduler parameters.
Modifications made to an existing scheduler are executed on all instantiated schedulers
created through association with the policy of the edited scheduler. This can cause policers,
queues, or schedulers to become orphaned (invalid parent association) and adversely affect
the ability of the system to enforce service level agreements (SLAs).
If the scheduler-name exists within the policy on a different tier (regardless of the inclusion of
the keyword create), an error occurs and the current CLI context will not change.
Issue: 01
3HE 11970 AAAA TQZZA 01
343
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
If the scheduler-name does not exist in this or another tier within the scheduler policy, it is
assumed that an attempt is being made to create a scheduler of that name. The success of
the command execution is dependent on the following:
1. The maximum number of schedulers has not been configured.
2. The provided scheduler-name is valid.
3. The create keyword is entered with the command if the system is configured to require
it (enabled in the environment create command).
When the maximum number of schedulers has been exceeded on the policy, a configuration
error occurs and the command will not execute, nor will the CLI context change.
If the provided scheduler-name is invalid according to the criteria below, a name syntax error
will occur, the command will not execute, and the CLI context will not change.
Parameters
scheduler-name — The name of the scheduler.
Values
Valid names consist of any string up to 32 characters long
composed of printable, 7-bit ASCII characters. If the string contains
special characters (#, $, spaces, and so on), the entire string must
be enclosed within double quotes.
Default
None. Each scheduler must be explicitly created.
create — This optional keyword explicitly specifies that it is acceptable to create a
scheduler with the given scheduler-name. If the create keyword is omitted,
scheduler-name is not created when the system environment variable create is set
to true. This safeguard is meant to avoid accidental creation of system objects (such
as schedulers) while attempting to edit an object with a mistyped name or ID. The
keyword has no effect when the object already exists.
parent
Syntax
Context
344
parent [weight weight] [cir-weight cir-weight]
no parent
config>service>apipe>sap>ingress>sched-override>scheduler
config>service>apipe>sap>egress>sched-override>scheduler
config>service>cpipe>sap>ingress>sched-override>scheduler
config>service>cpipe>sap>egress>sched-override>scheduler
config>service>epipe>sap>ingress>sched-override>scheduler
config>service>epipe>sap>egress>sched-override>scheduler
config>service>fpipe>sap>ingress>sched-override>scheduler
config>service>fpipe>sap>egress>sched-override>scheduler
config>service>ipipe>sap>ingress>sched-override>scheduler
config>service>ipipe>sap>egress>sched-override>scheduler
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
Description
VLL Services
This command can be used to override the scheduler’s parent weight and cir-weight
information. The weights apply to the associated level/cir-level configured in the applied
scheduler policy. The scheduler name must exist in the scheduler policy applied to the
ingress or egress of the SAP or multi-service site.
The override weights are ignored if the scheduler does not have a parent command
configured in the scheduler policy – this allows the parent of the scheduler to be removed
from the scheduler policy without having to remove all of the SAP/MSS overrides. If the
parent scheduler does not exist causing the configured scheduler to be fostered on an egress
port scheduler, the override weights will be ignored and the default values used; this avoids
having non default weightings for fostered schedulers.
The no form of the command returns the scheduler’s parent weight and cir-weight to the value
configured in the applied scheduler policy.
Default
Parameters
no parent
weight — Weight defines the relative weight of this scheduler in comparison to other
child schedulers, policers, and queues at the same strict level defined by the level
parameter in the applied scheduler policy. Within the level, all weight values from
active children at that level are summed and the ratio of each active child’s weight to
the total is used to distribute the available bandwidth at that level. A weight is
considered to be active when the policer, queue, or scheduler the weight pertains to
has not reached its maximum rate and still has packets to transmit.
A 0 (zero) weight value signifies that the child scheduler will receive bandwidth only
after bandwidth is distributed to all other non-zero weighted children in the strict level.
Values
0 to 100
Default
1
cir-weight — The cir-weight keyword defines the relative weight of this scheduler in
comparison to other child schedulers, policers, and queues at the same cir-level
defined by the cir-level parameter in the applied scheduler policy. Within the strict
cir-level, all cir-weight values from active children at that level are summed and the
ratio of each active child’s cir-weight to the total is used to distribute the available
bandwidth at that level. A cir-weight is considered to be active when the policer,
queue, or scheduler that the cir-weight pertains to has not reached the CIR and still
has packets to transmit.
A 0 (zero) cir-weight value signifies that the child scheduler will receive bandwidth
only after bandwidth is distributed to all other non-zero weighted children in the strict
cir-level.
Values
0 to 100
Default
1
rate
Syntax
Issue: 01
rate pir-rate [cir cir-rate]
3HE 11970 AAAA TQZZA 01
345
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
no rate
Context
Description
config>service>apipe>sap>egress>sched-override>scheduler
config>service>apipe>sap>ingress>sched-override>scheduler
config>service>cpipe>sap>egress>sched-override>scheduler
config>service>cpipe>sap>ingress>sched-override>scheduler
config>service>fpipe>sap>egress>sched-override>scheduler
config>service>fpipe>sap>ingress>sched-override>scheduler
config>service>ipipe>sap>egress>sched-override>scheduler
config>service>ipipe>sap>ingress>sched-override>scheduler
config>service>epipe>sap>egress>sched-override>scheduler
config>service>epipe>sap>ingress>sched-override>scheduler
This command can be used to override specific attributes of the specified scheduler rate. The
rate command defines the maximum bandwidth that the scheduler can offer its child policers,
queues or schedulers. The maximum rate is limited to the amount of bandwidth the scheduler
can receive from its parent scheduler. If the scheduler has no parent, the maximum rate is
assumed to be the amount available to the scheduler. When a parent is associated with the
scheduler, the CIR parameter provides the amount of bandwidth to be considered during the
parent scheduler’s ‘within CIR’ distribution phase.
The actual operating rate of the scheduler is limited by bandwidth constraints other than its
maximum rate. The scheduler’s parent scheduler may not have the available bandwidth to
meet the scheduler’s needs or the bandwidth available to the parent scheduler could be
allocated to other child schedulers or child policers or queues on the parent based on higher
priority. The children of the scheduler may not need the maximum rate available to the
scheduler due to insufficient offered load or limits to their own maximum rates.
When a scheduler is defined without specifying a rate, the default rate is max. If the scheduler
is a root scheduler (no parent defined), the default maximum rate must be changed to an
explicit value. Without this explicit value, the scheduler will assume that an infinite amount of
bandwidth is available and allow all child policers, queues, and schedulers to operate at their
maximum rates.
The no form of this command returns the scheduler’s PIR and CIR parameters to the values
configured in the applied scheduler policy.
Parameters
pir-rate — The pir parameter accepts the max keyword or a value of 1 to 3200000000.
Any other value will result in an error without modifying the current PIR rate.
Values
1 to 3200000000, max
Default
max
cir cir-rate — The cir parameter accepts a value of 0 to 3200000000 or the max keyword.
Any other value will result in an error without modifying the current CIR rate.
If the cir parameter is set to max, then the CIR rate is set to infinity but bounded by
the PIR rate.
346
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
The sum keyword specifies that the CIR will be used as the summed CIR values of
the children schedulers, policers, or queues.
Values
0 to 3200000000, max, sum
Default
sum
scheduler-policy
Syntax
Context
Description
scheduler-policy scheduler-policy-name
no scheduler-policy
config>service>apipe>sap>ingress
config>service>apipe>sap>egress
config>service>cpipe>sap>ingress
config>service>cpipe>sap>egress
config>service>fpipe>sap>ingress
config>service>fpipe>sap>egress
config>service>ipipe>sap>ingress
config>service>ipipe>sap>egress
config>service>epipe>sap>ingress
config>service>epipe>sap>egress
This command applies an existing scheduler policy to an ingress or egress scheduler used
by SAP queues associated with this multi-service customer site. The schedulers defined in
the scheduler policy can only be created once the customer site has been appropriately
assigned to a chassis port, channel or slot. Scheduler policies are defined in the
config>qos>scheduler-policy scheduler-policy-name context.
The no form of this command removes the configured ingress or egress scheduler policy
from the multi-service customer site. When the policy is removed, the schedulers created due
to the policy are removed also making them unavailable for the ingress SAP queues
associated with the customer site. Policers or queues that lose their parent scheduler
association are deemed to be orphaned and are no longer subject to a virtual scheduler. The
SAPs that have policers or queues reliant on the removed schedulers enter into an
operational state depicting the orphaned status of one or more policers or queues. When the
no scheduler-policy command is executed, the customer site ingress or egress node will
not contain an applied scheduler policy.
Parameters
Issue: 01
scheduler-policy-name — The scheduler-policy-name parameter applies an existing
scheduler policy that was created in the config>qos>scheduler-policy schedulerpolicy-name context to create the hierarchy of ingress or egress virtual schedulers.
The scheduler names defined within the policy are created and made available to any
ingress or egress queues and to egress policers managed by HQoS created on
associated SAPs.
3HE 11970 AAAA TQZZA 01
347
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
vlan-translation
Syntax
Context
Description
vlan-translation {vlan-id | copy-outer}
no vlan-translation
config>service>epipe>sap>ingress
This command configures ingress VLAN translation. If enabled with an explicit VLAN value,
the preserved vlan-id will be overwritten with this value. This setting is applicable to dot1q
encapsulated ports. If enabled with “copy-outer” keyword, the outer vlan-id will be copied to
inner position on QinQ encapsulated ports. The feature is not supported on default-dot1q
saps (1/1/1:* and 1/1/1:0), nor on TopQ saps.
The no version of the command sets the default value and no action will be taken.
Default
Parameters
By default, the preserved VLAN values will not be overwritten.
vlan-id — Specifies that the preserved vlan-id will be overwritten with this value.
Values
0 to 4094
copy-outer — Keyword specifies to use the outer VLAN ID.
match-qinq-dot1p
Syntax
match-qinq-dot1p {top | bottom}
no match-qinq-dot1p de
Context
config>service>ipipe>sap>ingress
config>service>epipe>sap>ingress
Description
This command specifies which Dot1Q tag position Dot1P bits in a QinQ encapsulated packet
should be used to evaluate Dot1P QoS classification.
The match-qinq-dot1p command allows the top or bottom PBits to be used when evaluating
the applied sap-ingress QoS policy’s Dot1P entries. The top and bottom keywords specify
which position should be evaluated for QinQ encapsulated packets.
The setting also applies to classification based on the DE indicator bit.
The no form of this command reverts the dot1p and de bits matching to the default tag.
By default, the bottom most service delineating Dot1Q tags Dot1P bits are used. Table 15
defines the default behavior for Dot1P evaluation.
Table 15
348
Default QinQ and TopQ SAP Dot1P Evaluation
Port / SAP Type
Existing Packet Tags
PBits Used for Match
Null
None
None
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
Table 15
Default
VLL Services
Default QinQ and TopQ SAP Dot1P Evaluation (Continued)
Port / SAP Type
Existing Packet Tags
PBits Used for Match
Null
Dot1P (VLAN-ID 0)
Dot1P PBits
Null
Dot1Q
Dot1Q PBits
Null
TopQ BottomQ
TopQ PBits
Null
TopQ (No BottomQ)
TopQ PBits
Dot1Q
None (Default SAP)
None
Dot1Q
Dot1P (Default SAP VLAN-ID 0)
Dot1P PBits
Dot1Q
Dot1Q
Dot1Q PBits
QinQ / TopQ
TopQ
TopQ PBits
QinQ / TopQ
TopQ BottomQ
TopQ PBits
QinQ / QinQ
TopQ BottomQ
BottomQ PBits
no match-qinq-dot1p (no filtering based on p-bits)
(top or bottom must be specified to override the default QinQ dot1p behavior)
Parameters
top — The top parameter is mutually exclusive to the bottom parameter. When the top
parameter is specified, the top most PBits are used (if existing) to match any dot1p
dot1p-value entries. Table 16 defines the dot1p evaluation behavior when the top
parameter is specified.
Table 16
Issue: 01
Top Position QinQ dot1P Evaluation Behavior
Port / SAP Type
Existing Packet Tags
PBits Used for Match
Null
None
None
Null
Dot1P (VLAN-ID 0)
Dot1P PBits
Null
Dot1Q
Dot1Q PBits
Null
TopQ BottomQ
TopQ PBits
Null
TopQ (No BottomQ)
TopQ PBits
Dot1Q
None (Default SAP)
None
Dot1Q
Dot1P (Default SAP VLAN-ID 0)
Dot1P PBits
Dot1Q
Dot1Q
Dot1Q PBits
QinQ / TopQ
TopQ
TopQ PBits
3HE 11970 AAAA TQZZA 01
349
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
Table 16
Top Position QinQ dot1P Evaluation Behavior (Continued)
Port / SAP Type
Existing Packet Tags
PBits Used for Match
QinQ / TopQ
TopQ BottomQ
TopQ PBits
QinQ / QinQ
TopQ BottomQ
TopQ PBits
bottom — The bottom parameter is mutually exclusive to the top parameter. When the
bottom parameter is specified, the bottom most PBits are used (if existing) to match
any dot1p dot1p-value entries. Table 17 defines the dot1p evaluation behavior when
the bottom parameter is specified.
Table 17
Port / SAP Type
Existing Packet Tags
PBits Used for Match
Null
None
None
Null
Dot1P (VLAN-ID 0)
Dot1P PBits
Null
Dot1Q
Dot1Q PBits
Null
TopQ BottomQ
TopQ PBits
Null
TopQ (No BottomQ)
TopQ PBits
Dot1Q
None (Default SAP)
None
Dot1Q
Dot1P (Default SAP VLAN-ID 0)
Dot1P PBits
Dot1Q
Dot1Q
Dot1Q PBits
QinQ / TopQ
TopQ
TopQ PBits
QinQ / TopQ
TopQ BottomQ
TopQ PBits
QinQ / QinQ
TopQ BottomQ
BottomQ PBits
Table 18
350
Bottom Position QinQ and TopQ SAP Dot1P Evaluation
Egress SAP Types
Egress SAP
Type
Ingress Packet Preserved
Dot1P State
Marked (or Remarked) PBits
Null
No preserved Dot1P bits
None
Null
Preserved Dot1P bits
Preserved tag PBits remarked using
dot1p-value
Dot1Q
No preserved Dot1P bits
New PBits marked using dot1pvalue
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
Table 18
VLL Services
Egress SAP Types (Continued)
Egress SAP
Type
Ingress Packet Preserved
Dot1P State
Marked (or Remarked) PBits
Dot1Q
Preserved Dot1P bits
Preserved tag PBits remarked using
dot1p-value
TopQ
No preserved Dot1P bits
TopQ PBits marked using dot1pvalue
TopQ
Preserved Dot1P bits (used as
TopQ and BottomQ PBits)
TopQ PBits marked using dot1pvalue, BottomQ PBits preserved
QinQ
No preserved Dot1P bits
TopQ PBits and BottomQ PBits
marked using dot1p-value
QinQ
Preserved Dot1P bits (used as
TopQ and BottomQ PBits)
TopQ PBits and BottomQ PBits
marked using dot1p-value
The QinQ and TopQ SAP PBit/DEI bit marking follows the default behavior defined
in the table above when qinq-mark-top-only is not specified.
The dot1p dot1p-value command must be configured without the qinq-mark-top-only
parameter to remove the TopQ PBits only marking restriction.
Note that a QinQ-encapsulated Ethernet port can have two different sap types:
For a TopQ SAP type, only the outer (top) tag is explicitly specified. For example, sap
1/1/1:10.*
For QinQ SAP type, both inner (bottom) and outer (top) tags are explicitly specified.
For example, sap 1/1/1:10.100.
2.17.2.8
VLL Frame Relay Commands
frame-relay
Syntax
Context
Description
Issue: 01
frame-relay
config>service>apipe>sap
config>service>fpipe>sap
config>service>ipipe>sap
config>service>epipe>sap
This command enters the context to configure Frame Relay parameters.
3HE 11970 AAAA TQZZA 01
351
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
frf-12
Syntax
Context
Description
[no] frf-12
config>service>fpipe>sap>frame-relay
config>service>ipipe>sap>frame-relay
config>service>epipe>sap>frame-relay
This command enables the use of FRF12 headers.
The no form of the command disables the use of FRF12 headers.
ete-fragment-threshold
Syntax
Context
Description
ete-fragment-threshold threshold
no ete-fragment-threshold
config>service>fpipe>sap>frame-relay>frf-12
config>service>ipipe>sap>frame-relay>frf-12
config>service>epipe>sap>frame-relay>frf-12
This command specifies the maximum length of a fragment to be transmitted.
The no form of the command reverts to the default.
Parameters
threshold — The maximum length of a fragment to be transmitted.
Values
128 to 512
Default
0
interleave
Syntax
Context
Description
[no] interleave
config>service>epipe>sap>frame-relay>frf.12
config>service>ipipe>sap>frame-relay>frf.12
This command enables interleaving of high priority frames and low-priority frame fragments
within a FR SAP using FRF.12 end-to-end fragmentation.
When this option is enabled, only frames of the FR SAP non expedited forwarding class
queues are subject to fragmentation. The frames of the FR SAP expedited queues are
interleaved, with no fragmentation header, among the fragmented frames. In effect, this
provides a behavior like in MLPPP Link Fragment Interleaving (LFI).
352
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
When this option is disabled, frames of all the FR SAP forwarding class queues are subject
to fragmentation. The fragmentation header is however not included when the frame size is
smaller than the user configured fragmentation size. In this mode, the SAP transmits all
fragments of a frame before sending the next full or fragmented frame.
The receive direction of the FR SAP supports both modes of operation concurrently, with and
without fragment interleaving.
The no form of this command restores the default mode of operation.
Default
no interleave
scheduling-class
Syntax
scheduling-class class-id
Context
config>service>apipe>sap>frame-relay
config>service>fpipe>sap>frame-relay
config>service>ipipe>sap>frame-relay
config>service>epipe>sap>frame-relay
Description
This command specifies the scheduling class to use for this SAP.
Parameters
class-id — Specifies the scheduling class to use for this sap.
2.17.2.9
Values
0 to 3
Default
0
VLL SDP Commands
spoke-sdp
Syntax
Context
Description
Issue: 01
spoke-sdp sdp-id[:vc-id] [vc-type {ether | vlan}] [no-endpoint]
spoke-sdp sdp-id[:vc-id] [vc-type {ether | vlan}] endpoint endpoint-name [icb]
no spoke-sdp sdp-id[:vc-id]
config>service>cpipe
config>service>epipe
This command binds a service to an existing Service Distribution Point (SDP). A spoke SDP
is treated like the equivalent of a traditional bridge “port” where flooded traffic received on the
spoke SDP is replicated on all other “ports” (other spoke and mesh SDPs or SAPs) and not
transmitted on the port it was received.
3HE 11970 AAAA TQZZA 01
353
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
The SDP has an operational state which determines the operational state of the SDP within
the service. For example, if the SDP is administratively or operationally down, the SDP for the
service will be down.
The SDP must already be defined in the config>service>sdp context in order to associate
an SDP with an Epipe, VPLS, VPRN, VPRN service. If the sdp sdp-id is not already
configured, an error message is generated. If the sdp-id does exist, a binding between that
sdp-id and the service is created.
SDPs must be explicitly associated and bound to a service. If an SDP is not bound to a
service, no far-end devices can participate in the service.
The no form of this command removes the SDP binding from the service. The SDP
configuration is not affected; only the binding of the SDP to a service. Once removed, no
packets are forwarded to the far-end router.
Default
Special Cases
No sdp-id is bound to a service.
Epipe — At most, only one sdp-id can be bound to an Epipe service. Since an Epipe is
a point-to-point service, it can have, at most, two end points. The two end points can
be one SAP and one SDP or two SAPs. Vc-switching VLLs are an exception. If the
VLL is a “vc-switching” VLL, then the two endpoints must both be SDPs.
L2TPv3 SDP types are only supported on Epipe services and not other xpipe
services.
Parameters
sdp-id — The SDP identifier.
Values
1 to 17407
vc-id — The virtual circuit identifier. The VC-ID is not used with L2TPv3 SDPs, however
it must be configured.
Values
1 to 4294967295
vc-type — This command overrides the default VC type signaled for the spoke or mesh
binding to the far end of the SDP. The VC type is a 15 bit-quantity containing a value
which represents the type of VC. The actual signaling of the VC type depends on the
signaling parameter defined for the SDP. If signaling is disabled, the vc-type
command can still be used to define the dot1q value expected by the far-end provider
equipment. A change of the bindings VC type causes the binding to signal the new
VC type to the far end when signaling is enabled.
VC types are derived according to IETF draft-martini-l2circuit-trans-mpls.
The VC type value for Ethernet is 0x0005.
The VC type value for an Ethernet VLAN is 0x0004.
The VC type value for a VPLS service is defined as 0x000B.
Values
ethernet
ether — Defines the VC type as Ethernet. The ethernet and vlan keywords are mutually
exclusive. When the VC type is not defined then the default is Ethernet for spoke
SDP bindings. Defining Ethernet is the same as executing no vc-type and restores
the default VC type for the spoke SDP binding.
354
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
vlan — Defines the VC type as VLAN. The top VLAN tag, if a VLAN tag is present, is
stripped from traffic received on the pseudowire, and a vlan-tag is inserted when
forwarding into the pseudowire. The ethernet and vlan keywords are mutually
exclusive. When the VC type is not defined then the default is Ethernet for spoke
SDP bindings.
The VLAN VC-type requires at least one dot1Q tag within each encapsulated
Ethernet packet transmitted to the far end.
Note: The system expects a symmetrical configuration with its peer, specifically it
expects to remove the same number of VLAN tags from received traffic as it adds to
transmitted traffic. As some of the related configuration parameters are local and not
communicated in the signaling plane, an asymmetrical behavior cannot always be
detected and so cannot be blocked. Consequently, protocol extractions will not
necessarily function for asymmetrical configurations as they would with a
symmetrical configurations resulting in an unexpected operation.
no-endpoint — Removes the association of a spoke SDP with an explicit endpoint
name.
endpoint-name — Specifies the name of the service endpoint.
icb — Configures the spoke SDP as an inter-chassis backup SDP binding.
spoke-sdp
Syntax
Context
Description
spoke-sdp sdp-id[:vc-id] [no-endpoint]
spoke-sdp sdp-id[:vc-id] endpoint endpoint-name [icb]
no spoke-sdp sdp-id[:vc-id]
config>service>apipe
config>service>fpipe
config>service>ipipe
config>service>cpipe
This command binds a service to an existing Service Distribution Point (SDP). A spoke SDP
is treated like the equivalent of a traditional bridge “port” where flooded traffic received on the
spoke SDP is replicated on all other “ports” (other spoke and mesh SDPs or SAPs) and not
transmitted on the port it was received.
The SDP has an operational state which determines the operational state of the SDP within
the service. For example, if the SDP is administratively or operationally down, the SDP for the
service will be down.
The SDP must already be defined in the config>service>sdp context in order to associate
an SDP with a service. If the sdp sdp-id is not already configured, an error message is
generated. If the sdp-id does exist, a binding between that sdp-id and the service is created.
SDPs must be explicitly associated and bound to a service. If an SDP is not bound to a
service, no far-end SR/ESS devices can participate in the service.
Issue: 01
3HE 11970 AAAA TQZZA 01
355
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
The no form of this command removes the SDP binding from the service. The SDP
configuration is not affected; only the binding of the SDP to a service. Once removed, no
packets are forwarded to the far-end router.
Default
Parameters
No sdp-id is bound to a service.
sdp-id — The SDP identifier.
Values
1 to 17407
vc-id — The virtual circuit identifier.
Values
1 to 4294967295
no-endpoint — Adds or removes a spoke SDP association.
endpoint-name — Specifies the name of the service endpoint.
icb — Configures the spoke SDP as an inter-chassis backup SDP binding.
entropy-label
Syntax
Context
Description
[no] entropy-label
config>service>epipe>spoke-sdp
config>service>ipipe>spoke-sdp
config>service>fpipe>spoke-sdp
config>service>vpls>spoke-sdp
config>service>vpls>mesh-sdp
config>service>pw-template
config>service>vpls>bgp-evpn>mpls
config>service>epipe>bgp-evpn>mpls
config>service>ies>if>spoke-sdp
config>service>vprn>if>spoke-sdp
config>service>vprn
This command enables or disables the use of entropy labels for spoke-SDPs.
If entropy-label is configured, the entropy label and ELI are inserted in packets for which at
least one LSP in the stack for the far-end of the tunnel used by the service has advertised
entropy-label-capability. If the tunnel is RSVP type, entropy-label can also be controlled
under the config>router>mpls or config>router>mpls>lsp contexts.
The entropy label and hash label features are mutually exclusive. The entropy label cannot
be configured on a spoke-SDP or service where the hash label feature has already been
configured.
Default
356
no entropy-label
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
hash-label
Syntax
Context
Description
hash-label [signal-capability]
no hash-label
config>service>epipe>spoke-sdp
config>service>fpipe>spoke-sdp
config>service>ipipe>spoke-sdp
config>service>pw-template
config>service>vprn
config>service>vprn>if>spoke-sdp
config>service>ies>if>spoke-sdp
This command enables the use of the hash label on a VLL, VPRN or VPLS service bound to
any MPLS type encapsulated SDP, as well as to a VPRN service that is using the auto-bindtunnel with the resolution-filter set to any MPLS tunnel type. This feature is not supported
on a service bound to a GRE SDP or for a VPRN service using the autobind mode with the
gre option. This feature is also not supported on multicast packets forwarded using RSVP
P2MP LPS or mLDP LSP in both the base router instance and in the multicast VPN (mVPN)
instance. It is, however, supported when forwarding multicast packets using an IES/VPRN
spoke-interface.
When this feature is enabled, the ingress data path is modified such that the result of the hash
on the packet header is communicated to the egress data path for use as the value of the
label field of the hash label. The egress data path appends the hash label at the bottom of
the stack (BoS) and sets the S-bit to one (1).
In order to allow applications where the egress LER infers the presence of the hash label
implicitly from the value of the label, the Most Significant Bit (MSB) of the result of the hash
is set before copying into the Hash Label. This means that the value of the hash label will
always be in the range [524,288 - 1,048,575] and will not overlap with the signaled/static LSP
and signaled/static service label ranges. This also guarantees that the hash label will not
match a value in the reserved label range.
The (unmodified) result of the hash continues to be used for the purpose of ECMP and LAG
spraying of packets locally on the ingress LER. Note, however, that for VLL services, the
result of the hash is overwritten and the ECMP and LAG spraying will be based on service-id
when ingress SAP shared queuing is not enabled. However, the hash label will still reflect the
result of the hash such that an LSR can use it to perform fine grained load balancing of VLL
PW packets.
Packets generated in CPM and that are forwarded labeled within the context of a service (for
example, OAM packets) must also include a Hash Label at the BoS and set the S-bit
accordingly.
The TTL of the hash label is set to a value of 0.
Issue: 01
3HE 11970 AAAA TQZZA 01
357
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
The user enables the signaling of the hash-label capability under a VLL spoke-sdp, a VPLS
spoke-sdp or mesh SDP, or an IES/VPRN spoke interface by adding the signal-capability
option. In this case, the decision whether to insert the hash label on the user and control plane
packets by the local PE is solely determined by the outcome of the signaling process and can
override the local PE configuration. The following are the procedures:
• The 7450 ESS or 7750 SR local PE will insert the flow label interface parameters subTLV with F=1 in the PW ID FEC element in the label mapping message for that spoke
SDP or mesh SDP.
• If the remote PE includes this sub-TLV with F=1 or F=0, then local PE must insert the
hash label in the user and control plane packets.
• If remote PE does not include this sub-TLV (for example, it does not support it, or it is
supported but the user did not enable the hash-label option or the signal-capability
option), then the local PE establishes the PW but must not insert the hash label in the
user and control packets over that spoke SDP or mesh SDP. If the remote PE does not
support the signal-capability option, then there are a couple of possible outcomes:
− If the hash-label option was enabled on the local configuration of the spoke SDP
or mesh SDP at the remote PE, the PW packets received by the local PE will have
the hash label included. These packets must be dropped. The only way to solve this
is to disable the signaling capability option on the local node which will result in the
insertion of the hash label by both PE nodes.
− If the hash-label option is not supported or was not enabled on the local
configuration of the spoke SDP or mesh SDP at the remote PE, the PW received
by the local PE will not have the hash label included.
• The user can enable or disable the signal-capability option in CLI as needed. When
doing so, the 7450 ESS or 7750 SR must withdraw the label it sent to its peer and send
a new label mapping message with the new value of the F bit in the flow label interface
parameters sub-TLV of the PW ID FEC element.
The no form of this command disables the use of the hash label.
Default
Parameters
no hash-label
signal-capability — Enables the signaling and negotiation of the use of the hash label
between the local and remote PE nodes. The signal-capability option is not
supported on a VPRN spoke-sdp.
cell-concatenation
Syntax
Context
Description
358
cell-concatenation
config>service>apipe>spoke-sdp
This command enters the context to provide access to the various options that control the
termination of ATM cell concatenation into an MPLS frame. Several options can be
configured simultaneously. The concatenation process for a given MPLS packet ends when
the first concatenation termination condition is met. The concatenation parameters apply only
to ATM N:1 cell mode VLL.
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
aal5-frame-aware
Syntax
Context
Description
[no] aal5-frame-aware
config>service>apipe>spoke-sdp>cell-concat
This command enables the configuration of AAL5 end-of-message (EOM) to be an indication
to complete the cell concatenation operation.
The no form of the command resets the configuration to ignore the AAL5 EOM as an
indication to complete the cell concatenation.
clp-change
Syntax
Context
Description
[no] clp-change
config>service>apipe>spoke-sdp>cell-concat
This command enables the configuration of CLP change to be an indication to complete the
cell concatenation operation.
The no form of the command resets the configuration to ignore the CLP change as an
indication to complete the cell concatenation.
max-cells
Syntax
Context
Description
max-cells cell-count
no max-cells [cell-count]
config>service>apipe>spoke-sdp>cell-concat
This command enables the configuration of the maximum number of ATM cells to accumulate
into an MPLS packet. The remote peer will also signal the maximum number of concatenated
cells it is willing to accept in an MPLS packet. When the lesser of (the configured value and
the signaled value) number of cells is reached, the MPLS packet is queued for transmission
onto the pseudowire. It is ensured that the MPLS packet MTU conforms to the configured
service MTU.
The no form of this command sets max-cells to the value ‘1’ indicating that no concatenation
will be performed.
Parameters
Issue: 01
cell-count — Specifies the maximum number of ATM cells to be accumulated into an
MPLS packet before queuing the packet for transmission onto the pseudowire.
Values
1 to 128
Default
1
3HE 11970 AAAA TQZZA 01
359
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
max-delay
Syntax
Context
Description
max-delay delay-time
no max-delay [delay-time]
config>service>apipe>spoke-sdp>cell-concat
This command enables the configuration of the maximum amount of time to wait while
performing ATM cell concatenation into an MPLS packet before transmitting the MPLS
packet. This places an upper bound on the amount of delay introduced by the concatenation
process. When this amount of time is reached from when the first ATM cell for this MPLS
packet was received, the MPLS packet is queued for transmission onto the pseudowire.
The no form of this command resets max-delay to its default value.
Parameters
delay-time — Specifies the maximum amount of time, in hundreds of microseconds, to
wait before transmitting the MPLS packet with whatever ATM cells have been
received. For example, to bound the delay to 1 ms the user would configure 10
(hundreds of microseconds). The delay-time is rounded up to one of the following
values 1, 5, 10, 50, 100, 200, 300 and 400.
Values
1 to 400
Default
400
control-word
Syntax
Context
Description
[no] control-word
config>service>apipe>spoke-sdp
config>service>cpipe>spoke-sdp
config>service>epipe>spoke-sdp
config>service>fpipe>spoke-sdp
config>service>ipipe>spoke-sdp
The control word command provides the option to add a control word as part of the packet
encapsulation for pseudowire types for which the control word is optional. These are Ethernet
pseudowires (Epipe). For the 7750 SR only, ATM N:1 cell mode pseudowires (apipe vc-types
atm-vcc and atm-vpc) and VT pseudowire (apipe vc-type atm-cell).
The configuration for the two directions of the pseudowire must match because the control
word negotiation procedures described in Section 6.2 of RFC 4447 are not supported. The
C-bit in the pseudowire FEC sent in the label mapping message is set to 1 when the control
word is enabled. Otherwise, it is set to 0.
360
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
The service will only come up if the same C-bit value is signaled in both directions. If a spokesdp is configured to use the control word but the node receives a label mapping message with
a C-bit clear, the node releases the label with the an “Illegal C-bit” status code as per Section
6.1 of RFC 4447. As soon as the user also enabled the control the remote peer, the remote
peer will withdraw its original label and will send a label mapping with the C-bit set to 1 and
the VLL service will be up in both nodes. The control word must be enabled to allow MPLSTP OAM to be used on a static spoke-sdp in a apipe, epipe and cpipe service.
pw-path-id
Syntax
Context
Description
[no] pw-path-id
config>service>epipe>spoke-sdp
config>service>cpipe>spoke-sdp
config>service>apipe>spoke-sdp
config>service>vpls>spoke-sdp
config>service>ies>if>spoke-sdp
config>service>vprn>if>spoke-sdp
This command enters the context to configure an MPLS-TP Pseudowire Path Identifier for a
spoke-sdp. All elements of the PW path ID must be configured in order to enable a spokesdp with a PW path ID.
For an IES or VPRN spoke-sdp, the pw-path-id is only valid for ethernet spoke-sdps.
The pw-path-id is only configurable if all of the following is true:
• SDP signaling is off
• control-word is enabled (control-word is disabled by default)
• the service type is epipe, vpls, cpipe, apipe, or IES/VPRN interface
• mate SDP signaling is off for vc-switched services
The no form of the command deletes the PW path ID.
Default
no pw-path-id
Syntax
agi agi
no agi
agi
Context
Issue: 01
config>service>epipe>spoke-sdp>pw-path-id
config>service>cpipe>spoke-sdp>pw-path-id
config>service>apipe>spoke-sdp>pw-path-id
config>service>vpls>spoke-sdp>pw-path-id
config>service>ies>if>spoke-sdp>pw-path-id
config>service>vprn>if>spoke-sdp>pw-path-id
3HE 11970 AAAA TQZZA 01
361
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
Description
This command configures the attachment group identifier for an MPLS-TP PW.
Parameters
agi — Specifies the attachment group identifier.
Values
0 to 4294967295
saii-type2
Syntax
Context
saii-type2 global-id:node-id:ac-id
no saii-type2
config>service>epipe>spoke-sdp>pw-path-id
config>service>cpipe>spoke-sdp>pw-path-id
config>service>apipe>spoke-sdp>pw-path-id
config>service>vpls>spoke-sdp>pw-path-id
config>service>ies>if>spoke-sdp>pw-path-id
config>service>vprn>if>spoke-sdp>pw-path-id
Description
This command configures the source individual attachment identifier (SAII) for an MPLS-TP
spoke-sdp. If this is configured on a spoke-sdp for which vc-switching is also configured (for
example, it is at an S-PE), then the values must match those of the taii-type2 of the mate
spoke-sdp.
Parameters
global-id — Specifies the global ID at the source PE or T-PE for the MPLS-TP PW for a
spoke-SDP.
Values
0 to 4294967295
node-id — Specifies the node ID at the source PE or T-PE for the MPLS-TP PW for a
spoke-SDP.
Values
a.b.c.d or 0 to 4294967295
ac-id — Specifies the attachment circuit ID at the source PE or T-PE for the MPLS-TP
PW for a spoke-SDP. If this node is the source of the PW, then the AC ID must be
set to a locally unique value.
Values
1 to 4294967295
taii-type2
Syntax
Context
362
taii-type2 global-id:node-id:ac-id
no taii-type2
config>service>epipe>spoke-sdp>pw-path-id
config>service>cpipe>spoke-sdp>pw-path-id
config>service>apipe>spoke-sdp>pw-path-id
config>service>vpls>spoke-sdp>pw-path-id
config>service>ies>if>spoke-sdp>pw-path-id
config>service>vprn>if>spoke-sdp>pw-path-id
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
Description
This command configures the target individual attachment identifier (TAII) for an MPLS-TP
spoke-sdp. If this is configured on a spoke-sdp for which vc-switching is also configured (for
example, it is at an S-PE), then the values must match those of the saii-type2 of the mate
spoke-sdp.
Parameters
global-id — Specifies the global ID at the target PE or T-PE for the MPLS-TP PW for a
spoke-SDP.
Values
0 to 4294967295
node-id — Specifies the node ID at the target PE or T-PE for the MPLS-TP PW for a
spoke-SDP.
Values
a.b.c.d or 0 to 4294967295
ac-id — Specifies the attachment circuit ID at the target PE or T-PE for the MPLS-TP PW
for a spoke-SDP. If this node is the source of the PW, then the AC ID must be set to
a locally unique value.
Values
1 to 4294967295
control-channel-status
Syntax
Context
Description
[no] control-channel-status
config>service>cpipe>spoke-sdp
config>service>epipe>spoke-sdp
config>service>apipe>spoke-sdp
config>service>ies>if>spoke-sdp
config>service>vpls>spoke-sdp
config>service>vprn>if>spoke-sdp
This command enables the configuration of static pseudowire status signaling on a spokeSDP for which signaling for its SDP is set to OFF.
A control-channel-status no shutdown is allowed only if all of the following are true:
• SDP signaling is off.
• The control-word is enabled (the control-word is disabled by default)
• The service type is Epipe, Apipe, VPLS, Cpipe, or IES/VPRN
• Mate SDP signaling is off (in vc-switched services)
• The pw-path-id is configured for this spoke-SDP.
The no form of this command removes control channel status signaling from a spoke-SDP.
It can only be removed if control channel status is shut down.
Default
Issue: 01
no control-channel-status
3HE 11970 AAAA TQZZA 01
363
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
acknowledgment
Syntax
Context
Description
[no] acknowledgment
config>service>cpipe>spoke-sdp>control-channel-status
config>service>epipe>spoke-sdp>control-channel-status
config>service>apipe>spoke-sdp>control-channel-status
config>service>vpls>spoke-sdp>control-channel-status
config>service>ies>if>spoke-sdp>control-channel-status
config>service>vprn>if>spoke-sdp>control-channel-status
This command enables the acknowledgment of control channel status messages. By default,
no acknowledgment packets are sent.
refresh-timer
Syntax
Context
Description
Default
Parameters
refresh-timer value
no refresh-timer
config>service>epipe>spoke-sdp>control-channel-status
config>service>cpipe>spoke-sdp>control-channel-status
config>service>apipe>spoke-sdp>control-channel-status
config>service>vpls>spoke-sdp>control-channel-status
config>service>ies>if>spoke-sdp>control-channel-status
config>service>vprn>if>spoke-sdp>control-channel-status
This command configures the refresh timer for control channel status signaling packets. By
default, no refresh packets are sent.
no refresh-timer
value — Specifies the refresh timer value, in seconds.
Values
10 to 65535
Default
0 (off)
request-timer
Syntax
Context
364
request-timer timer1 retry-timer timer2 timeout-multiplier multiplier
no request-timer
config>service>cpipe>spoke-sdp>control-channel-status
config>service>epipe>spoke-sdp>control-channel-status
config>service>apipe>spoke-sdp>control-channel-status
config>service>vpls>spoke-sdp>control-channel-status
config>service>ies>if>spoke-sdp>control-channel-status
config>service>vprn>if>spoke-sdp>control-channel-status
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
Description
This command configures the control channel status request mechanism. When it is
configured, control channel status request procedures are used. These augment the
procedures for control channel status messaging from RFC 6478. This command is mutually
exclusive with a non-zero refresh-timer value.
Parameters
timer1 — Specifies the interval, in seconds, at which pseudowire status messages,
including a reliable delivery TLV with the “request” bit set, are sent.
Values
10 to 65535
timer2 — specifies the timeout interval, in seconds, if no response to a pseudowire status
request is received. This parameter must be configured. A value of zero (0) disables
retries.
Values
0, 3 to 60
multiplier — If a requesting node does not receive a valid response to a pseudowire
status request within a number of seconds equal to the retry timer multiplied by this
multiplier, then it will assume the pseudowire is down. This parameter is optional.
Values
3 to 20
control-word
Syntax
Context
Description
[no] control-word
config>service>ies>if>spoke-sdp
config>service>vprn>if>spoke-sdp
This command enables/disables the PW control word on spoke-sdps terminated on an IES
or VPRN interface. The control word must be enabled to allow MPLS-TP OAM on the spokesdp.
It is only valid for MPLS-TP spoke-sdps when used with IES and VPRN services.
Default
no control-word
Syntax
egress
egress
Context
Description
Issue: 01
config>service>apipe>spoke-sdp
config>service>cpipe>spoke-sdp
config>service>fpipe>spoke-sdp
config>service>ipipe>spoke-sdp
This command configures the egress SDP context.
3HE 11970 AAAA TQZZA 01
365
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
hash-label
Syntax
Context
Description
hash-label [signal-capability]
no hash label
config>service>fpipe>spoke-sdp
config>service>ipipe>spoke-sdp
config>service>epipe>spoke-sdp
This command enables the use of the hash label on a VLL, VPLS, or VPRN service bound to
any MPLS type encapsulated SDP, as well as to a VPRN service using the auto-bind-tunnel
with the resolution-filter set to any MPLS tunnel type. This feature is not supported on a
service bound to a GRE SDP or for a VPRN service using the autobind mode with the gre
option.
When this feature is enabled, the ingress data path is modified such that the result of the hash
on the packet header is communicated to the egress data path for use as the value of the
label field of the hash label. The egress data path appends the hash label at the bottom of
the stack (BoS) and sets the S-bit to 1 to indicate that.
In order to allow for applications whereby the egress LER infers the presence of the Hash
Label implicitly from the value of the label, the Most Significant Bit (MSB) of the result of the
hash is set before copying into the Hash Label. This means that the value of the hash label
will always be in the range [524,288 - 1,048,575] and will not overlap with the signaled/static
LSP and signaled/static service label ranges. This also guarantees that the hash label will not
match a value in the reserved label range.
The (unmodified) result of the hash continues to be used for the purpose of ECMP and LAG
spraying of packets locally on the ingress LER. Note however that for VLL services, the result
of the hash is overwritten and the ECMP and LAG spraying will be based on service-id when
ingress SAP shared queuing is not enabled. However, the hash label will still reflect the result
of the hash such that an LSR can use it to perform fine grained load balancing of VLL
pseudowire packets.
Packets that are generated in CPM and forwarded labeled within the context of a service (for
example, OAM packets) must also include a Hash Label at the BoS and set the S-bit
accordingly.
The TTL of the Hash Label is set to a value of 0.
The no form of this command disables the use of the hash label.
The user enables the signaling of the hash-label capability under a VLL spoke-sdp, a VPLS
spoke SDP or mesh SDP, or an IES/VPRN spoke interface by adding the signal-capability
option. In this case, the decision whether to insert the hash label on the user and control plane
packets by the local PE is solely determined by the outcome of the signaling process and can
override the local PE configuration. The following are the procedures:
• The 7450 ESS or 7750 SR local PE will insert the flow label interface parameters subTLV with F=1 in the PW ID FEC element in the label mapping message for that spoke
SDP or mesh SDP.
366
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
• If the remote PE includes this sub-TLV with F=1 or F=0, then local PE must insert the
hash label in the user and control plane packets.
• If remote PE does not include this sub-TLV (for example, it does not support it, or it is
supported but the user did not enable the hash-label option or the signal-capability
option), then the local PE establishes the PW but must not insert the hash label in the
user and control packets over that spoke SDP or mesh SDP. If the remote PE does not
support the signal-capability option, then there are a couple of possible outcomes:
− If the hash-label option was enabled on the local configuration of the spoke SDP
or mesh SDP at the remote PE, the PW packets received by the local PE will have
the hash label included. These packets must be dropped. The only way to solve this
is to disable the signaling capability option on the local node which will result in the
insertion of the hash label by both PE nodes.
− If the hash-label option is not supported or was not enabled on the local
configuration of the spoke SDP or mesh SDP at the remote PE, the PW received
by the local PE will not have the hash label included.
• The user can enable or disable the signal-capability option in CLI as needed. When
doing so, the 7450 ESS or 7750 SR must withdraw the label it sent to its peer and send
a new label mapping message with the new value of the F bit in the flow label interface
parameters sub-TLV of the PW ID FEC element.
The no form of this command disables the use of the hash label.
Default
Parameters
no hash-label
signal-capability — Enables the signaling and negotiation of the use of the hash label
between the local and remote PE nodes. The signal-capability option is not
supported on a VPRN spoke-sdp.
ignore-oper-down
Syntax
Context
Description
ignore-oper-down
[no] ignore-oper-down
config>service>epipe>sap>
An ePipe service will not transition to Oper State: Down when a SAP fails and when this
optional command is configured under that specific SAP. Only a single SAP in an ePipe may
have this optional command included.
Default
no ignore-oper-down
Syntax
ingress
ingress
Context
Issue: 01
config>service>fpipe>spoke-sdp
3HE 11970 AAAA TQZZA 01
367
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
config>service>apipe>spoke-sdp
config>service>cpipe>spoke-sdp
Description
This command configures the ingress SDP context.
filter
Syntax
Context
Description
filter [ip ip-filter-id]
no filter
config>service>fpipe>spoke-sdp>egress
config>service>fpipe>spoke-sdp>ingress
This command associates an IP filter policy with an ingress or egress Service Distribution
Point (SDP). Filter policies control the forwarding and dropping of packets based on IP
matching criteria. Only one filter can be applied to a spoke SDP at a time.
The filter command is used to associate a filter policy with a specified ip-filter-id with an
ingress or egress spoke SDP. The ip-filter-id must already be defined before the filter
command is executed. If the filter policy does not exist, the operation will fail and an error
message returned.
IP filters apply only to RFC 2427-routed IP packets. Frames that do not contain IP packets
will not be subject to the filter and will always be passed, even if the filter's default action is to
drop.
The no form of this command removes any configured filter ID association with the SDP. The
filter ID itself is not removed from the system unless the scope of the created filter is set to
local. To avoid deletion of the filter ID and only break the association with the service object,
use the scope command within the filter definition to change the scope to local or global.
The default scope of a filter is local.
Parameters
ip — Keyword indicating the filter policy is an IP filter.
ip-filter-id — The filter name acts as the ID for the IP filter policy. The filter ID must already
exist within the created IP filters.
Values
1 to 65535
qos
Syntax
Context
368
qos network-policy-id port-redirect-group queue-group-name [instance instance-id]
no qos
config>service>apipe>spoke-sdp>egress
config>service>cpipe>spoke-sdp>egress
config>service>epipe>spoke-sdp>egress
config>service>fpipe>spoke-sdp>egress
config>service>ipipe>spoke-sdp>egress
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
config>service>vpls>spoke-sdp>egress
config>service>vpls>mesh-sdp>egress
config>service>pw-template>egress
config>service>vprn>if>spoke-sdp>egress
config>service>ies>if>spoke-sdp>egress
Description
This command is used to redirect PW packets to an egress port queue-group for the purpose
of shaping.
The egress PW shaping provisioning model allows the mapping of one or more PWs to the
same instance of queues, or policers and queues, that are defined in the queue-group
template.
Operationally, the provisioning model consists of the following steps:
1. Create an egress queue-group template and configure queues only, or policers and
queues for each FC that needs to be redirected.
2. Apply the queue-group template to the network egress context of all ports where there
exists a network IP interface that the PW packets can be forwarded on. This creates one
instance of the template on the egress of the port. One or more instances of the same
template can be created.
3. Configure FC-to-policer or FC-to-queue mappings together with the redirect to a queuegroup in the egress context of a network QoS policy. No queue-group name is specified
in this step, which means the same network QoS policy can redirect different PWs to
different queue-group templates.
4. Apply this network QoS policy to the egress context of a spoke-sdp inside a service, or
to the egress context of a PW template and specify the redirect queue-group name.
One or more spoke-sdps can have their FCs redirected to use queues only, or queues and
policers in the same queue-group instance.
The following are the constraints and rules of this provisioning model:
1. When a PW FC is redirected to use a queue or a policer and a queue in a queue-group
and the queue-group name does not exist, the association is failed at the time the user
associates the egress context of a spoke-sdp to the named queue-group. In such a
case, the PW packet will be fed directly to the corresponding egress queue for that FC
used by the IP network interface the PW packet is forwarded on. This queue can be a
queue-group queue or the egress shared queue for that FC defined in the networkqueue policy applied to the egress of this port. This is the existing implementation and
default behavior for a PW packet.
2. When a PW FC is redirected to use a queue or a policer and a queue in a queue-group
and the queue-group name exists but the policer-id and/or the queue-id is not defined in
the queue-group template, the association is failed at the time the user associates the
egress context of a spoke-sdp to the named queue-group. In such a case, the PW
packet will be fed directly to the corresponding egress queue for that FC used by the IP
network interface the PW packet is forwarded on.
Issue: 01
3HE 11970 AAAA TQZZA 01
369
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
3. When a PW FC is redirected to use a queue or a policer and a queue in a queue-group
and the queue-group name exists and the policer-id or policer-id plus queue-id exist, it
is not required to check that an instance of that queue-group exists in all egress network
ports that have network IP interfaces. The handling of this is dealt with in the data path
as follows:
− When a PW packet for that FC is forwarded and an instance of the referenced
queue-group name exists on that egress port, the packet is processed by the
queue-group policer and will then be fed to the queue-group queue.
− When a PW packet for that FC is forwarded and an instance of the referenced
queue-group name does not exist on that egress port, the PW packet will be fed
directly to the corresponding egress shared queue for that FC defined in the
network-queue policy applied to the egress of this port.
4. If a network QoS policy is applied to the egress context of a PW, any PW FC that is not
explicitly redirected in the network QoS policy will have the corresponding packets feed
directly the corresponding the egress shared queue for that FC defined in the networkqueue policy applied to the egress of this port.
When the queue-group name the PW is redirected to exists and the redirection succeeds, the
marking of the packet’s DEI/dot1p/DSCP and the tunnel’s DEI/dot1p/DSCP/EXP is
performed according to the relevant mappings of the {FC, profile} in the egress context of the
network QoS policy applied to the PW. This is true regardless if an instance of the queuegroup exists or not on the egress port the PW packet is forwarded to. If the packet’s profile
value changed due to egress child policer CIR profiling, the new profile value is used to mark
the packet’s DEI/dot1p and the tunnel’s DEI/dot1p/EXP, and the DSCP/prec will be remarked
if enable-dscp-prec-marking is enabled under the policer.
When the queue-group name the PW is redirected does not exist, the redirection command
is failed. In this case, the marking of the packet’s DEI/dot1p/DSCP and the tunnel’s DEI/
dot1p/DSCP/EXP fields is performed according to the relevant commands in the egress
context of the network QoS policy applied to the network IP interface the PW packet is
forwarded to.
The no version of this command removes the redirection of the PW to the queue-group.
Parameters
network-policy-id — Specifies the network policy identification. The value uniquely
identifies the policy on the system.
Values
1 to 65535
queue-group-name — Specifies the name of the queue group template up to 32
characters in length.
instance-id — Specifies the optional identification of a specific instance of the queuegroup.
Values
370
1 to 40960
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
qos
Syntax
Context
Description
qos network-policy-id fp-redirect-group queue-group-name instance instance-id
no qos
config>service>apipe>spoke-sdp>ingress
config>service>cpipe>spoke-sdp>ingress
config>service>epipe>spoke-sdp>ingress
config>service>fpipe>spoke-sdp>ingress
config>service>ipipe>spoke-sdp>ingress
config>service>vpls>spoke-sdp>ingress
config>service>vpls>mesh-sdp>ingress
config>service>pw-template>ingress
config>service>vprn>if>spoke-sdp>ingress
config>service>ies>if>spoke-sdp>ingress
This command is used to redirect PW packets to an ingress forwarding plane queue-group
for the purpose of rate-limiting.
The ingress PW rate-limiting feature uses a policer in queue-group provisioning model. This
model allows the mapping of one or more PWs to the same instance of policers that are
defined in a queue-group template.
Operationally, the provisioning model in the case of the ingress PW shaping feature consists
of the following steps:
1. Create an ingress queue-group template and configure policers for each FC that needs
to be redirected and optionally for each traffic type (unicast or multicast).
2. Apply the queue-group template to the network ingress forwarding plane where there
exists a network IP interface that the PW packets can be received on. This creates one
instance of the template on the ingress of the FP. One or more instances of the same
template can be created.
3. Configure FC-to-policer mappings together with the policer redirect to a queue-group in
the ingress context of a network QoS policy. No queue-group name is specified in this
step which means the same network QoS policy can redirect different PWs to different
queue-group templates.
4. Apply this network QoS policy to the ingress context of a spoke-sdp inside a service, or
to the ingress context of a PW template and specify the redirect queue-group name.
One or more spoke-sdps can have their FCs redirected to use policers in the same policer
queue-group instance.
The following are the constraints and rules of this provisioning model when used in the
ingress PW rate-limiting feature:
1. When a PW FC is redirected to use a policer in a named policer queue-group and the
queue-group name does not exist, the association is failed at the time the user
associates the ingress context of a spoke-sdp to the named queue-group. In such a
case, the PW packet will feed directly the ingress network shared queue for that FC
defined in the network-queue policy applied to the ingress of the MDA/FP.
Issue: 01
3HE 11970 AAAA TQZZA 01
371
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
2. When a PW FC is redirected to use a policer in a named policer queue-group and the
queue-group name exists but the policer-id is not defined in the queue-group template,
the association is failed at the time the user associates the ingress context of a spokesdp to the named queue-group. In such a case, the PW packet will feed directly the
ingress network shared queue for that FC defined in the network-queue policy applied
to the ingress of the MDA/FP.
3. When a PW FC is redirected to use a policer in a named policer queue-group and the
queue-group name exists and the policer-id is defined in the queue-group template, it is
not required to check that an instance of that queue-group exists in all ingress FPs that
have network IP interfaces. The handling of this is dealt within the data path as follows:
− When a PW packet for that FC is received and an instance of the referenced queuegroup name exists on that FP, the packet is processed by the policer and will then
feed the per-FP ingress shared queues referred to as “policer-output-queues”.
− When a PW packet for that FC is received and an instance of the referenced queuegroup name does not exist on that FP, the PW packets will be fed directly into the
corresponding ingress network shared queue for that FC defined in the networkqueue policy applied to the ingress of the MDA/FP.
4. If a network QoS policy is applied to the ingress context of a PW, any PW FC that is not
explicitly redirected in the network QoS policy will have the corresponding packets feed
directly into the ingress network shared queue for that FC defined in the network-queue
policy applied to the ingress of the MDA/FP.
5. If no network QoS policy is applied to the ingress context of the PW, then all packets of
the PW will feed:
− the ingress network shared queue for the packet’s FC defined in the network-queue
policy applied to the ingress of the MDA/FP. This is the default behavior.
− a queue-group policer followed by the per-FP ingress shared queues, referred to
as “policer-output-queues”, if the ingress context of the network IP interface from
which the packet is received is redirected to a queue-group. The only exceptions to
this behavior are for packets received from an IES/VPRN spoke interface and from
an R-VPLS spoke-sdp that is forwarded to the R-VPLS IP interface. In these two
cases, the ingress network shared queue for the packet’s FC defined in the
network-queue policy applied to the ingress of the MDA/FP is used.
When a PW is redirected to use a policer queue-group, the classification of the packet for the
purpose of FC and profile determination is performed according to the default classification
rule or the QoS filters defined in the ingress context of the network QoS policy applied to the
PW. This is true regardless if an instance of the named policer queue-group exists on the
ingress FP the pseudowire packet is received on. The user can apply a QoS filter matching
the dot1-p in the VLAN tag corresponding to the Ethernet port encapsulation, the EXP in the
outer label when the tunnel is an LSP, the DSCP in the IP header if the tunnel encapsulation
is GRE, and the DSCP in the payload’s IP header if the user enabled the ler-use-dscp option
and the pseudowire terminates in IES or VPRN service (spoke-interface).
When the policer queue-group name the pseudowire is redirected does not exist, the
redirection command is failed. In this case, the packet classification is performed according
to the default classification rule or the QoS filters defined in the ingress context of the network
QoS policy applied to the network IP interface the pseudowire packet is received on.
372
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
The no version of this command removes the redirection of the pseudowire to the queuegroup.
Parameters
network-policy-id — Specifies the network policy identification on the system.
Values
1to 65535
queue-group-name — Specifies the name of the queue group template up to 32
characters in length.
instance-id — Specifies the identification of a specific instance of the queue-group.
Values
1to 16384
vc-label
Syntax
Context
Description
[no] vc-label vc-label
config>service>fpipe>spoke-sdp>egress
config>service>apipe>spoke-sdp>egress
config>service>cpipe>spoke-sdp>egress
config>service>ipipe>spoke-sdp>egress
config>service>apipe>spoke-sdp>ingress
config>service>cpipe>spoke-sdp>ingress
config>service>fpipe>spoke-sdp>ingress
config>service>ipipe>spoke-sdp>ingress
This command configures the egress and ingress VC label.
Note that the actual maximum value that can be configured is limited by the
config>router>mpls-labels>static-label-range command.
Parameters
vc-label — A VC egress value that indicates a specific connection.
Values
for egress: 16 to 1048575
Values
for ingress: 32 to 18431
monitor-oper-group
Syntax
monitor-oper-group group-name
no monitor-oper-group
Context
config>service>epipe>spoke-sdp
config>service>epipe>sap
Description
This command specifies the operational group to be monitored by the object under which it
is configured. The oper-group name must be already configured under the config>service
context before its name is referenced in this command.
The no form of the command removes the association.
Issue: 01
3HE 11970 AAAA TQZZA 01
373
VLL Services
Default
Parameters
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
none
group-name — Specifies an oper group name.
oper-group
Syntax
Context
Description
oper-group group-name
no oper-group
config>service>epipe>sap
This command configures the operational group identifier.
The no form of the command removes the group name from the configuration.
Default
Parameters
none
group-name — Specifies the Operational-Group identifier up to 32 characters in length.
precedence
Syntax
Context
Description
precedence [precedence-value | primary]
no precedence
config>service>apipe>spoke-sdp
config>service>cpipe>spoke-sdp
config>service>fpipe>spoke-sdp
config>service>ipipe>spoke-sdp
config>service>epipe>spoke-sdp
This command specifies the precedence of the SDP binding when there are multiple SDP
bindings attached to one service endpoint. The value of zero can only be assigned to one
SDP bind making it the primary SDP bind. When an SDP binding goes down, the next highest
precedence SDP binding will begin to forward traffic.
The no form of the command returns the precedence value to the default.
Default
Parameters
4
precedence-value — Specifies the spoke SDP precedence.
Values
1 to 4
primary — Assigns primary precedence to the spoke SDP.
374
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
pw-status-signaling
Syntax
Context
Description
[no] pw-status-signaling
config>service>epipe>spoke-sdp
This command enables pseudowire status signaling for this spoke SDP binding.
The no form of the command disables the status signaling.
Default
pw-status-signaling
use-sdp-bmac
Syntax
Context
Description
[no] use-sdp-bmac
config>service>epipe>spoke-sdp
This command indicates that this spoke-SDP is expected to be part of a redundant
pseudowire connected to a PBB Epipe service. Enabling this parameter will cause traffic
forwarded from this spoke-SDP into the B-VPLS domain to use a virtual backbone MAC as
its source MAC address when both this, and the control pseudowire, are in the active state
on this BEB. This virtual backbone MAC is derived from the SDP source-bmac-lsb
configuration.
This command will fail when configuring it under a spoke-SDP within a PBB-Epipe that is
connected to a B-VPLS with mac-notification enabled.
Default
no use-sdp-bmac
vc-label
Syntax
Context
Description
[no] vc-label vc-label
config>service>cpipe>spoke-sdp>egress
config>service>epipe>spoke-sdp>egress
config>service>cpipe>spoke-sdp>ingress
config>service>epipe>spoke-sdp>ingress
This command configures the egress and ingress VC label.
Note that the actual maximum value that can be configured is limited by the
config>router>mpls-labels>static-label-range command.
Parameters
Issue: 01
vc-label — A VC egress value that indicates a specific connection.
Values
for egress: 16 to 1048575
Values
for ingress: 32 to 18431
3HE 11970 AAAA TQZZA 01
375
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
vlan-vc-tag
Syntax
Context
Description
vlan-vc-tag 0 to 4094
no vlan-vc-tag [0 to 4094]
config>service>epipe>spoke-sdp
This command specifies an explicit dot1q value used when encapsulating to the SDP far end.
When signaling is enabled between the near and far end, the configured dot1q tag can be
overridden by a received TLV specifying the dot1q value expected by the far end. This
signaled value must be stored as the remote signaled dot1q value for the binding. The
provisioned local dot1q tag must be stored as the administrative dot1q value for the binding.
When the dot1q tag is not defined, the default value of zero is stored as the administrative
dot1q value. Setting the value to zero is equivalent to not specifying the value.
The no form of this command disables the command.
Default
Parameters
no vlan-vc-tag
0 to 4094 — Specifies a valid VLAN identifier to bind an 802.1Q VLAN tag ID.
Values
0 to 4094
spoke-sdp-fec
Syntax
Context
Description
spoke-sdp-fec
spoke-sdp-fec spoke-sdp-fec-id [fec fec-type] [aii-type aii-type] [create]
spoke-sdp-fec spoke-sdp-fec-id no-endpoint
spoke-sdp-fec spoke-sdp-fec-id [fec fec-type] [aii-type aii-type] [create] endpoint name
[icb]
config>service>epipe
This command binds a service to an existing Service Distribution Point (SDP), using a
dynamic MS-PW.
A spoke SDP is treated like the equivalent of a traditional bridge “port” where flooded traffic
received on the spoke SDP is replicated on all other “ports” (other spoke and mesh SDPs or
SAPs) and not transmitted on the port it was received.
The SDP has an operational state which determines the operational state of the SDP within
the service. For example, if the SDP is administratively or operationally down, the SDP for the
service will be down.
376
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
When using dynamic MS-PWs, the particular SDP to bind-to is automatically selected based
on the Target Attachment Individual Identifier (TAII) and the path to use, specified under
spoke-SDP FEC. The selected SDP will terminate on the first hop S-PE of the MS-PW.
Therefore, an SDP must already be defined in the config>service>sdp context that reaches
the first hop router of the MS-PW. The router will in order to associate an SDP with a service.
If an SDP to that is not already configured, an error message is generated. If the sdp-id does
exist, a binding between that sdp-id and the service is created.
It differs from the spoke-sdp command in that the spoke-sdp command creates a spoke SDP
binding that uses a pseudowire with the PW ID FEC. However, the spoke-sdp-fec command
enables pseudowires with other FEC types to be used. In Release 9.0, only the Generalized
ID FEC (FEC129) may be specified using this command.
The no form of this command removes the SDP binding from the service. The SDP
configuration is not affected; only the binding of the SDP to a service. Once removed, no
packets are forwarded to the far-end router.
Default
Parameters
none
spoke-sdp-fec-id — An unsigned integer value identifying the spoke SDP.
Values
1 to 4294967295
fec-type — An unsigned integer value for the type of the FEC used by the MS-PW.
Values
129 to 130
aii-type — An unsigned integer value for the Attachment Individual Identifier (AII) type
used to identify the MS-PW endpoints.
Values
1 to 2
endpoint-name — Specifies the name of the service endpoint.
no endpoint — Adds or removes a spoke SDP association.
icb — Configures the spoke-SDP as an inter-chassis backup SDP binding.
auto-config
Syntax
Context
Description
[no] auto-config
config>service>epipe>spoke-sdp-fec
This command enables single sided automatic endpoint configuration of the spoke-SDP. The
router acts as the passive T-PE for signaling this MS-PW.
Automatic Endpoint Configuration allows the configuration of a spoke-SDP endpoint without
specifying the TAII associated with that spoke-SDP. It allows a single-sided provisioning
model where an incoming label mapping message with a TAII that matches the SAII of that
spoke-SDP to be automatically bound to that endpoint. In this mode, the far end T-PE actively
initiates MS-PW signaling and will send the initial label mapping message using T-LDP, while
the router T-PE for which auto-config is specified will act as the passive T-PE.
Issue: 01
3HE 11970 AAAA TQZZA 01
377
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
The auto-config command is blocked in CLI if signaling active has been enabled for this
spoke-SDP. It it is only applicable to spoke SDPs configured under the Epipe, IES and VPRN
interface context.
The no form of the command means that the router T-PE either acts as the active T-PE (if
signaling active is configured) or automatically determines which router will initiate MS-PW
signaling based on the prefix values configured in the SAII and TAII of the spoke-SDP. If the
SAII has the greater prefix value, then the router will initiate MS-PW signaling without waiting
for a label mapping message from the far end. However, if the TAII has the greater value
prefix, then the router will assume that the far end T-PE will initiate MS-PW signaling and will
wait for that label mapping message before responding with a T-LDP label mapping message
for the MS-PW in the reverse direction.
Default
no auto-config
Syntax
path name
no path
path
Context
Description
config>service>epipe>spoke-sdp-fec
This command specifies the explicit path, containing a list of S-PE hops, that should be used
for this spoke SDP. The path-name should correspond to the name of an explicit path
configured in the config>service>pw-routing context.
If no path is configured, then each next-hop of the MS-PW used by the spoke-SDP will be
chosen locally at each T-PE and S-PE.
Default
Parameters
no path
name — The name of the explicit path to be used, as configured under
config>service>pw-routing.
precedence
Syntax
Context
Description
precedence prec-value
precedence primary
no precedence
config>service>epipe>spoke-sdp-fec
This command specifies the precedence of the SDP binding when there are multiple SDP
bindings attached to one service endpoint. The value of zero can only be assigned to one
SDP bind making it the primary SDP bind. When an SDP binding goes down, the next highest
precedence SDP binding will begin to forward traffic.
The no form of the command returns the precedence value to the default.
378
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
Default
Parameters
VLL Services
42
prec-value — Specifies the spoke SDP precedence.
Values
1 to 4
primary — Assigns primary precedence to this spoke SDP.
pw-template-bind
Syntax
Context
Description
pw-template-bind policy-id
no pw-template-bind
config>service>epipe>spoke-sdp-fec
This command binds includes the parameters included in a specific PW Template to a spoke
SDP.
The no form of the command removes the values from the configuration.
Default
Parameters
none
policy-id — Specifies the existing policy ID.
Values
1 to 2147483647
retry-count
Syntax
Context
Description
retry-count retry-count
no retry-count
config>service>epipe>spoke-sdp-fec
This optional command specifies the number of attempts software should make to reestablish the spoke-SDP after it has failed. After each successful attempt, the counter is reset
to zero.
When the specified number is reached, no more attempts are made and the spoke-sdp is put
into the shutdown state.
Use the no shutdown command to bring up the path after the retry limit is exceeded.
The no form of this command reverts the parameter to the default value.
Default
Parameters
30
retry-count — The maximum number of retries before putting the spoke-sdp into the
shutdown state.
Values
Issue: 01
10 to 10000
3HE 11970 AAAA TQZZA 01
379
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
retry-timer
Syntax
Context
Description
retry-timer retry-timer
no retry-timer
config>service>epipe>spoke-sdp-fec
This command specifies a retry-timer for the spoke-SDP. This is a configurable exponential
back-off timer that determines the interval between retries to re-establish a spoke-SDP if it
fails and a label withdraw message is received with the status code “AII unreachable”.
The no form of this command reverts the timer to its default value.
Default
Parameters
30
retry-timer — The initial retry-timer value in seconds.
Values
10 to 480
saii-type2
Syntax
Context
saii-type2 global-id:prefix:ac-id
no saii-type2
config>service>epipe>spoke-sdp-fec
Description
This command configures the source attachment individual identifier for the spoke-sdp. This
is only applicable to FEC129 AII type 2.
Parameters
global-id — A Global ID of this router T-PE. This value must correspond to one of the
global_id values configured for a local-prefix under config>service>pwrouting>local-prefix context.
Values
1 to 4294967295
prefix — The prefix on this router T-PE that the spoke-sdp SDP is associated with.This
value must correspond to one of the prefixes configured under config>service>pwrouting>local-prefix context.
Values
an IPv4-formatted address a.b.c.d or 1 to 4294967295
ac-id — An unsigned integer representing a locally unique identifier for the spoke-SDP.
Values
1 to 4294967295
signaling
Syntax
Context
380
signaling signaling
config>service>epipe>spoke-sdp-fec
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
Description
VLL Services
This command enables a user to configure this router as the active pr passive T-PE for
signaling this MS-PW, or to automatically select whether this T-PE is active or passive based
on the prefix. In an active role, this endpoint initiates MS-PW signaling without waiting for a
T-LDP label mapping message to arrive from the far end T-PE. In a passive role, it will wait
for the initial label mapping message from the far end before sending a label mapping for this
end of the PW. In auto mode, if the SAII has the greater prefix value, then the router will
initiate MS-PW signaling without waiting for a label mapping message from the far end.
However, if the TAII has the greater value prefix, then the router will assume that the far end
T-PE will initiate MS-PW signaling and will wait for that label mapping message before
responding with a T-LDP label mapping message for the MS-PW in the reverse direction.
The no form of the command means that the router T-PE automatically selects the which
router will initiate MS-PW signaling based on the prefix values configured in the SAII and TAII
of the spoke-SDP, as described above.
Default
Parameters
auto
signaling — Configures this router as the active T-PE for signaling this MS-PW.
Values
auto, master
standby-signaling-slave
Syntax
Context
Description
[no] standby-signaling-slave
config>service>epipe>spoke-sdp-fec
This command enables standby-signaling-slave for an Epipe.
taii-type2
Syntax
Context
Description
taii-type2 global-id:prefix:ac-id
no taii-type2
config>service>epipe>spoke-sdp-fec
taii-type2 configures the target attachment individual identifier for the spoke-sdp. This is only
applicable to FEC129 AII type 2.
This command is blocked in CLI if this end of the spoke-SDP is configured for single-sided
auto configuration (using the auto-config command).
Parameters
global-id — A Global ID of this router T-PE. This value must correspond to one of the
global_id values configured for a local-prefix under config>service>pwrouting>local-prefix context.
Values
Issue: 01
1 to 4294967295
3HE 11970 AAAA TQZZA 01
381
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
prefix — The prefix on this router T-PE that the spoke-sdp SDP is associated with.This
value must correspond to one of the prefixes configured under config>service>pwrouting>local-prefix context.
Values
an IPv4-formatted address a.b.c.d or 1 to 4294967295
ac-id — An unsigned integer representing a locally unique identifier for the spoke-SDP.
Values
2.17.2.10
1 to 4294967295
ATM Commands
atm
Syntax
Context
Description
atm
config>service>epipe>sap
config>service>apipe>sap
config>service>ipipe>sap
config>service>epipe>sap
This command enables access to the context to configure ATM-related attributes.This
command can only be used when a given context (for example, a channel or SAP) supports
ATM functionality such as:
• Configuring ATM port or ATM port-related functionality on MDAs supporting ATM
functionality
• Configuring ATM-related configuration for ATM-based SAPs that exist on MDAs
supporting ATM functionality.
If ATM functionality is not supported for a given context, the command returns an error.
egress
Syntax
Context
Description
382
egress
config>service>epipe>sap
config>service>epipe>sap>atm
config>service>apipe>sap>atm
config>service>fpipe>sap
This command configures egress ATM attributes for the SAP.
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
ingress
Syntax
Context
Description
ingress
config>service>epipe>sap
config>service>epipe>sap>atm
config>service>epipe>sap
config>service>apipe>sap>atm
This command configures ingress ATM attributes for the SAP.
encapsulation
Syntax
encapsulation atm-encap-type
Context
config>service>epipe>sap>atm
Description
Default
Parameters
This command specifies the data encapsulation for an ATM PVCC delimited Epipe SAP. The
definition references RFC 2684, Multiprotocol Encapsulation over ATM AAL5, and to the ATM
Forum LAN Emulation specification. Ingress traffic that does not match the configured
encapsulation will be dropped.
aal5snap-bridged
atm-encap-type — Specifies the encapsulation type.
Values
aal5snap-bridged — Bridged encapsulation for LLC encapsulated
circuit (LLC/SNAP precedes protocol datagram) as defined in RFC
2684.
aal5mux-bridged-eth-nofcs — Bridged IP encapsulation for VC
multiplexed circuit as defined in RFC 2684.
encapsulation
Syntax
encapsulation atm-encap-type
Context
config>service>ipipe>sap>atm
Description
Default
Issue: 01
This command specifies the data encapsulation for an ATM PVCC delimited Ipipe SAP. The
definition references RFC 2684, Multiprotocol Encapsulation over ATM AAL5, and to the ATM
Forum LAN Emulation specification. Ingress traffic that does not match the configured
encapsulation will be dropped.
aal5snap-routed
3HE 11970 AAAA TQZZA 01
383
VLL Services
Parameters
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
atm-encap-type — Specifies the encapsulation type.
Values
aal5snap-routed — Routed encapsulation for LLC encapsulated
circuit (LLC/SNAP precedes protocol datagram) as defined in RFC
2684.
aal5mux-ip — Routed IP encapsulation for VC multiplexed circuit
as defined in RFC 2684.
traffic-desc
Syntax
Context
Description
traffic-desc traffic-desc-profile-id
no traffic-desc
config>service>epipe>sap
config>service>apipe>sap>atm>egress
config>service>apipe>sap>atm>ingress
config>service>epipe>sap>atm>egress
config>service>epipe>sap>atm>ingress
This command assigns an ATM traffic descriptor profile to a given context (for example, a
SAP).
When configured under the ingress context, the specified traffic descriptor profile defines the
traffic contract in the forward direction. When configured under the egress context, the
specified traffic descriptor profile defines the traffic contract in the backward direction.
The no form of the command reverts the traffic descriptor to the default traffic descriptor
profile.
Default
Parameters
2.17.2.11
The default traffic descriptor (trafficDescProfileId. = 1) is associated with newly created
PVCC-delimited SAPs.
traffic-desc-profile-id — Specifies a defined traffic descriptor profile (see the QoS atm-tdprofile command).
OAM Commands
oam
Syntax
Context
384
oam
config>service>epipe>sap
config>service>apipe>sap>atm
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
Description
VLL Services
This command enters the context to configure OAM functionality for a PVCC delimiting a
SAP.
• The ATM-capable MDAs support end-to-end and segment OAM functionality (AIS, RDI,
Loopback) over both F5 (VC) and end-to-end F4 (VP) OAM:
• ITU-T Recommendation I.610 - B-ISDN Operation and Maintenance version 11/95
• GR-1248-CORE - Generic Requirements for Operations of ATM N3 June 1996
• GR-1113-CORE - Bellcore, Asynchronous Transfer Mode (ATM) (AAL) Protocols
Generic Requirements, Issue 1, July 1994
alarm-cells
Syntax
Context
Description
[no] alarm-cells
config>service>epipe>sap>oam
config>service>epipe>sap>oam
config>service>apipe>sap>atm>oam
This command configures AIS/RDI fault management on a PVCC. Fault management allows
PVCC terminations to monitor and report the status of their connection by propagating fault
information through the network and by driving PVCC’s operational status.
When alarm-cells functionality is enabled, a PVCC’s operational status is affected when a
PVCC goes into an AIS or RDI state because of an AIS/RDI processing (assuming nothing
else affects PVCC’s operational status, for example, if the PVCC goes DOWN, or enters a
fault state and comes back UP, or exits that fault state). RDI cells are generated when PVCC
is operationally DOWN. No OAM-specific SNMP trap is raised whenever an endpoint enters/
exits an AIS or RDI state, however, if as result of an OAM state change, the PVCC changes
operational status, then a trap is expected from an entity the PVCC is associated with (for
example a SAP).
The no command disables alarm-cells functionality for a PVCC. When alarm-cells
functionality is disabled, a PVCC’s operational status is no longer affected by a PVCC’s OAM
state changes due to AIS/RDI processing (Note that when alarm-cells is disabled, a PVCC
will change operational status to UP due to alarm-cell processing) and RDI cells are not
generated as result of the PVCC going into AIS or RDI state. The PVCC’s OAM status,
however, will record OAM faults as described above.
Default
Enabled for PVCCs delimiting IES SAPs
terminate
Syntax
Context
Issue: 01
[no] terminate
config>service>apipe>sap>atm>oam
3HE 11970 AAAA TQZZA 01
385
VLL Services
Description
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
This command specifies whether this SAP will act as an OAM termination point. ATM SAPs
can be configured to tunnel or terminate OAM cells.
When configured to not terminate (the default is no terminate), the SAP will pass OAM cells
through the VLL without inspecting them. The SAP will respond to OAM loopback requests
that are directed to the local node by transmitting a loopback reply. Other loopback requests
are transparently tunneled through the pseudowire. In this mode, it is possible to launch a
loopback request towards the directly-attached ATM equipment and see the results of the
reply.
When configured to terminate, the SAP will respond to AIS by transmitting RDI and will signal
the change of operational status to the other endpoint (for example, through LDP status
notifications). The SAP will respond to OAM loopback requests by transmitting a loopback
reply. In this mode, it is possible to launch a loopback request towards the directly-attached
ATM equipment and see the results of the reply.
For Apipe services, the user has the option of enabling or disabling this option for VC types
atm-vcc and atm-sdu since these service types maintain the ATM layer and/or the AAL5 layer
across the VLL. It is not supported on atm-vpc and atm-cell apipe vc types since the VLL must
pass the VC level (F5) OAM cells.
The terminate option for OAM is the only and default mode of operation supported for an
ATM SAP which is part of Epipe, Ipipe, VPLS, and IES/VPRN. This is because the ATM and
AAL5 layers are terminated.
For Apipe services, the user has the option of enabling or disabling this option for vc types
atm-vcc and atm-sdu since these service types maintain the ATM layer and/or the AAL5 layer
across the VLL. It is not supported on atm-vpc and atm-cell Apipe vc types since the VLL must
pass the VC level (F5).
The terminate option for OAM is the only and default mode of operation supported for an
ATM SAP which is part of Epipe, Ipipe, VPLS, and IES/VPRN. This is because the ATM and
AAL5 layers are terminated.
Default
2.17.2.12
no terminate
Cpipe Commands
endpoint
Syntax
Context
386
[no] endpoint endpoint-name
config>service>cpipe
Description
This command configures a service endpoint.
Parameters
endpoint-name — Specifies an endpoint name.
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
active-hold-delay
Syntax
Context
Description
active-hold-delay active-hold-delay
no active-hold-delay
config>service>cpipe>endpoint
This command specifies that the node will delay sending the change in the T-LDP status bits
for the service endpoint when the MC-LAG transitions the LAG subgroup which hosts the
SAP for this VLL endpoint from “active” to “standby” or when any object in the endpoint. For
example., SAP, ICB, or regular spoke SDP, transitions from up to down operational state.
By default, when the MC-LAG transitioned the LAG subgroup which hosts the SAP for this
VLL endpoint from “active” to “standby”, the node sends immediately new T-LDP status bits
indicating the new value of “standby” over the spoke SDPs which are on the mate-endpoint
of the VLL. The same applies when any object in the endpoint changes an operational state
from up to down.
There is no delay applied to the VLL endpoint status bit advertisement when the MC-LAG
transitions the LAG subgroup which hosts the SAP from “standby” to “active” or when any
object in the endpoint transitions to an operationally up state.
Default
Parameters
0 — A value of zero means that when the MC-LAG transitioned the LAG subgroup which
hosts the SAP for this VLL endpoint from “active” to “standby”, the node sends immediately
new T-LDP status bits indicating the new value of “standby” over the spoke SDPs which are
on the mate-endpoint of the VLL. The same applies when any object in the endpoint changes
an operational state from up to down.
active-hold-delay — Specifies the active hold delay in 100s of milliseconds.
Values
0 to 60
revert-time
Syntax
Context
revert-time revert-time
revert-time infinite
no revert-time
config>service>cpipe>endpoint
Description
This command configures the time to wait before reverting back to the primary spoke SDP
defined on this service endpoint, after having failed over to a backup spoke SDP.
Parameters
revert-time — Specifies the time, in seconds, to wait before reverting to the primary SDP.
Values
0 to 600
infinite — Causes the endpoint to be non-revertive.
Issue: 01
3HE 11970 AAAA TQZZA 01
387
VLL Services
2.17.2.13
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL SAP Commands
sap
Syntax
Context
Description
sap sap-id [no-endpoint] [create]
sap sap-id endpoint endpoint-name [create]
no sap sap-id
config>service>cpipe
This command creates a Service Access Point (SAP) within a service. A SAP is a
combination of port and encapsulation parameters which identifies the service access point
on the interface and within the service router. Each SAP must be unique.
All SAPs must be explicitly created. If no SAPs are created within a service or on an IP
interface, a SAP will not exist on that object.
Enter an existing SAP without the create keyword to edit SAP parameters. The SAP is owned
by the service in which it was created.
A SAP can only be associated with a single service. A SAP can only be defined on a port that
has been configured as an access port using the config router interface port-type port-id
mode access command. Channelized TDM ports are always access ports.
If a port is shutdown, all SAPs on that port become operationally down. When a service is
shutdown, SAPs for the service are not displayed as operationally down although all traffic
traversing the service will be discarded.
The operational state of a SAP is relative to the operational state of the port on which the SAP
is defined.
The no form of this command deletes the SAP with the specified port. When a SAP is deleted,
all configuration parameters for the SAP will also be deleted.
Default
Special Cases
No SAPs are defined.
VLL Services — A SAP can be defined with Ethernet ports, SONET/SDH or TDM
channels. At most, only one sdp-id can be bound to an VLL service. Since a VLL is
a point-to-point service, it can have, at most, two end points. The two end points can
be one SAP and one SDP or two SAPs. Up to 49 SDPs can be associated with a
service in a single router. Each SDP must have a unique router destination or an error
will be generated.
A default SAP has the following format: port-id:*. This type of SAP is supported only
on Ethernet MDAs and its creation is allowed only in the scope of Layer 2 services.
This type of SAP is mutually exclusive with a SAP defined by explicit null
encapsulation (for example, 1/1/1:0).
Parameters
388
sap-id — Specifies the physical port identifier portion of the SAP definition.
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
port-id — Specifies the physical port ID.
If the card in the slot has Media Dependent Adapters (MDAs) installed, the port-id
must be in the slot_number/MDA_number/port_number format. For example 61/2/3
specifies port 3 on MDA 2 in slot 61.
The port-id must reference a valid port type. When the port-id parameter represents
SONET/SDH and TDM channels, the port ID must include the channel ID. A period
“.” separates the physical port from the channel-id. The port must be configured as
an access port.
If the SONET/SDH port is configured as clear-channel then only the port is specified.
port-id
slot/mda/port [.channel]
eth-sat-id
pxc-id
esat-id/slot/port
esat
keyword
id
1 to 20
pxc-id.sub-port
pxc
keyword
id
1 to 64
sub-port
a, b
endpoint — Adds a SAP endpoint association.
no endpoint — Removes the association of a SAP or a spoke-sdp with an explicit
endpoint name.
create — Keyword used to create a SAP instance. The create keyword requirement can
be enabled/disabled in the environment>create context.
cem
Syntax
Context
Description
cem
config>service>cpipe>sap
This command enters the context to specify circuit emulation (CEM) properties.
packet
Syntax
Context
Description
Issue: 01
packet jitter-buffer milliseconds [payload-size bytes]
packet payload-size bytes
no packet
config>service>cpipe>sap
This command specifies the jitter buffer size, in milliseconds, and payload size, in bytes.
3HE 11970 AAAA TQZZA 01
389
VLL Services
Default
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
The default value depends on the CEM SAP endpoint type, and if applicable, the number of
timeslots.
Table 19
Parameters
Default CEM SAP Endpoint Types
Endpoint Type
Timeslots
Default Jitter Buffer (in ms)
unstructuredE1
n/a
5
unstructuredT1
n/a
5
nxDS0 (E1/T1)
N=1
32
N = 2 to 4
16
N = 5 to 15
8
N >= 16
5
nxDS0WithCas (E1)
N
8
nxDS0WithCas (T1)
N
12
milliseconds — specifies the jitter buffer size in milliseconds (ms).
Configuring the payload size and jitter buffer to values that result in less than 2 packet
buffers or greater than 32 packet buffers is not allowed.
Setting the jitter butter value to 0 sets it back to the default value.
Values
1 to 250
payload-size bytes — Specifies the payload size (in bytes) of packets transmitted to the
packet service network (PSN) by the CEM SAP. This determines the size of the data
that will be transmitted over the service. If the size of the data received is not
consistent with the payload size, then the packet is considered malformed.
Values
0, 16 to 2048
Default
The default value depends on the CEM SAP endpoint type, and if
applicable, the number of timeslots.
Table 20
390
Payload Size CEM SAP Endpoint Types
Endpoint Type
Timeslots
Default Payload Size (in bytes)
unstructuredE1
n/a
256
unstructuredT1
n/a
192
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
Table 20
VLL Services
Payload Size CEM SAP Endpoint Types (Continued)
Endpoint Type
Timeslots
Default Payload Size (in bytes)
nxDS0 (E1/T1)
N=1
64
N = 2 to 4
N x 32
N = 5 to 15
N x 16
N >= 16
Nx8
nxDS0WithCas (E1)
N
N x 16
nxDS0WithCas (T1)
N
N x 24
For all endpoint types except for nxDS0WithCas, the valid payload
size range is from the default to 2048 bytes.
For nxDS0WithCas, the payload size divide by the number of
timeslots must be an integer factor of the number of frames per trunk
multi-frame (for example, 16 for E1 trunk and 24 for T1 trunk).
For 1xDS0, the payload size must be a multiple of 2.
For NxDS0, where N > 1, the payload size must be a multiple of the
number of timeslots.
For unstructuredE1 and unstructuredT1, the payload size must be a
multiple of 32 bytes.
Configuring the payload size and jitter buffer to values that result in
less than 2 packet buffers or greater than 32 packet buffer is not
allowed.
Setting the payload size to 0 sets it back to the default value.
report-alarm
Syntax
Context
Description
[no] report-alarm [stray] [malformed] [pktloss] [overrun] [underrun] [rpktloss] [rfault]
[rrdi]
config>service>cpipe>sap>cem
This command indicates the type of CEM SAP alarm.
The no form of the command removes the parameter from the configuration.
Parameters
stray — Reports the reception of packets not destined for this CES circuit.
malformed — Reports the reception of packet not properly formatted as CES packets.
pktloss — Reports the lack of reception of CES packets.
overrun — Reports the reception of too many CES packets resulting in a overrun of the
receive jitter buffer.
Issue: 01
3HE 11970 AAAA TQZZA 01
391
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
underrun — Reports the reception of too few CES packets resulting in a overrun of the
receive jitter buffer.
rpktloss — Reports hat the remote peer is currently in packet loss status.
rfault — Reports that the remote TDM interface is currently not in service.
rrdi — Reports that the remote TDM interface is currently in RDI status.
rtp-header
Syntax
Context
Description
Default
2.17.2.14
[no] rtp-header
config>service>cpipe>sap>cem
This command specifies whether an RTP header is used when packets are transmitted to the
packet service network (PSN) by the CEM SAP.
no rtp-header
CPipe SDP Commands
spoke-sdp
Syntax
Context
Description
spoke-sdp sdp-id[:vc-id] [no-endpoint] [create]
spoke-sdp sdp-id:vc-id [create] endpoint endpoint-name [icb]
no spoke-sdp sdp-id[:vc-id]
config>service>cpipe
This command binds a service to an existing Service Distribution Point (SDP). A spoke SDP
is treated like the equivalent of a traditional bridge “port” where flooded traffic received on the
spoke SDP is replicated on all other “ports” (other spoke and mesh SDPs or SAPs) and not
transmitted on the port it was received.
The SDP has an operational state which determines the operational state of the SDP within
the service. For example, if the SDP is administratively or operationally down, the SDP for the
service will be down.
The SDP must already be defined in the config>service>sdp context. If the sdp sdp-id is
not already configured, an error message is generated. If the sdp-id does exist, a binding
between that sdp-id and the service is created.
SDPs must be explicitly associated and bound to a service. If an SDP is not bound to a
service, no far-end devices can participate in the service.
392
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
The no form of this command removes the SDP binding from the service. The SDP
configuration is not affected; only the binding of the SDP to a service. Once removed, no
packets are forwarded to the far-end router.
Default
Parameters
No sdp-id is bound to a service.
sdp-id — The SDP identifier. Allowed values are integers in the range of 1 to 17407 for
existing SDPs.
vc-id — The virtual circuit identifier.
Values
1 to 4294967295
vc-type — This command overrides the default VC type signaled for the spoke or mesh
binding to the far end of the SDP. The VC type is a 15 bit-quantity containing a value
which represents the type of VC. The actual signaling of the VC type depends on the
signaling parameter defined for the SDP. If signaling is disabled, the vc-type
command can still be used to define the dot1q value expected by the far-end provider
equipment. A change of the bindings VC type causes the binding to signal the new
VC type to the far end when signaling is enabled.
VC types are derived according to IETF draft-martini-l2circuit-trans-mpls.
The VC type value for Ethernet is 0x0005.
The VC type value for an Ethernet VLAN is 0x0004.
The VC type value for a VPLS service is defined as 0x000B.
Values
ethernet
no endpoint — Removes the association of a spoke SDP with an explicit endpoint
name.
endpoint-name — Specifies the name of the service endpoint.
icb — Configures the spoke SDP as an inter-chassis backup SDP binding.
egress
Syntax
Context
Description
egress
config>service>cpipe>spoke-sdp
This command enters the context to configure egress spoke-SDP context.
ingress
Syntax
Context
Description
Issue: 01
ingress
config>service>cpipe>spoke-sdp
This command enters the context to configure ingress spoke-SDP context.
3HE 11970 AAAA TQZZA 01
393
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
vc-label
Syntax
Context
Description
vc-label egress-vc-label
no vc-label [egress-vc-label]
config>service>cpipe>spoke-sdp>egress
config>service>cpipe>spoke-sdp>ingress
This command configures the spoke-SDP egress and ingress VC label.
Note that the actual maximum value that can be configured is limited by the
config>router>mpls-labels>static-label-range command.
Parameters
egress-vc-label — A VC egress value that indicates a specific connection.
Values
for egress: 16 to 1048575
Values
for ingress: 32 to 18431
precedence
Syntax
Context
Description
precedence [precedence-value | primary]
no precedence
config>service>cpipe>spoke-sdp
This command specifies the precedence of the SDP binding when there are multiple SDP
bindings attached to one service endpoint. The value of zero can only be assigned to one
SDP bind making it the primary SDP bind. When an SDP binding goes down, the next highest
precedence SDP binding will begin to forward traffic.
The no form of the command returns the precedence value to the default.
Default
Parameters
4
precedence-value — Specifies the spoke SDP precedence.
Values
1 to 4
primary — Specifies to make this the primary spoke SDP.
2.17.2.15
Epipe SAP Template Commands
template
Syntax
394
template
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
Context
Description
VLL Services
config>service
This is the node for service templates.
epipe-sap-template
Syntax
Context
Description
epipe-sap-template name [create]
no epipe-sap-template name
config>service>template
This command specifies which SAP parameter template should be applied to the l2-ap SAP.
This can only be changed when the l2-ap is shutdown.
The no form of the command removes the template, the SAP will use default parameters.
Default
Parameters
None
name — Specifies the SAP template name associated with this template.
egress
Syntax
Context
Description
egress
config>service>template
This command enters the context to configure egress filter policies.
ingress
Syntax
Context
Description
ingress
config>service>template>epipe-sap-template
This command enters the context to configure ingress SAP Quality of Service (QoS) policies
and filter policies.
filter
Syntax
Context
Description
Issue: 01
[no] filter
config>service>template>epipe-sap-template>egress
config>service>template>epipe-sap-template>ingress
This command enters the context to configure filter parameters.
3HE 11970 AAAA TQZZA 01
395
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
ip
Syntax
Context
ip filter-id
no ip
config>service>template>epipe-sap-template>egress>filter
config>service>template>epipe-sap-template>ingress>filter
Description
This command associates an existing IP filter policy with the template.
Parameters
filter-id — Specifies the IP filter policy ID. The filter ID must already exist within the
created IP filters.
Values
1 to 65535
ipv6
Syntax
Context
ipv6 filter-id
no ipv6
config>service>template>epipe-sap-template>egress>filter
config>service>template>epipe-sap-template>ingress>filter
Description
This command associates an existing IPv6 filter policy with the template.
Parameters
ipv6-filter-id — Specifies the IPv6 filter policy. The filter ID must already exist within the
created IPv6 filters.
Values
1 to 65535
mac
Syntax
Context
mac filter-id
no mac
config>service>template>epipe-sap-template>egress>filter
config>service>template>epipe-sap-template>ingress>filter
Description
This command associates an existing MAC filter policy with the template.
Parameters
mac-filter-id — Specifies the MAC filter policy. The specified filter ID must already exist
within the created MAC filters. The filter policy must already exist within the created
MAC filters.
Values
396
1 to 65535
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
qos
Syntax
Context
qos policy-id
no qos
config>service>template>epipe-sap-template>egress
Description
This command associates an existing QoS policy with the template.
Parameters
policy-id — The egress policy ID to associate with SAP or IP interface on egress. The
policy ID must already exist.
Values
1 to 65535, or a name up to 64 characters in length
qos
Syntax
qos policy-id {shared-queuing | multipoint-shared}
qos policy-id
no qos
Context
config>service>template>epipe-sap-template>ingress
Description
Default
Parameters
This command associates a Quality of Service (QoS) policy with an ingress Service Access
Point (SAP) for the Epipe SAP template.
none
policy-id — The ingress policy ID to associate with SAP or IP interface on ingress. The
policy ID must already exist.
Values
1 to 65535
shared-queuing — This keyword can only be specified on SAP ingress. Specify the
ingress shared queue policy used by this SAP. When the value of this object is null,
the SAP will use individual ingress QoS queues, instead of the shared ones.
multipoint-shared — This keyword can only be specified on SAP ingress. Multipoint
shared queuing is a superset of shared queuing. When multipoint shared queuing
keyword is set, in addition to the unicast packets, multipoint packets also used
shared queues.
Ingress unicast service queues are mapped one-for-one with hardware queues and
unicast packets traverse the ingress forwarding plane twice, similar to the sharedqueuing option. In addition, the multipoint queues defined in the ingress SAP QoS
policy are not created. Instead, multipoint packets (broadcast, multicast and
unknown unicast destined) are treated to the same dual pass ingress forwarding
plane processing as unicast packets.
When the value of this object is null, the SAP will use individual ingress QoS queues,
instead of the shared ones.
Issue: 01
3HE 11970 AAAA TQZZA 01
397
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
When the value of this object is null, the SAP will use individual ingress QoS queues,
instead of the shared ones.
398
Values
Multipoint or not present.
Default
Present (the queue is created as non-multipoint).
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
2.18
VLL Services
VLL Show Command Reference
This section describes the VLL show command reference.
2.18.1
Command Hierarchies
2.18.1.1
Show Commands
show
— service
— egress-label start-label [end-label]
— id service-id
— all
— authentication
— base [msap]
— bgp-vpws
— endpoint [endpoint-name]
— labels
— retailers
— sap sap-id detail
— sdp [sdp-id[:vc-id]] | far-end {ip-address | ipv6-address}] [mrp] [detail]]
— spoke-sdp-fec [[1 to 4294967295]]
— stp [detail]
— stp mst-instance mst-instance-number
— vccv-bfd [session]
— wholesalers
— ingress-label start-label [end-label]
— sap-using [msap] [dyn-script] [description]
— sap-using [sap sap-id] [vlan-translation | anti-spoof] [description]
— sap-using {ingress | egress} atm-td-profile td-profile-id
— sap-using {ingress | egress} filter any-filter-id
— sap-using {ingress | egress} qos-policy qos-policy-id [msap]
— sap-using etree
— sdp sdp-id pw-port [pw-port-id]
— sdp sdp-id pw-port
— sdp sdp-id pw-port pw-port-id [statistics]
— sdp [consistent | inconsistent | na] egressifs
— sdp sdp-id keep-alive-history
— sdp far-end {ip-address | ipv6-address} keep-alive-history
— sdp [sdp-id] detail
— sdp far-end {ip-address | ipv6-address} detail
— sdp-using etree
— sdp-using node-id node-id [global-id global-id]
— sdp-using arrp arrpID
— sdp-using app-profile app-profile-name
— sdp-using far-end {ip-address | ipv6-address}
Issue: 01
3HE 11970 AAAA TQZZA 01
399
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
—
—
—
—
—
—
—
—
sdp-using [sdp-is[:vc-id]]
sdp-using transit-policy ip transit-ip-policy
sdp-using transit-policy prefix transit-prefix-policy
service-using [epipe] [ies] [vpls] [vprn] [mirror] [apipe] [fpipe] [ipipe] [cpipe] [etree]
[vsd] [b-vpls] [i-vpls] [m-vpls] [sdp sdp-id] [customer customer-id] [origin
creation-origin]
— spoke-sdp-fec-using [spoke-sdp-fec-id spoke-sdp-fec-id] [saii-type2 globalid:prefix:ac-id] [taii-type2 global-id:prefix:ac-id] [path name] [expired]
pw-port [pw-port-id] [detail]
pw-port sdp sdp-id
pw-port none
pw-port pw-port-id statistics
show
— connection-profile [1 to 8000]
2.18.1.2
Clear Commands
clear
— service
— id service-id
— arp
— host-tracking [statistics]
— host-tracking sap sap-id [host ip-address] [statistics]
— mesh-sdp sdp-id[:vc-id] ingress-vc-label
— mesh-sdp sdp-id[:vc-id] vccv-bfd {session | statistics}
— spoke-sdp sdp-id:vc-id ingress-vc-label
— spoke-sdp sdp-id:vc-id l2tpv3
— spoke-sdp sdp-id:vc-id vccv-bfd {session | statistics}
— statistics
— id service-id
— counters
— spoke-sdp sdp-id[:vc-id] {all | counters | stp | 12pt | mrp}
— sap sap-id {all | cem | counters | stp | 12pt | mrp}
— sap sap-id encap-group group-name [member encap-id]
— sdp sdp-id keep-alive
— sdp sdp-id pw-port [1 to 10239]
2.18.1.3
Debug Commands
debug
— service
— id service-id
— [no] sap sap-id
— [no] event-type {arp | config-change | oper-status-change |
neighbor -discovery}
— [no] sdp sdp-id:vc-id
400
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
— [no] event-type {arp | config-change | oper-status-change |
neighbor -discovery}
2.18.1.4
Tools Commands
tools
— dump
— epipe-map-access-to-egress-port service service-id [end-service service-id]
— epipe-map-access-to-egress-port lag lag-id summary
Issue: 01
3HE 11970 AAAA TQZZA 01
401
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
2.18.2
Command Descriptions
2.18.2.1
VLL Show Commands
The following command outputs are examples only; actual displays may differ
depending on supported functionality and user configuration.
egress-label
Syntax
Context
Description
egress-label egress-label1 [egress-label2]
show>service
This command displays services using the range of egress labels. If only the mandatory
egress-label1 parameter is specified, only services using the specified label are displayed.
If both egress-label1 and egress-label2 parameters are specified, the services using the
range of labels X where egress-label1 <= X <= egress-label2 are displayed.
Use the show router ldp bindings command to display dynamic labels.
Parameters
egress-label1 — The starting egress label value for which to display services using the
label range. If only egress-label1 is specified, services only using egress-label1 are
displayed.
Values
0, 2049 to 131071
egress-label2 — The ending egress label value for which to display services using the
label range.
Output
Default
The egress-label1 value.
Values
2049 to 131071
The following output is an example of egress label information, and Table 21 describes the
output fields.
Sample Output
*A:ALA-12# show service egress-label 0 10000
==============================================================================
Martini Service Labels
==============================================================================
Svc Id
Sdp Id
Type I.Lbl
E.Lbl
-----------------------------------------------------------------------------1
10:1
Mesh 0
0
1
20:1
Mesh 0
0
1
30:1
Mesh 0
0
1
100:1
Mesh 0
0
402
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
...
1
107:1
Mesh 0
0
1
108:1
Mesh 0
0
1
300:1
Mesh 0
0
1
301:1
Mesh 0
0
1
302:1
Mesh 0
0
1
400:1
Mesh 0
0
1
500:2
Spok 131070
2001
1
501:1
Mesh 131069
2000
100
300:100
Spok 0
0
200
301:200
Spok 0
0
300
302:300
Spok 0
0
400
400:400
Spok 0
0
-----------------------------------------------------------------------------Number of Bindings Found : 23
==============================================================================
*A:ALA-12#
Table 21
Show Service Egress Label Output Fields
Label
Description
Svc Id
The ID that identifies a service.
Sdp Id
The ID that identifies an SDP.
Type
Indicates whether the SDP binding is spoke or mesh.
I. Lbl
The VC label used by the far-end device to send packets to this
device in this service by the SDP.
E. Lbl
The VC label used by this device to send packets to the far-end
device in this service by the SDP.
Number of bindings
found
The total number of SDP bindings that exist within the specified
egress label range.
ingress-label
Syntax
Context
Description
ingress-label start-label [end-label]
show>service
This command displays services using the range of ingress labels. If only the mandatory
start-label parameter is specified, only services using the specified label are displayed.
If both start-label and end-label parameters are specified, the services using the range of
labels X where start-label <= X <= end-label are displayed.
Use the show router vprn-service-id ldp bindings command to display dynamic labels.
Issue: 01
3HE 11970 AAAA TQZZA 01
403
VLL Services
Parameters
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
start-label — The starting ingress label value for which to display services using the label
range. If only start-label is specified, services only using start-label are displayed.
Values
0, 18432 to 524287
end-label — The ending ingress label value for which to display services using the label
range.
Output
Values
18432 to 524287
Default
The start-label value.
The following output is an example of ingress label information, and Table 22 describes the
output fields.
Sample Output
*A:ALA-12# show service ingress-label 0
==============================================================================
Martini Service Labels
==============================================================================
Svc Id
Sdp Id
Type I.Lbl
E.Lbl
-----------------------------------------------------------------------------1
10:1
Mesh 0
0
1
20:1
Mesh 0
0
1
30:1
Mesh 0
0
1
50:1
Mesh 0
0
1
100:1
Mesh 0
0
1
101:1
Mesh 0
0
1
102:1
Mesh 0
0
1
103:1
Mesh 0
0
1
104:1
Mesh 0
0
1
105:1
Mesh 0
0
1
106:1
Mesh 0
0
1
107:1
Mesh 0
0
1
108:1
Mesh 0
0
1
300:1
Mesh 0
0
1
301:1
Mesh 0
0
1
302:1
Mesh 0
0
1
400:1
Mesh 0
0
100
300:100
Spok 0
0
200
301:200
Spok 0
0
300
302:300
Spok 0
0
400
400:400
Spok 0
0
-----------------------------------------------------------------------------Number of Bindings Found : 21
-----------------------------------------------------------------------------*A:ALA-12#
Table 22
404
Show Service Ingress-Label Output Fields
Label
Description
Svc ID
The service identifier.
SDP Id
The SDP identifier.
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
Table 22
VLL Services
Show Service Ingress-Label Output Fields (Continued)
Label
Description (Continued)
Type
Indicates whether the SDP is a spoke or a mesh.
I.Lbl
The ingress label used by the far-end device to send packets to
this device in this service by the SDP.
E.Lbl
The egress label used by this device to send packets to the farend device in this service by the SDP.
Number of Bindings
Found
The number of SDP bindings within the label range specified.
sap-using
Syntax
Context
Description
sap-using [msap] [dyn-script] [description]
sap-using [sap sap-id] [vlan-translation | anti-spoof] [description]
sap-using {ingress | egress} atm-td-profile td-profile-id
sap-using {ingress | egress} filter any-filter-id
sap-using {ingress | egress} qos-policy qos-policy-id [msap]
sap-using etree
show>service
This command displays SAP information.
If no optional parameters are specified, the command displays a summary of all defined
SAPs.
The optional parameters restrict output to only SAPs matching the specified properties.
Parameters
ingress — Specifies matching an ingress policy.
egress — Specifies matching an egress policy.
qos-policy-id — The ingress or egress QoS Policy ID for which to display matching SAPs.
Values
1 to 65535
td-profile-id — Displays SAPs using this traffic description for the 7750 SR only.
filter-id — The ingress or egress filter policy ID for which to display matching SAPs.
Values
1 to 65535
sap-id — Specifies the physical port identifier portion of the SAP definition.
dyn-script — Displays dynamic service SAPs information.
msap — Displays MSAPs.
vlan-translation — Displays VLAN translation information.
Issue: 01
3HE 11970 AAAA TQZZA 01
405
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
anti-spoof — Displays anti-spoof information.
Output
The following output is an example if SAP using information, and Table 23 describes the
output fields.
Sample Output
*A:Dut-A# show service sap-using
========================================================================
Service Access Points
===============================================================================
PortId
SvcId
Ing. Ing.
Egr. Egr.
Adm Opr
QoS
Fltr
QoS
Fltr
-----------------------------------------------------------------------1/1/1:1
1
1
none
1
none
Up
Up
2/1/2:10/11
1
1
none
1
none
Up
Up
2/1/2:10/12
1
1
none
1
none
Up
Up
2/1/2:20/11
1
1
none
1
none
Up
Up
2/1/2:20/12
1
1
none
1
none
Up
Up
2/1/4:cp.10
10
1
none
1
none
Up
Up
2/1/4:cp.20
20
1
none
1
none
Up
Up
-----------------------------------------------------------------------Number of SAPs : 7
-----------------------------------------------------------------------========================================================================
The following is a sample of SAP information for a specific SAP for the 7450 ESS or 7750 SR:
A:ALA-42#
*A:ALA-48# show service sap-using sap 1/1/21:0
===============================================================================
Service Access Points Using Port 1/1/21:0
===============================================================================
PortId
SvcId
Ing. Ing.
Egr. Egr.
Anti
Adm Opr
QoS
Fltr
QoS
Fltr
Spoof
------------------------------------------------------------------------------1/1/21:0
1
1
none
1
none
none
Up
Down
------------------------------------------------------------------------------Number of SAPs : 1
===============================================================================
*A:ALA-48#
Following is a sample of SAP information for the egress traffic policy for the 7750 SR.
*A:ALA-12# show service sap-using egress atm-td-profile 2
==============================================================================
Service Access Point Using ATM Traffic Profile 2
===============================================================================
PortId SvcId I.QoS I.Fltr E.QoS E.Fltr A.Pol Adm Opr
------------------------------------------------------------------------------5/1/1:0/11 511111 2 none 2 none none Up Up
5/1/1:0/12 511112 2 none 2 none none Up Up
5/1/1:0/13 511113 2 none 2 none none Up Up
5/1/1:0/14 511114 2none 2 none none Up Up
5/1/1:0/15 511115 2 none 2 none none Up Up
406
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
5/1/1:0/16 511116 2 none 2 none none Up Up
5/1/1:0/17 511117 2 none 2 none none Up Up
5/1/1:0/18 511118 2 none 2 none none Up Up
5/1/1:0/19 511119 2 none 2 none none Up Up
5/1/1:0/20 511120 2 none 2 none none Up Up
5/1/1:0/21 511121 2 none 2 none none Up Up
5/1/1:0/22 511122 2 none 2 none none Up Up
5/1/1:0/23 511123 2 none 2 none none Up Up
5/1/1:0/24 511124 2 none 2 none none Up Up
5/1/1:0/25 511125 2 none 2 none none Up Up
...
===============================================================================
*A:ALA-12#
Table 23
Show Service SAP Output Fields
Label
Description
Port ID
The ID of the access port where the SAP is defined.
Svc ID
The service identifier.
Sap MTU
The SAP MTU value.
Ing. QoS
The SAP ingress QoS policy number specified on the ingress
SAP.
Ing Fltr
The MAC or IP filter policy ID applied to the ingress SAP.
Egr. QoS
The SAP egress QoS policy number specified on the egress SAP
for the 7450 ESS and 7750 SR only.
Egr. Fltr
The MAC or IP filter policy ID applied to the egress SAP.
Adm
The administrative state of the SAP.
Opr
The operational state of the SAP.
sdp-using
Syntax
Context
Issue: 01
sdp-using etree
sdp-using node-id node-id [global-id global-id]
sdp-using aarp aarpID
sdp-using app-profile app-profile-name
sdp-using far-end {ip-address | ipv6-address}
sdp-using [sdp-id[:vc-id]]
sdp-using transit-policy ip transit-ip-policy
sdp-using transit-policy prefix transit-prefix-policy
show>service
3HE 11970 AAAA TQZZA 01
407
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
Description
Display services using SDP or far-end address options.
Parameters
node-id — Specifies the node ID.
Values
a.b.c.d, 1 to 4294967295
global-id — Specifies the global ID.
Values
1 to 4294967295
aarpID — Specifies the AARP ID.
Values
1 to 65535
app-profile-name — 32 characters max.
sdp-id — Displays only services bound to the specified SDP ID.
Values
1 to 17407
vc-id — The virtual circuit identifier.
Values
1 to 4294967295
ip-address — Displays only services matching with the specified far-end IP address. 64
characters maximum.
Default
Services with any far-end IP address.
ipv6-address — Displays only services matching with the specified far-end IPv6 address.
64 characters maximum.
transit-ip-policy — Specifies a transit IP policy ID.
Values
1 to 65535
transit-prefix-policy — Specifies a transit prefix policy ID.
Values
Output
1 to 65535
The following output is an example of SDP using information, and Table 24 describes the
output fields.
Sample Output
*A:ALA-1# show service sdp-using 300
===============================================================================
Service Destination Point (Sdp Id : 300)
===============================================================================
SvcId
SdpId
Type Far End
Opr State I.Label E.Label
------------------------------------------------------------------------------1
300:1
Mesh 10.0.0.13
Up
131071
131071
2
300:2
Spok 10.0.0.13
Up
131070
131070
100
300:100
Mesh 10.0.0.13
Up
131069
131069
101
300:101
Mesh 10.0.0.13
Up
131068
131068
102
300:102
Mesh 10.0.0.13
Up
131067
131067
------------------------------------------------------------------------------Number of SDPs : 5
------------------------------------------------------------------------------*A:ALA-1#
408
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
Table 24
VLL Services
Show Service SDP Using Output Fields
Label
Description
Svc ID
The service identifier.
Sdp ID
The SDP identifier.
Type
Type of SDP: spoke or mesh.
Far End
The far end address of the SDP.
Oper State
The operational state of the service.
Ingress Label
The label used by the far-end device to send packets to this
device in this service by this SDP.
Egress Label
The label used by this device to send packets to the far-end
device in this service by this SDP.
service-using
Syntax
Context
Description
service-using [epipe] [ies] [vpls] [vprn] [mirror] [apipe] [fpipe] [ipipe] [cpipe] [etree] [bvpls] [i-vpls] [m-vpls] [sdp sdp-id] [customer customer-id] [creation creation-origin]
show>service
This command displays the services matching certain usage properties. Not all syntax
options are available for each router type.
If no optional parameters are specified, all services defined on the system are displayed.
Parameters
epipe — Displays epipe services.
ies — Displays IES services.
vpls — Displays VPLS services.
vprn — Displays VPRN services.
mirror — Displays mirror services.
apipe — Displays apipe services.
fpipe — Displays fpipe services.
ipipe — Displays ipipe services.
cpipe — Displays cpipe services.
b-vpls — Specifies the B-component instance of the Provider Backbone Bridging (PBB/
IEEE 802.1ah) feature. It represents the multi-point tunneling component that
multiplexes multiple customer VPNs (ISIDs) together. It is similar to a regular VPLS
instance that operates on the backbone MAC addresses.
Issue: 01
3HE 11970 AAAA TQZZA 01
409
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
i-vpls — Specifies the I-component instance of the Provider Backbone Bridging (PBB/
IEEE 802.1ah) feature. It identifies the specific VPN entity associated to a customer
multipoint (ELAN) service. It is similar to a regular VPLS instance that operates on
the customer MAC addresses.
m-vpls — Specifies the M-component (managed VPLS) instance of the Provider
Backbone Bridging (PBB/IEEE 802.1ah) feature.
sdp-id — Displays only services bound to the specified SDP ID.
Values
1 to 17407
Default
Services bound to any SDP ID.
customer-id — Displays services only associated with the specified customer ID.
Values
1 to 2147483647
Default
Services associated with any customer.
creation-origin — Specifies the method by which the service was created.
Values
Output
manual, multi-segment-p-w, dyn-script, vsd
The following output is an example of service using information, and Table 25 describes the
output fields.
Sample Output
*A:ALA-12# show service service-using customer 10
==============================================================================
Services
==============================================================================
ServiceId
Type
Adm
Opr
CustomerId
Last Mgmt Change
-----------------------------------------------------------------------------1
VPLS
Up
Up
10
09/05/2006 13:24:15
100
IES
Up
Up
10
09/05/2006 13:24:15
300
Epipe
Up
Up
10
09/05/2006 13:24:15
-----------------------------------------------------------------------------Matching Services : 3
==============================================================================
*A:ALA-12#
*A:ALA-12# show service service-using
===============================================================================
Services
===============================================================================
ServiceId
Type
Adm
Opr
CustomerId
Last Mgmt Change
------------------------------------------------------------------------------1
uVPLS
Up
Up
1
10/26/2006 15:44:57
2
Epipe
Up
Down
1
10/26/2006 15:44:57
10
mVPLS
Down
Down
1
10/26/2006 15:44:57
11
mVPLS
Down
Down
1
10/26/2006 15:44:57
100
mVPLS
Up
Up
1
10/26/2006 15:44:57
101
mVPLS
Up
Up
1
10/26/2006 15:44:57
102
mVPLS
Up
Up
1
10/26/2006 15:44:57
999
uVPLS
Down
Down
1
10/26/2006 16:14:33
-------------------------------------------------------------------------------
410
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
Matching Services : 8
------------------------------------------------------------------------------*A:ALA-12#
The following is a sample of epipe service information for the 7450 ESS or 7750 SR.
*A:ALA-12# show service service-using epipe
===============================================================================
Services [epipe]
===============================================================================
ServiceId
Type
Adm
Opr
CustomerId
Last Mgmt Change
------------------------------------------------------------------------------6
Epipe
Up
Up
6
06/22/2006 23:05:58
7
Epipe
Up
Up
6
06/22/2006 23:05:58
8
Epipe
Up
Up
3
06/22/2006 23:05:58
103
Epipe
Up
Up
6
06/22/2006 23:05:58
------------------------------------------------------------------------------Matching Services : 4
===============================================================================
*A:ALA-12#
Table 25
Show Service-Using Output Fields
Label
Description
Service Id
The service identifier.
Type
Specifies the service type configured for the service ID.
Adm
The desired state of the service.
Opr
The operating state of the service.
CustomerID
The ID of the customer who owns this service.
Last Mgmt Change
The date and time of the most recent management-initiated
change to this service.
spoke-sdp-fec-using
Syntax
Context
spoke-sdp-fec-using [spoke-sdp-fec-id spoke-sdp-fec-id] [saii-type2 global-id:prefix:acid] [taii-type2 global-id:prefix:ac-id] [path name] [expired]
show>service
Description
Displays the SDPs used by spoke-sdp-fecs at this node.
Parameters
spoke-sdp-fec-id — Specifies the spoke SDP FEC ID for which to show SDP information.
Values
Issue: 01
1 to 4294967295
3HE 11970 AAAA TQZZA 01
411
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
global-id — Specifies the SAII or TAII global ID.
Values
1 to 4294967295
prefix — Specifies the SAII or TAII prefix.
Values
a.b.c.d, 1 to 4294967295
ac-id — Specifies the SAII or TAII AC ID.
Values
1 to 4294967295
name — Specifies the path name. 32 characters maximum.
expired — Displays information for expired SDPs.
Output
The following output is an example of spoke SDP information.
Sample Output
*A:Dut-C# show service spoke-sdp-fec-using
===============================================================================
Service Spoke-SDP-Fec Information
===============================================================================
SvcId
SpokeSdpFec Oper-SdpBind
SAII-Type2
Path
TAII-Type2
------------------------------------------------------------------------------1
1
17407:4294967245 3:10.20.1.3:1
n/a
6:10.20.1.6:1
2
2
17407:4294967247 3:10.20.1.3:2
n/a
6:10.20.1.6:2
3
3
17407:4294967248 3:10.20.1.3:3
n/a
6:10.20.1.6:3
4
4
17407:4294967249 3:10.20.1.3:4
n/a
6:10.20.1.6:4
5
5
17407:4294967250 3:10.20.1.3:5
n/a
6:10.20.1.6:5
6
6
17407:4294967251 3:10.20.1.3:6
n/a
6:10.20.1.6:6
7
7
17407:4294967252 3:10.20.1.3:7
n/a
6:10.20.1.6:7
8
8
17407:4294967253 3:10.20.1.3:8
n/a
6:10.20.1.6:8
9
9
17407:4294967254 3:10.20.1.3:9
n/a
6:10.20.1.6:9
10
10
17407:4294967255 3:10.20.1.3:10
n/a
6:10.20.1.6:10
------------------------------------------------------------------------------Entries found: 10
vccv-bfd
Syntax
Context
412
vccv-bfd [session]
show>service>id
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
Description
VLL Services
This command shows whether VCCV BFD is configured for a particular service and
information about the VCCV session state.
The show>service>id>vccv-bfd session command gives a summary of all the VCCV
sessions. Using both the sdp-id and the vc-id parameters gives VCCV BFD session
information about a specific spoke-SDP.
For services where auto-discovery and signaling are used (for example, BGP VPWS, VPLS,
and BGP-AD VPLS), use the show>service>id>detail command to determine the sdp-id
and vc-id parameters allocated by the system.
Parameters
Output
session — Displays a summary of all VCCV sessions.
The following output is an example of VCCV BFD information.
Sample Output
*A:Dut-C# show service id 1000 vccv-bfd session
===============================================================================
BFD Session
===============================================================================
Interface/Lsp Name
State
Tx Intvl Rx Intvl Multipl
Remote Address/Info
Protocols
Tx Pkts
Rx Pkts
Type
LAG port/sdp-id:vc-id
LAG ID/SvcId
------------------------------------------------------------------------------N/A
Up (3)
1000
1000
3
N/A
vccv
152
151
central
100:100
1000
------------------------------------------------------------------------------No. of BFD sessions: 1
===============================================================================
id
Syntax
Context
id service-id {all | arp | base | endpoint | fdb | interface | labels | sap | sdp | split-horizongroup | stp}
show>service
Description
This command displays information for a particular service-id.
Parameters
service-id — The service identification number that identifies the service in the domain.
Values
service-id: 1 to 214748364
svc-name: A string up to 64 characters in length.
all — Displays detailed information about the service.
arp — Displays ARP entries for the service.
base — Displays basic service information.
endpoint — Displays service endpoint information.
Issue: 01
3HE 11970 AAAA TQZZA 01
413
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
interface — Displays service interfaces.
labels — Displays labels being used by this service.
sap — Displays SAPs associated to the service.
sdp — Displays SDPs associated with the service.
split-horizon-group — Displays split horizon group information.
stp — Displays STP information.
Output
The following output is an example of service ID information.
Sample Output
A:bksim1611>config>service>ipipe# show service id 1009 all
===============================================================================
Service Detailed Information
===============================================================================
Service Id
: 1009
Vpn Id
: 0
Service Type
: Ipipe
Name
: (Not Specified)
Description
: (Not Specified)
Customer Id
: 1
Last Status Change: 09/15/2010 13:06:46 Last Mgmt Change : 09/15/2010 13:06:02
Admin State
: Up
Oper State
: Up
MTU
: 1500
Vc Switching
: False
SAP Count
: 1
SDP Bind Count
: 1
CE IPv4 Discovery : Enabled
CE IPv6 Discovery : Enabled
------------------------------------------------------------------------------Service Destination Points(SDPs)
------------------------------------------------------------------------------------------------------------------------------------------------------------Sdp Id 5:1009 -(5.5.5.5)
------------------------------------------------------------------------------Description
: (Not Specified)
SDP Id
: 5:1009
Type
: Spoke
Spoke Descr
: (Not Specified)
Split Horiz Grp
: (Not Specified)
VC Type
: Ipipe
VC Tag
: 0
Admin Path MTU
: 0
Oper Path MTU
: 1568
Far End
: 5.5.5.5
Delivery
: MPLS
Tunnel Far End
: n/a
Hash Label
: Disabled
Admin State
Acct. Pol
Ingress Label
Ingr Mac Fltr-Id
Ingr IP Fltr-Id
Ingr IPv6 Fltr-Id
Admin ControlWord
Admin BW(Kbps)
Last Status Change
Last Mgmt Change
Endpoint
PW Status Sig
414
:
:
:
:
:
:
:
:
:
:
:
:
Up
None
131048
n/a
n/a
n/a
Not Preferred
0
09/15/2010 13:06:46
09/15/2010 13:06:02
N/A
Enabled
3HE 11970 AAAA TQZZA 01
Oper State
Collect Stats
Egress Label
Egr Mac Fltr-Id
Egr IP Fltr-Id
Egr IPv6 Fltr-Id
Oper ControlWord
Oper BW(Kbps)
Signaling
:
:
:
:
:
:
:
:
:
Up
Disabled
131053
n/a
n/a
n/a
False
0
TLDP
Precedence
: 4
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
Class Fwding State
Flags
Peer Pw Bits
Peer Fault Ip
Peer Vccv CV Bits
Peer Vccv CC Bits
:
:
:
:
:
:
VLL Services
Down
None
None
None
lspPing
mplsRouterAlertLabel
KeepAlive Information :
Admin State
: Disabled
Hello Time
: 10
Max Drop Count
: 3
Oper State
Hello Msg Len
Hold Down Time
: Disabled
: 0
: 10
Statistics
I. Fwd. Pkts.
I. Fwd. Octs.
E. Fwd. Pkts.
I. Dro. Pkts.
I. Dro. Octs.
E. Fwd. Octets
: 0
: 0
: 1604
:
: 15
: 1460
: 17
------------------------------------------------------------------------------RSVP/Static LSPs
------------------------------------------------------------------------------Associated LSP LIST :
Lsp Name
: to-bksim180-1
Admin State
: Up
Oper State
: Up
Time Since Last Tr*: 16h07m44s
Lsp Name
: to-bksim180-2
Admin State
: Up
Time Since Last Tr*: 16h07m45s
Oper State
: Up
------------------------------------------------------------------------------Class-based forwarding :
------------------------------------------------------------------------------Class forwarding
: Enabled
EnforceDSTELspFc : Disabled
Default LSP
: to-bksim180-1
Multicast LSP
: None
===============================================================================
FC Mapping Table
===============================================================================
FC Name
LSP Name
------------------------------------------------------------------------------ef
to-bksim180-2
===============================================================================
------------------------------------------------------------------------------IPIPE Service Destination Point specifics
------------------------------------------------------------------------------Configured CE IP Addr : n/a
Peer CE IP Addr
: 0.0.0.0
Peer IPv6 Capability
Peer IPv6 LL Addr
Peer IPv6 Global Addr
: No
: FE80::2009:2009:2
: 3FFE:1200:2009:2009:9:9:9:8
------------------------------------------------------------------------------Number of SDPs : 1
------------------------------------------------------------------------------------------------------------------------------------------------------------Service Access Points
-------------------------------------------------------------------------------
Issue: 01
3HE 11970 AAAA TQZZA 01
415
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
------------------------------------------------------------------------------SAP 1/7/3:1009
------------------------------------------------------------------------------Service Id
: 1009
SAP
: 1/7/3:1009
Encap
: q-tag
Description
: (Not Specified)
Admin State
: Up
Oper State
: Up
Flags
: None
Multi Svc Site
: None
Last Status Change : 09/15/2010 13:06:21
Last Mgmt Change
: 09/15/2010 13:06:02
Sub Type
: regular
Dot1Q Ethertype
: 0x8100
QinQ Ethertype
: 0x8100
Split Horizon Group: (Not Specified)
Admin MTU
Ingr IP Fltr-Id
Ingr Mac Fltr-Id
Ingr IPv6 Fltr-Id
tod-suite
Ing Agg Rate Limit
Endpoint
Q Frame-Based Acct
:
:
:
:
:
:
:
:
1518
n/a
n/a
n/a
None
max
N/A
Disabled
Oper MTU
:
Egr IP Fltr-Id
:
Egr Mac Fltr-Id
:
Egr IPv6 Fltr-Id :
qinq-pbit-marking :
Egr Agg Rate Limit:
1518
n/a
n/a
n/a
both
max
Acct. Pol
: None
Collect Stats
: Disabled
Oper Group
: (none)
Monitor Oper Grp
: (none)
------------------------------------------------------------------------------ETH-CFM SAP specifics
------------------------------------------------------------------------------Tunnel Faults
: n/a
CFM Hold-Timer
: n/a
------------------------------------------------------------------------------Ipipe SAP Configuration Information
------------------------------------------------------------------------------Configured CE IP
: n/a
Discovered CE IP : 209.1.1.1
SAP MAC Address
: ac:55:01:07:00:03
Mac Refresh Inter*: 14400
------------------------------------------------------------------------------Ipipe SAP IPv4 ARP Entry Info
------------------------------------------------------------------------------209.1.1.1
00:11:22:33:44:55 dynamic
------------------------------------------------------------------------------Ipipe SAP IPv6 Neighbor Entry Info
------------------------------------------------------------------------------FE80::2009:2009:1
00:11:22:33:44:55 dynamic
------------------------------------------------------------------------------QOS
------------------------------------------------------------------------------Ingress qos-policy : 1
Egress qos-policy : 1
Shared Q plcy
: n/a
Multipoint shared : Disabled
I. Sched Pol
: (Not Specified)
E. Sched Pol
: (Not Specified)
I. Policer Ctl Pol : (Not Specified)
E. Policer Ctl Pol : (Not Specified)
-------------------------------------------------------------------------------
416
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
Sap Statistics
------------------------------------------------------------------------------Last Cleared Time
: N/A
Packets
Forwarding Engine Stats
Dropped
: 2
Off. HiPrio
: 0
Off. LowPrio
: 17
Off. Uncolor
: 0
Octets
172
0
1978
0
Queueing Stats(Ingress QoS Policy 1)
Dro. HiPrio
: 0
Dro. LowPrio
: 0
For. InProf
: 0
For. OutProf
: 17
0
0
0
1978
Queueing Stats(Egress QoS Policy 1)
Dro. InProf
: 0
0
Dro. OutProf
: 0
0
For. InProf
: 0
0
For. OutProf
: 15
1790
------------------------------------------------------------------------------Sap per Queue stats
------------------------------------------------------------------------------Packets
Octets
Ingress Queue 1 (Unicast) (Priority)
Off. HiPrio
: 0
Off. LoPrio
: 17
Dro. HiPrio
: 0
Dro. LoPrio
: 0
For. InProf
: 0
For. OutProf
: 17
0
1978
0
0
0
1978
Egress Queue 1
For. InProf
For. OutProf
Dro. InProf
Dro. OutProf
0
1790
0
0
:
:
:
:
0
15
0
0
------------------------------------------------------------------------------Service Endpoints
------------------------------------------------------------------------------No Endpoints found.
===============================================================================
VPLS Sites
===============================================================================
Site
Site-Id
Dest
Mesh-SDP Admin
Oper Fwdr
------------------------------------------------------------------------------No Matching Entries
===============================================================================
===============================================================================
show service id x all
------------------------------------------------------------------------------SAP 1/1/4:500
------------------------------------------------------------------------------Service Id
: 500
Issue: 01
3HE 11970 AAAA TQZZA 01
417
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
SAP
:
Description
:
Admin State
:
Flags
:
Multi Svc Site
:
Last Status Change :
Last Mgmt Change
:
Sub Type
:
Dot1Q Ethertype
:
Split Horizon Group:
1/1/4:500
(Not Specified)
Up
PortOperDown
None
09/19/2013 11:43:04
09/19/2013 11:43:05
regular
0x8100
(Not Specified)
Encap
: q-tag
Oper State
: Down
QinQ Ethertype
: 0x8100
Admin MTU
Ingr IP Fltr-Id
Ingr Mac Fltr-Id
Ingr IPv6 Fltr-Id
tod-suite
1518
n/a
n/a
n/a
None
Oper MTU
:
Egr IP Fltr-Id
:
Egr Mac Fltr-Id
:
Egr IPv6 Fltr-Id :
qinq-pbit-marking :
Egr Agg Rate Limit:
:
:
:
:
:
1518
n/a
n/a
n/a
both
max
Endpoint
: N/A
Q Frame-Based Acct : Disabled
Vlan-translation
: None
Acct. Pol
: None
Collect Stats
: Disabled
Monitor Oper Grp
: (none)
Application Profile: None
Transit Policy
: None
Oper Group
Host Lockout Plcy
Ignore Oper Down
Lag Link Map Prof
Cflowd
:
:
:
:
:
(none)
n/a
Disabled
(none)
Disabled
------------------------------------------------------------------------------ETH-CFM SAP specifics
------------------------------------------------------------------------------Tunnel Faults
: n/a
AIS
: Disabled
MC Prop-Hold-Timer : n/a
Squelch Levels
: 0 1 2 3 4 5 6 7
------------------------------------------------------------------------------QOS
------------------------------------------------------------------------------Ingress qos-policy : 1
Egress qos-policy : 1
.
.
.
------------------------------------------------------------------------------Service Destination Points(SDPs)
------------------------------------------------------------------------------------------------------------------------------------------------------------Sdp Id 1:2 -(1.1.1.1)
------------------------------------------------------------------------------Description
: (Not Specified)
SDP Id
: 1:2
Type
: Spoke
Spoke Descr
: (Not Specified)
Split Horiz Grp
: (Not Specified)
VC Type
: Ether
VC Tag
: n/a
Admin Path MTU
: 0
Oper Path MTU
: 0
Delivery
: GRE
418
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
Far End
Tunnel Far End
Hash Label
Oper Hash Label
:
:
:
:
1.1.1.1
n/a
Disabled
Disabled
Admin State
Acct. Pol
Ingress Label
Ingr Mac Fltr-Id
Ingr IP Fltr-Id
Ingr IPv6 Fltr-Id
Admin ControlWord
Last Status Change
Last Mgmt Change
Endpoint
PW Status Sig
Class Fwding State
Flags
:
:
:
:
:
:
:
:
:
:
:
:
:
Time to RetryReset
Mac Move
Local Pw Bits
Peer Pw Bits
Peer Fault Ip
Peer Vccv CV Bits
Peer Vccv CC Bits
:
:
:
:
:
:
:
Up
Oper State
None
Collect Stats
0
Egress Label
n/a
Egr Mac Fltr-Id
n/a
Egr IP Fltr-Id
n/a
Egr IPv6 Fltr-Id
Not Preferred
Oper ControlWord
09/11/2013 20:02:40
Signaling
09/15/2013 13:56:56
Force Vlan-Vc
N/A
Precedence
Enabled
Down
SdpOperDown
NoIngVCLabel NoEgrVCLabel
PathMTUTooSmall
never
Retries Left
Blockable
Blockable Level
None
None
None
None
None
Application Profile:
Transit Policy
:
Max Nbr of MAC Addr:
Learned MAC Addr
:
OAM MAC Addr
:
Host MAC Addr
:
SPB MAC Addr
:
None
None
No Limit
0
0
0
0
MAC Learning
:
MAC Aging
:
BPDU Translation
:
L2PT Termination
:
MAC Pinning
:
Ignore Standby Sig :
Oper Group
:
Rest Prot Src Mac :
Auto Learn Mac Prot:
Enabled
Enabled
Disabled
Disabled
Disabled
False
(none)
Disabled
Disabled
Ingress Qos Policy : (none)
Ingress FP QGrp
: (none)
Ing FP QGrp Inst
: (none)
LSP Types
Hash Lbl Sig Cap
Total MAC Addr
Static MAC Addr
DHCP MAC Addr
Intf MAC Addr
Cond MAC Addr
: n/a
: Disabled
:
:
:
:
:
:
:
:
:
:
Down
Disabled
0
n/a
n/a
n/a
False
TLDP
Disabled
4
: 3
: Tertiary
:
:
:
:
:
0
0
0
0
0
Discard Unkwn Srce: Disabled
Block On Mesh Fail: False
Monitor Oper Grp : (none)
RestProtSrcMacAct : Disable
Egress Qos Policy : (none)
Egress Port QGrp : (none)
Egr Port QGrp Inst: (none)
------------------------------------------------------------------------------ETH-CFM SDP-Bind specifics
------------------------------------------------------------------------------V-MEP Filtering
: Disabled
KeepAlive Information :
Admin State
: Disabled
Hello Time
: 10
Max Drop Count
: 3
Issue: 01
3HE 11970 AAAA TQZZA 01
Oper State
Hello Msg Len
Hold Down Time
: Disabled
: 0
: 10
419
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
Statistics
I. Fwd. Pkts.
E. Fwd. Pkts.
: 0
: 0
:
Squelch Levels
: 0 1 2 3 4 5 6 7
I. Dro. Pkts.
E. Fwd. Octets
: 0
: 0
authentication
Syntax
Context
Description
authentication
show>service>id
This command enables the context to display subscriber authentication information.
statistics
Syntax
Context
statistics [policy name] [sap sap-id]
show>service>id>authentication
Description
This command displays session authentication statistics for this service.
Parameters
name — Specifies the subscriber authentication policy statistics to display.
sap-id — Specifies the SAP ID statistics to display.
Output
The following output is an example of statistics information.
Sample Output
*A:ALA-1# show service id 11 authentication statistics
===============================================================
Authentication statistics
===============================================================
Interface / SAP
Authentication Authentication
Successful
Failed
--------------------------------------------------------------vpls-11-90.1.0.254
1582
3
--------------------------------------------------------------Number of entries: 1
===============================================================
*A:ALA-1#
all
Syntax
Context
420
all
show>service>id
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
Description
Output
VLL Services
This command displays detailed information for all aspects of the service.
The following output is an example of all service ID information, and Table 26 describes the
output fields.
Sample Output
A:SR12# show service id 10 all
========================================================================
Service Detailed Information
========================================================================
Service Id
: 10
Vpn Id
: 0
Service Type
: Apipe
VLL Type
: ATMCell
Name
: (Not Specified)
Description
: (Not Specified)
Customer Id
: 2
Last Status Change: 10/07/2010 05:03:47 Last Mgmt Change : 10/07/2010 05:03:51
Admin State
: Up
Oper State
: Down
MTU
: 1508
Signaling Override: ATMVCC
Vc Switching
: False
SAP Count
: 1
SDP Bind Count
: 1
......... (No change to SDP description)
-----------------------------------------------------------------------SAP 2/1/4:cp.10
----------------------------------------------------------------------Service Id
: 10
SAP
: 2/1/4:cp.10
Encap
: atm
Description
: (Not Specified)
Admin State
: Up
Oper State
: Up
Flags
: None
Multi Svc Site
: None
Last Status Change : 10/16/2010 06:58:41
Last Mgmt Change
: 10/16/2010 06:58:41
Sub Type
: regular
Split Horizon Group: (Not Specified)
Admin MTU
Ingr IP Fltr-Id
Ingr Mac Fltr-Id
Ingr IPv6 Fltr-Id
tod-suite
Ing Agg Rate Limit
Endpoint
:
:
:
:
:
:
:
1524
n/a
n/a
n/a
None
max
N/A
Oper MTU
:
Egr IP Fltr-Id
:
Egr Mac Fltr-Id
:
Egr IPv6 Fltr-Id :
qinq-pbit-marking :
Egr Agg Rate Limit:
1524
n/a
n/a
n/a
both
max
Acct. Pol
: None
Collect Stats
: Disabled
Oper Group
: (none)
Monitor Oper Grp
: (none)
*B:ALA-Dut-H# show service id 100 all
===============================================================================
Service Detailed Information
===============================================================================
Service Id
: 100
Vpn Id
: 100
Service Type
: Epipe
Description
: Default epipe description for service id 100
Customer Id
: 100
Issue: 01
3HE 11970 AAAA TQZZA 01
421
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
Last Status Change: 02/06/2007 10:03:11
Last Mgmt Change : 02/06/2007 09:43:27
Admin State
: Up
Oper State
: Up
MTU
: 1514
Vc Switching
: False
SAP Count
: 1
SDP Bind Count
: 4
------------------------------------------------------------------------------Service Destination Points(SDPs)
------------------------------------------------------------------------------Sdp Id 1:10100 -(10.20.1.7)
------------------------------------------------------------------------------SDP Id
: 1:10100
Type
: Spoke
VC Type
: Ether
VC Tag
: n/a
Admin Path MTU
: 1560
Oper Path MTU
: 1560
Far End
: 10.20.1.7
Delivery
: MPLS
Admin State
Acct. Pol
Ingress Label
Ing mac Fltr
Ing ip Fltr
Ing ipv6 Fltr
Admin ControlWord
Last Status Change
Last Mgmt Change
Endpoint
Flags
Peer Pw Bits
Peer Fault Ip
Peer Vccv CV Bits
Peer Vccv CC Bits
MAC Pinning
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
Up
None
130065
n/a
n/a
n/a
Not Preferred
02/06/2007 10:03:24
02/06/2007 09:43:27
y
SapOperDown
None
None
lspPing
mplsRouterAlertLabel
Disabled
Oper State
Collect Stats
Egress Label
Egr mac Fltr
Egr ip Fltr
Egr ipv6 Fltr
Oper ControlWord
Signaling
:
:
:
:
:
:
:
:
Up
Disabled
130368
n/a
n/a
n/a
False
TLDP
Precedence
: 4
KeepAlive Information :
Admin State
: Enabled
Hello Time
: 10
Max Drop Count
: 3
Oper State
Hello Msg Len
Hold Down Time
: Alive
: 0
: 10
Statistics
I. Fwd. Pkts.
E. Fwd. Pkts.
I. Dro. Pkts.
E. Fwd. Octets
: 0
: 0
:
: 0
: 0
Associated LSP LIST :
Lsp Name
: lsp1_G
Admin State
: Up
Oper State
: Up
Time Since Last Tr*: 01h40m15s
------------------------------------------------------------------------------Sdp Id 2:100 -(10.20.1.4)
------------------------------------------------------------------------------SDP Id
: 2:100
Type
: Spoke
VC Type
: Ether
VC Tag
: n/a
Admin Path MTU
: 1560
Oper Path MTU
: 1560
Far End
: 10.20.1.4
Delivery
: MPLS
Admin State
: Up
Oper State
: Up
Acct. Pol
: None
Collect Stats
: Disabled
Ingress Label
: 130671
Egress Label
: 130367
Ing mac Fltr
: n/a
Egr mac Fltr
: n/a
Ing ip Fltr
: n/a
Egr ip Fltr
: n/a
Ing ipv6 Fltr
: n/a
Egr ipv6 Fltr
: n/a
422
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
Admin ControlWord
Last Status Change
Last Mgmt Change
Endpoint
Flags
Peer Pw Bits
Peer Fault Ip
Peer Vccv CV Bits
Peer Vccv CC Bits
MAC Pinning
:
:
:
:
:
:
:
:
:
:
Not Preferred
02/06/2007 10:03:11
02/06/2007 09:43:27
y
None
pwFwdingStandby
None
lspPing
mplsRouterAlertLabel
Disabled
VLL Services
Oper ControlWord
Signaling
: False
: TLDP
Precedence
: 0
KeepAlive Information :
Admin State
: Enabled
Hello Time
: 10
Max Drop Count
: 3
Oper State
Hello Msg Len
Hold Down Time
: Alive
: 0
: 10
Statistics
I. Fwd. Pkts.
E. Fwd. Pkts.
I. Dro. Pkts.
E. Fwd. Octets
: 0
: 0
:
: 0
: 0
Associated LSP LIST :
Lsp Name
: lsp2_D
Admin State
: Up
Oper State
: Up
Time Since Last Tr*: 01h40m16s
------------------------------------------------------------------------------Sdp Id 3:100 -(10.20.1.5)
------------------------------------------------------------------------------SDP Id
: 3:100
Type
: Spoke
VC Type
: Ether
VC Tag
: n/a
Admin Path MTU
: 1560
Oper Path MTU
: 1560
Far End
: 10.20.1.5
Delivery
: MPLS
Admin State
Acct. Pol
Ingress Label
Ing mac Fltr
Ing ip Fltr
Ing ipv6 Fltr
Admin ControlWord
Last Status Change
Last Mgmt Change
Endpoint
Flags
Peer Pw Bits
Peer Fault Ip
Peer Vccv CV Bits
Peer Vccv CC Bits
MAC Pinning
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
Up
None
130971
n/a
n/a
n/a
Not Preferred
02/06/2007 10:03:17
02/06/2007 09:43:27
y
None
None
None
lspPing
mplsRouterAlertLabel
Disabled
KeepAlive Information :
Admin State
: Enabled
Hello Time
: 10
Max Drop Count
: 3
Statistics
:
I. Fwd. Pkts.
: 0
E. Fwd. Pkts.
: 0
Associated LSP LIST :
Lsp Name
: lsp3_E
Issue: 01
3HE 11970 AAAA TQZZA 01
Oper State
Collect Stats
Egress Label
Egr mac Fltr
Egr ip Fltr
Egr ipv6 Fltr
Oper ControlWord
Signaling
:
:
:
:
:
:
:
:
Up
Disabled
130368
n/a
n/a
n/a
False
TLDP
Precedence
: 4
Oper State
Hello Msg Len
Hold Down Time
: Alive
: 0
: 10
I. Dro. Pkts.
E. Fwd. Octets
: 0
: 0
423
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
Admin State
: Up
Oper State
: Up
Time Since Last Tr*: 01h40m16s
------------------------------------------------------------------------------...
===============================================================================
*B:ALA-Dut-H#
A:SR12# show service id 20 all
========================================================================
Service Detailed Information
========================================================================
Service Id
: 20
Vpn Id
: 0
Service Type
: Apipe
VLL Type
: ATMCell
Name
: (Not Specified)
Description
: (Not Specified)
Customer Id
: 2
Last Status Change: 10/07/2010 05:03:47 Last Mgmt Change : 10/07/2010 05:03:51
Admin State
: Up
Oper State
: Down
MTU
: 1508
Signaling Override: ATMVCC
Vc Switching
: False
SAP Count
: 1
SDP Bind Count
: 1
------------------------------------------------------------------------------APIPE SDU-mode specifics
------------------------------------------------------------------------------Interworking
: None
------------------------------------------------------------------------------Service Destination Points(SDPs)
------------------------------------------------------------------------------Sdp Id 3:1 -(1.1.1.1)
------------------------------------------------------------------------------Description
: Default sdp description
SDP Id
: 3:1
Type
: Spoke
VC Type
: AAL5SDU
VC Tag
: 0
Admin Path MTU
: 1600
Oper Path MTU
: 1600
Far End
: 1.1.1.1
Delivery
: GRE
Admin State
Acct. Pol
Ingress Label
Ing mac Fltr
Ing ip Fltr
Admin ControlWord
Last Status Change
Last Mgmt Change
Endpoint
Flags
Peer Pw Bits
Peer Fault Ip
Peer Vccv CV Bits
Peer Vccv CC Bits
MAC Pinning
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
Up
None
119665
n/a
n/a
Preferred
04/04/2007 20:52:24
04/04/2007 20:48:24
N/A
None
None
None
lspPing
pwe3ControlWord
Disabled
KeepAlive Information :
Admin State
: Disabled
Hello Time
: 10
Max Drop Count
: 3
Statistics
424
Oper State
Collect Stats
Egress Label
Egr mac Fltr
Egr ip Fltr
Oper ControlWord
Signaling
:
:
:
:
:
:
:
Up
Disabled
103665
n/a
n/a
True
TLDP
Precedence
: 4
Oper State
Hello Msg Len
Hold Down Time
: Disabled
: 0
: 10
:
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
I. Fwd. Pkts.
: 0
I. Dro. Pkts.
: 0
E. Fwd. Pkts.
: 0
E. Fwd. Octets
: 0
Associated LSP LIST :
SDP Delivery Mechanism is not MPLS
------------------------------------------------------------------------------Sdp Id 6:2 -(4.4.4.4)
------------------------------------------------------------------------------Description
: Default sdp description
SDP Id
: 6:2
Type
: Spoke
VC Type
: AAL5SDU
VC Tag
: 0
Admin Path MTU
: 1600
Oper Path MTU
: 1600
Far End
: 4.4.4.4
Delivery
: GRE
Admin State
Acct. Pol
Ingress Label
Ing mac Fltr
Ing ip Fltr
Admin ControlWord
Last Status Change
Last Mgmt Change
Endpoint
Flags
Peer Pw Bits
Peer Fault Ip
Peer Vccv CV Bits
Peer Vccv CC Bits
MAC Pinning
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
Up
Oper State
None
Collect Stats
103664
Egress Label
n/a
Egr mac Fltr
n/a
Egr ip Fltr
Preferred
Oper ControlWord
04/04/2007 20:53:13
Signaling
04/04/2007 20:48:24
N/A
Precedence
None
None
None
lspPing
pwe3ControlWord mplsRouterAlertLabel
Disabled
KeepAlive Information :
Admin State
: Disabled
Hello Time
: 10
Max Drop Count
: 3
Oper State
Hello Msg Len
Hold Down Time
:
:
:
:
:
:
:
Up
Disabled
119665
n/a
n/a
True
TLDP
: 4
: Disabled
: 0
: 10
Statistics
:
I. Fwd. Pkts.
: 0
I. Dro. Pkts.
: 0
E. Fwd. Pkts.
: 0
E. Fwd. Octets
: 0
Associated LSP LIST :
SDP Delivery Mechanism is not MPLS
------------------------------------------------------------------------------Number of SDPs : 2
------------------------------------------------------------------------------Service Access Points
------------------------------------------------------------------------------No Sap Associations
------------------------------------------------------------------------------Service Endpoints
------------------------------------------------------------------------------No Endpoints found.
===============================================================================
*A:ALA-DutC>config>service#
*A:ALU-76# show service id 200 all
===============================================================================
Service Detailed Information
===============================================================================
Service Id
: 200
Vpn Id
: 0
Service Type
: Cpipe
VLL Type
: CESoPSN
Customer Id
: 1
Issue: 01
3HE 11970 AAAA TQZZA 01
425
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
Last Status Change: 09/11/2008 19:05:29
Last Mgmt Change : 09/10/2008 19:51:06
Admin State
: Up
Oper State
: Up
MTU
: 1400
Vc Switching
: False
SAP Count
: 1
SDP Bind Count
: 1
------------------------------------------------------------------------------Service Destination Points(SDPs)
------------------------------------------------------------------------------Sdp Id 5:200 -(5.5.5.5)
------------------------------------------------------------------------------SDP Id
: 5:200
Type
: Spoke
VC Type
: CESoPSN
VC Tag
: 0
Admin Path MTU
: 0
Oper Path MTU
: 1568
Far End
: 5.5.5.5
Delivery
: MPLS
Admin State
: Up
Oper State
: Up
Acct. Pol
: None
Collect Stats
: Disabled
Ingress Label
: 131061
Egress Label
: 131066
Ing mac Fltr
: n/a
Egr mac Fltr
: n/a
Ing ip Fltr
: n/a
Egr ip Fltr
: n/a
Admin ControlWord : Preferred
Oper ControlWord : True
Admin BW(Kbps)
: 0
Oper BW(Kbps)
: 0
Last Status Change : 09/11/2008 19:05:29
Signaling
: TLDP
Last Mgmt Change
: 09/10/2008 19:51:06
Endpoint
: N/A
Precedence
: 4
Class Fwding State : Down
Flags
: None
Peer Pw Bits
: None
Peer Fault Ip
: None
Peer Vccv CV Bits : lspPing
Peer Vccv CC Bits : pwe3ControlWord mplsRouterAlertLabel
KeepAlive Information :
Admin State
: Disabled
Hello Time
: 10
Max Drop Count
: 3
Oper State
Hello Msg Len
Hold Down Time
: Disabled
: 0
: 10
Statistics
I. Fwd. Pkts.
I. Fwd. Octs.
E. Fwd. Pkts.
I. Dro. Pkts.
I. Dro. Octs.
E. Fwd. Octets
: 0
: 0
: 0
:
: 0
: 0
: 0
Associated LSP LIST :
Lsp Name
: to-ALU-80-1
Admin State
: Up
Oper State
: Up
Time Since Last Tr*: 03d21h52m
------------------------------------------------------------------------------Class-based forwarding :
------------------------------------------------------------------------------Class forwarding
: disabled
EnforceDSTELspFc : disabled
Default LSP
: Uknwn
Multicast LSP
: None
===============================================================================
FC Mapping Table
===============================================================================
FC Name
LSP Name
------------------------------------------------------------------------------No FC Mappings
------------------------------------------------------------------------------CPIPE Service Destination Point specifics
426
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
------------------------------------------------------------------------------Local Bit-rate
: 12
Peer Bit-rate
: 12
Local Payload Size : 192
Peer Payload Size : 192
Local Sig Pkts
: No Sig.
Peer Sig Pkts
: No Sig.
Local CAS Framing : No CAS
Peer CAS Framing : No CAS
Local RTP Header
: No
Peer RTP Header
: No
Local Differential : No
Peer Differential : No
Local Timestamp
: 0
Peer Timestamp
: 0
------------------------------------------------------------------------------Number of SDPs : 1
------------------------------------------------------------------------------Service Access Points
------------------------------------------------------------------------------SAP 1/5/1.1.1.1
------------------------------------------------------------------------------Service Id
: 200
SAP
: 1/5/1.1.1.1
Encap
: cem
Admin State
: Up
Oper State
: Up
Flags
: None
Multi Svc Site
: None
Last Status Change : 09/10/2008 19:51:27
Last Mgmt Change
: 09/10/2008 19:51:06
Sub Type
: regular
Admin MTU
Ingr IP Fltr-Id
Ingr Mac Fltr-Id
Ingr IPv6 Fltr-Id
tod-suite
Ing Agg Rate Limit
Endpoint
:
:
:
:
:
:
:
1578
n/a
n/a
n/a
None
max
N/A
Oper MTU
:
Egr IP Fltr-Id
:
Egr Mac Fltr-Id
:
Egr IPv6 Fltr-Id :
qinq-pbit-marking :
Egr Agg Rate Limit:
1578
n/a
n/a
n/a
both
max
Acct. Pol
: None
Collect Stats
: Disabled
------------------------------------------------------------------------------QOS
------------------------------------------------------------------------------Ingress qos-policy : 1
Egress qos-policy : 1
Shared Q plcy
: n/a
Multipoint shared : Disabled
------------------------------------------------------------------------------Sap Statistics
------------------------------------------------------------------------------Last Cleared Time
: N/A
Packets
Octets
Forwarding Engine Stats
Dropped
: 0
0
Off. HiPrio
: 0
0
Off. LowPrio
: 0
0
Off. Uncolor
: 0
0
Queueing Stats(Ingress QoS Policy 1)
Dro. HiPrio
: 0
0
Dro. LowPrio
: 0
0
For. InProf
: 0
0
For. OutProf
: 0
0
Queueing Stats(Egress QoS Policy 1)
Dro. InProf
: 0
0
Dro. OutProf
: 0
0
For. InProf
: 0
0
For. OutProf
: 0
0
-------------------------------------------------------------------------------
Issue: 01
3HE 11970 AAAA TQZZA 01
427
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
Sap per Queue stats
------------------------------------------------------------------------------Packets
Octets
Ingress Queue 1 (Unicast) (Priority)
Off. HiPrio
: 0
Off. LoPrio
: 0
Dro. HiPrio
: 0
Dro. LoPrio
: 0
For. InProf
: 0
For. OutProf
: 0
0
0
0
0
0
0
Ingress Queue 11 (Multipoint) (Priority)
Off. HiPrio
: 0
Off. LoPrio
: 0
Dro. HiPrio
: 0
Dro. LoPrio
: 0
For. InProf
: 0
For. OutProf
: 0
0
0
0
0
0
0
Egress Queue 1
For. InProf
: 0
0
For. OutProf
: 0
0
Dro. InProf
: 0
0
Dro. OutProf
: 0
0
------------------------------------------------------------------------------CEM SAP Configuration Information
------------------------------------------------------------------------------Endpoint Type
: NxDS0
Bit-rate
: 12
Payload Size
: 192
Jitter Buffer (ms)
: 8
Jitter Buffer (packets): 4
Playout Threshold (packets): 3
Use RTP Header
: No
Differential
: No
Timestamp Freq
: 0
CAS Framing
: No CAS
Cfg Alarm
: stray malformed pktloss overrun underrun
Alarm Status
:
------------------------------------------------------------------------------CEM SAP Statistics
------------------------------------------------------------------------------Packets
Seconds
Events
Egress Stats
Forwarded
: 0
Dropped
: 0
Missing
: 0
Reordered Forwarded
: 0
Underrun
: 0
0
Overrun
: 0
0
Misordered Dropped
: 0
Malformed Dropped
: 0
LBit Dropped
: 0
Multiple Dropped
: 0
Error
:
0
Severely Error
:
0
Unavailable
:
0
Failure Count
:
0
Jitter Buffer Depth
: 0
Ingress Stats
Forwarded
: 0
Dropped
: 0
428
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
------------------------------------------------------------------------------Service Endpoints
------------------------------------------------------------------------------No Endpoints found.
===============================================================================
*A:ALU-76#
*A:bksim180# show service id 1000 all
===============================================================================
Service Detailed Information
===============================================================================
Service Id
: 1000
Vpn Id
: 0
Service Type
: Ipipe
Customer Id
: 1
Last Status Change: 03/11/1973 10:20:24
Last Mgmt Change : 03/11/1973 10:20:23
Admin State
: Up
Oper State
: Up
MTU
: 1400
Vc Switching
: False
SAP Count
: 1
SDP Bind Count
: 1
CE Addr Discovery : enabled
------------------------------------------------------------------------------Service Destination Points(SDPs)
------------------------------------------------------------------------------Sdp Id 22:1000 -(2.2.2.2)
------------------------------------------------------------------------------SDP Id
: 22:1000
Type
: Spoke
VC Type
: Ipipe
VC Tag
: 0
Admin Path MTU
: 0
Oper Path MTU
: 1568
Far End
: 2.2.2.2
Delivery
: MPLS
Admin State
Acct. Pol
Ingress Label
Ing mac Fltr
Ing ip Fltr
Admin ControlWord
Admin BW(Kbps)
Last Status Change
Last Mgmt Change
Endpoint
Class Fwding State
Flags
Time to RetryReset
Mac Move
Peer Pw Bits
Peer Fault Ip
Peer Vccv CV Bits
Peer Vccv CC Bits
Issue: 01
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
Up
None
131070
n/a
n/a
Not Preferred
0
03/11/1973 10:20:24
03/11/1973 10:19:21
N/A
Down
None
1999616832 seconds
Ukwn
None
None
lspPing
mplsRouterAlertLabel
Oper State
Collect Stats
Egress Label
Egr mac Fltr
Egr ip Fltr
Oper ControlWord
Oper BW(Kbps)
Signaling
:
:
:
:
:
:
:
:
Up
Disabled
131062
n/a
n/a
False
0
TLDP
Precedence
: 4
Retries Left
Blockable Level
: 2984947
: Unknown
KeepAlive Information :
Admin State
: Disabled
Hello Time
: 10
Max Drop Count
: 3
Oper State
Hello Msg Len
Hold Down Time
: Disabled
: 0
: 10
Statistics
I. Fwd. Pkts.
I. Fwd. Octs.
I. Dro. Pkts.
I. Dro. Octs.
: 0
: 0
:
: 0
: 0
3HE 11970 AAAA TQZZA 01
429
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
E. Fwd. Pkts.
: 0
E. Fwd. Octets
: 0
Associated LSP LIST :
Lsp Name
: to-bksim176-1
Admin State
: Up
Oper State
: Up
Time Since Last Tr*: 00h01m28s
------------------------------------------------------------------------------Class-based forwarding :
------------------------------------------------------------------------------Class forwarding
: disabled
Default LSP
: Uknwn
Multicast LSP
: None
===============================================================================
FC Mapping Table
===============================================================================
FC Name
LSP Name
------------------------------------------------------------------------------No FC Mappings
------------------------------------------------------------------------------IPIPE Service Destination Point specifics
------------------------------------------------------------------------------Configured CE IP Addr : n/a
Peer CE IP Addr
: 1.1.1.2
------------------------------------------------------------------------------Number of SDPs : 1
------------------------------------------------------------------------------Service Access Points
------------------------------------------------------------------------------SAP 1/7/1
------------------------------------------------------------------------------Service Id
: 1000
SAP
: 1/7/1
Encap
: null
Admin State
: Up
Oper State
: Up
Flags
: None
Multi Svc Site
: None
Last Status Change : 03/11/1973 10:20:23
Last Mgmt Change
: 03/11/1973 10:19:21
Sub Type
: regular
Dot1Q Ethertype
: 0x8100
QinQ Ethertype
: 0x8100
Admin MTU
Ingr IP Fltr-Id
Ingr Mac Fltr-Id
Ingr IPv6 Fltr-Id
tod-suite
Ing Agg Rate Limit
Endpoint
:
:
:
:
:
:
:
1514
n/a
n/a
n/a
None
max
N/A
Oper MTU
:
Egr IP Fltr-Id
:
Egr Mac Fltr-Id
:
Egr IPv6 Fltr-Id :
qinq-pbit-marking :
Egr Agg Rate Limit:
1514
n/a
n/a
n/a
both
max
Q Frame-Based Acct : Disabled
\
Acct. Pol
: None
Collect Stats
: Disabled
------------------------------------------------------------------------------Ipipe SAP Info
------------------------------------------------------------------------------Configured CE IP
: n/a
Discovered CE IP : 1.1.1.1
SAP MAC Address
: 8c:c7:01:07:00:01
Mac Refresh Inter*: 14400
------------------------------------------------------------------------------Ipipe SAP ARP Entry Info
-------------------------------------------------------------------------------
430
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
1.1.1.1
8c:c7:01:07:00:03 dynamic
04h00m00s
------------------------------------------------------------------------------QOS
------------------------------------------------------------------------------Ingress qos-policy : 1
Egress qos-policy : 1
Shared Q plcy
: n/a
Multipoint shared : Disabled
------------------------------------------------------------------------------Sap Statistics
------------------------------------------------------------------------------Last Cleared Time
: N/A
Packets
Octets
Forwarding Engine Stats
Dropped
: 0
0
Off. HiPrio
: 0
0
Off. LowPrio
: 0
0
Off. Uncolor
: 0
0
Queueing Stats(Ingress QoS Policy 1)
Dro. HiPrio
: 0
Dro. LowPrio
: 0
For. InProf
: 0
For. OutProf
: 0
0
0
0
0
Queueing Stats(Egress QoS Policy 1)
Dro. InProf
: 0
0
Dro. OutProf
: 0
0
For. InProf
: 0
0
For. OutProf
: 0
0
------------------------------------------------------------------------------Sap per Queue stats
------------------------------------------------------------------------------Packets
Octets
Ingress Queue 1 (Unicast) (Priority)
Off. HiPrio
: 0
Off. LoPrio
: 0
Dro. HiPrio
: 0
Dro. LoPrio
: 0
For. InProf
: 0
For. OutProf
: 0
0
0
0
0
0
0
Ingress Queue 11 (Multipoint) (Priority)
Off. HiPrio
: 0
Off. LoPrio
: 0
Dro. HiPrio
: 0
Dro. LoPrio
: 0
For. InProf
: 0
For. OutProf
: 0
0
0
0
0
0
0
Egress Queue 1
For. InProf
: 0
0
For. OutProf
: 0
0
Dro. InProf
: 0
0
Dro. OutProf
: 0
0
------------------------------------------------------------------------------Service Endpoints
------------------------------------------------------------------------------No Endpoints found.
===============================================================================
Issue: 01
3HE 11970 AAAA TQZZA 01
431
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
*A:bksim180#
*A:ces-A# show service id 1 all
===============================================================================
Service Detailed Information
===============================================================================
Service Id
: 1
Vpn Id
: 0
Service Type
: Cpipe
VLL Type
: SAToPT1
Description
: (Not Specified)
Customer Id
: 1
Last Status Change: 07/06/2010 19:21:14
Last Mgmt Change : 07/06/2010 19:21:14
Admin State
: Up
Oper State
: Up
MTU
: 1514
Vc Switching
: False
SAP Count
: 1
SDP Bind Count
: 1
------------------------------------------------------------------------------Service Destination Points(SDPs)
------------------------------------------------------------------------------------------------------------------------------------------------------------Sdp Id 12:1 -(2.2.2.2)
------------------------------------------------------------------------------Description
: (Not Specified)
SDP Id
: 12:1
Type
: Spoke
VC Type
: SAToPT1
VC Tag
: 0
Admin Path MTU
: 0
Oper Path MTU
: 9190
Far End
: 2.2.2.2
Delivery
: MPLS
Admin State
Acct. Pol
Ingress Label
Admin ControlWord
Admin BW(Kbps)
Last Status Change
Last Mgmt Change
Endpoint
Flags
Peer Pw Bits
Peer Fault Ip
Peer Vccv CV Bits
Peer Vccv CC Bits
:
:
:
:
:
:
:
:
:
:
:
:
:
Up
Oper State
None
Collect Stats
131064
Egress Label
Preferred
Oper ControlWord
0
Oper BW(Kbps)
07/06/2010 19:21:14
Signaling
07/06/2010 19:21:14
N/A
Precedence
None
None
None
lspPing
pwe3ControlWord mplsRouterAlertLabel
:
:
:
:
:
:
Up
Disabled
131064
True
0
TLDP
: 4
KeepAlive Information :
Admin State
: Enabled
Hello Time
: 10
Max Drop Count
: 3
Oper State
Hello Msg Len
Hold Down Time
: Alive
: 0
: 10
Statistics
I. Fwd. Pkts.
E. Fwd. Pkts.
I. Fwd. Octs.
E. Fwd. Octets
: 31430316
: 31431426
Oper State
: Up
:
: 141578
: 141583
Associated LSP LIST :
Lsp Name
: to_b_1_2
Admin State
: Up
Time Since Last Tr*: 04h08m22s
*A:Dut-B# show service id 1 all
===============================================================================
432
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
Service Detailed Information
===============================================================================
Service Id
: 1
Vpn Id
: 0
Service Type
: Epipe
Name
: (Not Specified)
Description
: (Not Specified)
Customer Id
: 1
Creation Origin
: manual
Last Status Change: 01/28/2015 22:05:35
Last Mgmt Change : 01/28/2015 22:05:22
Test Service
: No
Admin State
: Up
Oper State
: Up
MTU
: 1514
Vc Switching
: False
SAP Count
: 1
SDP Bind Count
: 1
Per Svc Hashing
: Disabled
Force QTag Fwd
: Disabled
------------------------------------------------------------------------------BGP Information
------------------------------------------------------------------------------------------------------------------------------------------------------------ETH-CFM service specifics
------------------------------------------------------------------------------Tunnel Faults
: ignore
------------------------------------------------------------------------------Service Destination Points(SDPs)
------------------------------------------------------------------------------------------------------------------------------------------------------------Sdp Id 230:1 -(10.20.1.3)
------------------------------------------------------------------------------Description
: (Not Specified)
SDP Id
: 230:1
Type
: Spoke
Spoke Descr
: (Not Specified)
VC Type
: Ether
VC Tag
: n/a
Admin Path MTU
: 0
Oper Path MTU
: 1582
Delivery
: MPLS
Far End
: 10.20.1.3
Tunnel Far End
: n/a
LSP Types
: SR-ISIS
Hash Label
: Disabled
Hash Lbl Sig Cap : Disabled
Oper Hash Label
: Disabled
Admin State
Acct. Pol
Ingress Label
Ingr Mac Fltr-Id
Ingr IP Fltr-Id
Ingr IPv6 Fltr-Id
Admin ControlWord
Admin BW(Kbps)
BFD Template
BFD-Enabled
Last Status Change
Last Mgmt Change
Endpoint
PW Status Sig
Force Vlan-Vc
Issue: 01
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
Up
None
262135
n/a
n/a
n/a
Not Preferred
0
None
no
01/28/2015 22:05:35
01/28/2015 22:05:22
N/A
Enabled
Disabled
3HE 11970 AAAA TQZZA 01
Oper State
Collect Stats
Egress Label
Egr Mac Fltr-Id
Egr IP Fltr-Id
Egr IPv6 Fltr-Id
Oper ControlWord
Oper BW(Kbps)
:
:
:
:
:
:
:
:
Up
Disabled
262135
n/a
n/a
n/a
False
0
BFD-Encap
Signaling
: ipv4
: TLDP
Precedence
: 4
Force Qinq-Vc
: Disabled
433
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
Class Fwding State
Flags
Local Pw Bits
Peer Pw Bits
Peer Fault Ip
Peer Vccv CV Bits
Peer Vccv CC Bits
:
:
:
:
:
:
:
Application Profile:
Transit Policy
:
Standby Sig Slave :
Block On Peer Fault:
Use SDP B-MAC
:
Down
None
None
None
None
lspPing bfdFaultDet
mplsRouterAlertLabel
None
None
False
False
False
Ingress Qos Policy : (none)
Ingress FP QGrp
: (none)
Ing FP QGrp Inst
: (none)
Egress Qos Policy : (none)
Egress Port QGrp : (none)
Egr Port QGrp Inst: (none)
KeepAlive Information :
Admin State
: Disabled
Hello Time
: 10
Max Drop Count
: 3
Oper State
Hello Msg Len
Hold Down Time
: Disabled
: 0
: 10
Statistics
I. Fwd. Pkts.
I. Fwd. Octs.
E. Fwd. Pkts.
I. Dro. Pkts.
I. Dro. Octs.
E. Fwd. Octets
: 0
: 0
: 0
:
: 0
: 0
: 0
------------------------------------------------------------------------------Control Channel Status
------------------------------------------------------------------------------PW Status
: disabled
Refresh Timer
: <none>
Peer Status Expire : false
Request Timer
: <none>
Acknowledgement
: false
------------------------------------------------------------------------------ETH-CFM SDP-Bind specifics
------------------------------------------------------------------------------Squelch Levels
: None
------------------------------------------------------------------------------RSVP/Static LSPs
------------------------------------------------------------------------------Associated LSP List :
No LSPs Associated
------------------------------------------------------------------------------Class-based forwarding :
------------------------------------------------------------------------------Class forwarding
: Disabled
EnforceDSTELspFc : Disabled
Default LSP
: Uknwn
Multicast LSP
: None
===============================================================================
FC Mapping Table
===============================================================================
FC Name
LSP Name
------------------------------------------------------------------------------No FC Mappings
434
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
------------------------------------------------------------------------------Number of SDPs : 1
------------------------------------------------------------------------------------------------------------------------------------------------------------Service Access Points
------------------------------------------------------------------------------------------------------------------------------------------------------------SAP 1/1/8:1.1
------------------------------------------------------------------------------Service Id
: 1
SAP
: 1/1/8:1.1
Encap
: qinq
QinQ Dot1p
: Default
Description
: (Not Specified)
Admin State
: Up
Oper State
: Up
Flags
: None
Multi Svc Site
: None
Last Status Change : 01/28/2015 22:05:22
Last Mgmt Change
: 01/28/2015 22:05:22
Sub Type
: regular
Dot1Q Ethertype
: 0x8100
QinQ Ethertype
: 0x8100
Split Horizon Group: (Not Specified)
Admin MTU
Ingr IP Fltr-Id
Ingr Mac Fltr-Id
Ingr IPv6 Fltr-Id
tod-suite
:
:
:
:
:
1522
n/a
n/a
n/a
None
Oper MTU
:
Egr IP Fltr-Id
:
Egr Mac Fltr-Id
:
Egr IPv6 Fltr-Id :
qinq-pbit-marking :
Egr Agg Rate Limit:
1522
n/a
n/a
n/a
both
max
Endpoint
: N/A
Q Frame-Based Acct : Disabled
Vlan-translation
: None
Limit Unused BW
: Disabled
Acct. Pol
Collect Stats
: Disabled
Monitor Oper Grp
: (none)
: None
Application Profile: None
Transit Policy
: None
Oper Group
Host Lockout Plcy
Ignore Oper Down
Lag Link Map Prof
Cflowd
:
:
:
:
:
(none)
n/a
Disabled
(none)
Disabled
------------------------------------------------------------------------------ETH-CFM SAP specifics
------------------------------------------------------------------------------Tunnel Faults
: accept
AIS
: Disabled
MC Prop-Hold-Timer : n/a
Squelch Levels
: None
------------------------------------------------------------------------------QOS
------------------------------------------------------------------------------Ingress qos-policy : 2
Egress qos-policy : 2
Ingress FP QGrp
: (none)
Egress Port QGrp : (none)
Ing FP QGrp Inst
: (none)
Egr Port QGrp Inst: (none)
Shared Q plcy
: n/a
Multipoint shared : Disabled
Issue: 01
3HE 11970 AAAA TQZZA 01
435
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
I. Sched Pol
: (Not Specified)
E. Sched Pol
: (Not Specified)
I. Policer Ctl Pol : (Not Specified)
E. Policer Ctl Pol : (Not Specified)
------------------------------------------------------------------------------Sap Statistics
------------------------------------------------------------------------------Last Cleared Time
: N/A
CPM Ingress
Packets
: 0
Octets
0
Forwarding Engine Stats
Dropped
: 0
Received Valid
: 0
Off. HiPrio
: 0
Off. LowPrio
: 0
Off. Uncolor
: 0
Off. Managed
: 0
0
0
0
0
0
0
Queueing Stats(Ingress QoS Policy 2)
Dro. HiPrio
: 0
Dro. LowPrio
: 0
For. InProf
: 0
For. OutProf
: 0
0
0
0
0
Queueing Stats(Egress QoS Policy 2)
Dro. InProf
: 0
0
Dro. OutProf
: 0
0
For. InProf
: 0
0
For. OutProf
: 0
0
------------------------------------------------------------------------------Sap per Queue stats
------------------------------------------------------------------------------Packets
Octets
Ingress Queue 1 (Unicast) (Priority)
Off. HiPrio
: 0
Off. LowPrio
: 0
Dro. HiPrio
: 0
Dro. LowPrio
: 0
For. InProf
: 0
For. OutProf
: 0
0
0
0
0
0
0
Egress Queue 1
For. InProf
For. OutProf
Dro. InProf
Dro. OutProf
0
0
0
0
:
:
:
:
0
0
0
0
------------------------------------------------------------------------------Service Endpoints
------------------------------------------------------------------------------No Endpoints found.
------------------------------------------------------------------------------==========================================================================
VLL Sites
==========================================================================
436
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
Site
Site-Id
Dest
Admin
Oper Fwdr
-------------------------------------------------------------------------No Matching Entries
==========================================================================
===============================================================================
*A:Dut-B#
*A:Dut-B>config>service>sdp# show service id 1 all
===============================================================================
Service Detailed Information
===============================================================================
Service Id
: 1
Vpn Id
: 0
Service Type
: Epipe
Name
: (Not Specified)
Description
: (Not Specified)
Customer Id
: 1
Creation Origin
: manual
Last Status Change: 05/27/2015 03:08:37
Last Mgmt Change : 05/27/2015 02:56:37
Test Service
: No
Admin State
: Up
Oper State
: Up
MTU
: 1514
Vc Switching
: False
SAP Count
: 1
SDP Bind Count
: 1
Per Svc Hashing
: Disabled
Force QTag Fwd
: Disabled
------------------------------------------------------------------------------BGP Information
------------------------------------------------------------------------------------------------------------------------------------------------------------ETH-CFM service specifics
------------------------------------------------------------------------------Tunnel Faults
: ignore
------------------------------------------------------------------------------Service Destination Points(SDPs)
------------------------------------------------------------------------------------------------------------------------------------------------------------Sdp Id 230:1 -(10.20.1.3)
------------------------------------------------------------------------------Description
: (Not Specified)
SDP Id
: 230:1
Type
: Spoke
Spoke Descr
: (Not Specified)
VC Type
: Ether
VC Tag
: n/a
Admin Path MTU
: 0
Oper Path MTU
: 1582
Delivery
: MPLS
Far End
: 10.20.1.3
Tunnel Far End
: n/a
LSP Types
: SR-OSPF
Hash Label
: Disabled
Hash Lbl Sig Cap : Disabled
Oper Hash Label
: Disabled
Admin State
Acct. Pol
Ingress Label
Ingr Mac Fltr-Id
Issue: 01
:
:
:
:
Up
None
262142
n/a
3HE 11970 AAAA TQZZA 01
Oper State
Collect Stats
Egress Label
Egr Mac Fltr-Id
:
:
:
:
Up
Disabled
262141
n/a
437
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
Ingr IP Fltr-Id
Ingr IPv6 Fltr-Id
Admin ControlWord
Admin BW(Kbps)
BFD Template
BFD-Enabled
Last Status Change
Last Mgmt Change
Endpoint
PW Status Sig
Force Vlan-Vc
Class Fwding State
Flags
Local Pw Bits
Peer Pw Bits
Peer Fault Ip
Peer Vccv CV Bits
Peer Vccv CC Bits
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
Application Profile:
Transit Policy
:
Eth Seg Name
:
Standby Sig Slave :
Block On Peer Fault:
Use SDP B-MAC
:
n/a
n/a
Not Preferred
0
None
no
05/27/2015 03:08:37
05/27/2015 02:56:37
N/A
Enabled
Disabled
Down
None
None
None
None
lspPing bfdFaultDet
mplsRouterAlertLabel
Egr IP Fltr-Id
Egr IPv6 Fltr-Id
Oper ControlWord
Oper BW(Kbps)
:
:
:
:
n/a
n/a
False
0
BFD-Encap
Signaling
: ipv4
: TLDP
Precedence
: 4
Force Qinq-Vc
: Disabled
None
None
<none>
False
False
False
Ingress Qos Policy : (none)
Ingress FP QGrp
: (none)
Ing FP QGrp Inst
: (none)
Egress Qos Policy : (none)
Egress Port QGrp : (none)
Egr Port QGrp Inst: (none)
KeepAlive Information :
Admin State
: Disabled
Hello Time
: 10
Max Drop Count
: 3
Oper State
Hello Msg Len
Hold Down Time
: Disabled
: 0
: 10
Statistics
I. Fwd. Pkts.
I. Fwd. Octs.
E. Fwd. Pkts.
I. Dro. Pkts.
I. Dro. Octs.
E. Fwd. Octets
: 0
: 0
: 0
:
: 0
: 0
: 0
------------------------------------------------------------------------------Control Channel Status
------------------------------------------------------------------------------PW Status
: disabled
Refresh Timer
: <none>
Peer Status Expire : false
Request Timer
: <none>
Acknowledgement
: false
------------------------------------------------------------------------------ETH-CFM SDP-Bind specifics
------------------------------------------------------------------------------Squelch Levels
: None
------------------------------------------------------------------------------RSVP/Static LSPs
------------------------------------------------------------------------------Associated LSP List :
No LSPs Associated
438
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
------------------------------------------------------------------------------Class-based forwarding :
------------------------------------------------------------------------------Class forwarding
: Disabled
EnforceDSTELspFc : Disabled
Default LSP
: Uknwn
Multicast LSP
: None
===============================================================================
FC Mapping Table
===============================================================================
FC Name
LSP Name
------------------------------------------------------------------------------No FC Mappings
------------------------------------------------------------------------------Segment Routing
------------------------------------------------------------------------------OSPF
: enabled
LSP Id
: 524289
Oper Instance Id
: 0
------------------------------------------------------------------------------Number of SDPs : 1
------------------------------------------------------------------------------------------------------------------------------------------------------------Service Access Points
------------------------------------------------------------------------------------------------------------------------------------------------------------SAP 1/1/8:1.1
------------------------------------------------------------------------------Service Id
: 1
SAP
: 1/1/8:1.1
Encap
: qinq
QinQ Dot1p
: Default
Description
: (Not Specified)
Admin State
: Up
Oper State
: Up
Flags
: None
Multi Svc Site
: None
Last Status Change : 05/27/2015 02:56:37
Last Mgmt Change
: 05/27/2015 02:56:37
Sub Type
: regular
Dot1Q Ethertype
: 0x8100
QinQ Ethertype
: 0x8100
Split Horizon Group: (Not Specified)
Eth Seg Name
Admin MTU
Ingr IP Fltr-Id
Ingr Mac Fltr-Id
Ingr IPv6 Fltr-Id
tod-suite
:
:
:
:
:
:
<none>
1522
n/a
n/a
n/a
None
Oper MTU
:
Egr IP Fltr-Id
:
Egr Mac Fltr-Id
:
Egr IPv6 Fltr-Id :
qinq-pbit-marking :
Egr Agg Rate Limit:
1522
n/a
n/a
n/a
both
max
Endpoint
: N/A
Q Frame-Based Acct : Disabled
Vlan-translation
: None
Limit Unused BW
: Disabled
Acct. Pol
Collect Stats
: Disabled
Monitor Oper Grp
: (none)
: None
Application Profile: None
Transit Policy
: None
Oper Group
Host Lockout Plcy
Issue: 01
: (none)
: n/a
3HE 11970 AAAA TQZZA 01
439
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
Ignore Oper Down
Lag Link Map Prof
Cflowd
: Disabled
: (none)
: Disabled
------------------------------------------------------------------------------ETH-CFM SAP specifics
------------------------------------------------------------------------------Tunnel Faults
: accept
AIS
: Disabled
MC Prop-Hold-Timer : n/a
Squelch Levels
: None
------------------------------------------------------------------------------QOS
------------------------------------------------------------------------------Ingress qos-policy : 2
Egress qos-policy : 2
Ingress FP QGrp
: (none)
Egress Port QGrp : (none)
Ing FP QGrp Inst
: (none)
Egr Port QGrp Inst: (none)
Shared Q plcy
: n/a
Multipoint shared : Disabled
I. Sched Pol
: (Not Specified)
E. Sched Pol
: (Not Specified)
I. Policer Ctl Pol : (Not Specified)
E. Policer Ctl Pol : (Not Specified)
------------------------------------------------------------------------------Sap Statistics
------------------------------------------------------------------------------Last Cleared Time
: N/A
CPM Ingress
Packets
: 0
Octets
0
Forwarding Engine Stats
Dropped
: 0
Received Valid
: 0
Off. HiPrio
: 0
Off. LowPrio
: 0
Off. Uncolor
: 0
Off. Managed
: 0
0
0
0
0
0
0
Queueing Stats(Ingress QoS Policy 2)
Dro. HiPrio
: 0
Dro. LowPrio
: 0
For. InProf
: 0
For. OutProf
: 0
0
0
0
0
Queueing Stats(Egress QoS Policy 2)
Dro. InProf
: 0
0
Dro. OutProf
: 0
0
For. InProf
: 0
0
For. OutProf
: 0
0
------------------------------------------------------------------------------Sap per Queue stats
------------------------------------------------------------------------------Packets
Octets
------------------------------------------------------------------------------Sap per Policer stats
------------------------------------------------------------------------------Packets
Octets
Ingress Policer 1 (Stats mode: minimal)
440
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
Off. All
Dro. All
For. All
: 0
: 0
: 0
Egress Policer 1 (Stats mode: minimal)
Off. All
: 0
Dro. All
: 0
For. All
: 0
VLL Services
0
0
0
0
0
0
------------------------------------------------------------------------------Service Endpoints
------------------------------------------------------------------------------No Endpoints found.
------------------------------------------------------------------------------==========================================================================
VLL Sites
==========================================================================
Site
Site-Id
Dest
Admin
Oper Fwdr
-------------------------------------------------------------------------No Matching Entries
==========================================================================
===============================================================================
*A:Dut-B>config>service>sdp#
Table 26 describes the Show service ID output fields when the all option is specified.
Table 26
Issue: 01
Show Service ID Output Fields
Label
Description
Service Id
The service identifier.
VPN Id
The number which identifies the VPN.
Service Type
Specifies the type of service.
VLL Type
Specifies the VLL type.
SDP Id
The SDP identifier for the 7450 ESS or 7750 SR.
Description
Generic information about the service.
Customer Id
The customer identifier.
Last Mgmt Change
The date and time of the most recent management-initiated
change.
Endpoint
Specifies the name of the service endpoint for the 7450 ESS or
7750 SR.
3HE 11970 AAAA TQZZA 01
441
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
Table 26
Show Service ID Output Fields (Continued)
Label
Description (Continued)
Flags
Specifies the conditions that affect the operating status of this
SAP.
Display output includes: ServiceAdminDown, SapAdminDown,
InterfaceAdminDown, PortOperDown, PortMTUTooSmall,
L2OperDown, SapIngressQoSMismatch,
SapEgressQoSMismatch,RelearnLimitExceeded, RxProtSrcMac,
ParentIfAdminDown, NoSapIpipeCeIpAddr, SapParamMismatch,
CemSapNoEcidOrMacAddr, StandByForMcRing,
ServiceMTUTooSmall, SapIngressNamedPoolMismatch,
SapEgressNamedPoolMismatch, NoSapEpipeRingNode.
SAP Count
The number of SAPs specified for this service.
SDP Bind Count
The number of SDPs bound to this service for the 7450 ESS or
7750 SR.
Split Horizon Group Specifics
Split Horizon Group
Name of the split horizon group for this VPLS for the 7450 ESS or
7750 SR.
Description
Description of the split horizon group for the 7450 ESS or
7750 SR.
Last Changed
The date and time of the most recent management-initiated
change to this split horizon group for the 7450 ESS or 7750 SR.
Service Destination Points (SDPs)
442
SDP Id
The SDP identifier for the 7450 ESS or 7750 SR.
Type
Indicates whether this Service SDP binding is a spoke or a mesh
for the 7450 ESS or 7750 SR.
Admin Path MTU
The desired largest service frame size (in octets) that can be
transmitted through this SDP to the far-end router, without
requiring the packet to be fragmented for the 7450 ESS or
7750 SR.
Oper Path MTU
The actual largest service frame size (in octets) that can be
transmitted through this SDP to the far-end router, without
requiring the packet to be fragmented for the 7450 ESS or
7750 SR.
Delivery
Specifies the type of delivery used by the SDP: GRE or MPLS for
the 7450 ESS or 7750 SR.
Admin State
The administrative state of this SD for the 7450 ESS or 7750 SR.
Oper State
The operational state of this SDP for the 7450 ESS or 7750 SR.
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
Table 26
VLL Services
Show Service ID Output Fields (Continued)
Label
Description (Continued)
Jitter Buffer
(packets)
Indicates the jitter buffer length in number of packet buffers for the
7450 ESS or 7750 SR.
Playout Threshold
(packets)
Indicates the playout buffer packets threshold in number of packet
buffers for the 7450 ESS or 7750 SR.
Playout Threshold
(packets)
Indicates the current packet depth of the jitter buffer for the
7450 ESS or 7750 SR.
Peer Pw Bits
Indicates the bits set by the LDP peer when there is a fault on its
side of the pseudowire for the 7450 ESS or 7750 SR. LAC failures
occur on the SAP that has been configured on the pipe service,
PSN bits are set by SDP-binding failures on the pipe service. The
pwNotForwarding bit is set when none of the above failures apply,
such as an MTU mismatch failure. This value is only applicable if
the peer is using the pseudowire status signaling method to
indicate faults.
pwNotForwarding — Pseudowire not forwarding
lacIngressFault Local — Attachment circuit RX fault
lacEgressFault Local — Attachment circuit TX fault
psnIngressFault Local — PSN-facing PW RX fault
psnEgressFault Local — PSN-facing PW TX fault
pwFwdingStandby — Pseudowire in standby mode
Signaling Override
Indicates the overriding signaled pseudowire type, as configured
under the signaled-vc-type-override option for Apipes. This field
is only displayed if signaled-vc-type-override is configured for
the 7750 SR.
base
Syntax
Context
base [msap]
show>service>id
Description
Displays basic information about the service ID including service type, description, SAPs and
SDPs.
Parameters
msap — Displays MSAPs.
Output
The following output is an example of base service ID information, and Table 27 describes
the output fields.
Sample Output
Issue: 01
3HE 11970 AAAA TQZZA 01
443
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
*A:ALA-48>config>service>epipe>sap# show service id 6 base
===============================================================================
Service Basic Information
===============================================================================
Service Id
: 6
Vpn Id
: 6
Service Type
: Epipe
Description
: Distributed Epipe service to east coast
Customer Id
: 6
Last Status Change: 02/02/2009 09:27:55
Last Mgmt Change : 02/02/2009 09:27:57
Admin State
: Up
Oper State
: Down
MTU
: 1514
Vc Switching
: False
SAP Count
: 1
SDP Bind Count
: 1
------------------------------------------------------------------------------Service Access & Destination Points
------------------------------------------------------------------------------Identifier
Type
AdmMTU OprMTU Adm Opr
------------------------------------------------------------------------------sap:1/2/9:0
q-tag
1518
1518
Up
Down
sdp:2:6 S(10.10.10.104)
n/a
0
0
Up
Down
===============================================================================
*A:ALA-48>config>service>epipe>sap#
Table 27
444
Show Service-ID Base Output Fields
Label
Description
Service Id
The service identifier.
Vpn Id
Specifies the VPN ID assigned to the service.
Service Type
The type of service: Epipe, Apipe, Fpipe, Ipipe, VPLS, IES,
VPRN.
Description
Generic information about the service.
Customer Id
The customer identifier.
Last Mgmt Change
The date and time of the most recent management-initiated
change to this customer.
Adm
The desired state of the service.
Oper
The operating state of the service.
Mtu
The largest frame size (in octets) that the service can handle.
Def. Mesh VC Id
This object is only valid in services that accept mesh SDP
bindings. It is used to validate the VC ID portion of each mesh
SDP binding defined in the service.
SAP Count
The number of SAPs defined on the service.
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
Table 27
VLL Services
Show Service-ID Base Output Fields (Continued)
Label
Description (Continued)
SDP Bind Count
The number of SDPs bound to the service.
Identifier
Specifies the service access (SAP) and destination (SDP) points.
Type
Specifies the signaling protocol used to obtain the ingress and
egress labels used in frames transmitted and received on the
SDP.
AdmMTU
Specifies the desired largest service frame size (in octets) that
can be transmitted through this SDP to the far-end ESR, without
requiring the packet to be fragmented.
PBB Tunnel Point
Specifies the endpoint in the B-VPLS environment where the
Epipe terminates.
Admin MTU
Specifies the B-VPLS admin MTU.
Backbone-Flooding
Specifies whether or not the traffic is flooded in the B-VPLS for
the destination instead of unicast. If the backbone destination
MAC is in the B-VPLS FDB, then it will be unicast.
ISID
The 24 bit field carrying the service instance identifier associated
with the frame. It is used at the destination PE as a demultiplexor
field.
bgp-vpws
Syntax
Context
Description
Output
bgp-vpws
show>service>id
This command displays BGP VPWS related information for the service.
The following output is an example of BGP VPWS information.
Sample Output
*A:cses-E11>config>service>epipe>bgp-vpws# show service id 2 bgp-vpws
===============================================================================
BGP VPWS Information
===============================================================================
Admin State
: Enabled
VE Name
: PE1
VE Id
: 1
PW Template
: 2
Route Dist
: 65536:3
Rte-Target Import
: 65536:2
Rte-Target Export: 65536:2
PW-Template Id
Import Rte-Tgt
Issue: 01
: 2
: None
3HE 11970 AAAA TQZZA 01
445
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
------------------------------------------------------------------------------Remote-Ve Information
------------------------------------------------------------------------------Remote VE Name
: PE2
Remote VE Id
: 2
===============================================================================
*A:cses-E11>config>service>epipe>bgp-vpws#
endpoint
Syntax
Context
endpoint [endpoint-name]
show>service>id
Description
This command displays service endpoint information.
Parameters
endpoint-name — Specifies the name of an existing endpoint for the service.
Output
The following output is an example of service endpoint information.
Sample Output
*A:ALA-48>config>service>epipe# show service id 6 endpoint
===============================================================================
Service 6 endpoints
===============================================================================
Endpoint name
: x
Revert time
: 0
Act Hold Delay
: 0
Tx Active
: none
------------------------------------------------------------------------------Members
------------------------------------------------------------------------------No members found.
===============================================================================
Endpoint name
: y
Revert time
: 0
Act Hold Delay
: 0
Tx Active
: none
------------------------------------------------------------------------------Members
------------------------------------------------------------------------------No members found.
===============================================================================
*A:ALA-48>config>service>epipe#
labels
Syntax
Context
Description
446
labels
show>service>id
Displays the labels being used by the service.
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
Output
VLL Services
The following output is an example of service label information, and Table 28 describes the
output fields.
Sample Output
*A:ALA-12# show service id 1 labels
==============================================================================
Martini Service Labels
==============================================================================
Svc Id
Sdp Id
Type I.Lbl
E.Lbl
-----------------------------------------------------------------------------1
10:1
Mesh 0
0
1
20:1
Mesh 0
0
1
30:1
Mesh 0
0
1
40:1
Mesh 130081
131061
1
60:1
Mesh 131019
131016
1
100:1
Mesh 0
0
-----------------------------------------------------------------------------Number of Bound SDPs : 6
-----------------------------------------------------------------------------*A:ALA-12#
Table 28
Show Service-ID Labels Output Fields
Label
Description
Svc Id
The service identifier.
Sdp Id
The SDP identifier.
Type
Indicates whether the SDP is a spoke or a mesh.
I. Lbl
The VC label used by the far-end device to send packets to this
device in this service by the SDP.
E. Lbl
The VC label used by this device to send packets to the far-end
device in this service by the SDP.
retailers
Syntax
Context
Description
retailers
show>service>id
This command displays the service ID of the retailer subscriber service to which this DHCP
lease belongs.
wholesalers
Syntax
Issue: 01
wholesalers
3HE 11970 AAAA TQZZA 01
447
VLL Services
Context
Description
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
show>service>id
This command displays service wholesaler information.
connection-profile
Syntax
Context
connection-profile [1 to 8000]
show
Description
This command displays connection profile information.
Parameters
conn-prof-id — Specifies the connection profile ID.
Values
Output
1 to 8000
The following output is an example of connection profile information.
Sample Output
*A:Dut-A# show connection-profile
========================================================================
Connection Profile Summary Information
========================================================================
CP Index Number of
Members
-----------------------------------------------------------------------10
2
20
2
========================================================================
*A:Dut-A#
*A:Dut-A# show connection-profile 10
========================================================================
Connection Profile 10 Information
========================================================================
Description : (Not Specified)
Last Change : 10/16/2010 06:53:30
-----------------------------------------------------------------------VPI/VCI
-----------------------------------------------------------------------10/11
10/12
========================================================================
*A:Dut-A#
*A:Dut-A#
*A:bksim2801# show connection-profile
========================================================================
Connection Profile Summary Information
========================================================================
CP Index Number of
Members
448
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
------------------------------------------------------------------------------5000
0
========================================================================
*A:bksim2801#
*A:bksim2801# show connection-profile 2
========================================================================
Connection Profile 2 Information
========================================================================
Description : (Not Specified)
Last Change : 09/09/2010 07:55:28
-----------------------------------------------------------------------VPI/VCI
-----------------------------------------------------------------------2/102
10/100
========================================================================
*A:bksim2801#
sap
Syntax
Context
sap sap-id [detail]
show>service>id
Description
This command displays information for the SAPs associated with the service. If no optional
parameters are specified, a summary of all associated SAPs is displayed.
Parameters
sap-id — The ID that displays SAPs for the service in the form slot/mda/port[.channel].
detail — Displays detailed information for the SAP.
Output
The following output is an example of SAP information, and Table 29 describes the output
fields.
Sample Output
*B:Dut-A# show service id 10 sap 2/1/4:cp.10
========================================================================
Service Access Points(SAP)
========================================================================
Service Id
: 10
SAP
: 2/1/4:cp.10
Encap
: atm
Description
: Default sap description for service id 10
Admin State
: Up
Oper State
: Up
Flags
: None
Multi Svc Site
: None
Last Status Change : 11/01/2010 11:33:16
Last Mgmt Change
: 11/01/2010 13:46:15
========================================================================
A:SR12# configure service apipe 1 sap
- no sap <sap-id>
Issue: 01
3HE 11970 AAAA TQZZA 01
449
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
- sap <sap-id> [create] [no-endpoint]
- sap <sap-id> [create] endpoint <endpoint-name>
<sap-id>
: null
- <port-id|bundle-id|bpgrp-id|lag-id|
aps-id>
...
atm
- <port-id|aps-id>[:vpi/vci|vpi|
vpi1.vpi2|
ima-grp
- <bundle-id>[:vpi/vci|vpi|vpi1.vpi2]
...
A:ALA-48>config>service>epipe# show service id 8 sap 881/1/2:4094
===============================================================================
Service Access Points(SAP)
===============================================================================
Service Id
: 8
SAP
: 8/1/2:4094
Encap
: bcpDot1q
Admin State
: Up
Oper State
: Down
Flags
: ServiceAdminDown
PortOperDown
Last Status Change : 02/06/2007 12:01:14
Last Mgmt Change
: 02/06/2007 12:01:17
Admin MTU
: 1522
Oper MTU
: 1522
Ingress qos-policy : 1
Egress qos-policy : 1
Shared Q plcy
: n/a
Multipoint shared : Disabled
Ingress Filter-Id : n/a
Egress Filter-Id : n/a
tod-suite
: None
Multi Svc Site
: None
Acct. Pol
: None
Collect Stats
: Disabled
===============================================================================
A:ALA-48>config>service>epipe#
*A:bksim2801# config>service>apipe>sap$ show service id 1 sap 1/1/1:cp.2
========================================================================
Service Access Points(SAP)
========================================================================
Service Id
: 1
SAP : 1/1/1:cp.2 Encap
: atm
Description
: (Not Specified)
Admin State
: Up
Oper State : Down
Flags
: ServiceAdminDown
PortOperDown
Multi Svc Site
: None
Last Status Change
: 09/09/2010 07:55:28
Last Mgmt Change
: 09/09/2010 08:02:44
========================================================================
*A:bksim2801#
A:ALA-48>config>service>epipe# show service id 8 sap 881/1/2:4094 detail
===============================================================================
Service Access Points(SAP)
===============================================================================
Service Id
: 8
SAP
: 8/1/2:4094
Encap
: bcpDot1q
Admin State
: Up
Oper State
: Down
Flags
: ServiceAdminDown
PortOperDown
Last Status Change : 02/06/2007 12:01:14
Last Mgmt Change
: 02/06/2007 12:01:17
450
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
Admin MTU
Ingress qos-policy
Shared Q plcy
Ingress Filter-Id
tod-suite
:
:
:
:
:
1522
1
n/a
n/a
None
VLL Services
Oper MTU
Egress qos-policy
Multipoint shared
Egress Filter-Id
:
:
:
:
1522
1
Disabled
n/a
Multi Svc Site
: None
Acct. Pol
: None
Collect Stats
: Disabled
------------------------------------------------------------------------------Sap Statistics
------------------------------------------------------------------------------Packets
Octets
Forwarding Engine Stats
Dropped
: 0
0
Off. HiPrio
: 0
0
Off. LowPrio
: 0
0
Off. Uncolor
: 0
0
Queueing Stats(Ingress QoS Policy 1)
Dro. HiPrio
: 0
0
Dro. LowPrio
: 0
0
For. InProf
: 0
0
For. OutProf
: 0
0
Queueing Stats(Egress QoS Policy 1)
Dro. InProf
: 0
0
Dro. OutProf
: 0
0
For. InProf
: 0
0
For. OutProf
: 0
0
------------------------------------------------------------------------------Sap per Queue stats
------------------------------------------------------------------------------Packets
Octets
Ingress Queue 1 (Unicast) (Priority)
Off. HiPrio
: 0
0
Off. LoPrio
: 0
0
Dro. HiPrio
: 0
0
Dro. LoPrio
: 0
0
For. InProf
: 0
0
For. OutProf
: 0
0
Egress Queue 1
For. InProf
: 0
0
For. OutProf
: 0
0
Dro. InProf
: 0
0
Dro. OutProf
: 0
0
===============================================================================
A:ALA-48>config>service>epipe#
Table 29
Issue: 01
Show Service-ID SAP Output Fields
Label
Description
Service Id
The service identifier.
SAP
The SAP and qtag.
Encap
The encapsulation type of the SAP.
Ethertype
Specifies an Ethernet type II Ethertype value.
3HE 11970 AAAA TQZZA 01
451
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
Table 29
Show Service-ID SAP Output Fields (Continued)
Label
Description (Continued)
Admin State
The administrative state of the SAP.
Oper State
The operating state of the SAP.
Flags
Specifies the conditions that affect the operating status of this
SAP.
Display output includes: ServiceAdminDown, SapAdminDown,
InterfaceAdminDown, PortOperDown, PortMTUTooSmall,
L2OperDown, SapIngressQoSMismatch,
SapEgressQoSMismatch,RelearnLimitExceeded,
RxProtSrcMac, ParentIfAdminDown, NoSapIpipeCeIpAddr,
TodResourceUnavail, TodMssResourceUnavail,
SapParamMismatch, CemSapNoEcidOrMacAddr,
StandByForMcRing, ServiceMTUTooSmall,
SapIngressNamedPoolMismatch,
SapEgressNamedPoolMismatch, NoSapEpipeRingNode.
Last Status Change
The time of the most recent operating status change to this SAP.
Last Mgmt Change
The time of the most recent management-initiated change to this
SAP.
Admin MTU
The desired largest service frame size (in octets) that can be
transmitted through the SAP to the far-end router, without
requiring the packet to be fragmented.
Oper MTU
The actual largest service frame size (in octets) that can be
transmitted through the SAP to the far-end router, without
requiring the packet to be fragmented.
Ingress qos-policy
The ingress QoS policy ID assigned to the SAP.
Egress qos-policy
The egress QoS policy ID assigned to the SAP.
Ingress Filter-Id
The ingress filter policy ID assigned to the SAP.
Egress Filter-Id
The egress filter policy ID assigned to the SAP.
Acct. Pol
The accounting policy ID assigned to the SAP.
Collect Stats
Specifies whether collect stats is enabled.
LLF Admin State
Displays the Link Loss Forwarding administrative state.
LLF Oper State
Displays the Link Loss Forwarding operational state.
pw-port
pw-id[:qtag1[.qtag2]] pw-id[:qtag1[.qtag2]] pw-2:1.1
Sample Output
452
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
A:ALA-48# show service id 1 sap 1/1/1:2
===============================================================================
Service Access Points(SAP)
===============================================================================
Service Id
: 1
SAP
: 1/1/1:5
Encap
: q-tag
Dot1Q Ethertype
: 0x8100
QinQ Ethertype
: 0x8100
Admin State
: Up
Oper State
: Up
Flags
: None
Last Status Change : 10/05/2006 17:06:03
Last Mgmt Change
: 10/05/2006 22:30:03
Max Nbr of MAC Addr: No Limit
Total MAC Addr
: 0
Learned MAC Addr
: 0
Static MAC Addr
: 0
Admin MTU
: 1518
Oper MTU
: 1518
Ingress qos-policy : 1190
Egress qos-policy : 1190
Shared Q plcy
: n/a
Multipoint shared : Disabled
Ingr IP Fltr-Id
: n/a
Egr IP Fltr-Id
: n/a
Ingr Mac Fltr-Id
: n/a
Egr Mac Fltr-Id
: n/a
Ingr IPv6 Fltr-Id : n/a
Egr IPv6 Fltr-Id : n/a
tod-suite
: suite_sixteen
qinq-pbit-marking : both
Egr Agg Rate Limit : max
ARP Reply Agent
: Unknown
Host Conn Verify : Disabled
Mac Learning
: Enabled
Discard Unkwn Srce: Disabled
Mac Aging
: Enabled
Mac Pinning
: Disabled
L2PT Termination
: Disabled
BPDU Translation : Disabled
Multi Svc Site
: None
I. Sched Pol
: SchedPolCust1_Night
E. Sched Pol
: SchedPolCust1Egress_Night
Acct. Pol
: None
Collect Stats
: Disabled
Anti Spoofing
: None
Nbr Static Hosts : 0
===============================================================================
A:ALA-48#
A:kerckhot_4# show service id 1 sap 1/1/1:6
===============================================================================
Service Access Points(SAP)
===============================================================================
Service Id
: 1
SAP
: 1/1/1:6
Encap
: q-tag
Dot1Q Ethertype
: 0x8100
QinQ Ethertype
: 0x8100
Admin State
: Up
Oper State
: Down
Flags
: TodResourceUnavail
Last Status Change : 12/01/2006 09:59:42
Last Mgmt Change
: 12/01/2006 09:59:45
...
A:kerckhot_4#
sdp
Syntax
Context
Issue: 01
sdp [[sdp-id[:vc-id]] [detail]
sdp far-end {ip-address | ipv6-address} [detail]
sdp sdp-id[:vc-id] mrp
show>service>id
3HE 11970 AAAA TQZZA 01
453
VLL Services
Description
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
This command displays information for the SDPs associated with the service.
If no optional parameters are specified, a summary of all associated SDPs is displayed.
Parameters
sdp-id — Displays only information for the specified SDP ID.
Values
1 to 17407
vc-id — Displays only information for the specified virtual circuit ID.
Values
1 to 4294967295
ip-address — Displays only SDPs matching the specified far-end IPv4 address.
ipv6-address — Displays only SDPs matching the specified far-end IPv6 address.
detail — Displays detailed SDP information.
mrp — Displays detailed MRP information.
Output
The following output is an example of SDP information, and Table 30 describes the output
fields.
Sample Output
A:Dut-A# show service id 1 sdp detail
===============================================================================
Services: Service Destination Points Details
===============================================================================
Sdp Id 1:1 -(10.20.1.2)
------------------------------------------------------------------------------Description
: Default sdp description
SDP Id
: 1:1
Type
: Spoke
VC Type
: Ether
VC Tag
: n/a
Admin Path MTU
: 0
Oper Path MTU
: 9186
Far End
: 10.20.1.2
Delivery
: MPLS
454
Admin State
:
Acct. Pol
:
Ingress Label
:
Ing mac Fltr
:
Ing ip Fltr
:
Ing ipv6 Fltr
:
Admin ControlWord :
Last Status Change :
Last Mgmt Change
:
Class Fwding State :
Flags
:
Peer Pw Bits
:
Peer Fault Ip
:
Peer Vccv CV Bits :
Peer Vccv CC Bits :
Max Nbr of MAC Addr:
Learned MAC Addr
:
Up
None
2048
n/a
n/a
n/a
Not Preferred
05/31/2007 00:45:43
05/31/2007 00:45:43
Up
None
None
None
None
None
No Limit
0
Oper State
Collect Stats
Egress Label
Egr mac Fltr
Egr ip Fltr
Egr ipv6 Fltr
Oper ControlWord
Signaling
:
:
:
:
:
:
:
:
Total MAC Addr
Static MAC Addr
: 0
: 0
MAC Learning
MAC Aging
L2PT Termination
MAC Pinning
Enabled
Enabled
Disabled
Disabled
Discard Unkwn Srce: Disabled
:
:
:
:
3HE 11970 AAAA TQZZA 01
BPDU Translation
Up
Disabled
2048
n/a
n/a
n/a
False
None
: Disabled
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
KeepAlive Information :
Admin State
: Disabled
Hello Time
: 10
Max Drop Count
: 3
Statistics
:
I. Fwd. Pkts.
: 0
I. Fwd. Octs.
: 0
E. Fwd. Pkts.
: 0
MCAC Policy Name
:
MCAC Max Unconst BW: no limit
MCAC In use Mand BW: 0
MCAC In use Opnl BW: 0
Associated LSP LIST :
Lsp Name
: A_B_1
Admin State
: Up
Time Since Last Tr*: 00h26m35s
VLL Services
Oper State
Hello Msg Len
Hold Down Time
: Disabled
: 0
: 10
I. Dro. Pkts.
I. Dro. Octs.
E. Fwd. Octets
: 0
: 0
: 0
MCAC Max Mand BW : no limit
MCAC Avail Mand BW: unlimited
MCAC Avail Opnl BW: unlimited
Oper State
: Up
Lsp Name
: A_B_2
Admin State
: Up
Time Since Last Tr*: 00h26m35s
Oper State
: Up
Lsp Name
: A_B_3
Admin State
: Up
Time Since Last Tr*: 00h26m34s
Oper State
: Up
Lsp Name
: A_B_4
Admin State
: Up
Time Since Last Tr*: 00h26m34s
Oper State
: Up
Lsp Name
: A_B_5
Admin State
: Up
Time Since Last Tr*: 00h26m34s
Oper State
: Up
Lsp Name
: A_B_6
Admin State
: Up
Time Since Last Tr*: 00h26m34s
Oper State
: Up
Lsp Name
: A_B_7
Admin State
: Up
Time Since Last Tr*: 00h26m34s
Oper State
: Up
Lsp Name
: A_B_8
Admin State
: Up
Time Since Last Tr*: 00h26m35s
Oper State
: Up
Lsp Name
: A_B_9
Admin State
: Up
Time Since Last Tr*: 00h26m34s
Oper State
: Up
Lsp Name
: A_B_10
Admin State
: Up
Oper State
: Up
Time Since Last Tr*: 00h26m34s
------------------------------------------------------------------------------Class-based forwarding :
------------------------------------------------------------------------------Class forwarding
: enabled
Default LSP
: A_B_10
Multicast LSP
: A_B_9
Issue: 01
3HE 11970 AAAA TQZZA 01
455
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
===============================================================================
FC Mapping Table
===============================================================================
FC Name
LSP Name
------------------------------------------------------------------------------af
A_B_3
be
A_B_1
ef
A_B_6
h1
A_B_7
h2
A_B_5
l1
A_B_4
l2
A_B_2
nc
A_B_8
===============================================================================
Stp Service Destination Point specifics
------------------------------------------------------------------------------Mac Move
: Blockable
Stp Admin State
: Up
Stp Oper State
: Down
Core Connectivity : Down
Port Role
: N/A
Port State
: Forwarding
Port Number
: 2049
Port Priority
: 128
Port Path Cost
: 10
Auto Edge
: Enabled
Admin Edge
: Disabled
Oper Edge
: N/A
Link Type
: Pt-pt
BPDU Encap
: Dot1d
Root Guard
: Disabled
Active Protocol
: N/A
Last BPDU from
: N/A
Designated Bridge : N/A
Designated Port Id: 0
Fwd Transitions
: 0
Bad BPDUs rcvd
: 0
Cfg BPDUs rcvd
: 0
Cfg BPDUs tx
: 0
TCN BPDUs rcvd
: 0
TCN BPDUs tx
: 0
RST BPDUs rcvd
: 0
RST BPDUs tx
: 0
------------------------------------------------------------------------------Number of SDPs : 1
------------------------------------------------------------------------------* indicates that the corresponding row element may have been truncated.
------------------------------------------------------------------------------A:Dut-A#
Table 30
456
Show Service-ID SDP Output Fields
Label
Description
Sdp Id
The SDP identifier.
Type
Indicates whether the SDP is a spoke or a mesh.
Split Horizon Group
Name of the split horizon group that the SDP belongs to.
VC Type
The VC type, ether, vlan, or vpls.
VC Tag
The explicit dot1Q value used when encapsulating to the SDP far
end.
I. Lbl
The VC label used by the far-end device to send packets to this
device in this service by the SDP.
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
Table 30
Issue: 01
VLL Services
Show Service-ID SDP Output Fields (Continued)
Label
Description (Continued)
Admin Path MTU
The operating path MTU of the SDP is equal to the admin path
MTU (when one is set) or the dynamically computed tunnel MTU,
when no admin path MTU is set (the default case).
Oper Path MTU
The actual largest service frame size (in octets) that can be
transmitted through this SDP to the far-end router, without
requiring the packet to be fragmented.
Far End
Specifies the IP address of the remote end of the GRE or MPLS
tunnel defined by this SDP.
Delivery
Specifies the type of delivery used by the SDP: GRE or MPLS.
Admin State
The administrative state of this SDP.
Oper State
The current state of this SDP.
Ingress Label
The label used by the far-end device to send packets to this
device in this service by this SDP.
Egress Label
The label used by this device to send packets to the far-end
device in this service by the SDP.
Last Changed
The date and time of the most recent change to the SDP.
Signaling
Specifies the signaling protocol used to obtain the ingress and
egress labels used in frames transmitted and received on this
SDP.
Admin State
The administrative state of the Keepalive process.
Oper State
The operational state of the Keepalive process.
Hello Time
Transmission frequency of the SDP echo request messages.
Max Drop Count
Specifies the maximum number of consecutive SDP echo
request messages that can be unacknowledged before the
keepalive protocol reports a fault.
Hello Msg Len
The length of the SDP echo request messages transmitted on
this SDP.
Hold Down Time
Specifies the amount of time to wait before the keepalive
operating status is eligible to enter the alive state.
I. Fwd. Pkts.
Specifies the number of forwarded ingress packets.
I. Dro. Pkts
Specifies the number of dropped ingress packets.
E. Fwd. Pkts.
Specifies the number of forwarded egress packets.
3HE 11970 AAAA TQZZA 01
457
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
Table 30
Show Service-ID SDP Output Fields (Continued)
Label
Description (Continued)
Associated LSP List
When the SDP type is MPLS, a list of LSPs used to reach the farend router displays. All the LSPs in the list must terminate at the
IP address specified in the Far End field.
If the SDP type is GRE, then the following message displays:
SDP delivery mechanism is not MPLS.
Ingress Cookie1
Ingress Cookie2
Specifies the ingress cookies configured for an L2TPv3 spokeSDP binding for an Epipe service. One or two L2TPv3 ingress
cookies may be configured.
Egress Cookie
Specifies the egress cookies configured for an L2TPv3 spokeSDPs for an Epipe service.
Session Mismatch
Specifies a mismatch detected between the configured (far-end
binding) cookie to what is received by the local IP address of the
L2TPv3 SDP. The flag is set when a mismatch is detected and
must be manually cleared by an operator.
The following examples show both sides (PE nodes) when control word is enabled:
*A:ALA-Dut-B>config>service>epipe# show service id 2100 sdp detail
===============================================================================
Services: Service Destination Points Details
------------------------------------------------------------------------------Sdp Id 1:2001 -(1.1.1.1)
------------------------------------------------------------------------------Description
: Default sdp description
SDP Id
: 1:2001
Type
: Spoke
VC Type
: Ether
VC Tag
: n/a
Admin Path MTU
: 1600
Oper Path MTU
: 1600
Far End
: 1.1.1.1
Delivery
: GRE
Admin State
:
Acct. Pol
:
Ingress Label
:
Ing mac Fltr
:
Ing ip Fltr
:
Ing ipv6 Fltr
:
Admin ControlWord :
Last Status Change :
Last Mgmt Change
:
Class Fwding State :
Endpoint
:
Flags
:
Peer Pw Bits
:
Peer Fault Ip
:
Peer Vccv CV Bits :
Peer Vccv CC Bits :
Max Nbr of MAC Addr:
Learned MAC Addr
:
458
Up
None
115066
n/a
n/a
n/a
Preferred
02/05/2007 16:39:22
02/05/2007 16:39:22
Up
N/A
None
None
None
None
None
No Limit
0
3HE 11970 AAAA TQZZA 01
Oper State
Collect Stats
Egress Label
Egr mac Fltr
Egr ip Fltr
Egr ipv6 Fltr
Oper ControlWord
Signaling
:
:
:
:
:
:
:
:
Up
Disabled
119068
n/a
n/a
n/a
True
TLDP
Precedence
: 4
Total MAC Addr
Static MAC Addr
: 0
: 0
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
MAC Learning
MAC Aging
L2PT Termination
MAC Pinning
:
:
:
:
Enabled
Enabled
Disabled
Disabled
VLL Services
Discard Unkwn Srce: Disabled
BPDU Translation
: Disabled
KeepAlive Information :
Admin State
: Disabled
Hello Time
: 10
Max Drop Count
: 3
Oper State
Hello Msg Len
Hold Down Time
: Disabled
: 0
: 10
Statistics
I. Fwd. Pkts.
E. Fwd. Pkts.
I. Dro. Pkts.
E. Fwd. Octets
: 0
: 0
:
: 0
: 0
Associated LSP LIST :
SDP Delivery Mechanism is not MPLS
------------------------------------------------------------------------------Number of SDPs : 1
===============================================================================
*A:ALA-Dut-B>config>service>epipe#
The following is an example when one side (PE) has the control word enabled (the pipe will
be down).
This is the side with control word disabled:
*A:ALA-Dut-B>config>service>epipe# show service id 2100 sdp detail
===============================================================================
Services: Service Destination Points Details
===============================================================================
Sdp Id 1:2001 -(1.1.1.1)
------------------------------------------------------------------------------Description
: Default sdp description
SDP Id
: 1:2001
Type
: Spoke
VC Type
: Ether
VC Tag
: n/a
Admin Path MTU
: 1600
Oper Path MTU
: 1600
Far End
: 1.1.1.1
Delivery
: GRE
Admin State
:
Acct. Pol
:
Ingress Label
:
Ing mac Fltr
:
Ing ip Fltr
:
Ing ipv6 Fltr
:
Admin ControlWord :
Last Status Change :
Last Mgmt Change
:
Flags
:
Peer Pw Bits
:
Peer Fault Ip
:
Peer Vccv CV Bits :
Peer Vccv CC Bits :
Max Nbr of MAC Addr:
Learned MAC Addr
:
MAC Learning
:
MAC Aging
:
L2PT Termination
:
Issue: 01
Up
None
115066
n/a
n/a
n/a
Not Preferred
02/05/2007 16:47:54
02/05/2007 16:47:54
None
None
None
None
None
No Limit
0
Enabled
Enabled
Disabled
3HE 11970 AAAA TQZZA 01
Oper State
Collect Stats
Egress Label
Egr mac Fltr
Egr ip Fltr
Egr ipv6 Fltr
Oper ControlWord
Signaling
:
:
:
:
:
:
:
:
Down
Disabled
119068
n/a
n/a
n/a
False
TLDP
Total MAC Addr
: 0
Static MAC Addr
: 0
Discard Unkwn Srce: Disabled
BPDU Translation
: Disabled
459
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
MAC Pinning
: Disabled
KeepAlive Information :
Admin State
: Disabled
Oper State
: Disabled
Hello Time
: 10
Hello Msg Len
: 0
Max Drop Count
: 3
Hold Down Time
: 10
Statistics
:
I. Fwd. Pkts.
: 0
I. Dro. Pkts.
: 0
E. Fwd. Pkts.
: 0
E. Fwd. Octets
: 0
Associated LSP LIST :
SDP Delivery Mechanism is not MPLS
------------------------------------------------------------------------------Number of SDPs : 1
===============================================================================
*A:ALA-Dut-B>config>service>epipe#
This is the side with control word enabled:
*A:ALA-B# show service id 2100 sdp detail
===============================================================================
Services: Service Destination Points Details
===============================================================================
Sdp Id 1:12000 -(3.3.3.3)
------------------------------------------------------------------------------Description
: Default sdp description
SDP Id
: 1:12000
Type
: Spoke
VC Type
: Ether
VC Tag
: n/a
Admin Path MTU
: 1600
Oper Path MTU
: 1600
Far End
: 3.3.3.3
Delivery
: GRE
Admin State
: Up
Oper State
: Down
Acct. Pol
: None
Collect Stats
: Disabled
Ingress Label
: 119066
Egress Label
: 0
Ing mac Fltr
: n/a
Egr mac Fltr
: n/a
Ing ip Fltr
: n/a
Egr ip Fltr
: n/a
Ing ipv6 Fltr
: n/a
Egr ipv6 Fltr
: n/a
Admin ControlWord : Preferred
Oper ControlWord : True
Last Status Change : 02/04/2007 22:52:43
Signaling
: TLDP
Last Mgmt Change
: 02/04/2007 02:06:08
Flags
: None
Peer Pw Bits
: None
Peer Fault Ip
: None
Peer Vccv CV Bits : None
Peer Vccv CC Bits : None
Max Nbr of MAC Addr: No Limit
Total MAC Addr
: 0
Learned MAC Addr
: 0
Static MAC Addr
: 0
MAC Learning
: Enabled
Discard Unkwn Srce: Disabled
MAC Aging
: Enabled
L2PT Termination
: Disabled
BPDU Translation : Disabled
MAC Pinning
: Disabled
KeepAlive Information :
Admin State
: Disabled
Oper State
: Disabled
Hello Time
: 10
Hello Msg Len
: 0
Max Drop Count
: 3
Hold Down Time
: 10
Statistics
:
I. Fwd. Pkts.
: 0
E. Fwd. Pkts.
: 0
Associated LSP LIST :
SDP Delivery Mechanism is not MPLS
460
3HE 11970 AAAA TQZZA 01
I. Dro. Pkts.
E. Fwd. Octets
: 0
: 0
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
------------------------------------------------------------------------------Number of SDPs : 1
===============================================================================
*A:ALA-B#
The following is an example when both sides have control word disabled:
*A:ALA-Dut-B>config>service>epipe# show service id 2100 sdp detail
===============================================================================
Services: Service Destination Points Details
===============================================================================
Sdp Id 1:2001 -(1.1.1.1)
------------------------------------------------------------------------------Description
: Default sdp description
SDP Id
: 1:2001
Type
: Spoke
VC Type
: Ether
VC Tag
: n/a
Admin Path MTU
: 1600
Oper Path MTU
: 1600
Far End
: 1.1.1.1
Delivery
: GRE
Admin State
: Up
Oper State
: Up
Acct. Pol
: None
Collect Stats
: Disabled
Ingress Label
: 115066
Egress Label
: 119068
Ing mac Fltr
: n/a
Egr mac Fltr
: n/a
Ing ip Fltr
: n/a
Egr ip Fltr
: n/a
Ing ipv6 Fltr
: n/a
Egr ipv6 Fltr
: n/a
Admin ControlWord : Not Preferred
Oper ControlWord : False
Last Status Change : 02/05/2007 16:49:05
Signaling
: TLDP
Last Mgmt Change
: 02/05/2007 16:47:54
Flags
: None
Peer Pw Bits
: None
Peer Fault Ip
: None
Peer Vccv CV Bits : None
Peer Vccv CC Bits : None
Max Nbr of MAC Addr: No Limit
Total MAC Addr
: 0
Learned MAC Addr
: 0
Static MAC Addr
: 0
MAC Learning
: Enabled
Discard Unkwn Srce: Disabled
MAC Aging
: Enabled
L2PT Termination
: Disabled
BPDU Translation : Disabled
MAC Pinning
: Disabled
KeepAlive Information :
Admin State
: Disabled
Oper State
: Disabled
Hello Time
: 10
Hello Msg Len
: 0
Max Drop Count
: 3
Hold Down Time
: 10
Statistics
:
I. Fwd. Pkts.
: 0
I. Dro. Pkts.
: 0
E. Fwd. Pkts.
: 0
E. Fwd. Octets
: 0
Associated LSP LIST :
SDP Delivery Mechanism is not MPLS
------------------------------------------------------------------------------Number of SDPs : 1
===============================================================================
*A:ALA-Dut-B>config>service>epipe#
*A:SetupCLI>config>service>epipe>spoke-sdp# show service id 2 sdp 2000:1 detail
========================================================================
Service Destination Point (Sdp Id : 2000:1) Details
========================================================================
-------------------------------------------------------------------------------
Issue: 01
3HE 11970 AAAA TQZZA 01
461
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
Sdp Id 2000:1 -(101.101.101.101)
-----------------------------------------------------------------------Description
: (Not Specified)
SDP Id
: 2000:1
Type
: Spoke
Spoke Descr
: (Not Specified)
VC Type
: Ether
VC Tag
: n/a
Admin Path MTU
: 1500
Oper Path MTU
: 1500
Far End
: 101.101.101.101
Delivery
: MPLS
Hash Label
: Enabled
Admin State
: Up
Oper State
: Down
Acct. Pol
: None
Collect Stats
: Disabled
Ingress Label
: 0
Egress Label
: 0
Ingr Mac Fltr-Id
: n/a
Egr Mac Fltr-Id
: n/a
Ingr IP Fltr-Id
: n/a
Egr IP Fltr-Id
: n/a
Ingr IPv6 Fltr-Id : n/a
Egr IPv6 Fltr-Id : n/a
Admin ControlWord : Not Preferred
Oper ControlWord : False
Admin BW(Kbps)
: 0
Oper BW(Kbps)
: 0
Last Status Change : 10/08/2009 06:55:54
Signaling
: TLDP
Last Mgmt Change
: 10/08/2009 07:04:27
Force Vlan-Vc
: Disabled
Endpoint
: N/A
Precedence
: 4
Class Fwding State : Down
Flags
: SvcAdminDown SdpOperDown
NoIngVCLabel NoEgrVCLabel
PathMTUTooSmall
Peer Pw Bits
: None
Peer Fault Ip
: None
Peer Vccv CV Bits : None
Peer Vccv CC Bits : None
Application Profile: None
KeepAlive Information :
Admin State
: Enabled
Hello Time
: 600
Max Drop Count
: 3
Oper State
Hello Msg Len
Hold Down Time
: No response
: 1500
: 10
Statistics
:
I. Fwd. Pkts.
: 0
I. Dro. Pkts.
: 0
E. Fwd. Pkts.
: 0
E. Fwd. Octets
: 0
-----------------------------------------------------------------------RSVP/Static LSPs
----------------------------------------------------------------------Associated LSP LIST :
No LSPs Associated
-----------------------------------------------------------------------Class-based forwarding :
------------------------------------------------------------------------------Class forwarding
: Disabled
EnforceDSTELspFc : Disabled
Default LSP
: Uknwn
Multicast LSP
: None
========================================================================
FC Mapping Table
========================================================================
FC Name
LSP Name
-----------------------------------------------------------------------No FC Mappings
-----------------------------------------------------------------------Number of SDPs : 1
-----------------------------------------------------------------------========================================================================
*A:SetupCLI>config>service>epipe>spoke-sdp#
462
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
Sample Output for L2TPv3 SDP binding
The following is sample output for L2TPv3 SDP binding, (not an MPLS or GRE SDP binding):
*A:cses-V36# show service id 999 sdp detail
===============================================================================
Services: Service Destination Points Details
===============================================================================
------------------------------------------------------------------------------Sdp Id 999:999 -(2001:db8::1)
------------------------------------------------------------------------------Description
: (Not Specified)
SDP Id
: 999:999
Type
: Spoke
Spoke Descr
: (Not Specified)
VC Type
: Ether
VC Tag
: n/a
Admin Path MTU
: 0
Oper Path MTU
: 8890
Delivery
: L2TPv3
Far End
: 2001:db8::1
Local End
: 2001:db8:aaab::36
Tunnel Far End
: n/a
LSP Types
: n/a
Hash Label
: Disabled
Hash Lbl Sig Cap : Disabled
Oper Hash Label
: Disabled
Entropy Label
: Enabled
Admin State
Acct. Pol
Ingress Label
Ingr Mac Fltr-Id
Ingr IP Fltr-Id
Ingr IPv6 Fltr-Id
Admin ControlWord
Admin BW(Kbps)
BFD Template
BFD-Enabled
Last Status Change
Last Mgmt Change
Endpoint
PW Status Sig
Force Qinq-Vc
Class Fwding State
Flags
Local Pw Bits
Peer Pw Bits
Peer Fault Ip
Peer Vccv CV Bits
Peer Vccv CC Bits
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
Application Profile:
Transit Policy
:
Standby Sig Slave :
Block On Peer Fault:
Use SDP B-MAC
:
Up
None
0
n/a
n/a
n/a
Not Preferred
0
None
no
06/19/2014 17:31:16
06/19/2014 17:23:47
N/A
Disabled
Disabled
Down
None
None
None
None
None
None
Oper State
Collect Stats
Egress Label
Egr Mac Fltr-Id
Egr IP Fltr-Id
Egr IPv6 Fltr-Id
Oper ControlWord
Oper BW(Kbps)
:
:
:
:
:
:
:
:
Up
Disabled
0
n/a
n/a
n/a
False
0
BFD-Encap
Signaling
Force Vlan-Vc
Precedence
:
:
:
:
ipv4
None
Disabled
4
None
None
False
False
False
Ingress Qos Policy : (none)
Ingress FP QGrp
: (none)
Ing FP QGrp Inst
: (none)
Egress Qos Policy : (none)
Egress Port QGrp : (none)
Egr Port QGrp Inst: (none)
KeepAlive Information :
Issue: 01
3HE 11970 AAAA TQZZA 01
463
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
Admin State
Hello Time
Max Drop Count
: Disabled
: 10
: 3
Statistics
I. Fwd. Pkts.
I. Fwd. Octs.
E. Fwd. Pkts.
: 0
: 0
: 0
Oper State
Hello Msg Len
Hold Down Time
: Disabled
: 0
: 10
I. Dro. Pkts.
I. Dro. Octs.
E. Fwd. Octets
: 0
: 0
: 0
:
------------------------------------------------------------------------------L2TPv3 Information
------------------------------------------------------------------------------Ingress Cookie
: AB:BA:BA:BB:A0:00:00:00
Ingress Cookie2
: BA:BA:BA:BA:BA:BA:BA:BA
Egress Cookie
: AB:BA:BA:BB:A0:00:00:00
Session Mismatch
: false
Sess Mismatch Clrd : 06/19/2014 17:23:21
------------------------------------------------------------------------------Control Channel Status
------------------------------------------------------------------------------PW Status
: disabled
Refresh Timer
: <none>
Peer Status Expire : false
Request Timer
: <none>
Acknowledgement
: false
------------------------------------------------------------------------------ETH-CFM SDP-Bind specifics
------------------------------------------------------------------------------Squelch Levels
: None
------------------------------------------------------------------------------MPLS-TP LSPs
------------------------------------------------------------------------------Associated LSP List :
No LSPs Associated
------------------------------------------------------------------------------Class-based forwarding :
------------------------------------------------------------------------------Class forwarding
: Disabled
EnforceDSTELspFc : Disabled
Default LSP
: Uknwn
Multicast LSP
: None
===============================================================================
FC Mapping Table
===============================================================================
FC Name
LSP Name
------------------------------------------------------------------------------No FC Mappings
------------------------------------------------------------------------------Number of SDPs : 1
------------------------------------------------------------------------------===============================================================================
464
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
spoke-sdp-fec
Syntax
Context
spoke-sdp-fec [1 to 4294967295]
show>service>id
Description
This command displays spoke-SDP FEC information.
Parameters
detail — Displays detailed information.
Output
The following output is an example of spoke-SDP FEC information.
Sample Output
===============================================================================
Service Spoke-SDP FEC Information
===============================================================================
Spoke-Sdp-Fec-Id
: 1
Admin State
: enabled
FEC Type
: 129
AII Type
: 2
Standby Sig Slave
: disabled
ICB
: disabled
Signaling
: auto
Auto Config
: disabled
PW Template Id
: (none)
Precedence
: 4
Retry Timer
: 10 secs
Retry Count
: 10
Retry Timer Remaining: 0 secs
Retries Remaining: 0
SAII Type2
: 3:10.20.1.3:1
TAII Type2
: 6:10.20.1.6:1
Path
: n/a
Endpoint
: n/a
Oper SDP-Bind
: 17407:4294967246
Last Error
: <none>
===============================================================================
Entries found: 1
===============================================================================
stp
Syntax
Context
stp [detail]
stp mst-instance mst-inst-number
show>service>id
Description
This command displays information for the spanning tree protocol instance for the service.
Parameters
detail — Displays detailed information.
mst-inst-number — Specifies an existing Multiple Spanning Tree Instance number.
Values
Issue: 01
1 to 4094
3HE 11970 AAAA TQZZA 01
465
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
spoke-sdp-fec
Syntax
Context
Description
Output
spoke-sdp-fec [[1 to 4294967295]]
show>service>id
This command displays the details of a spoke-sdp-fec spoke-sdp.
The following output is an example of spoke-SDP FEC information.
Sample Output
===============================================================================
Service Spoke-SDP FEC Information
===============================================================================
Spoke-Sdp-Fec-Id
: 1
Admin State
: enabled
FEC Type
: 129
AII Type
: 2
Standby Sig Slave
: disabled
ICB
: disabled
Signaling
: auto
Auto Config
: disabled
PW Template Id
: (none)
Precedence
: 4
Retry Timer
: 10 secs
Retry Count
: 10
Retry Timer Remaining: 0 secs
Retries Remaining: 0
SAII Type2
: 3:10.20.1.3:1
TAII Type2
: 6:10.20.1.6:1
Path
: n/a
Endpoint
: n/a
Oper SDP-Bind
: 17407:4294967246
Last Error
: <none>
===============================================================================
Entries found: 1
===============================================================================
sdp
Syntax
Context
Description
sdp sdp-id pw-port [pw-port-id]
sdp sdp-id pw-port
sdp sdp-id pw-port pw-port-id [statistics]
sdp [consistent | inconsistent | na] egressifs
sdp sdp-id keep-alive-history
sdp far-end {ip-address | ipv6-address} keep-alive-history
sdp [sdp-id] detail
sdp far-end {ip-address | ipv6-address} detail
show>service
Displays information for the SDPs associated with the service.
If no optional parameters are specified, a summary of all associated SDPs is displayed.
466
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
Parameters
VLL Services
sdp-id — Specifies the SDP ID for which to display information.
Values
1 to 17407
pw-port-id — Specifies the pseudo-wire port identifier.
Values
1 to 10239
ip-address — Displays only SDPs with the specified far-end IPv4 address. 64 characters
maximum.
ipv6-address — Displays only SDPs with the specified far-end IPv6 address. 64
characters maximum.
detail — Displays detailed SDP information.
Default
SDP summary output
keep-alive-history — Displays the last fifty SDP keepalive events for the SDP.
Default
Output
SDP summary output
The following output is an example of SDP information.
Sample Output
*A:ALA-12>config>service# show service sdp 1 pw-port
===============================================================================
Service Destination Point (sdp Id 1 Pw-Port)
===============================================================================
Pw-port
VC-Id
Adm
Encap
Opr
VC Type
Egr
Monitor
Shaper
Oper
VPort
Group
------------------------------------------------------------------------------1
1
up
dot1q
up
ether
2
2
up
qinq
up
ether
3
3
up
dot1q
up
ether
4
4
up
qinq
up
ether
------------------------------------------------------------------------------Entries found : 4
===============================================================================
*A:ALA-12>config>service# show service sdp 1 pw-port 3
===============================================================================
Service Destination Point (Sdp Id 1 Pw-Port 3)
===============================================================================
SDP Binding port
: lag-1
VC-Id
: 3
Admin Status
: up
Encap
: dot1q
Oper Status
: up
VC Type
: ether
Oper Flags
: (Not Specified)
Monitor Oper-Group
: (Not Specified)
===============================================================================
*A:ALA-12>config>service# show service sdp 1 pw-port 3 statistics
===============================================================================
Service Destination Point (Sdp Id 1 Pw-Port 3)
Issue: 01
3HE 11970 AAAA TQZZA 01
467
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
===============================================================================
SDP Binding port
: lag-1
VC-Id
: 3
Admin Status
: up
Encap
: dot1q
Oper Status
: up
VC Type
: ether
Oper Flags
: (Not Specified)
Monitor Oper-Group
: (Not Specified)
Statistics
:
I. Fwd. Pkts.
: 0
I. Dro. Pkts.
: 0
I. Fwd. Octs.
: 0
I. Dro. Octs.
: 0
E. Fwd. Pkts.
: 0
E. Fwd. Octets
: 0
===============================================================================
pw-port
Syntax
Context
Description
pw-port [pw-port-id] [detail]
pw-port sdp sdp-id
pw-port sdp none
pw-port pw-port-id statistics
show>pw-port
Displays pseudowire port information.
If no optional parameters are specified, the command displays a summary of all defined PW
ports. The optional parameters restrict output to only ports matching the specified properties.
Parameters
pw-port-id — Specifies the pseudo-wire port identifier.
Values
1 to 10239
detail — Displays detailed port information that includes all the pw-port output fields.
sdp-id — The SDP ID for which to display matching PW port information.
Values
1 to 17407
statistics — Displays statistics information.
Output
The following output is an example of PW port information, and Table 31 described the output
fields.
Sample Output
*A:ALA-48>config>service# show pw-port
============================================================================
PW Port Information
============================================================================
PW Port
Encap
SDP
IfIndex
VC-Id
---------------------------------------------------------------------------1
dot1q
1
1526726657
1
2
qinq
1
1526726658
2
468
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
3
dot1q
1
1526726659
3
4
qinq
1
1526726660
4
============================================================================
*A:ALA-48>config>service# show pw-port 3
============================================================================
PW Port Information
============================================================================
PW Port
Encap
SDP
IfIndex
VC-Id
---------------------------------------------------------------------------3
dot1q
1
1526726659
3
============================================================================
*A:ALA-48>config>service# show pw-port 3 detail
===============================================================================
PW Port Information
===============================================================================
PW Port
: 3
Encap
: dot1q
SDP
: 1
IfIndex
: 1526726659
VC-Id
: 3
Description
: 1-Gig Ethernet dual fiber
===============================================================================
*A:ALA-48>config>pw-port$ show pw-port sdp none
============================================================================
PW Port Information
============================================================================
PW Port
Encap
SDP
IfIndex
VC-Id
---------------------------------------------------------------------------5
dot1q
1526726661
============================================================================
*A:ALA-48>config>pw-port$ show pw-port sdp 1
============================================================================
PW Port Information
============================================================================
PW Port
Encap
SDP
IfIndex
VC-Id
---------------------------------------------------------------------------1
dot1q
1
1526726657
1
2
qinq
1
1526726658
2
3
dot1q
1
1526726659
3
4
qinq
1
1526726660
4
============================================================================
Table 31
Issue: 01
Show PW-Port Output Fields
Label
Description
PW Port
The PW Port identifier.
Encap
The encapsulation type of the PW Port.
SDP
The SDP identifier.
3HE 11970 AAAA TQZZA 01
469
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
Table 31
Show PW-Port Output Fields (Continued)
Label
Description (Continued)
IfIndex
The interface index used for the PW Port.
VC-Id
The Virtual Circuit identifier.
Description
The description string for the PW Port.
2.18.2.2
VLL Clear Commands
id
Syntax
Context
Description
id {service-id | service-name} neighbor
clear>service
clear>service>statistics
This command clears commands for a specific service.
For the 7450 ESS or 7750 SR, it clears the discovered IPv6 address of the neighboring CE
associated with an iPipe SAP. Note that when IPv6CP comes back up following the execution
of this command on an IPv6CP SAP, the node will check to see if an IPv6 address has been
learned for the remote CE attached to the ipipe service. If one has been learned, then this is
used to bring up IPv6CP.
Parameters
service-id — The ID that uniquely identifies a service.
Values
service-id: 1 to 214748364
svc-name: A string up to 64 characters long.
service-name — Neighboring IPv6 address, for the 7450 ESS or 7750 SR only.
arp
Syntax
Context
Description
arp
clear>service>id
This command clears all ARP entries. This command is only valid for Ipipe services.
neighbor
Syntax
470
neighbor
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
Context
Description
VLL Services
clear>service>id
This command clears the discovered IPv6 address of the neighboring CE associated with an
iPipe SAP.
host-tracking
Syntax
Context
host-tracking [statistics]
host-tracking sap sap-id [host ip-address] [statistics]
clear>service>id
Description
This command clears host tracking data.
Parameters
sap-id — Specifies a SAP for which to clear host tracking data.
ip-address — Specifies the IP address of a host for which to clear tracking data.
Values
a.b.c.d
statistics — Clears statistics.
mesh-sdp
Syntax
Context
mesh-sdp sdp-id[:vc-id] ingress-vc-label
mesh-sdp sdp-id[:vc-id] vccv-bfd {session | statistics}
clear>service>id
Description
This command clears and resets the mesh SDP binding.
Parameters
sdp-id — The spoke SDP ID for which to clear statistics.
Values
1 to 17407
vc-id — The virtual circuit ID on the SDP ID to be reset.
Values
1 to 4294967295
ingress-vc-label — Specifies to clear the ingress VC label.
vccv-bfd —
session — Displays session information.
statistics — Clears statistics.
spoke-sdp
Syntax
Issue: 01
spoke-sdp sdp-id:vc-id [ingress-vc-label] [lt2pv3] [vccv-bfd {session | statistics}]
3HE 11970 AAAA TQZZA 01
471
VLL Services
Context
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
clear>service>id
Description
This command clears and resets the spoke SDP bindings for the service.
Parameters
sdp-id — The spoke SDP ID to be reset.
Values
1 to 17407
vc-id — The virtual circuit ID on the SDP ID to be reset.
Values
1 to 4294967295
ingress-vc-label — Specifies to clear the ingress VC label.
l2tpv3 — Specifies to clear the session mismatch flag on the spoke-SDP binding after
the flag was set to true by a detected mismatch between the configured parameters
and the received parameters.
vccv-bfd session — Specifies to clear a VCCV BFD session for a given spoke-SDP.
Clearing the VCCV BFD session for a given spoke-SDP will cause the session to go
down and restart.
vccv-bfd statistics — Specifies to clear a VCCV BFD session statistics for a given
spoke-SDP.
statistics
Syntax
Context
Description
statistics
clear>service
This command clears the statistics for a service.
sap
Syntax
Context
sap sap-id {all | cem | counters | stp | l2pt | mrp}
sap sap-id encap-group group-name [member encap-id]
clear>service>statistics
Description
This command clears SAP statistics for a SAP.
Parameters
sap-id — Specifies the physical port identifier portion of the SAP definition.
all — Clears all SAP queue statistics and STP statistics.
counters — Clears all queue statistics associated with the SAP.
stp — Clears all STP statistics associated with the SAP.
l2pt — Clears all L2PT statistics associated with the SAP.
mrp — Clears all MRP statistics associated with the SAP.
472
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
group-name — Specifies the group name. 32 characters max
encap-id — Specifies the encap ID.
Values
o to 16777215
sdp
Syntax
Context
sdp sdp-id keep-alive
sdp sdp-id pw-port [1 to 10239]
clear>service>statistics
Description
This command clears keepalive statistics associated with the SDP ID.
Parameters
sdp-id — The SDP ID for which to clear keepalive statistics.
Values
1 to 17407
keep-alive — Clears the keep-alive history associated with the SDP ID.
counters
Syntax
Context
Description
counters
clear>service>statistics>id
This command clears all traffic queue counters associated with the service ID.
spoke-sdp
Syntax
Context
spoke-sdp sdp-id[:vc-id] {all | counters | stp | 12pt | mrp}
clear>service>statistics>id
Description
This command clears statistics for the spoke SDP bound to the service.
Parameters
sdp-id — The spoke SDP ID for which to clear statistics.
Values
1 to 17407
vc-id — The virtual circuit ID on the SDP ID to be reset.
Values
1 to 4294967295
all — Clears all queue statistics and STP statistics associated with the SDP.
counters — Clears all queue statistics associated with the SDP.
stp — Clears all STP statistics associated with the SDP.
Issue: 01
3HE 11970 AAAA TQZZA 01
473
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
stp
Syntax
Context
Description
stp
clear>service>statistics>id
Clears all spanning tree statistics for the service ID.
2.18.2.3
VLL Debug Commands
id
Syntax
Context
id service-id
debug>service
Description
This command debugs commands for a specific service.
Parameters
service-id — The ID that uniquely identifies a service.
Values
service-id: 1 to 214748364
svc-name: A string up to 64 characters in length
sap
Syntax
Context
[no] sap sap-id
debug>service>id
Description
This command enables debugging for a particular SAP.
Parameters
sap-id — Specifies the SAP ID.
event-type
Syntax
Context
Description
[no] event-type {arp | config-change | oper-status-change | neighbor-discovery}
debug>service>id>sap
This command enables a particular debugging event type.
The no form of the command disables the event type debugging.
Parameters
arp — Displays ARP events.
config-change — Debugs configuration change events.
474
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VLL Services
oper-status-change — Debugs service operational status changes.
neighbor-discovery — Displays the status of IPv6 neighbor discovery for the sap or the
spoke-sdp for the 7450 ESS or 7750 SR only.
Output
The following output is an example of event-type information.
Sample Output
A:bksim180# debug service id 1000 sap 1/7/1 event-type arp
DEBUG OUTPUT show on CLI is as follows:
3 2008/11/17 18:13:24.35 UTC MINOR: DEBUG #2001 Base Service 1000 SAP
1/7/1 "Service 1000 SAP 1/7/1:
RX: ARP_REQUEST (0x0001)
hwType
: 0x0001
prType
: 0x0800
hwLength
: 0x06
prLength
: 0x04
srcMac
: 8c:c7:01:07:00:03
destMac
: 00:00:00:00:00:00
srcIp
: 200.1.1.2
destIp
: 200.1.1.1
"
4 2008/11/17 18:13:24.35 UTC MINOR: DEBUG #2001 Base Service 1000
SAP 1/7/1 "Service 1000 SAP 1/7/1:
TX: ARP_RESPONSE (0x0002)
hwType
: 0x0001
prType
: 0x0800
hwLength
: 0x06
prLength
: 0x04
srcMac
: 00:03:0a:0a:0a:0a
destMac
: 8c:c7:01:07:00:03
srcIp
: 200.1.1.1
destIp
: 200.1.1.2
"
sdp
Syntax
Context
[no] sdp sdp-id:vc-id
debug>service>id
Description
This command enables debugging for a particular SDP.
Parameters
sdp-id — Specifies the SDP ID.
Values
1 to 17407
vc-id — Specifies the virtual circuit ID.
Values
Issue: 01
1 to 4294967295
3HE 11970 AAAA TQZZA 01
475
VLL Services
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
event-type
Syntax
Context
Description
[no] event-type {config-change | oper-status-change | neighbor-discovery | controlchannel-status}
debug>service>id>sdp
This command enables a particular debugging event type.
The no form of the command disables the event type debugging.
Parameters
config-change — Debugs configuration change events.
oper-status-change — Debugs service operational status changes.
neighbor-discovery — Displays the status of IPv6 neighbor discovery for the sap or the
spoke-sdp for the 7450 ESS or 7750 SR only.
control-channel-status —
2.18.2.4
VLL Tools Commands
epipe-map-access-to-egress-port
Syntax
Context
Description
epipe-map-access-to-egress-port {service target-svc-id [end-service end-svc-id]} | lag
lag-id
tools>dump
This command will display the egress port that will be used to transmit traffic associated with
the displayed Epipe service(s). The information displayed shows the egress port for traffic
traveling from SAP to egress SDP or SAP.
This command will support Epipe services with the following combinations:
• SAP to SDP (with no endpoint configuration)
• SAP to SAP (with or without an ICB)
• SAP to SDP using endpoints with 1 or 2 SDPs
The command can be executed by specifying either a service ID, service-ID range or an
ingress LAG ID.
This command will not display the egress port for traffic traveling from the SDP to egress
SAP. This command also does not work with services that use policers or shared queues and
also does not support PBB services.
This command replaces the command tools dump epipe-map-to-network, which has been
deprecated.
476
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
Parameters
VLL Services
service service-id — Identifies the service ID for which the command will return the
egress port. If used in conjunction with the end-service parameter, this value
represent the beginning of the service ID range for which the command will be
executed against.
Values
1 to 2148278316, svc-name: 64 characters max
end-service service-id — This parameter is used to identify the end of the service ID
range for which the command will be executed against.
Values
1 to 2148278316, svc-name: 64 characters max
lag-id — This parameter caused the command to return the egress port for all service
with SAPs associated with the specified LAG ID.
Values
Issue: 01
1 to 800
3HE 11970 AAAA TQZZA 01
477
VLL Services
478
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
Virtual Private LAN Service
3 Virtual Private LAN Service
3.1 In This Chapter
This chapter provides information about Virtual Private LAN Service (VPLS), process
overview, and implementation notes.
3.2 VPLS Service Overview
Virtual Private LAN Service (VPLS) as described in RFC 4905, Encapsulation
methods for transport of layer 2 frames over MPLS, is a class of virtual private
network service that allows the connection of multiple sites in a single bridged
domain over a provider-managed IP/MPLS network. The customer sites in a VPLS
instance appear to be on the same LAN, regardless of their location. VPLS uses an
Ethernet interface on the customer-facing (access) side which simplifies the LAN/
WAN boundary and allows for rapid and flexible service provisioning.
VPLS offers a balance between point-to-point Frame Relay service and outsourced
routed services (VPRN). VPLS enables each customer to maintain control of their
own routing strategies. All customer routers in the VPLS service are part of the same
subnet (LAN) which simplifies the IP addressing plan, especially when compared to
a mesh constructed from many separate point-to-point connections. The VPLS
service management is simplified since the service is not aware of nor participates
in the IP addressing and routing.
A VPLS service provides connectivity between two or more SAPs on one (which is
considered a local service) or more (which is considered a distributed service)
service routers. The connection appears to be a bridged domain to the customer
sites so protocols, including routing protocols, can traverse the VPLS service.
Other VPLS advantages include:
• VPLS is a transparent, protocol-independent service.
• There is no Layer 2 protocol conversion between LAN and WAN technologies.
• There is no need to design, manage, configure, and maintain separate WAN
access equipment, thus, eliminating the need to train personnel on WAN
technologies such as Frame Relay.
Issue: 01
3HE 11970 AAAA TQZZA 01
479
Virtual Private LAN Service
3.2.1
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VPLS Packet Walkthrough
This section provides an example of VPLS processing of a customer packet sent
across the network (Figure 55) from site-A, which is connected to PE-Router-A, to
site-B, which is connected to PE-Router-C (Figure 56).
Figure 55
VPLS Service Architecture
PE D
LSP Full-mesh
B
PE A
VPLS Service1
VPLS Service1
PE C
B
B
B
B
IP/MPLS
Network
Virtual
Bridge
B
B
PE B
OSSG201
1. PE-Router-A (Figure 56)
a. Service packets arriving at PE-Router-A are associated with a VPLS service
instance based on the combination of the physical port and the IEEE
802.1Q tag (VLAN-ID) in the packet.
Figure 56
Access Port Ingress Packet Format and Lookup
Customer
Location A
PE A
B
IP/MPLS Network
Dest Src VLAN Customer
MAC MAC
ID
Packet
Ingress look-up based on
access port or port/VLAN-ID.
OSSG202
480
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
Virtual Private LAN Service
b. PE-Router-A learns the source MAC address in the packet and creates an
entry in the FDB table that associates the MAC address to the service
access point (SAP) on which it was received.
c. The destination MAC address in the packet is looked up in the FDB table for
the VPLS instance. There are two possibilities: either the destination MAC
address has already been learned (known MAC address) or the destination
MAC address is not yet learned (unknown MAC address).
For a Known MAC Address (Figure 57)
d. If the destination MAC address has already been learned by PE-Router-A,
an existing entry in the FDB table identifies the far-end PE-router and the
service VC-label (inner label) to be used before sending the packet to farend PE-Router-C.
e. PE-Router-A chooses a transport LSP to send the customer packets to PERouter-C. The customer packet is sent on this LSP once the IEEE 802.1Q
tag is stripped and the service VC-label (inner label) and the transport label
(outer label) are added to the packet.
For an Unknown MAC Address (Figure 57)
If the destination MAC address has not been learned, PE-Router-A will flood the
packet to both PE-Router-B and PE-Router-C that are participating in the
service by using the VC-labels that each PE-Router previously signaled for the
VPLS instance. Note that the packet is not sent to PE-Router-D since this VPLS
service does not exist on that PE-router.
Figure 57
Network Port Egress Packet Format and Flooding
Pre-assigned and
signaled by PE ‘C’.
Tunnel
VC
Dest Src Customer
Label Label X MAC MAC
Packet
Customer
Location A
PE C
B
PE A
B
IP/MPLS Network
Apply VC and
Tunnel Labels
Dest Src Customer
Tunnel
VC
Packet
Label Label Y MAC MAC
B
PE B
Pre-assigned and
signaled by PE ‘B’.
OSSG203
2. Core Router Switching
Issue: 01
3HE 11970 AAAA TQZZA 01
481
Virtual Private LAN Service
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
a. All the core routers ('P' routers in IETF nomenclature) between PE-RouterA and PE-Router-B and PE-Router-C are Label Switch Routers (LSRs) that
switch the packet based on the transport (outer) label of the packet until the
packet arrives at far-end PE-Router. All core routers are unaware that this
traffic is associated with a VPLS service.
3. PE-Router-C
a. PE-Router-C strips the transport label of the received packet to reveal the
inner VC-label. The VC-label identifies the VPLS service instance to which
the packet belongs.
b. PE-Router-C learns the source MAC address in the packet and creates an
entry in the FDB table that associates the MAC address to PE-Router-A and
the VC-label that PE-Router-A signaled it for the VPLS service on which the
packet was received
c. The destination MAC address in the packet is looked up in the FDB table for
the VPLS instance. Again, there are two possibilities: either the destination
MAC address has already been learned (known MAC address) or the
destination MAC address has not been learned on the access side of PERouter-C (unknown MAC address).
Known MAC address (Figure 58)
d. If the destination MAC address has been learned by PE-Router-C, an
existing entry in the FDB table identifies the local access port and the IEEE
802.1Q tag to be added before sending the packet to customer Location-C.
The egress Q tag may be different than the ingress Q tag.
Figure 58
Access Port Egress Packet Format and Lookup
Pre-assigned and
signaled by PE ‘C’.
Tunnel
VC
Dest Src Customer
Label Label X MAC MAC
Packet
Customer
Location A
PE C
B
PE A
B
IP/MPLS Network
Apply VC and
Tunnel Labels
Dest Src Customer
Tunnel
VC
Packet
Label Label Y MAC MAC
B
PE B
Pre-assigned and
signaled by PE ‘B’.
OSSG204
482
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
Virtual Private LAN Service
3.3 VPLS Features
This section features:
• VPLS Enhancements
• Pseudo-wire Control Word
• Split Horizon SAP Groups and Split Horizon Spoke SDP Groups
• VPLS and Spanning Tree Protocol
• VPLS Redundancy
• VPLS Access Redundancy
• VCCV BFD Support for VPLS Services
3.3.1
VPLS Enhancements
Nokia’s VPLS implementation includes several enhancements beyond basic VPN
connectivity. The following VPLS features can be configured individually for each
VPLS service instance:
• Extensive MAC and IP filter support (up to Layer 4). Filters can be applied on a
per SAP basis.
• Forwarding Database (FDB) management features on a per service level
including:
− Configurable FDB size limit. On the 7450 ESS, it can be configured on a per
VPLS, per SAP and per spoke SDP basis.
− FDB size alarms. On the 7450 ESS, it can be configured on a per VPLS
basis.
− MAC learning disable. On the 7450 ESS, it can be configured on a per
VPLS, per SAP and per spoke SDP basis.
− Discard unknown. On the 7450 ESS, it can be configured on a per VPLS
basis.
− Separate aging timers for locally and remotely learned MAC addresses.
• Ingress rate limiting for broadcast, multicast, and destination unknown flooding
on a per SAP basis.
• Implementation of Spanning Tree Protocol (STP) parameters on a per VPLS,
per SAP and per spoke SDP basis.
• A split horizon group on a per-SAP and per-spoke SDP basis.
Issue: 01
3HE 11970 AAAA TQZZA 01
483
Virtual Private LAN Service
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
• DHCP snooping and anti-spoofing on a per-SAP and per-SDP basis for the
7450 ESS or 7750 SR.
• IGMP snooping on a per-SAP and per-SDP basis.
• Optional SAP and/or spoke SDP redundancy to protect against node failure.
3.3.2
VPLS over MPLS
The VPLS architecture proposed in RFC 4762, Virtual Private LAN Services Using
LDP Signaling specifies the use of provider equipment (PE) that is capable of
learning, bridging, and replication on a per-VPLS basis. The PE routers that
participate in the service are connected using MPLS Label Switched Path (LSP)
tunnels in a full-mesh composed of mesh SDPs or based on an LSP hierarchy
(Hierarchical VPLS (H-VPLS)) composed of mesh SDPs and spoke SDPs.
Multiple VPLS services can be offered over the same set of LSP tunnels. Signaling
specified in RFC 4905, Encapsulation methods for transport of layer 2 frames over
MPLS is used to negotiate a set of ingress and egress VC labels on a per-service
basis. The VC labels are used by the PE routers for demultiplexing traffic arriving
from different VPLS services over the same set of LSP tunnels.
VPLS is provided over MPLS by:
• Connecting bridging-capable provider edge routers with a full mesh of MPLS
LSP (label switched path) tunnels.
• Negotiating per-service VC labels using draft-Martini encapsulation.
• Replicating unknown and broadcast traffic in a service domain.
• Enabling MAC learning over tunnel and access ports (see VPLS MAC Learning
and Packet Forwarding).
• Using a separate forwarding database (FDB) per VPLS service.
3.3.3
VPLS Service Pseudo-wire VLAN Tag Processing
VPLS services can be connected using pseudo-wires that can be provisioned
statically or dynamically and are represented in the system as either a mesh or a
spoke SDP. The mesh and spoke SDP can be configured to process zero, one or
two VLAN tags as traffic is transmitted and received. In the transmit direction VLAN
tags are added to the frame being sent and in the received direction VLAN tags are
removed from the frame being received. This is analogous to the SAP operations on
a null, dot1q and QinQ SAP.
484
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
Virtual Private LAN Service
The system expects a symmetrical configuration with its peer, specifically it expects
to remove the same number of VLAN tags from received traffic as it adds to
transmitted traffic. When removing VLAN tags from a mesh or spoke SDP, the
system attempts to remove the configured number of VLAN tags (see below for the
configuration details); if fewer tags are found, the system removes the VLAN tags
found and forwards the resulting packet. As some of the related configuration
parameters are local and not communicated in the signaling plane, an asymmetrical
behavior cannot always be detected and so cannot be blocked. With an
asymmetrical behavior, protocol extractions will not necessarily function as they
would with a symmetrical configurations resulting in an unexpected operation.
The VLAN tag processing is configured as follows on a mesh or spoke SDP in a
VPLS service:
• Zero VLAN tags processed—This requires the configuration of vc-type ether
under the mesh or spoke SDP, or in the related pw-template.
• One VLAN tag processed—This requires one of the following configurations:
− vc-type vlan under the mesh or spoke SDP, or in the related pw-template.
− vc-type ether and force-vlan-vc-forwarding under the mesh or spoke
SDP, or in the related pw-template.
• Two VLAN tags processed—This requires the configuration of force-qinq-vcforwarding under the mesh or spoke SDP, or in the related pw-template.
The pw-template configuration provides support for BGP VPLS services and LDP
VPLS services using BGP Auto-Discovery.
The following restrictions apply to VLAN tag processing:
• The configuration of vc-type vlan and force-vlan-vc-forwarding is mutually
exclusive.
• BGP VPLS services operate in a mode equivalent to vc-type ether,
consequently the configuration of vc-type vlan in a pw-template for a BGP
VPLS service is ignored.
• force-qinq-vc-forwarding can be configured with the mesh or spoke SDP
signaled as either vc-type ether or vc-type vlan.
• The following are not supported with force-qinq-vc-forwarding configured
under the mesh or spoke SDP, or in the related pw-template:
− Routed, Etree or PBB VPLS services.
− L2PT termination on QinQ mesh or spoke SDPs.
− IGMP/MLD/PIM snooping within the VPLS service.
− ETH-CFM MIPs and MEPs are not supported on dynamically signaled BGP
QinQ PWs.
Issue: 01
3HE 11970 AAAA TQZZA 01
485
Virtual Private LAN Service
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
Table 32 and Table 33 describe the VLAN tag processing with respect to the zero,
one and two VLAN tag configuration described above for the VLAN identifiers, Ether
type, ingress QoS classification (dot1p/DE) and QoS propagation to the egress
(which can be used for egress classification and/or to set the QoS information in the
innermost egress VLAN tag).
Table 32
VPLS Mesh and Spoke SDP VLAN Tag Processing: Ingress
Ingress (received on
mesh or spoke SDP)
Zero VLAN
tags
One VLAN tag
Two VLAN tags
VLAN identifiers
N/A
Ignored
Both inner and outer ignored
Ether type (to
determine the presence
of a VLAN tag)
N/A
0x8100 or value
configured under sdp
vlan-vc-etype
Both inner and outer VLAN tags:
0x8100, or outer VLAN tag value
configured under sdp
vlan-vc-etype (inner VLAN tag
value must be 0x8100)
Ingress QoS (dot1p/
DE) classification
N/A
Ignored
Both inner and outer ignored
QoeE (dot1p/DE)
propagation to egress
Dot1p/DE=0
Dot1p/DE taken from
received VLAN tag
Dot1p/DE taken from inner received
VLAN tag
486
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
Table 33
Virtual Private LAN Service
VPLS Mesh and Spoke SDP VLAN Tag Processing: Egress
Egress (sent on mesh
or spoke SDP)
Zero VLAN
tags
One VLAN tag
Two VLAN tags
VLAN identifiers (set in
VLAN tags)
N/A
For one VLAN tag, one of the
following applies:
For both inner and outer VLAN
tags, one of the following
applies:
• the vlan-vc-tag value
configured in pwtemplate or under the
mesh/spoke SDP
• taken from the inner tag
received on a QinQ SAP
or QinQ mesh/spoke
SDP
• taken from the VLAN tag
received on a dot1q
SAP or mesh/spoke
SDP (with vc-type vlan
or force-vlan-vcforwarding)
• taken from the outer tag
received on a qtag.*
SAP
• 0 if there is no service
delimiting VLAN tag at
the ingress SAP or
mesh/spoke SDP
Ether type (set in VLAN
tags)
Issue: 01
N/A
0x8100 or value configured
under sdp vlan-vc-etype
3HE 11970 AAAA TQZZA 01
• the vlan-vc-tag value
configured in pwtemplate or under the
mesh/spoke SDP
• taken from the inner tag
received on a QinQ SAP
or QinQ mesh/spoke
SDP
• taken from the VLAN tag
received on a dot1q
SAP or mesh/spoke
SDP (with vc-type vlan
or force-vlan-vcforwarding)
• taken from the outer tag
received on a qtag.*
SAP
• 0 if there is no service
delimiting VLAN tag at
the ingress SAP or
mesh/spoke SDP
Both inner and outer VLAN
tags: 0x8100, or outer VLAN tag
value configured under sdp
vlan-vc-etype (inner VLAN tag
value will be 0x8100)
487
Virtual Private LAN Service
Table 33
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
VPLS Mesh and Spoke SDP VLAN Tag Processing: Egress (Continued)
Egress (sent on mesh
or spoke SDP)
Zero VLAN
tags
One VLAN tag
Two VLAN tags
Egress QoS (dot1p/DE)
(set in VLAN tags)
N/A
Taken from the innermost
ingress service delimiting tag,
one of the following applies:
For both inner and outer dot1p/
DE, the value is taken from the
innermost ingress service
delimiting tag. One of the
following applies:
• the inner tag received on
a QinQ SAP or QinQ
mesh/spoke SDP
• taken from the VLAN tag
received on a dot1q
SAP or mesh/spoke
SDP (with vc-type vlan
or force-vlan-vcforwarding)
• taken from the outer tag
received on a qtag.*
SAP
• 0 if there is no service
delimiting VLAN tag at
the ingress SAP or
mesh/spoke SDP
Note that neither the inner nor
outer dot1p/DE values can be
explicitly set.
• the inner tag received on
a QinQ SAP or QinQ
mesh/spoke SDP
• taken from the VLAN tag
received on a dot1q
SAP or mesh/spoke
SDP (with vc-type vlan
or force-vlan-vcforwarding)
• taken from the outer tag
received on a qtag.*
SAP
• 0 if there is no service
delimiting VLAN tag at
the ingress SAP or
mesh/spoke SDP
Note that neither the inner nor
outer dot1p/DE values can be
explicitly set.
Any non-service delimiting VLAN tags are forwarded transparently through the VPLS
service. SAP egress classification is possible on the outer most customer VLAN tag
received on a mesh or spoke SDP using the ethernet-ctag parameter in the
associated SAP egress QoS policy.
3.3.4
VPLS MAC Learning and Packet Forwarding
The 7950 XRS, 7750 SR, and 7450 ESS perform the packet replication required for
broadcast and multicast traffic across the bridged domain. MAC address learning is
performed by the router to reduce the amount of unknown destination MAC address
flooding.
488
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
Virtual Private LAN Service
The 7450 ESS, 7750 SR, and 7950 XRS routers learn the source MAC addresses of
the traffic arriving on their access and network ports.
Each router maintains a Forwarding Database (FDB) for each VPLS service instance
and learned MAC addresses are populated in the FDB table of the service. All traffic
is switched based on MAC addresses and forwarded between all objects in the VPLS
service. Unknown destination packets (for example, the destination MAC address
has not been learned) are forwarded on all objects to all participating nodes for that
service until the target station responds and the MAC address is learned by the
routers associated with that service.
3.3.4.1
MAC Learning Protection
In a Layer 2 environment, subscribers or customers connected to SAPs A, B, C can
create a denial of service attack by sending packets sourcing the gateway MAC
address. This will move the learned gateway MAC from the uplink SDP/SAP to the
subscriber’s or customer’s SAP causing all communication to the gateway to be
disrupted. If local content is attached to the same VPLS (D), a similar attack can be
launched against it. Communication between subscribers or customers is also
disallowed but split-horizon will not be sufficient in the topology depicted in Figure 59.
Figure 59
MAC Learning Protection
Local
Content
D
H1
A1
A2
H2
VPLS
VPLS
G
IES
VPLS
VPLS
H
IES
A3
B1
H3
B2
B3
OSSG189
Issue: 01
3HE 11970 AAAA TQZZA 01
489
Virtual Private LAN Service
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
The 7450 ESS, 7750 SR, and 7950 XRS routers enable MAC learning protection
capability for SAPs and SDPs. With this mechanism, forwarding and learning rules
apply to the non-protected SAPs. Assume hosts H1, H2 and H3 (Figure 59) are nonprotected while IES interfaces G and H are protected. When a frame arrives at a
protected SAP/SDP the MAC is learned as usual. When a frame arrives from a nonprotected SAP or SDP the frame must be dropped if the source MAC address is
protected and the MAC address is not relearned. The system allows only packets
with a protected MAC destination address.
The system can be configured statically. The addresses of all protected MACs are
configured. Only the IP address can be included and use a dynamic mechanism to
resolve the MAC address (cpe-ping). All protected MACs in all VPLS instances in the
network must be configured.
In order to eliminate the ability of a subscriber or customer to cause a DOS attack,
the node restricts the learning of protected MAC addresses based on a statically
defined list. In addition the destination MAC address is checked against the protected
MAC list to verify that a packet entering a restricted SAP has a protected MAC as a
destination.
3.3.4.2
DEI in IEEE 802.1ad
IEEE 802.1ad-2005 standard allows drop eligibility to be conveyed separately from
priority in Service VLAN TAGs (STAGs) so that all of the previously introduced traffic
types can be marked as drop eligible. The Service VLAN TAG has a new format
where the priority and discard eligibility parameters are conveyed in the three bit
Priority Code Point (PCP) field and respectively in the DE Bit (Figure 60).
Figure 60
2
1
DE
Octets:
DE Bit in the 802.1ad S-TAG
PCP
Bits:
8
6
5
VID
4
1
8
1
0986
The DE bit allows the S-TAG to convey eight forwarding classes/distinct emission
priorities, each with a drop eligible indication.
When DE bit is set to 0 (DE=FALSE), the related packet is not discard eligible. This
is the case for the packets that are within the CIR limits and must be given priority in
case of congestion. If the DEI is not used or backwards compliance is required the
DE bit should be set to zero on transmission and ignored on reception.
490
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
Virtual Private LAN Service
When the DE bit is set to 1 (DE=TRUE), the related packet is discard eligible. This is
the case for the packets that are sent above the CIR limit (but below the PIR). In case
of congestion these packets will be the first ones to be dropped.
3.3.5
VPLS Using G.8031 Protected Ethernet Tunnels
The use of MPLS tunnels provides a way to scale the core while offering fast failover
times using MPLS FRR. In environments where Ethernet services are deployed
using native Ethernet backbones Ethernet tunnels are provided to achieve the same
fast failover times as in the MPLS FRR case. There are still service provider
environments where Ethernet services are deployed using native Ethernet
backbones.
The Nokia VPLS implementation offers the capability to use core Ethernet tunnels
compliant with ITU-T G.8031 specification to achieve 50 ms resiliency for backbone
failures. This is required to comply with the stringent SLAs provided by service
providers in the current competitive environment. The implementation also allows a
LAG-emulating Ethernet Tunnel providing a complimentary native Ethernet ELAN
capability. The LAG-emulating Ethernet tunnels and G.8031 protected Ethernet
tunnels operate independently. (refer to LAG emulation using Ethernet Tunnels)
When using Ethernet Tunnels, the Ethernet Tunnel logical interface is created first.
= The Ethernet tunnel has member ports which are the physical ports supporting the
links. The Ethernet tunnel control SAPs carries G.8031 and 802.1ag control traffic
and user data traffic. Ethernet Service SAPs are configured on the Ethernet tunnel.
Optionally when tunnels follow the same paths end to end services may be
configured with, Same-fate Ethernet tunnel SAPs which carry only user data traffic
and shares the fate of the Ethernet tunnel port (if properly configured).
When configuring VPLS and BVPLS using Ethernet tunnels the services are very
similar.
Refer to the IEEE 802.1ah PBB Guide for examples.
Issue: 01
3HE 11970 AAAA TQZZA 01
491
Virtual Private LAN Service
3.3.6
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
Pseudo-wire Control Word
The control word command enables the use of the control word individually on each
mesh SDP or spoke sdp. By default, the control word is disabled. When the control
word is enabled, all VPLS packets, including the BPDU frames are encapsulated with
the control word. The T-LDP control plane behavior will be the same as the control
word for VLL services. The configuration for the two directions of the Ethernet
pseudo-wire should match.
3.3.7
Table Management
The following sections describe VPLS features related to management of the
Forwarding Database (FDB).
3.3.7.1
Selective MAC Address Learning
Source MAC addresses are learned in a VPLS service by default with an entry
allocated in the FDB for each address on all line cards. Therefore, all MAC addresses
are considered to be global. This operation can be modified so that the line card
allocation of some MAC addresses is selective, based on where the service has a
configured object.
An example of the advantage of selective MAC address learning is for services to
benefit from the higher MAC address scale of some line cards (particularly for
network interfaces used by mesh or spoke SDPs, EVPN-VXLAN tunnels, and EVPNMPLS destinations) while using lower MAC address scale cards for the SAPs.
Selective MAC addresses are those learned locally and dynamically in the data path
(displayed in the show output with type “L”) or by EVPN (displayed in the show
output with type “Evpn”, excluding those with the sticky bit set, which are displayed
with type “EvpnS”). An exception is when a MAC address configured as a conditional
static MAC address is learned dynamically on an object other than its monitored
object; this can be displayed with type “L” or “Evpn” but is learned as global because
of the conditional static MAC configuration.
492
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
Virtual Private LAN Service
Selective MAC addresses have FDB entries allocated on line cards where the
service has a configured object. When a MAC address is learned, it is allocated an
FDB entry on all line cards on which the service has a SAP configured (for LAG or
Ethernet tunnel SAPs, the MAC address is allocated an FBD entry on all line cards
on which that LAG or Ethernet tunnel has configured ports) and on all line cards that
have a network interface port if the service is configured with VXLAN, EVPN-MPLS,
or a mesh or spoke SDP.
When using selective learning in an I-VPLS service, the learned CMACs are
allocated FDB entries on all the line cards where the I-VPLS service has a configured
object and on the line cards on which the associated B-VPLS has a configured
object. When using selective learning in a VPLS service with allow-ip-intf-bind
configured (for it to become a routed VPLS), FDB entries are allocated on all line
cards on which there is an IES or VPRN interface.
If a new configured object is added to a service and there are sufficient MAC FDB
resources available on the new line cards, the selective MAC addresses present in
the service are allocated on the new line cards. Otherwise, if any of the selective
MAC addresses currently learned in the service cannot be allocated an FDB entry on
the new line cards, those MAC addresses will be deleted from all line cards. Such a
deletion increments the FailedMacCmplxMapUpdts statistic displayed in the tools
dump service vpls-fdb-stats output.
When the set of configured objects changes for a service using selective learning,
the system must reallocate its FDB entries accordingly, which can cause FDB entry
"allocate" or "free" operations to pend temporarily. The pending operations can be
displayed using the tools dump service id fdb command.
When a global MAC address is to be learned, there must be a free FDB entry in the
service and system FDBs and on all line cards in the system for it to be accepted.
When a selective MAC address is to be learned, there must be a free FDB entry in
the service and system FDBs and on all line cards where the service has a
configured object for it to be accepted.
To demonstrate the selective MAC address learning logic, consider the following:
• a system has three line cards: 1, 2, and 3
• two VPLS services are configured on the system:
− VPLS 1 having learned MAC addresses M1, M2, and M3 and has
configured SAPs 1/1/1 and 2/1/1
− VPLS 2 learned MAC addresses M4, M5, and M6 and has configured SAPs
2/1/2 and 3/1/1
This is shown in Table 34.
Issue: 01
3HE 11970 AAAA TQZZA 01
493
Virtual Private LAN Service
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
Table 34
MAC Address Learning Logic Example
Learned MAC addresses
Configured SAPs
VPLS1
M1, M2, M3
sap 1/1/1
sap 2/1/1
VPLS2
M4, M5, M6
sap 2/1/2
sap 3/1/1
Figure 61 shows the FDB entry allocation when the MAC addresses are global and
when they are selective. Notice that in the selective case, all MAC addresses are
allocated FDB entries on line card 2, but line card 1 and 3 only have FDB entries
allocated for services VPLS 1 and VPLS 2 respectively.
Figure 61
MAC FDB Entry Allocation: Global versus Selective
MAC FDB Entry Allocation: Global (Default)
Line Card 2
Line Card 1
Line Card 3
VPLS 1
VPLS 2
VPLS 1
VPLS 2
VPLS 1
VPLS 2
M1
M4
M1
M4
M1
M4
M2
M5
M2
M5
M2
M5
M3
M6
M3
M6
M3
M6
MAC FDB Entry Allocation: Selective
Line Card 1
VPLS 1
Line Card 2
VPLS 2
Line Card 3
VPLS 1
VPLS 2
VPLS 1
VPLS 2
M1
M1
M4
M4
M2
M2
M5
M5
M3
M3
M6
M6
sw0069
Selective MAC address learning can be enabled as follows within any VPLS service,
except for B-VPLS and routed VPLS services.
configure
service
vpls <service-id> create
[no] selective-learned-fdb
Enabling selective MAC address learning has no effect on single line card systems.
494
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
Virtual Private LAN Service
When selective learning is enabled or disabled in a VPLS service, the system may
need to reallocate FDB entries; this can cause temporary pending FDB entry allocate
or free operations. The pending operations can be displayed using the tools dump
service id fdb command.
3.3.7.1.1
Example Operational Information
The show and tools dump command output can display the global and selective
MAC addresses along with the MAC address limits and the number of allocated and
free MAC addresses FDB entries. The show output displays the system and card
FDB usage, while the tools output displays the FDB per service with respect to MAC
addresses and cards.
The configuration for the following output is similar to the simple example above:
• the system has three line cards: 1, 2, and 5
• the system has two VPLS services:
− VPLS 1 is an EVPN-MPLS service with a SAP on 5/1/1:1 and uses a
network interface on 5/1/5
− VPLS 2 has two SAPs on 2/1/1:2 and 2/1/2:2.
The first set of output shows the default where all MAC addresses are global. The
second enables selective learning in the two VPLS services.
Global MAC address learning only (default)
By default, VPLS 1 and 2 are not configured for selective learning, so all MAC
addresses are global:
*A:PE1# show service id [1,2] fdb | match expression ", Service|Sel Learned FDB"
Forwarding Database, Service 1
Sel Learned FDB
: Disabled
Forwarding Database, Service 2
Sel Learned FDB
: Disabled
*A:PE1#
Traffic is sent into the services, resulting in the following MAC addresses being
learned:
*A:PE1# show service fdb-mac
===============================================================================
Service Forwarding Database
===============================================================================
ServId
MAC
Source-Identifier
Type
Last Change
Age
Issue: 01
3HE 11970 AAAA TQZZA 01
495
Virtual Private LAN Service
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
------------------------------------------------------------------------------1
00:00:00:00:01:01 sap:5/1/1:1
L/0
01/31/17 08:44:37
1
00:00:00:00:01:02 sap:5/1/1:1
L/0
01/31/17 08:44:37
1
00:00:00:00:01:03 eMpls:
EvpnS
01/31/17 08:41:38
P
10.251.72.58:262142
1
00:00:00:00:01:04 eMpls:
EvpnS
01/31/17 08:41:38
P
10.251.72.58:262142
2
00:00:00:00:02:01 sap:2/1/2:2
L/0
01/31/17 08:44:37
2
00:00:00:00:02:02 sap:2/1/2:2
L/0
01/31/17 08:44:37
2
00:00:00:02:02:03 sap:2/1/1:2
L/0
01/31/17 08:44:37
2
00:00:00:02:02:04 sap:2/1/1:2
L/0
01/31/17 08:44:37
------------------------------------------------------------------------------No. of Entries: 8
------------------------------------------------------------------------------Legend: L=Learned O=Oam P=Protected-MAC C=Conditional S=Static Lf=Leaf
===============================================================================
*A:PE1#
A total of eight MAC addresses are learned. There are two MAC addresses learned
locally on SAP 5/1/1:1 in service VPLS 1 (type “L”), another two MAC addresses
learned using EVPN with the sticky bit set, also in service VPLS 1 (type “EvpnS”). A
further two sets of two MAC addresses are learned on SAP 2/1/1:2 and 2/1/2:2 in
service VPLS 2 (type “L”).
The system and line card FDB usage is shown below:
*A:PE1# show service system fdb-usage
===============================================================================
FDB Usage
===============================================================================
System
------------------------------------------------------------------------------Limit:
511999
Allocated: 8
Free:
511991
Global:
8
------------------------------------------------------------------------------Line Cards
------------------------------------------------------------------------------Card
Selective
Allocated
Limit
Free
------------------------------------------------------------------------------1
0
8
511999
511991
2
0
8
511999
511991
5
0
8
511999
511991
------------------------------------------------------------------------------===============================================================================
*A:PE1#
The system MAC address limit is 511999, of which eight are allocated, and the rest
are free. All eight MAC addresses are global and are allocated on cards 1, 2, and 5.
There are no selective MAC addresses. This output can be reduced to specific line
cards by specifying the card’s slot id as a parameter to the command.
496
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
Virtual Private LAN Service
To see the MAC address information per service, tools dump commands can be
used, as shown below for VPLS 1. The following output displays the card status:
*A:PE1# tools dump service id 1 fdb card-status
===============================================================================
VPLS FDB Card Status at 01/31/2017 08:44:38
===============================================================================
Card
Allocated
PendAlloc
PendFree
------------------------------------------------------------------------------1
4
0
0
2
4
0
0
5
4
0
0
===============================================================================
*A:PE1#
All of the line cards have four FDB entries allocated in VPLS 1. The “PendAlloc” and
“PendFree” columns show the number of pending MAC address allocate and free
operations, which are all zero.
The following output displays the MAC address status for VPLS 1:
*A:PE1# tools dump service id 1 fdb mac-status
===============================================================================
VPLS FDB MAC status at 01/31/2017 08:44:38
===============================================================================
MAC Address
Type
Status : Card list
------------------------------------------------------------------------------00:00:00:00:01:01
Global
Allocated : All
00:00:00:00:01:02
Global
Allocated : All
00:00:00:00:01:03
Global
Allocated : All
00:00:00:00:01:04
Global
Allocated : All
===============================================================================
*A:PE1#
The type and card list for each MAC address in VPLS 1 is displayed. VPLS 1 has
learned four MAC addresses; the two local MAC addresses on SAP 5/1/1:1 and the
two EvpnS MAC addresses. Each MAC address has an FDB entry allocated on all
line cards. This output can be further reduced by optionally specifying a given MAC
address, a specific card, and the operational pending state.
Selective and global MAC address learning
Selective MAC address learning is now enabled in VPLS 1 and VPLS 2.
*A:PE1# show service id [1,2] fdb | match expression ", Service|Sel Learned FDB"
Forwarding Database, Service 1
Sel Learned FDB
: Enabled
Forwarding Database, Service 2
Sel Learned FDB
: Enabled
*A:PE1#
Issue: 01
3HE 11970 AAAA TQZZA 01
497
Virtual Private LAN Service
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
The MAC addresses learned are the same, with the same traffic being sent;
however, there are now selective MAC addresses which are allocated FDB entries
on different line cards.
The system and line card FDB usage is shown below:
*A:PE1# show service system fdb-usage
===============================================================================
FDB Usage
===============================================================================
System
------------------------------------------------------------------------------Limit:
511999
Allocated: 8
Free:
511991
Global:
2
------------------------------------------------------------------------------Line Cards
------------------------------------------------------------------------------Card
Selective
Allocated
Limit
Free
------------------------------------------------------------------------------1
0
2
511999
511997
2
4
6
511999
511993
5
2
4
511999
511995
------------------------------------------------------------------------------===============================================================================
*A:PE1#
The system MAC address limit and allocated numbers have not changed but now
there are only two global MAC addresses; these are the two EvpnS MAC addresses.
There are two FDB entries allocated on card 1, which are the global MAC addresses;
there are no services or network interfaces configured on card 1, so the FDB entries
allocated are for the global MAC addresses.
Card 2 has six FDB entries allocated in total; two for the global MAC addresses plus
four for the selective MAC addresses in VPLS 2 (these are the two sets of two local
MAC addresses in VPLS 2 on SAP 2/1/1:2 and 2/1/2:2).
Card 5 has four FDB entries allocated in total; two for the global MAC addresses plus
two for the selective MAC addresses in VPLS 1 (these are the two local MAC
addresses in VPLS 1 on SAP 5/1/1:1).
This output can be reduced to specific line cards by specifying the card’s slot ID as
a parameter to the command.
To see the MAC address information per service, tools dump commands can be
used for VPLS 1.
The following output displays the card status:
*A:PE1# tools dump service id 1 fdb card-status
498
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
Virtual Private LAN Service
===============================================================================
VPLS FDB Card Status at 01/31/2017 08:44:39
===============================================================================
Card
Allocated
PendAlloc
PendFree
------------------------------------------------------------------------------1
2
0
0
2
2
0
0
5
4
0
0
===============================================================================
*A:PE1#
There are two FDB entries allocated on line card 1, two on line card 2, and four on
line card 5. The “PendAlloc” and “PendFree” columns are all zeros.
The following output displays the MAC address status for VPLS 1.
*A:PE1# tools dump service id 1 fdb mac-status
===============================================================================
VPLS FDB MAC status at 01/31/2017 08:44:39
===============================================================================
MAC Address
Type
Status : Card list
------------------------------------------------------------------------------00:00:00:00:01:01
Select
Allocated : 5
00:00:00:00:01:02
Select
Allocated : 5
00:00:00:00:01:03
Global
Allocated : All
00:00:00:00:01:04
Global
Allocated : All
===============================================================================
*A:PE1#
The type and card list for each MAC address in VPLS 1 is displayed. VPLS 1 has
learned four MAC addresses; the two local MAC addresses on SAP 5/1/1:1 and the
two EvpnS MAC addresses. The local MAC addresses are selective and have FDB
entries allocated only on card 5. The global MAC addresses are allocated on all line
cards. This output can be further reduced by optionally specifying a given MAC
address, a specific card, and the operational pending state.
3.3.7.2
System FDB Size
The system FDB table size is configurable as follows:
configure
service
system
fdb-table-size table-size
where table-size can have values in the range from 255 999 to 2 047 999 (2000k).
Issue: 01
3HE 11970 AAAA TQZZA 01
499
Virtual Private LAN Service
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
The default, minimum and maximum values for the table-size are dependent on the
chassis type. To support more than 500k MAC addresses, the CPMs provisioned in
the system must have at least 16 GB memory. The maximum system FDB table size
also limits the maximum FDB table size of any card within the system.
The actual achievable maximum number of MAC addresses depends on the MAC
address scale supported by the active cards and whether selective learning is
enabled.
If an attempt is made to configure the system FDB table size such that:
• the new size is greater than or equal to the current number of allocated FDB
entries, the command succeeds and the new system FDB table size is used.
• the new size is less than the number of allocated FDB entries, the command fails
with an error message. In this case, the user is expected to reduce the current
FDB usage (for example by deleting statically configured MAC addresses,
shutting down EVPN, clearing learned MACs, and so on) to lower the number of
allocated MAC addresses in the FDB so that it does not exceed the system FDB
table size being configured.
The logic when attempting a rollback is similar, however, when rolling back to a
configuration where the system FDB table size is smaller than the current system
FDB table size, the system will flush all learned MAC addresses (by performing a
shutdown then no shutdown in all VPLS services) to allow the rollback to continue.
The system FDB table size can be larger than some of the line card FDB sizes,
resulting in the possibility that the current number of allocated global MAC addresses
is larger than the maximum FDB size supported on some line cards. When a new line
card is provisioned, the system checks whether the line card's FDB can
accommodate all of the currently allocated global MAC addresses. If it can, then the
provisioning succeeds; if it cannot, then the provisioning fails and an error is
reported. If the provisioning fails, the number of global MACs allocated must be
reduced in the system to a number that the new line card can accommodate and then
the card-type must be reprovisioned.
3.3.7.3
Per-VPLS Service FDB Size
The following MAC table management features are available for each instance of a
SAP or spoke SDP within a particular VPLS service instance:
• MAC FDB size limits — Allows users to specify the maximum number of MAC
FDB entries that are learned locally for a SAP or remotely for a spoke SDP. If
the configured limit is reached, then no new addresses will be learned from the
SAP or spoke SDP until at least one FDB entry is aged out or cleared.
500
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
Virtual Private LAN Service
− When the limit is reached on a SAP or spoke SDP, packets with unknown
source MAC addresses are still forwarded (this default behavior can be
changed by configuration). By default, if the destination MAC address is
known, it is forwarded based on the FDB, and if the destination MAC
address is unknown, it will be flooded. Alternatively, if discard unknown is
enabled at the VPLS service level, any packets from unknown source MAC
addresses are discarded at the SAP.
− The log event SAP MAC limit reached is generated when the limit is
reached. When the condition is cleared, the log event SAP MAC Limit
Reached Condition Cleared is generated.
− Disable learning allows users to disable the dynamic learning function on a
SAP or a spoke SDP of a VPLS service instance.
− Disable aging allows users to turn off aging for learned MAC addresses on
a SAP or a spoke SDP of a VPLS service instance.
3.3.7.4
System FDB Size Alarms
High and low water mark alarms give warning when the system MAC FDB usage is
high. An alarm is generated when the number of FDB entries allocated in the system
FDB reaches 95% of the total system FDB table size and is cleared when it reduces
to 90% of the system FDB table size. These percentages are not configurable.
3.3.7.5
Line Card FDB Size Alarms
High and low water mark alarms give warning when a line card's MAC FDB usage is
high. An alarm is generated when the number of FDB entries allocated in a line card
FDB reaches 95% of its maximum FDB table size and is cleared when it reduces to
90% of its maximum FDB table size. These percentages are not configurable.
3.3.7.6
Per VPLS FDB Size Alarms
The size of the VPLS FDB can be configured with a low watermark and a high
watermark, expressed as a percentage of the total FDB size limit. If the actual FDB
size grows above the configured high watermark percentage, an alarm is generated.
If the FDB size falls below the configured low watermark percentage, the alarm is
cleared by the system.
Issue: 01
3HE 11970 AAAA TQZZA 01
501
Virtual Private LAN Service
3.3.7.7
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
Local and Remote Aging Timers
Like a Layer 2 switch, learned MACs within a VPLS instance can be aged out if no
packets are sourced from the MAC address for a specified period of time (the aging
time). In each VPLS service instance, there are independent aging timers for locally
learned MAC and remotely learned MAC entries in the FDB. A local MAC address is
a MAC address associated with a SAP because it ingressed on a SAP. A remote
MAC address is a MAC address received by an SDP from another router for the
VPLS instance. The local-age timer for the VPLS instance specifies the aging time
for locally learned MAC addresses, and the remote-age timer specifies the aging
time for remotely learned MAC addresses.
In general, the remote-age timer is set to a longer period than the local-age timer to
reduce the amount of flooding required for destination unknown MAC addresses.
The aging mechanism is considered a low priority process. In most situations, the
aging out of MAC addresses happens within tens of seconds beyond the age time.
However, it, can take up to two times their respective age timer to be aged out.
3.3.7.8
Disable MAC Aging
The MAC aging timers can be disabled which will prevent any learned MAC entries
from being aged out of the FDB. When aging is disabled, it is still possible to manually
delete or flush learned MAC entries. Aging can be disabled for learned MAC
addresses on a SAP or a spoke SDP of a VPLS service instance.
3.3.7.9
Disable MAC Learning
When MAC learning is disabled for a service, new source MAC addresses are not
entered in the VPLS FDB, whether the MAC address is local or remote. MAC
learning can be disabled for individual SAPs or spoke SDPs.
3.3.7.10
Unknown MAC Discard
Unknown MAC discard is a feature which discards all packets ingressing the service
where the destination MAC address is not in the FDB. The normal behavior is to flood
these packets to all end points in the service.
502
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
Virtual Private LAN Service
Unknown MAC discard can be used with the disable MAC learning and disable MAC
aging options to create a fixed set of MAC addresses allowed to ingress and traverse
the service.
3.3.7.11
VPLS and Rate Limiting
Traffic that is normally flooded throughout the VPLS can be rate limited on SAP
ingress through the use of service ingress QoS policies. In a service ingress QoS
policy, individual queues can be defined per forwarding class to provide shaping of
broadcast traffic, MAC multicast traffic and unknown destination MAC traffic.
3.3.7.12
MAC Move
The MAC move feature is useful to protect against undetected loops in a VPLS
topology as well as the presence of duplicate MACs in a VPLS service.
If two clients in the VPLS have the same MAC address, the VPLS will experience a
high re-learn rate for the MAC. When MAC move is enabled, the 7450 ESS,
7750 SR, or 7950 XRS will shut down the SAP or spoke SDP and create an alarm
event when the threshold is exceeded.
MAC move allows sequential order port blocking. By configuration, some VPLS ports
can be configured as “non-blockable” which allows simple level of control which ports
are being blocked during loop occurrence. There are two sophisticated control
mechanisms that allow blocking of ports in a sequential order:
1. Configuration capabilities to group VPLS ports and to define the order they
should be blocked.
2. Criteria defining when individual groups should be blocked.
For the first, configuration CLI is extended by definition of “primary” and “secondary”
ports. Per default, all VPLS ports are considered “tertiary” ports unless they are
explicitly declared primary or secondary. The order of blocking will always follow a
strict order starting from “tertiary” to secondary and then primary.
The definition of criteria for the second control mechanism is the number of periods
during which the given re-learn rate has been exceeded. The mechanism is based
on the “cumulative” factor for every group of ports. Tertiary VPLS ports are blocked
if the re-learn rate exceeds the configured threshold during one period while
secondary ports are blocked only when re-learn rates are exceeded during two
Issue: 01
3HE 11970 AAAA TQZZA 01
503
Virtual Private LAN Service
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
consecutive periods, and so forth. The retry timeout period must be larger than the
period before blocking the “highest priority port” so it sufficiently spans across the
period required to block all ports in sequence. The period before blocking the
“highest priority port” is the cumulative factor of the highest configured port multiplied
by 5 seconds (the retry timeout can be configured through the CLI).
3.3.7.13
Auto-Learn MAC Protect
This section provides information about auto-learn-mac-protect and restrictprotected-src discard-frame features.
VPLS solutions usually involve learning of MAC addresses in order for traffic to be
forwarded to the correct SAP/SDP. If a MAC address is learned on the wrong SAP/
SDP then traffic would be re-directed away from its intended destination. This could
occur through a mis-configuration, a problem in the network or by a malicious source
creating a DOS attack and is applicable to any type of VPLS network, for example
mobile backhaul or residential service delivery networks. auto-learn-mac-protect
can be used to safe-guard against the possibility of MAC addresses being learned
on the wrong SAP/SDP.
This feature provides the ability to automatically protect source MAC addresses
which have been learned on a SAP or a spoke/mesh SDP and prevent frames with
the same protected source MAC address from entering into a different SAP/spoke or
mesh SDP.
This is a complementary solution to features such as mac-move and mac-pinning,
but has the advantage that MAC moves are not seen and it has a low operational
complexity. It should be noted that if a MAC is initially learned on the wrong SAP/
SDP, the operator can clear the MAC from the MAC FDB in order for it to be relearned on the correct SAP/SDP.
Two separate commands are used which provide the configuration flexibility of
separating the identification (learning) function from the application of the restriction
(discard).
The auto-learn-mac-protect and restrict-protected-src commands allow the
following functions:
• The ability to enable the automatic protection of a learned MAC using the autolearn-mac-protect command under a SAP/spoke or mesh SDP/SHG contexts.
504
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
Virtual Private LAN Service
• The ability to discard frames associated with automatically protected MACs
instead of shutting down the entire SAP/SDP as with the restrict-protected-src
feature. This is enabled using a restrict-protected-src discard-frame command
in the SAP/spoke or mesh SDP/ SHG context. An optimized alarm mechanism
is used to generate alarms related to these discards. The frequency of alarm
generation is fixed to be at most one alarm per MAC address per forwarding
complex per 10 minutes in a given VPLS service.
Note, if auto-learn-mac-protect or restrict-protected-src discard-frame is configured
under an SHG the operation applies only to SAPs in the SHG not to spoke SDPs in
the SHG. If required, these parameters can also be enabled explicitly under specific
SAPs/spoke SDPs within the SHG.
Applying or removing auto-learn-mac-protect or restrict-protected-src discard-frame
to/from a SAP, spoke or mesh SDP or SHG, will clear the MACs on the related
objects (for the SHG, this results in clearing the MACs only on the SAPs within the
SHG).
The use of restrict-protected-src discard-frame is mutually exclusive with both the
restrict-protected-src [alarm-only] command and with the configuration of manually
protected MAC addresses, using the mac-protect command, within a given VPLS.
The following rules govern the changes to the state of protected MACs:
• Automatically learned protected MACs are subject to normal removal, aging
(unless disabled) and flushing at which time the associated entries are removed
from the FDB.
• Automatically learned protected MACs can only move from their learned SAP/
spoke or mesh SDP if they enter a SAP/spoke or mesh SDP without restrictprotected-src enabled.
If a MAC address does legitimately move between SAPs/spoke or mesh SDPs after
it has been automatically protected on a given SAP/spoke or mesh SDP (thereby
causing discards when received on the new SAP/spoke or mesh SDP), the operator
must manually clear the MAC from the FDB for it to be learned in the new/correct
location.
MAC addresses that are manually created (using static-mac, static-host with a MAC
address specified or oam mac-populate) will not be protected even if they are
configured on a SAP/x SDP that has auto-learn-mac-protect enabled on it. Also, the
MAC address associated with a routed VPLS IP interface is protected within its VPLS
service such that frames received with this MAC address as the source address are
discarded (this is not based on the auto-learn MAC protect function). However,
VRRP MAC addresses associated with a routed VPLS IP interface are not protected
either in this way or using the auto-learn MAC protect function.
Issue: 01
3HE 11970 AAAA TQZZA 01
505
Virtual Private LAN Service
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
MAC addresses that are dynamically created (learned, using static-host with no MAC
address specified or lease-populate) will be protected when the MAC address is
“learned” on a SAP/x- SDP that has auto-learn-mac-protect enabled on it.
The actions of the following features are performed in the order listed.
1. Restrict-protected-src
2. MAC-pinning
3. MAC-move
3.3.7.13.1
Operation
Figure 62 shows a specific configuration using auto-learn-mac-protect and
restrict-protected-src discard-frame in order to describe their operation for the
7750 SR, 7450 ESS, or 7950 XRS.
Figure 62
Auto-Learn-Mac-Protect Operation
ALMP
SAP3
SAP1
RPS + DF
ALMP
SAP2
RPS + DF
SDP2
VPLS
SDP1
ALMP
RPS + DF
ALMP
RPS + DF
auto-learned-mac-protect
restrict-protected-src discard-frame
OSSG698
A VPLS service is configured with SAP1 and SDP1 connecting to access devices
and SAP2, SAP3 and SDP2 connecting to the core of the network. auto-learn-macprotect is enabled on SAP1, SAP3 and SDP1 and restrict-protected-src discardframe is enabled on SAP1, SDP1 and SDP2. The following series of events describe
the details of the functionality:
Assume that the FDB is empty at the start of each sequence.
Sequence 1:
506
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
Virtual Private LAN Service
1. A frame with source MAC A enters SAP1, MAC A is learned on SAP1 and MACA/SAP1 is protected because of the presence of the auto-learn-mac-protect on
SAP1.
2. All subsequent frames with source MAC A entering SAP1 are forwarded into the
VPLS.
3. Frames with source MAC A enter either SDP1 or SDP2, these frames are
discarded and an alarm indicating MAC A and SDP1/SDP2 is initiated because
of the presence of the restrict-protected-src discard-frame on SDP1/SDP2.
4. The above continues, with MAC-A/SAP1 protected in the FDB until MAC A on
SAP1 is removed from the FDB.
Sequence 2:
1. A frame with source MAC A enters SAP1, MAC A is learned on SAP1 and MACA/SAP1 is protected because of the presence of the auto-learn-mac-protect on
SAP1.
2. A frame with source MAC A enters SAP2. As restrict-protected-src is not
enabled on SAP2, MAC A is re-learned on SAP2 (but not protected), replacing
the MAC-A/SAP1 entry in the FDB.
3. All subsequent frames with source MAC A entering SAP2 are forwarded into the
VPLS. This is because restrict-protected-src is not enabled SAP2 and autolearn-mac-protect is not enabled on SAP2, so the FDB would not be changed.
4. A frame with source MAC A enters SAP1, MAC A is re-learned on SAP1 and
MAC-A/SAP1 is protected because of the presence of the auto-learn-macprotect on SAP1.
Sequence 3:
1. A frame with source MAC A enters SDP2, MAC A is learned on SDP2 but is not
protected as auto-learn-mac-protect is not enabled on SDP2.
2. A frame with source MAC A enters SDP1, MAC A is re-learned on SDP1 as
previously it was not protected. Consequently, MAC-A/SDP1 is protected
because of the presence of the auto-learn-mac-protect on SDP1.
Sequence 4:
1. A frame with source MAC A enters SAP1, MAC A is learned on SAP1 and MACA/SAP1 is protected because of the presence of the auto-learn-mac-protect on
SAP1.
2. A frame with source MAC A enters SAP3. As restrict-protected-src is not
enabled on SAP3, MAC A is re-learned on SAP3 and the MAC-A/SAP1 entry is
removed from the FDB with MAC-A/SAP3 being added as protected to the FDB
(because auto-learn-mac-protect is enabled on SAP3).
Issue: 01
3HE 11970 AAAA TQZZA 01
507
Virtual Private LAN Service
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
3. All subsequent frames with source MAC A entering SAP3 are forwarded into the
VPLS.
4. A frame with source MAC A enters SAP1, these frames are discarded and an
alarm indicating MAC A and SAP1 is initiated because of the presence of the
restrict-protected-src discard-frame on SAP1.
Example Use
Figure 63 shows a possible configuration using auto-learn-mac-protect and
restrict-protected-src discard-frame in a mobile backhaul network, with the focus
on PE1 for the 7750 SR or 7950 XRS.
Figure 63
Auto-Learn-Mac-Protect Example
eNodeB MAC Addresses Are Not
Allowed to Enter a Different SAP
Once Protected
SAP1
BNG/RNC MAC Addresses
Cannot Be Spoofed Via the
eNodeBs
ALMP
ALMP
RPS+DF
RPS+DF
e PW
Activ
PE2
VPLS 40
SAP1
RNC/BNG
VPLS 40
ALMP
RPS+DF
ALMP
PE1
RPS+DF
Stand
by PW
VPLS 40
SAP2
SAP1
RNC/BNG
PE3
RPS+DF = Restrict-protected-src discard-frame
ALMP = Auto-learn-mac-protect
OSSG717
In order to protect the MAC addresses of the BNG/RNCs on PE1, auto-learn-macprotect is enabled on the pseudo-wires connecting it to PE2 and PE3. Enabling
restrict-protected-src discard-frame on the SAPs towards the eNodeBs will
prevent frames with the source MAC addresses of the BNG/RNCs from entering PE1
from the eNodeBs.
The MAC addresses of the eNodeBs are protected in two ways. In addition to the
above commands, enabling auto-learn-mac-protect on the SAPs towards the
eNodeBs will prevent the MAC addresses of the eNodeBs being learned on the
wrong eNodeB SAP. Enabling restrict-protected-src discard-frame on the pseudowires connecting PE1 to PE2 and PE3 will protect the eNodeB MAC addresses from
being learned on the pseudo-wires. This may happen if their MAC addresses are
incorrectly injected into VPLS 40 on PE2/PE3 from another eNodeB aggregation PE.
The above configuration is equally applicable to other Layer 2 VPLS based
aggregation networks, for example to business or residential service networks.
508
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
3.3.8
Virtual Private LAN Service
Split Horizon SAP Groups and Split Horizon Spoke
SDP Groups
Within the context of VPLS services, a loop-free topology within a fully meshed VPLS
core is achieved by applying a split-horizon forwarding concept that packets received
from a mesh SDP are never forwarded to other mesh SDPs within the same service.
The advantage of this approach is that no protocol is required to detect loops within
the VPLS core network.
In applications such as DSL aggregation, it is useful to extend this split-horizon
concept also to groups of SAPs and/or spoke SDPs. This extension is referred to as
a split horizon SAP group or residential bridging.
Traffic arriving on a SAP or a spoke SDP within a split horizon group will not be
copied to other SAPs and spoke SDPs in the same split horizon group (but will be
copied to SAPs / spoke SDPs in other split horizon groups if these exist within the
same VPLS).
3.3.9
VPLS and Spanning Tree Protocol
Nokia’s VPLS service provides a bridged or switched Ethernet Layer 2 network.
Equipment connected to SAPs forward Ethernet packets into the VPLS service. The
7450 ESS, 7750 SR, or 7950 XRS participating in the service learns where the
customer MAC addresses reside, on ingress SAPs or ingress SDPs.
Unknown destinations, broadcasts, and multicasts are flooded to all other SAPs in
the service. If SAPs are connected together, either through misconfiguration or for
redundancy purposes, loops can form and flooded packets can keep flowing through
the network. Nokia’s implementation of the Spanning Tree Protocol (STP) is
designed to remove these loops from the VPLS topology. This is done by putting one
or several SAPs and/or spoke SDPs in the discarding state.
Nokia’s implementation of the Spanning Tree Protocol (STP) incorporates some
modifications to make the operational characteristics of VPLS more effective.
The STP instance parameters allow the balancing between resiliency and speed of
convergence extremes. Modifying particular parameters can affect the behavior. For
information on command usage, descriptions, and CLI syntax, refer to Configuring a
VPLS Service with CLI.
Issue: 01
3HE 11970 AAAA TQZZA 01
509
Virtual Private LAN Service
3.3.9.1
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
Spanning Tree Operating Modes
Per VPLS instance, a preferred STP variant can be configured. The STP variants
supported are:
• rstp — Rapid Spanning Tree Protocol (RSTP) compliant with IEEE 802.1D2004 - default mode
• dot1w — Compliant with IEEE 802.1w
• comp-dot1w — Operation as in RSTP but backwards compatible with IEEE
802.1w (this mode allows interoperability with some MTU types)
• mstp — Compliant with the Multiple Spanning Tree Protocol specified in IEEE
802.1Q-REV/D5.0-09/2005. This mode of operation is only supported in an
mVPLS.
While the 7450 ESS, 7750 SR, or 7950 XRS initially use the mode configured for the
VPLS, it will dynamically fall back (on a per-SAP basis) to STP (IEEE 802.1D-1998)
based on the detection of a BPDU of a different format. A trap or log entry is
generated for every change in spanning tree variant.
Some older 802.1W compliant RSTP implementations may have problems with
some of the features added in the 802.1D-2004 standard. Interworking with these
older systems is improved with the comp-dot1w mode. The differences between the
RSTP mode and the comp-dot1w mode are:
• The RSTP mode implements the improved convergence over shared media
feature, for example, RSTP will transition from discarding to forwarding in 4
seconds when operating over shared media. The comp-dot1w mode does not
implement this 802.1D-2004 improvement and transitions conform to 802.1w in
30 seconds (both modes implement fast convergence over point-to-point links).
• In the RSTP mode, the transmitted BPDUs contain the port's designated priority
vector (DPV) (conforms to 802.1D-2004). Older implementations may be
confused by the DPV in a BPDU and may fail to recognize an agreement BPDU
correctly. This would result in a slow transition to a forwarding state (30
seconds). For this reason, in the comp-dot1w mode, these BPDUs contain the
port's port priority vector (conforms to 802.1w).
The 7450 ESS, 7750 SR, and 7950 XRS support two BDPU encapsulation formats,
and can dynamically switch between the following supported formats (on a per-SAP
basis):
• IEEE 802.1D STP
• Cisco PVST
510
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
3.3.9.2
Virtual Private LAN Service
Multiple Spanning Tree
The Multiple Spanning Tree Protocol (MSTP) extends the concept of the IEEE
802.1w Rapid Spanning Tree Protocol (RSTP) by allowing grouping and associating
VLANs to Multiple Spanning Tree Instances (MSTI). Each MSTI can have its own
topology, which provides architecture enabling load balancing by providing multiple
forwarding paths. At the same time, the number of STP instances running in the
network is significantly reduced as compared to Per VLAN STP (PVST) mode of
operation. Network fault tolerance is also improved because a failure in one instance
(forwarding path) does not affect other instances.
The Nokia implementation of Management VPLS (mVPLS) is used to group different
VPLS instances under single RSTP instance. Introducing MSTP into the mVPLS
allows interoperating with traditional Layer 2 switches in access network and
provides an effective solution for dual homing of many business Layer 2 VPNs into
a provider network.
3.3.9.2.1
Redundancy Access to VPLS
The GigE MAN portion of the network is implemented with traditional switches. Using
MSTP running on individual switches facilitates redundancy in this part of the
network. In order to provide dual homing of all VPLS services accessing from this
part of the network, the VPLS PEs must participate in MSTP.
This can be achieved by configuring mVPLS on VPLS-PEs (only PEs directly
connected to GigE MAN network) and then assign different managed-vlan ranges to
different MSTP instances. Typically, the mVPLS would have SAPs with null
encapsulations (to receive, send, and transmit MSTP BPDUs) and a mesh SDP to
interconnect a pair of VPLS PEs.
Different access scenarios are displayed in Figure 64 as example network diagrams
dually connected to the PBB PEs:
• Access Type A — Source devices connected by null or Dot1q SAPs
• Access Type B — One QinQ switch connected by QinQ/801ad SAPs
• Access Type C — Two or more ES devices connected by QinQ/802.1ad SAPs
Issue: 01
3HE 11970 AAAA TQZZA 01
511
Virtual Private LAN Service
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
Figure 64
Access Resiliency
7x50
6
5
B
B
CS
PBB
7x50
B
B
1
Null/dot1q
B
2
A
AS
4
C
802.1ad/QinQ
B
B
3
ES
CE
CE
CE
CE
Metro Network
OSSG205
The following mechanisms are supported for the I-VPLS:
• STP/RSTP can be used for all access types.
• M-VPLS with MSTP can be used as is just for access Type A. MSTP is required
for access type B and C.
• LAG and MC-LAG can be used for access Type A and B.
• Split-horizon-group does not require residential.
PBB I-VPLS inherits current STP configurations from the regular VPLS and MVPLS.
3.3.9.3
MSTP for QinQ SAPs
MSTP runs in a MVPLS context and can control SAPs from source VPLS instances.
QinQ SAPs are supported. The outer tag is considered by MSTP as part of VLAN
range control.
512
3HE 11970 AAAA TQZZA 01
Issue: 01
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
3.3.9.4
Virtual Private LAN Service
Provider MSTP
Provider MSTP is specified in (IEEE-802.1ad-2005). It uses a provider bridge group
address instead of a regular bridge group address used by STP, RSTP, MSTP
BPDUs. This allows for implicit separation of source and provider control planes.
The 802.1ad access network sends PBB PE P-MSTP BPDUs using the specified
MAC address and also works over QinQ interfaces. P-MSTP mode is used in PBBN
for core resiliency and loop avoidance.
Similar to regular MSTP, the STP mode (for example, PMSTP) is only supported in
VPLS services where the m-VPLS flag is configured.
3.3.9.4.1
MSTP General Principles
MSTP represents modification of RSTP which allows the grouping of different VLANs
into multiple MSTIs. To enable different devices to participate in MSTIs, they must
be consistently configured. A collection of interconnected devices that have the
same MST configuration (region-name, revision and VLAN-to-instance assignment)
comprises an MST region.
There is no limit to the number of regions in the network, but every region can support
a maximum of 16 MSTIs. Instance 0 is a special instance for a region, known as the
Internal Spanning Tree (IST) instance. All other instances are numbered from 1 to
4094. IST is the only spanning-tree instance that sends and receives BPDUs
(typically BPDUs are untagged). All other spanning-tree instance information is
included in MSTP records (M-records), which are encapsulated within MSTP
BPDUs. This means that single BPDU carries information for multiple MSTI which
reduces overhead of the protocol.
Any given MSTI is local to an MSTP region and completely independent from an
MSTI in other MST regions. Two redundantly connected MST regions will use only a
single path for all traffic flows (no load balancing between MST regions or between
MST and SST region).
Traditional Layer 2switches running MSTP protocol assign all VLANs to the IST
instance per default. The operator may then “re-assign” individual VLANs to a given
MSTI by configuring per VLAN assignment. This means that a SR-Series PE can be
considered as the part of the same MST region only if the VLAN assignment to IST
and MSTIs is identical to the one of Layer 2 switches in access network.
Issue: 01
3HE 11970 AAAA TQZZA 01
513
Virtual Private LAN Service
3.3.9.4.2
LAYER 2 SERVICES AND EVPN GUIDE: VLL,
VPLS, PBB, AND EVPN
MSTP in the SR-Series Platform
The SR-Series platform uses a concept of mVPLS to group different SAPs under a
single STP instance. The VLAN range covering SAPs to be managed by a given
mVPLS is declared under a specific mVPLS SAP definition. MSTP mode-ofoperation is only supported in an mVPLS.
When running MSTP, by default, all VLANs are mapped to the CIST. On the VPLS
level VLANs can be assigned to specific MSTIs. When running RSTP, the operator
must explicitly indicate, per SAP, which VLANs are managed by that SAP.
3.3.9.5
Enhancements to the Spanning Tree Protocol
To interconnect 7450 ESS or 7750 SR OS (PE devices) across the backbone,
service tunnels (SDPs) are used. These service tunnels are shared among multiple
VPLS instances. Nokia’s implementation of the Spanning Tree Protocol (STP)
incorporates some enhancements to make the operational characteristics of VPLS
more effective. The implementation of STP on the router is modified in order to
guarantee that service tunnels will not be blocked in any circumstance without
imposing artificial restrictions on the placement of the root bridge within the network.
The modifications introduced are fully compliant with the 802.1D-2004 STP
specification.
When running MSTP, spoke SDPs cannot be configured. Also, ensure that all
bridges connected