Appendix A: Service Template Configuration
Overview
The Service Template mechanism in OcNOS (supported up to version 6.6.0) was introduced to simplify Layer 2 VPN (L2VPN) service deployment by decoupling traffic classification logic (such as VLAN matching) from physical interface configurations. A service-template could be applied to multiple interfaces, enabling consistent and reusable provisioning across access ports in VPWS, VPLS, and other L2VPN scenarios.
Starting with OcNOS version 7.0.0, sub-interfaces replace Service Templates as the preferred configuration method. While legacy Service Template configurations remain functional, the associated commands are now hidden and will be completely removed in a future release. To ensure future-proofing and continued manageability, please migrate all existing Service Templates to sub-interfaces.
Purpose and Function
Service Templates enabled:
|
•
|
Centralized VLAN matching and classification logic that could be applied across multiple interfaces. |
|
•
|
A method to bind L2VPN services (e.g., VPWS or VPLS) to access interfaces based on tag criteria, such as untagged, single-tagged, or double-tagged (Q-in-Q) traffic. |
|
•
|
mpls-l2-circuit for VPWS |
|
•
|
mpls-vpls or vpls-instance for VPLS |
|
•
|
Under the context of switchport interfaces |
Typical Use Cases
Service Templates were commonly used in the following scenarios:
|
•
|
Virtual Private Wire Service (VPWS): For point-to-point pseudowire configurations between two PE routers. |
|
•
|
Virtual Private LAN Service (VPLS): For multipoint Layer 2 VPN services spanning multiple sites. |
|
•
|
VPLS Service Mapping: Including static, LDP-signaled, and BGP-signaled VPLS instances using various tag matching schemes. |
Common Syntax Patterns
This section provides typical examples of Service Template-based configurations used in VPLS and VPWS deployments in OcNOS versions up to 6.6.0. These patterns demonstrate how various service scenarios were modeled using service templates, including handling of untagged traffic, VLAN-tagged traffic, and VLAN tag rewrites.
VPLS – Untagged Interface Configuration
In this example, a basic service template without any match condition is used to identify untagged traffic on the access port.
Copy
service-template <service template name>
!
mpls vpls <vpls instance name> <vpls id>
signaling ldp
vpls-type <encapsulation type>
vpls-peer <far end peer address>
exit-signaling
exit-vpls
!
interface xe21
switchport
mpls-vpls <vpls instance name> service-template <service template name>
exit-if-vpls
!
VPLS – VLAN Tagged Interface Configuration
Here, the service template matches traffic based on a single VLAN tag (outer VLAN). This is used for identifying tagged access traffic.
Copy
service-template <service template name>
match outer-vlan <vlan tag>
!
mpls vpls <vpls instance name> <vpls id>
signaling ldp
vpls-type <encapsulation type>
vpls-peer <far end peer address>
exit-signaling
exit-vpls
!
interface xe21
switchport
mpls-vpls <vpls instance name> service-template <service template name>
exit-if-vpls
!
VPLS – VLAN Tagged Interface with Rewrite
This example includes both a VLAN tag match and a rewrite directive. It translates the ingress VLAN tag to a new value before forwarding.
Copy
service-template <service template name>
match outer-vlan <vlan tag>
rewrite ingress translate <new vlan tag value to change to> outgoing-tpid dot1.q
!
mpls vpls <vpls instance name> <vpls id>
signaling ldp
vpls-type <encapsulation type>
vpls-peer <far end peer address>
exit-signaling
exit-vpls
!
interface xe21
switchport
mpls-vpls <vpls instance name> service-template <service template name>
exit-if-vpls
!
VPWS – Untagged Interface Configuration
This is a standard point-to-point L2 circuit configuration for untagged traffic using a service template.
Copy
service-template <service template name>
match untagged
!
mpls l2-circuit <vpws name> <virtual circuit ID number> <far end neighbor>
!
interface xe21
switchport
mpls-l2-circuit <vpws name> service-template <service template name> primary
!
VPWS – VLAN Tagged Interface Configuration
This example uses a VLAN match to associate tagged ingress traffic with a VPWS instance.
Copy
service-template <service template name>
match outer-vlan <vlan tag>
!
mpls l2-circuit <vpws name> <virtual circuit ID number> <far end neighbor>
!
interface xe21
switchport
mpls-l2-circuit <vpws name> service-template <service template name> primary
!
VPWS – VLAN Tagged Interface with Rewrite
This pattern includes VLAN tag rewriting on ingress, which is useful in service provider environments requiring normalization or mapping of customer VLANs.
Copy
service-template <service template name>
match outer-vlan <vlan tag>
rewrite ingress translate <new vlan tag value to change to> outgoing-tpid dot1.q
!
mpls l2-circuit <vpws name> <virtual circuit ID number> <far end neighbor>
!
interface xe21
switchport
mpls-l2-circuit <vpws name> service-template <service template name> primary
!
Documentation Reference
For detailed service-template configuration procedures in different service types, refer to the following sections in the Layer 2 Virtual Private Network Configuration in the OcNOS 6.5.x MPLS document:
Migration from Service Template to Sub-interface Configuration
Applicability: OcNOS Release 6.6.1 and later
Starting with OcNOS version 6.6.1, we would like to recommend using the sub-interface-based configuration model for MPLS Layer 2 VPN services, including VPLS and VPWS. We are phasing out the support for the traditional Service Template based configurations and would like to provide a migration plan. While existing functionality for service templates will continue to be available in OcNOS 6.6.1, the related commands and configuration procedures have been removed from the documentation to encourage migration to sub-interface-based service binding. This change aligns with our intent of providing a more manageable and operationally usable sub-interface-based configuration model to our OcNOS customer base.
Although service-template-based functionality continues to be available in 6.6.1, customers are advised to begin transitioning existing deployments to sub-interface-based configurations.
Guidance
When upgrading from an earlier release (prior to 6.6.1), review all configurations that use service-template under mpls-l2-circuit or mpls-vpls, and reconfigure them using sub-interfaces with appropriate VLAN encapsulation.
Key Capabilities
|
•
|
Sub-interfaces (e.g., xe21.1, xe21.100) are created to handle encapsulation (e.g., untagged, outer-vlan). |
|
•
|
The access-if-vpws or access-if-vpls context is used to bind services directly to the sub-interface. |
|
•
|
This model improves operational clarity and scalability. |
Example
VPWS Sub-interface-based Configuration (Recommended):
Copy
interface xe1
no switchport
no mpls-l2-circuit <vpws name>
exit
commit
interface xe1.1 switchport
encapsulation untagged
access-if-vpws
mpls-l2-circuit <vpws name> primary
exit
commit
VPWS Service Template-based Configuration:
Copy
service-template <service template name>
match untagged
!
mpls l2-circuit <vpws name> <virtual circuit ID number> <far end neighbor>
!
interface xe1
switchport
mpls-l2-circuit <vpws name> service-template <service template name> primary
!
VPLS Sub-interface-based Configuration (Recommended):
Copy
interface xe1
no switchport
no mpls-vpls <vpls instance name> service-template <service template name>
exit
Commit
interface xe1.1 switchport
encapsulation untagged
access-if-vpls
mpls-vpls <vpls instance name>
exit
commit
VPLS Service Template-based Configuration:
Copy
service-template <service template name>
!
mpls vpls <vpls instance name> <vpls id>
signaling ldp
vpls-type <encapsulation type>
vpls-peer <far end peer address>
exit-signaling
exit-vpls
!
interface xe1
switchport
mpls-vpls <vpls instance name> service-template <service template name>
exit-if-vpls
!
It is highly recommended to migrate your Service Template configurations to sub-interfaces prior to the upgrade. Following the upgrade, the Service Template CLI commands will be hidden and no longer accessible for configuration. Refer to the table below for the configuration changes before and after upgrade.
| |
Before Upgrade from 6.6.1 |
After Upgrade to 7.0 |
| Service Template Configuration |
Copy
!
service-template st1
!
service-template st2
!
interface xe8
mpls-l2-circuit t1 service-template st1 primary
!
interface xe5
vc-mode revertive service-template st3
mpls-vpls vpls1 service-template st2
!
|
Copy
!
interface xe8
!
interface xe5
!
|