3.9. Configuring a VLL Service with CLI
This section describes how to configure Virtual Leased Line (VLL) services using the command line interface.
3.9.1. 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.
- Associate the service with a customer ID.
- Define SAP parameters.
- (Optional) Select ingress QoS policies (configured in the config>qos context).
- (Optional) Select accounting policy (configured in the config>log context).
- Define spoke-SDP parameters.
Note: Spoke-SDP parameters are only supported on 7210 SAS platforms operating in the network mode.
- Enable the service.
3.9.2. Configuring VLL Components
This section provides VLL configuration examples for the VLL services.
3.9.2.1. Creating a Cpipe Service
This section provides information about creating a Cpipe service.
3.9.2.1.1. Basic Configuration
The following fields require specific input (there are no defaults) to configure a basic Cpipe service:
- customer ID
- interface parameters
- spoke-SDP parameters
The following is a sample configuration of a Cpipe service:
Use the following syntax to create a Cpipe service. A route distinguisher must be defined in order for Cpipe to be operationally active.
The following is a sample Cpipe service configuration output:
3.9.2.1.2. Configuration Requirements
Before a Cpipe service can be provisioned, the following tasks must be completed:
3.9.2.1.2.1. Configuring a DS1 Port
The following is a sample DS1 port configured for CES:
3.9.2.1.2.2. Configuring a Channel Group
The following is a sample DS1 channel group configured for CES:
3.9.2.1.3. Configuring Cpipe SAPs and Spoke-SDPs
The following is a sample Cpipe SAP and spoke-SDP configuration output:
3.9.2.2. Creating an Epipe Service in Network Mode
Use the following syntax to create an Epipe service.
The following is a sample Epipe configuration output:
3.9.2.3. Creating an Epipe Service in Access-uplink Mode
| Note: This section only applies to 7210 SAS-M and 7210 SAS-T operating in access-uplink mode. |
Use the following syntax to create an Epipe service.
3.9.2.3.1. Configuring Epipe SAP Parameters
A default QoS policy is applied to each ingress 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.
3.9.2.3.1.1. Epipe SAP
3.9.2.3.1.2. 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 service SAPS. Existing filter policies or other existing QoS policies can be associated with service SAPs on ingress and egress ports.
Ingress and egress SAP parameters can be applied to local and distributed Epipe service SAPs.
The following is a sample of SAP configurations for local Epipe service 500 on SAP 1/1/2 and SAP 1/1/3 on ALA-1:
3.9.2.3.1.3. Distributed Epipe Service
| Note: SDPs are supported on all 7210 SAS platforms as described in this document, except those operating in access-uplink mode. |
To configure a distributed Epipe service, you must configure service entities on the originating and far-end nodes. You must use the same service ID on both ends (for example, Epipe 5500 on ALA-1 and Epipe 5500 on ALA-2). The spoke-sdp sdp-id: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 service SAPs. On egress, QoS policies are associated with a port. Existing filter policies can be associated with service SAPs on ingress and egress.
Meters (defined in SAP-ingress policies) can be applied on ingress, which is associated with SAPs. Scheduler policies can be applied on egress, which is associated with a port.
Ingress and egress SAP parameters can be applied to local and distributed Epipe service SAPs.
For SDP configuration information, see Configuring an SDP. For SDP binding information, see Configuring SDP Bindings.
The following example configures a distributed service between ALA-1 and ALA-2:
The following is a sample of the SAP configurations for ALA-1 and ALA-2:
3.9.2.3.1.4. Configuring Ingress SAP Parameters
By default, QoS policy ID 1 is applied to ingress service SAPs. Existing filter policies or other existing QoS policies can be associated with service SAPs on ingress and egress ports.
Ingress and egress SAP parameters can be applied to local and distributed Epipe service SAPs.
The following is a sample of SAP ingress and egress parameters:
The following is a sample Epipe SAP ingress configuration output:
3.9.2.4. Creating an Epipe Service for 7210 SAS-M and 7210 SAS-Mxp with Range SAPs
The following is a sample of connection-profile used to configure a range of SAPs and an Epipe configuration output using the connection profile:
3.9.2.5. Configuring Default QinQ SAPs for Epipe Transit Traffic in a Ring Scenario in Access-uplink Mode
| Note: Default QinQ SAPs are only supported on 7210 SAS platforms operating in the access-uplink mode. |
In Figure 38, 7210-1 is used to deliver some services to customers connected to the device, and additionally it needs to pass through transit from other nodes on the ring (for example, traffic from 7210-2 to 7210-3 or from 7210-2 to 7750-SR onto the core network).
Figure 38: Default QinQ SAP for Transit Traffic in a Ring Scenario
Without default QinQ SAPs, the user would need to configure a service on 7210-1, with access-uplink SAPs for each service originating on some other node in the ring. With support for default QinQ SAPs, all traffic that does not need to be delivered to any customer service configured on 7210-1 can be switched using the Epipe service.
The following is a sample configuration output:
3.9.2.5.1. Configuring SDP Bindings
| Note: SDPs are supported on all 7210 SAS platforms as described in this document, except those operating in access-uplink mode. |
Figure 39 shows an example of a distributed Epipe service configuration between two routers, identifying the service and customer IDs, and the unidirectional 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.
Figure 39: SDPs — Unidirectional Tunnels
Use the following syntax to create a spoke-SDP binding with an Epipe service.
The following shows the command usage to bind an Epipe service between ALA-1 and ALA-2. This example assumes that the SAPs have already been configured (see Distributed Epipe Service).
The following is a sample SDP binding for the Epipe service between ALA-1 and ALA-2 configuration output:
3.9.3. Using Spoke-SDP Control Words
| Note: SDPs are supported on all 7210 SAS platforms as described in this document, except those operating in access-uplink mode. |
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. On the 7210 SAS, an option is provided to enable it for Ethernet PW (Epipe). The control word might be needed because when ECMP is enabled on the network, packets of a specific PW 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.
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, the router alert label is used. In that case, VCCV CC type 2 is signaled. Note that for a multi-segment PW (MS-PW), the CC type 1 is the only type supported, and therefore the control word must be enabled on the spoke-SDP to be able to use VCCV-ping and VCCV-trace.
The following is a sample spoke-SDP control word configuration output:
3.9.4. Configuring VLL Resilience
Figure 40 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 40: VLL Resilience
PE1
The following is a sample configuration output on PE1:
3.9.5. Configuring VLL Resilience for a Switched Pseudowire Path
Figure 41 shows VLL resilience with pseudowire switching.
Figure 41: VLL Resilience with Pseudowire Switching
T-PE1
The following is a sample configuration output on TPE1:
T-PE2
The following is a sample configuration output on TPE2:
S-PE1
The following is a sample configuration output on S-PE1:
3.9.6. Service Management Tasks
This section provides information about VLL service management tasks.
3.9.6.1. Modifying a Cpipe Service
The following is a sample Cpipe service configuration output:
3.9.6.2. Deleting a Cpipe Service
A Cpipe service cannot be deleted until SAPs are shut down and deleted. If a spoke-SDP is defined, it must be shut down and removed from the configuration as well.
Use the following syntax to delete a Cpipe service.
3.9.6.3. Modifying Epipe Service Parameters
The following shows the command usage to add an accounting policy to an existing SAP.
The following is a sample SAP configuration output:
3.9.6.4. Disabling an Epipe Service
Use the following syntax to shut down an Epipe service without deleting the service parameters.
3.9.6.5. Re-Enabling an Epipe Service
Use the following syntax to re-enable an Epipe service that was shut down.
3.9.6.6. Deleting an Epipe Service
Perform the following steps before deleting an Epipe service.
- Shut down the SAP.
- Delete the SAP.
- Shut down the service.
Use the following syntax to delete an Epipe service.