3.7. Configuring a VLL Service with CLI
This section describes how to configure Virtual Leased Line (VLL) services using the command line interface.
3.7.1. Basic Configurations
3.7.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:
- 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).
- Enable the service.
3.7.2.1. Creating an Epipe Service for 7210 SAS-D
Use the following syntax to create an Epipe service.
The following is a sample Epipe configuration output:
3.7.2.2. Creating an Epipe Service for 7210 SAS-Dxp
Use the following syntax to create an Epipe service.
The following is a sample Epipe configuration output:
3.7.2.3. Creating an Epipe Service with Range SAPs
The following is a sample connection profile used to configure a range of SAPs and an Epipe configuration using the connection profile:
3.7.2.4. Creating an Epipe Service for 7210 SAS-K 2F1C2T
Use the following syntax to create an Epipe service.
The following is a sample Epipe configuration output:
3.7.2.5. Creating an Epipe Service for 7210 SAS-K 2F1C2T with Range SAPs
The following is a sample connection profile used to configure a range of SAPs and an Epipe configuration using the connection profile:
3.7.2.5.1. Configuring Epipe SAP Parameters
A default QoS policy is applied to each ingress SAP. and a default access egress QoS policy is applied on the port where SAP is egressing. The access egress QoS policy is common to all SAPs on that port. 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.7.2.5.1.1. 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 SAP configuration output for local Epipe service 500 on SAP 1/1/2 and SAP 1/1/3 on ALA-1:
The following are sample SAP configurations output for ALA-1 and ALA-2:
3.7.2.5.2. Distributed Epipe Service
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 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 shows the command usage to configure a distributed service between ALA-1 and ALA-2:
The following are sample SAP configuration outputs for ALA-1 and ALA-2:
3.7.2.5.3. Configuring SDP Bindings
Figure 38 displays 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 38: 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:
3.7.2.5.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. 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. 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:
Use the following syntax to disable the control word on spoke-sdp 1:2001.
3.7.2.5.5. Configuring Ingress and Egress 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 are sample SAP ingress and egress parameters:
The following is a sample Epipe SAP ingress and egress configuration output:
3.7.2.5.6. Configuring VLL Resilience
Figure 39 displays an example to create VLL resilience. The zero revert-time value means that the VLL path will be switched back to the primary immediately after it comes back up.
Figure 39: VLL Resilience
PE1
The following is a sample configuration output on PE1(a 7210 SAS-K 2F6C4T node):
3.7.2.5.7. Configuring VLL Resilience for a Switched Pseudowire Path
Figure 40 shows an example of VLL resilience with pseudowire switching.
Figure 40: VLL Resilience with Pseudowire Switching
T-PE1
The following is a sample configuration output on TPE1 (which can be a 7210 SAS-K 2F6C4T or 7210 SAS-K 3SFP+ 8C):
T-PE2
The following is a sample configuration output on TPE2:
S-PE1
The following is a sample configuration output on S-PE1:
3.7.2.6. Configuring Default QinQ SAPs for Epipe Transit Traffic in a Ring Scenario in Access-uplink Mode
Figure 41: Default QinQ SAP for Transit Traffic in a Ring Scenario
In Figure 41, 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 (example – traffic from 7210-2 to 7210-3 OR from 7210-2 to 7750 –SR onto the core network).
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 are the sample configuration commands in this scenario:
3.7.3. Service Management Tasks
This section describes the Epipe service management tasks.
3.7.3.1. 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.7.3.2. Disabling an Epipe Service
Use the following syntax to shut down an Epipe service without deleting the service parameters.
3.7.3.3. Re-Enabling an Epipe Service
Use the following syntax to re-enable an Epipe service that was shut down.
3.7.3.4. 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.