VLL services

This chapter provides information about Virtual Leased Line (VLL) services and implementation notes.

Epipe

This section provides information about the Epipe service and implementation notes.

Epipe service overview

An Epipe service is a Layer 2 point-to-point service where the customer data is encapsulated and transported across a service provider's network. An Epipe service is completely transparent to the subscriber's data and protocols. The 7210 SAS 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.

The following support is available on different platforms:

  • The 7210 SAS-D, 7210 SAS-Dxp, and 7210 SAS-K 2F1C2T support only local Epipe services. The 7210 SAS-D provide null, QinQ SAPs and dot1q SAPs to provide point-point Layer 2 local services.

  • The 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C support both local and distributed Epipe services. The platforms provide null, QinQ SAPs and dot1q SAPs to provide a point-point Layer 2 local and distributed service. The platforms support the use of MPLS tunnels for distributed services.

Each SAP configuration includes a specific port on which service traffic enters the 7210 SAS 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, a unique encapsulation value (ID) must be specified.

Local Epipe/VLL service using access or access-uplink ports on the 7210 SAS shows a local Epipe (VLL) service using access or access-uplink ports on a 7210 SAS. Distributed Epipe/ VLL service using network ports on 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C shows a distributed Epipe (VLL) service using network ports on a 7210 SAS-K 2F6C4T or 7210 SAS-K 3SFP+ 8C.

Figure 1. Local Epipe/VLL service using access or access-uplink ports on the 7210 SAS
Figure 2. Distributed Epipe/ VLL service using network ports on 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Epipe oper state decoupling on 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, and 7210 SAS-K 3SFP+ 8C

An Epipe service transitions to an operational state of down when only a single entity SAP or binding is active and the operational state of the mate is down or displays an equivalent state. The default behavior does not allow operators to validate the connectivity and measure performance metrics. With this feature an option is provided to allow operators to validate the connectivity and measure performance metrics of an Epipe service before the customer hand-off. The operator can also maintain performance and continuity measurement across their network regardless of the connectivity between the terminating node and the customer.

If the SAP between the operator and the customer enters a Oper Down state, the Epipe remains operationally up, so the results can continue to be collected uninterrupted. The operator receives applicable port or SAP alerts/alarms. This option is available only for the customer-facing SAP failures. If a network-facing SAP or spoke-SDP fails, the operational state of the Epipe service is set to down. That is, there is no option to hold the service in an UP state, if a network component fails.

The following functionality is supported:

  • Configuration under SAP is required to change the default behavior of the Epipe service in response to the SAP failure.

  • The user can create a SAP on a LAG where the LAG has no port members. In this case, the operator configures the ‟ignore-oper-state” on the SAP and the service remains operational. However, because no ports exist in the LAG member group, there is no extraction function that can be created. This feature protects against an established working configuration with full forwarding capabilities from failing to collect PM data. The user should shutdown their equipment and place the Epipe SAP in an operationally down state.

  • The SAP connecting the provider equipment to the customer is configured to hold the Epipe service status UP when the customer-facing SAP enters any failed state. Only one SAP per Epipe is allowed to be configured.

  • Any failure of the network entity (network SAP or SDP-binding) still causes the Epipe service to transition to operationally down.

  • As the service remains operationally up, all bindings should remain operationally up and should be able to receive and transmit data. The PW status represents the failed SAP in the LDP status message, but this does not prevent the data from using the PW as a transport, in or out. This is the same as LDP status messaging.

  • The SAP failure continues to trigger normal reactions, except the operational state of the service.

  • ETH-CFM PM measurement tools (DMM/SLM) can be used with the Up MEP on the failed SAP to collect performance metric. Additionally, CFM troubleshooting tools and connectivity (LBM, LTM, AIS, CCM) can be used and will function regularly.

  • ETH-CFM CCM processing and fault propagation does not change. Even when a SAP fails with the hold service UP configuration, CCM sets the interface status TLV to down.

  • VPLS services remain operationally UP until the final entity in the service enters a failed operational state. There are no changes to VPLS services and the change is specific to Epipe.

Dynamic Multi-Segment Pseudowire routing

Note:

The 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C can only be configured as a T-PE node and not as an S-PE node.

The following sections describe the end-to-end solution with BGP PW-routing, assuming appropriate platforms are used for various functions.

Dynamic Multi-Segment Pseudowire (MS-PW) routing enables a complete MS-PW to be established, while only requiring per-pseudowire configuration on the T-PEs. No per-pseudowire 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, allowing dynamic routing of the MS-PW through the intervening network of S-PEs. Dynamic MS-PWs are described in IETF draft-ietf-pwe3-dynamic-ms-pw-13.txt.

The following figure shows the operation of dynamic MS-PWs.

Figure 3. Dynamic MS-PW operation

The FEC 129 AII Type 2 structure depicted in the following figure is used to identify each individual pseudowire endpoint.

Figure 4. MS-PW addressing using FEC129 AII Type 2

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.

This new AII type is mapped into the MS-PW BGP NLRI (a new BGP AFI of Layer 2 VPN, 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 S-PEs in the network, as shown in the following figure.

Figure 5. Advertisement of PE addresses by PW routing

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, pseudowire 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 shown in the following figure.

Figure 6. Signaling of dynamic MS-PWs using T-LDP

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 7210 SAS, the AIIs are locally configured for each spoke-SDP, according to the model shown in Mapping of AII to SAP. Therefore, the 7210 SAS 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 7. Mapping of AII to SAP

Before T-LDP signaling starts, the two T-PEs determine 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 therefore uses a statically configured PW segment, the signaling of individual segments follows the procedures already implemented in the PW switching feature.

Note:

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 four ECMP paths for each destination.

The signaling of the forward path ends when 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/inter-provider environment, as shown in the following figure.

Figure 8. VLL using dynamic MS-PWs, Inter-AS scenario
Note:

Data plane forwarding at the S-PEs uses pseudowire service label switching, as per the pseudowire switching feature.

MS-PW routing — pseudowire routing

Note:

The 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C can only be configured as a T-PE node and not as an S-PE node.

The following sections describe the end-to-end solution with BGP PW-routing, assuming appropriate platforms are used for various functions.

Each S-PE and T-PE has a pseudowire 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 specific 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.

To enable support for dynamic MS-PWs on a 7210 SAS 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 7210 SAS 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 pseudowire routing or to configure spoke-SDPs using dynamic MS-PWs at a T-PE unless an S-PE 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 pseudowire status notification sent for faults at an S-PE.

Each T-PE is also be configured with the following parameters:

  1. Global ID

    This is a 4-byte identifier that uniquely identifies an operator or the local network.

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

  3. For each local prefix, at least one 8-byte route distinguisher (RD) 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 and unique RD and community pseudowire 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 pseudowire routes is enabled for each prefix and RD, using the advertise-bgp command.

An export policy is also required 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, the preceding would export all routes. Nokia recommends enabling 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"

The local-preference parameter for iBGP and BGP communities can be configured under such a policy.

MS-PW routing — 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, this represents the default route. If a static route exists to a specific T-PE, this is used in preference to any BGP route that may exist.

MS-PW routing — 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:

It is possible to configure explicit paths independently of the configuration of BGP or static routing.

MS-PW routing — 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 pseudowire, as opposed to FEC128 (also known as the PW ID FEC) used for traditional single segment pseudowires and for pseudowire 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 pseudowire 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 - 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 pseudowire. This should be locally unique within the scope of the global-id:prefix

MS-PW routing — 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. The TT-PE 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 7210 SAS will determine which T-PE is the ST-PE (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 assumes the active role. However, it is possible to override this behavior using the signaling {master | auto} command under the spoke-sdp-fec. If master is selected at a specific T-PE, 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 autoconfiguration is used, 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.

MS-PW routing — 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 can be automatically bound to that endpoint. This is useful in scenarios where a service provider needs to separate service configuration from the service activation phase.

Automatic endpoint configuration is supported required for Epipe VLL spoke-sdp-fec endpoints bound to a VLL SAP. It is configured using the spoke-sdp-fec>auto-config command, and excludes the TAII from the configuration. When autoconfiguration is used, the node assumes passive behavior from a point of view of T-LDP signaling. Therefore, the far-end T-PE must be configured for signaling master for that spoke-sdp-fec.

MS-PW routing — 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 follows the reverse of the path of the outgoing label mapping.

A node can use explicit paths, static routes, or BGP routes to select the next hop S-PE or T-PE. The order of preference used in selecting these routes is:

  1. explicit path

  2. static route

  3. BGP route

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 the spoke-sdp-fec context.

If an explicit path name is not configured, 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 S-PE or T-PE to reach the TAII.

Pseudowire routing chooses the MS-PW path in terms of the sequence of S-PEs to use to reach a specific 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 specific pseudowire segment, an LDP SDP will be used to reach the next-hop S-PE/T-PE if such an SDP exists. If not, and an 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.

MS-PW routing — pseudowire templates

Dynamic MS-PWs support the use of the pseudowire template for specifying generic pseudowire parameters at the T-PE. The pseudowire 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 pseudowire template.

MS-PW routing — pseudowire redundancy

Pseudowire redundancy is supported on dynamic MS-PWs used for VLLs. It is configured in a similar manner to pseudowire redundancy on VLLs using FEC128, whereby each spoke-sdp FEC within an endpoint is configured with a unique SAII/TAII.

The following figure shows the use of pseudowire redundancy.

Figure 9. Pseudowire redundancy

The following is a summary of the key points to consider in using pseudowire 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 pseudowire is configured in the spoke-sdp-fec>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 specific 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.

    • Provide path diversity for each primary pseudowire through the use of a BGP RD.

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

Note:

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.

MS-PW routing — 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 pseudowire. Both the vccv-ping and vccv-trace commands support dynamic MS-PWs.

MS-PW routing — 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 explicitly specify the SAII and TAII to use, or the user can specify only the spoke-sdp-fec-id of the MS-PW in the vccv-ping command.

If the SAII:TAII is entered by the user in the vccv-ping command, those values are used for the vccv-ping echo request. However, 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 MS-PW.

Note:

If SAII:TAII is entered in addition to the spoke-sdp-fec-id, the system will verify the entered values against the values stored in the context for that spoke-sdp-fec-id. The use of spoke-sdp-fec-id in vccv-ping is only applicable at T-PE nodes, because it is not configured for a specific MS-PW at S-PE nodes.

If the SAII:TAII is not entered by the user, and if a switching point TLV was received in the initial label mapping message for the reverse direction of the MS-PW (with respect to the sending PE), the SAII:TAII to use in the target FEC stack of the vccv-ping echo request message is derived by parsing that 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 pseudowire switching point TLV was received, 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 MS-PW.

MS-PW routing — VCCV-trace on dynamic MS-PWs

The 7210 SAS supports the MS-PW path trace mode of operation for VCCV-trace, as per pseudowire switching, but using FEC129 AII type 2. As in the case of VCCV-ping, the SAII:TAII used in the vccv-trace 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:

The use of spoke-sdp-fec-id in vccv-trace is only applicable at T-PE nodes, because it is not configured for a specific MS-PW at S-PE nodes.

MS-PW routing — 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 7210 SAS nodes. The network consists of two 7210 SAS T-PEs and two 7210 playing the role of S-PEs, as shown in the following figure. Each 7210 peers with its neighbor using LDP and BGP.

Figure 10. Dynamic MS-PW example

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. The appropriate BGP export policies must also be configured.

Finally, pseudowire 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.

When 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
           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
        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

Master-slave operation

Note:

7210 SAS devices support only the standby-signaling-master option. The 7210 SAS does not support the CLI command standby-signaling-slave. In the following description, reference to the standby-signaling-slave command is only used to describe the solution. The 7210 SAS can be used only where standby-signaling-master is used in the following example.

This section describes a mechanism in which one end on a pseudowire (the ‟master”) dictates the active PW selection, which is followed by the other end of the PW (the ‟slave”). This mechanism and associated terminology is specified in RFC 6870.

This section describes master-slave pseudowire redundancy. This redundancy adds the ability for the remote peer to react to the pseudowire 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 satisfies a majority of deployments where bidirectional blocking of the forwarding on a standby spoke-SDP is required.

Master-slave pseudowire redundancy shows the operation of master-slave pseudowire redundancy. In this scenario, an Epipe service is provided between CE1 and CE2. CE2 is dual-homed to PE2 and PE3, and therefore PE1 is dual-homed to PE2 and PE3 using Epipe spoke-SDPs. The objective of this feature is to ensure that only one pseudowire 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 toward 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 11. Master-slave pseudowire redundancy

Master-slave pseudowire redundancy adds the ability for the remote peer to react to the pseudowire standby status notification, even if only one spoke-SDP terminates on the VLL endpoint on the remote peer. When the CLI command standby-signaling-slave is enabled at the spoke-SDP or explicit endpoint level in PE2 and PE3, any spoke-SDP for which the remote peer signals PW FWD standby will be blocked in the transmit direction.

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 specific peer PE signals one of the following pseudowire status bits:

  • Pseudowire 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)

That the specific spoke-SDP has been blocked will be signaled to the LDP peer through the pseudowire status bit (PW FWD standby (0x20)). This will prevent traffic being sent over this spoke-SDP by the remote peer, but only in case that remote peer supports and reacts to pseudowire status notification. Previously, this applied only if the spoke-SDP terminated 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 PW redundancy — operation of master-slave pseudowire redundancy with existing scenarios.

Note:

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 pseudowire 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 are 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 datapath.

PW redundancy — operation of master-slave pseudowire redundancy with existing scenarios

This section describes how master-slave pseudowire redundancy could operate.

PW redundancy — VLL resilience

The following figure shows a VLL resilience path example. An sample configuration follows.

Figure 12. VLL resilience path
Note:

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

VLL resilience for a switched pseudowire path

The following figure shows the use of both pseudowire redundancy and pseudowire switching to provide a resilient VLL service across multiple IGP areas in a provider network.

Figure 13. VLL resilience with PW redundancy and PW switching

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

As 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 pseudowire, 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 pseudowire 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:

It is possible that the secondary pseudowire 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 pseudowires is the same, T-PE1 will not switch the VLL path onto the secondary pseudowire upon receipt of a pseudowire status notification indicating that the remote SAP is down. This occurs because the status notification is sent over both the primary and secondary pseudowires. However, the status notification on the primary pseudowire may arrive earlier than the one on the secondary pseudowire due to the differential delay between the paths. This will cause T-PE1 to switch the path of the VLL to the secondary standby pseudowire and remain there until the status notification is cleared. At that time, the VLL path is switched back to the primary pseudowire due to the revertive behavior operation. The path will not switch back to a secondary path when it comes up, even if it has a higher precedence than the currently active secondary path.

PW redundancy — VLL resilience for a switched PW path

Note:

The 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C can only be configured as a T-PE node and not as an S-PE node.

VC-switching is not supported on the 7210 SAS-Dxp, 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, and 7210 SAS-K 3SFP+ 8C.

The following figure shows a VLL resilience for a switched pseudowire path example. A sample configuration follows.

Figure 14. VLL resilience with pseudowire switching

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 

Access node resilience using MC-LAG and pseudowire redundancy

The following figure shows the use of both Multi-Chassis Link Aggregation (MC-LAG) in the access network and pseudowire redundancy in the core network to provide a resilient end-to-end VLL service to the customers.

Figure 15. Access node resilience using MC-LAG and PW redundancy

In this application, a pseudowire status bit of active or standby indicates the status of the SAP in the MC-LAG instance in the 7210 SAS aggregation node. All spoke-SDPs are of secondary type and there is no use of a primary pseudowire type in this mode of operation.

Node A is in the active state according to its local MC-LAG instance, and therefore advertises active status notification messages to both its peer pseudowire 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 therefore advertises standby status notification messages to both nodes C and D. Node C performs the same operation.

The 7210 SAS node selects a pseudowire as the active path for forwarding packets when both the local pseudowire status and the received remote pseudowire status indicate active status. However, a 7210 SAS 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 pseudowires that are up. This is to avoid black holing of user traffic during transitions.

The 7210 SAS standby node forwards these packets to the active node via the Inter-Chassis Backup (ICB) pseudowire for this VLL service. An ICB is a spoke-SDP used by an MC-LAG node to back up an MC-LAG SAP during transitions. The same ICB can also be used by the peer MC-LAG node to protect against network failures causing the active pseudowire to go down.

Note:

At configuration time, the user specifies a precedence parameter for each of the pseudowires that are part of the redundancy set as described in the application. A 7210 SAS node uses this to select which pseudowire to forward packet to in case both pseudowires show active/active for the local/remote status during transitions.

Only VLL service of type Epipe is supported in this application. Also, ICB spoke-SDP can only be added to the SAP side of the VLL cross-connect if the SAP is configured on an MC-LAG instance.

VLAN range for SAPs (or dot1q range SAPs) in an Epipe service

The 7210 SAS VLAN ranges (or dot1q range SAPs) provide a mechanism to group a range of VLAN IDs as a single service entity. This allows the operator to provide the service treatment (forwarding, ACL, QoS, accounting, and others) to the group of VLAN IDs as a whole.

Note:

  • Dot1q range SAPs are supported on all 7210 SAS platforms as described in this document.

  • Grouping a range of VLAN IDs to a SAP is supported only for Virtual Leased Line (VLL) Ethernet services.

Processing behavior for dot1q range SAPs in access-uplink mode on 7210 SAS-D, 7210 SAS-Dxp, and 7210 SAS-K 2F1C2T

The access SAPs that specify VLAN range values using connection profile (also known as dot1q range SAPs) are allowed in Epipe service and in VPLS service. For more information about functionality supported, see VLAN range SAPs feature support and restrictions. The system allows only one range SAP in an Epipe service, and it fails any attempt to configure more than one. Range SAPs can only be configured on access ports. The other endpoint in the Epipe service has to be a Q.* SAP in access-uplink mode. The processing and forwarding behavior for packets received on range SAPs are listed as follows:

  • No VLAN tags are removed/stripped on ingress of an access dot1q SAP configured to use VLAN ranges. A single tag (Q1) is added to the frame when it is forwarded out of the Q1.* access-uplink SAP.

  • When a packet is received on the access-uplink Q1.* SAP, the outermost tag is removed and the packet is forwarded out of the access dot1q range SAP. The system does not check if the inner VLAN tag matches the VLANs IDs (both range and individual values specified in the connection profile) of the dot1q access SAPs configured in the service.

  • The dot1q range SAP can be supported in a service with svc-sap-type set to dot1q-range.

VLAN range SAPs feature support and restrictions

The feature support and restrictions of VLAN range SAPs are the following:

  • The access SAPs that specify VLAN range values (using the connection profile) are only allowed in an Epipe service. The system allows only one range SAP in an Epipe service, and fails any attempt to configure more than one. Range SAPs can only be configured on access ports.

  • On 7210 SAS-D and 7210 SAS-Dxp, the dot1q range SAP can only be configured in a service with svc-sap-type set to dot1q-range.

  • On 7210 SAS-K 2F1C2T, the dot1q range SAP can only be configured in a service with svc-sap-type set to dot1q-range.

  • The access SAPs using VLAN range values are only allowed for ports or a LAGs configured for dot1q encapsulation.

  • A connection profile is used to specify either range of VLAN IDs or individual VLANs to be grouped together in a single SAP.

  • On 7210 SAS-D and 7210 SAS-Dxp, dot1q default SAP and dot1q range SAP is not allowed to be configured on the same access port. That is, they are mutually exclusive. This restriction does not apply to 7210 SAS-K 2F1C2T.

  • Multiple connection-profiles can be used per port or LAG if the VLAN value specified by each of them does not overlap. The number of VLAN ranges available per port/LAG is limited. The available number must be shared among all the SAPs on the port/LAG.

  • The connection profile associated with a SAP cannot be modified. To modify a connection profile, it must be removed from all SAPs using it.

  • ACL support – Filter policies are supported on SAP ingress. IP criteria and MAC criteria-based filter policy is available for use with access SAPs. For more information about ACL on range SAPs, refer to the 7210 SAS-D, Dxp, K 2F1C2T, K 2F6C4T, K 3SFP+ 8C Router Configuration Guide.

  • On 7210 SAS-K 2F1C2T, the outermost VLAN tag and Inner VLAN tag matches are supported for both ingress/egress ACL and ingress QoS classification.

  • On 7210 SAS-D and 7210 SAS-Dxp, access SAP egress filters are not supported for SAPs configured in a dot1q-range service.This restriction does not apply to 7210 SAS-K 2F1C2T.

  • On 7210 SAS-D and 7210 SAS-Dxp, access-uplink SAP egress filters are not supported for SAPs configured in a dot1q-range service. This restriction does not apply to 7210 SAS-K 2F1C2T.

  • QoS on 7210 SAS-D and 7210 SAS-Dxp, Ingress classification, metering with hierarchical metering support for SAP ingress is available:

    • SAP ingress classification criteria that is available for use with VLAN range SAPs is similar to that available for other SAPs supported in an Epipe service. Dot1p-based ingress classification uses the dot1p bits in the outermost VLAN tag for matching.

  • QoS on 7210 SAS-K 2F1C2T- Ingress classification, queuing with hierarchical shaping support for SAP ingress is available:

    • SAP ingress classification criteria that is available for use with VLAN range SAPs is similar to that available for other SAPs supported in an Epipe service. Dot1p-based ingress classification uses the dot1p bits in the outermost VLAN tag for matching.

  • The amount of hardware resources (such as CAM entries used for matching in QoS classification and ACL matching, meters used in SAP ingress policy, and others), consumed by a single range SAP, are equivalent to the amount of resources consumed by a single SAP that specifies a single VLAN ID for service identification. That is, the hardware can match a range of VLAN values, and therefore uses X resources for a SAP using a VLAN range, instead of X * n, where n is the number of VLANs specified in the range and X is the amount of QoS or ACL resources needed.

  • Ingress accounting support is like the support available for other SAPs in an Epipe service. The count of packets or octets received from individual VLANs configured in the connection profile is not available. No support for Egress SAP statistics and accounting is available.

  • Mirroring is supported.

Processing behavior for dot1q range SAPs on 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

The access SAPs that specify VLAN range values (using the connection profile) are only allowed in an Epipe service. The system allows only one range SAP in an Epipe service, and fails any attempt to configure more than one. Range SAPs can only be configured on access ports. The other endpoint in the Epipe service has to be a Q.* access SAP or a Q.* access-uplink SAP or a spoke-SDP (PW) in network mode.

The spoke-SDP processing and forwarding behavior for packets received on range SAPs are as follows:

  • No VLAN tags are removed/stripped on ingress of the access dot1q SAPs using VLAN range connection profile.

  • When the other endpoint in the service is configured to be an Q1.* access SAP or a Q1.* access-uplink SAP, the 7210 adds another tag to the packet and forwards it out of that SAP. If the other endpoint in the service is configured to be a spoke-SDP whose VS type is set to vc-ether, the 7210 SAS adds the appropriate MPLS PW and LSP encapsulations and forwards it out of the SDP.

  • In the reverse direction, when the other endpoint is a Q1.* access SAP or a Q1.* access-uplink SAP and a packet is received on it, the 7210 SAS removes the outermost VLAN tag and forwards the packet out of the access dot1q SAP using VLAN ranges. When the other endpoint is a spoke-SDP (whose VC type is set to vc-ether), the 7210 SAS removes the MPLS PW and LSP encapsulation and forwards the packet out of the access dot1q SAP using VLAN ranges. The system does not check if the VLAN in the packet matches the VLAN IDs of the dot1q access SAPs configured in the service. That is, when forwarding the traffic out of the range SAPs, the outermost VLAN tag value is not matched against the range configuration.

VLAN range SAPs feature support and restrictions on 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

The following information describes VLAN range SAPs feature support and restrictions:

  • The access SAPs that specifies VLAN range values (using connection profile) is only allowed in Epipe service. The system allows only one range SAP in an Epipe service. It will fail any attempt to configure more than one range SAP in an Epipe service. Range SAP can be configured only on access ports.

  • The dot1q range sap can be configured only in a service with svc-sap-type set to dot1q-range.

  • The access SAPs using VLAN range values are only allowed for dot1q encapsulation port.

  • A connection profile is used to specify either range of VLAN IDs or individual VLANs to be grouped together in a single SAP.

  • The dot1q default SAP and dot1q range SAP can co-exist on the same access port.

  • Multiple connection profiles can be used per port or LAG as long as the VLAN value specified by each of them does not overlap. The number of VLAN ranges match resources available per port/LAG is limited. The available number must be shared among all the dot1q range SAPs configured on the port/LAG.

  • The connection profile associated with a SAP cannot be modified. To modify a connection profile, it must be removed from all SAPs using it.

  • ACL support – Filter policies are supported on SAP ingress and SAP egress. Only MAC criteria-based filter policy is available for use with access SAPs. For more information about ACL on range SAPs, refer to the 7210 SAS-D, Dxp, K 2F1C2T, K 2F6C4T, K 3SFP+ 8C Router Configuration Guide.

  • The outermost VLAN tag and Inner VLAN tag matches are supported for both ingress/egress ACL and ingress QoS classification.

  • SDP egress and ingress filter are not supported.

  • QoS – ingress classification, queuing with hierarchical shaping support for SAP ingress:

    • SAP ingress classification criteria that is available for use with VLAN range SAPs is like that available for other SAPs supported in an Epipe service. Dot1p-based ingress classification uses the dot1p bits in the outermost VLAN tag for matching. On access egress, dot1p received from the SDP (on a network port) from another access port is preserved.

  • The amount of hardware resources (such as CAM entries used for matching in QoS classification and ACL matching, meters used in SAP ingress policy, and others), consumed by a single range SAP, are equivalent to the amount of resources consumed by a single SAP that specifies a single VLAN ID for service identification. That is, the hardware can match a range of VLAN values, and therefore uses X resources for a SAP using a VLAN range, instead of X * n, where n is the number of VLANs specified in the range and X is the amount of QoS or ACL resources needed.

  • Ingress accounting support is like the support available for other SAPs in an Epipe service. The count of packets or octets received from individual VLANs configured in the connection profile is not available. No support for Egress SAP statistics and accounting is available.

  • Mirroring is supported.

  • Service resiliency mechanisms, such as Epipe PW redundancy, are supported.

Epipe pseudowire switching on 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Note:

The 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C can only be configured as T-PE nodes and not as S-PE nodes. In this section, references to S-PE nodes refer to other products in the Nokia IP product family that support S-PE functionality.

The pseudowire 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 on the PE; however, the target destination of the SDP is the pseudowire switching node instead of the remote PE. In addition, the user configures a VLL service on the pseudowire switching node using the two SDPs.

The pseudowire switching node (that is, S-PE node) acts in a passive role with respect to signaling of the pseudowires. It waits until one or both PEs (that is, T-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 pseudowire switching point TLV is inserted by the switching pseudowire 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 pseudowire, especially if multiple pseudowire 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.

  • It is inserted in pseudowire status notification messages when they are sent end-to-end or from a pseudowire switching node toward a destination PE.

Pseudowire OAM is supported for the manual switching pseudowires and allows the pseudowire switching node to relay end-to-end pseudowire status notification messages between the two PEs. The pseudowire switching node can generate a pseudowire status and send it to one or both PEs by including its system address in the pseudowire switching point TLV. This allows a PE to identify the origin of the pseudowire status notification message.

In the following example, the user configures a regular Epipe VLL service PE1 and PE2 (acting as T-PE nodes). These services each consist of a SAP and a spoke-SDP. However, the target destination of the SDP is not the remote PE but the pseudowire switching node. In addition, the user configures an Epipe VLL service on the pseudowire switching node using the two SDPs.

|7210 SAS-K 2F6C4T PE1 [T-PE node] (Epipe)|---sdp 2:10---
|7450 ESS, 7750 SR, and 7950 XRS PW SW [S-PE node] (Epipe)|---sdp 7:15---|7210 SAS-
K12 PE2 [T-PE node] (Epipe)|

Configuration examples can be found in ‟Configuring Two VLL Paths Terminating on T-PE2”.

Pseudowire switching with protection

Pseudowire 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. This illustrates the use of pseudowire redundancy to provide a scalable and resilient VLL service across multiple IGP areas in a provider network.

In the network in VLL resilience with pseudowire redundancy and switching, PE nodes act as leading nodes and pseudowire switching nodes act as followers for the purpose of pseudowire signaling. A switching node must 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 pseudowire 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. 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 affect the spoke-SDP cross-connect only when both directions of the pseudowire have been signaled and matched.

Figure 16. VLL resilience with pseudowire redundancy and switching

The pseudowire switching TLV is useful in a few situations. First, it allows for troubleshooting of the path of the pseudowire especially if multiple pseudowire switching points exist between the two T-PE nodes. Second, 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 pseudowire status messages when they are sent from a pseudowire switching node toward a destination PE.

Pseudowire status messages can be generated by the T-PE nodes and/or the S-PE nodes. Pseudowire status messages received by a switching node are processed, 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, 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.

Pseudowire switching behavior

In the network in VLL resilience with pseudowire redundancy and switching, PE nodes act as leading nodes and pseudowire switching nodes act as followers for the purpose of pseudowire 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 pseudowire 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 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 S-PE2 will affect the spoke-SDP cross-connect only when both directions of the pseudowire have been signaled and matched.

Pseudowire status notification messages can be generated by the T-PE nodes and/ or the S-PE nodes. Pseudowire status notification messages received by a switching node are processed, 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 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 spoke-SDPs 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 the value of the pseudowire segment to the next hop.

  • When the local operational status for any of the spoke-SDPs is down, the S-PE always sends SDP-binding down status bits, regardless of whether the received status bits from the remote node indicated SAP up/down or SDP-binding up/down.

Pseudowire switching TLV

The following figure shows the format of the pseudowire switching TLV.

Figure 17. Pseudowire switching TLV

PW sw TLV Length - Specifies the total length of all the following pseudowire 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

Pseudowire switching point sub-TLVs

The following are details specific to pseudowire switching point sub-TLVs:

  • pseudowire ID of last pseudowire segment traversed - this sub-TLV type contains a pseudowire ID in the format of the pseudowire ID

  • pseudowire switching point description string - an optional description string of text up to 80 characters

  • IP address of pseudowire switching point

The IP V4 or V6 address of the pseudowire switching point. This is an optional sub TLV:

  • MH VCCV capability indication

Pseudowire redundancy

Pseudowire redundancy provides the ability to protect a pseudowire with a preprovisioned secondary standby pseudowire and to switch traffic over to the secondary standby pseudowire in case of a SAP and/or network failure condition. Pseudowires are redundant due to the SDP redundancy mechanism. For example, if the SDP is an RSVP LSP and is protected by a secondary standby path and/or by Fast Reroute (FRR) paths, the pseudowire is also protected. However, there are a couple of applications in which SDP redundancy does not protect the end-to-end pseudowire 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 pseudowire path is switched in the middle of the network and the pseudowire switching node fails.

Pseudowire 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-to-point and multi-point connections and services. When deployed with multi-chassis LAG, the path for return traffic is maintained through the pseudowire or VPLS switchover, which enables carriers to deliver ‟always on” services across their IP/MPLS networks.

VLL service resilience with pseudowire on 7210 SAS-K 3SFP+ 8C

The following sections describe VLL resilience.

VLL resilience with two destination PE nodes

The following figure shows the application of pseudowire redundancy to provide Ethernet VLL service resilience for broadband service subscribers accessing the broadband service on the service provider BRAS.

Figure 18. VLL resilience

If the Ethernet SAP on PE2 fails, PE2 notifies PE1 of the failure by either withdrawing the primary pseudowire label it advertised or by sending a pseudowire 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. To avoid black holing of in-flight packets during the switching of the path, PE1 will accept packets received from PE2 on the primary pseudowire while transmitting over the backup pseudowire. However, in other applications such as those described in Access node resilience using MC-LAG and pseudowire redundancy, it will be important to minimize service outage to end users.

When the SAP on PE2 is restored, PE2 updates the new status of the SAP by sending a new label mapping message for the same pseudowire FEC or by sending a 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 pseudowire.

The behavior of the pseudowire 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 that will cause PE1 to trigger a switchover to the secondary standby pseudowire:

  • LDP peer (remote PE) node withdrew the pseudowire label.

  • T-LDP peer signaled a FEC status indicating a pseudowire failure or a remote SAP failure.

  • T-LDP session to the peer node times out.

  • SDP binding and VLL service went down as a result of a network failure condition, such as the SDP to peer node going operationally down.

The SDP type for the primary and secondary pseudowires need not be the same. That is, the user can protect a RSVP-TE based spoke-SDP with a LDP one. This provides the ability to route the path of the two pseudowires over different areas of the network. All VLL service types, for example, Apipe, Epipe, Fpipe, and Ipipe are supported on the 7750 SR.

The 7210 SAS routers support the ability to configure multiple secondary standby pseudowire paths. For example, PE1 uses the value of the configurable precedence parameter associated with each spoke-SDP to select the next available pseudowire path after the failure of the current active pseudowire (whether it is the primary or one of the secondary pseudowires). However, the revertive operation always switches the path of the VLL back to the primary pseudowire. There is no revertive operation between secondary paths, meaning that the path of the VLL will not be switched back to a secondary pseudowire of higher precedence when the latter comes back up again.

The 7210 SAS 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 7210 SAS, this application is supported with Epipe Service.

Master-slave operation

This section describes a mechanism in which one end on a pseudowire (the ‟master”) dictates the active PW selection, which is followed by the other end of the PW (the ‟slave”). This mechanism and associated terminology is specified in RFC 6870.

This section describes master-slave pseudowire redundancy. It adds the ability for the remote peer to react to the pseudowire 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.

Master-slave pseudowire redundancy shows the operation of master-slave pseudowire redundancy. In this scenario, an Epipe service is provided between CE1 and CE2. CE2 is dual-homed to PE2 and PE3, and therefore PE1 is dual-homed to PE2 and PE3 using Epipe spoke-SDPs. The objectives of this feature is to ensure that only one pseudowire 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 toward 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 19. Master-slave pseudowire redundancy

Master-slave pseudowire redundancy adds the ability for the remote peer to react to the pseudowire standby status notification, even if only one spoke-SDP terminates on the VLL endpoint on the remote peer. When the CLI command standby-signaling-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.

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 specific peer PE signals one of the following pseudowire status bits:

  • Pseudowire 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 specific spoke-SDP has been blocked will be signaled to LDP peer through the pseudowire 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 pseudowire 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 master-slave pseudowire redundancy with existing scenarios.

Note:

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 pseudowire 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 datapath.

Operation of master-slave pseudowire redundancy with existing scenarios

This section describes how master-slave pseudowire redundancy could operate.

The following figure shows a VLL resilience path example. An sample configuration follows.

Figure 20. VLL resilience
Note:

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

VLL resilience for a switched pseudowire path

The following figure displays VLL resilience for a switched pseudowire path example. A sample configuration follows.

Figure 21. VLL resilience with pseudowire switching
T-PE-1
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-PE-2
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-PE-1

VC switching indicates a VC cross-connect so that the service manager does not signal the VC label mapping immediately but will put S-PE-1 into passive mode, as follows:

configure service epipe 1 vc-switching 
   spoke-sdp 1:100 
   spoke-sdp 4:400 

Pseudowire redundancy service models

This section describes the various pseudowire 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, Pseudowire redundancy — redundant VLL service model.

Pseudowire redundancy — redundant VLL service model

To implement pseudowire redundancy, a VLL service accommodates more than a single object on the SAP side and on the spoke-SDP side. The following figure shows the model for a redundant VLL service based on the concept of endpoints.

Figure 22. Redundant VLL endpoint objects

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.

To add more objects, up to two 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 shown in Redundant VLL endpoint objects.

Redundant VLL endpoint objects is just an example and the Y endpoint can also have a SAP and/or an ICB spoke-SDP. The following describes 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 pseudowire and only switches to a secondary pseudowire when it is down. The VLL service switches the path to the primary pseudowire 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-SDPs per endpoint. The user can configure the precedence of a secondary pseudowire to indicate the order in which a secondary pseudowire is activated.

  • Inter-Chassis Backup (ICB) spoke-SDP

    This is a special pseudowire used for MC-LAG and pseudowire redundancy application. Forwarding between ICBs is blocked on the same node. The user has to explicitly indicate that the spoke-SDP is an ICB at creation time. There are a few scenarios, as follows, where the user can configure the spoke-SDP as an ICB or as a regular spoke-SDP on a specific node. The CLI for those cases will indicate both options.

A VLL service endpoint can only use one active object to transmit at any specific time, but can receive from all endpoint objects.

An explicitly named endpoint can have a maximum of one SAP and one ICB. When 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 an MC-LAG instance. A SAP that is not part of an MC-LAG instance cannot be added to an endpoint that 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

Pseudowire redundancy — T-LDP status notification handling rules

Using 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:

Any allowed combination of objects as specified in Pseudowire redundancy — redundant VLL service model can be used on endpoints X and Y.

The following sections refer to the specific combination objects in Redundant VLL endpoint objects as an example to describe the more general rules.

Processing endpoint SAP active/standby status bits

The advertised admin forwarding status of active/standby reflects the status of the local LAG SAP in the MC-LAG application. If the SAP is not part of an MC-LAG instance, the forwarding status of active is always advertised.

When the SAP in endpoint X is part of an MC-LAG instance, a node must send the T-LDP 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 an MC-LAG instance, the forwarding status sent over all Y endpoint spoke-SDPs should always be set to zero (active by default).

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 receives 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:

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 an MC-LAG instance.

If the ICB spoke-SDP in endpoint X transitions locally to the 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 receives T-LDP SDP-binding down status bits or pseudowire 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 have any of the following happen, the node must send status bits of SAP down over all Y endpoint spoke-SDPs, including the ICB:

  • transition locally to down state

  • receive a SAP down notification by remote T-LDP status bits

  • receive a SAP down notification by SAP-specific OAM signal

  • receive status bits of SDP-binding down

  • receive status bits of pseudowire not forwarding

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.

If a spoke-SDP in endpoint Y, including the ICB spoke-SDP, receive any of the following, the node saves this status and takes no further action:

  • T-LDP SAP down status bits

  • T-LDP SDP-binding down status bits

  • status bits of pseudowire not forwarding

The saved status is used for selecting the active transmit endpoint object.

If all objects in endpoint Y, except the ICB spoke-SDP, have any of the following happen, the node must send status bits of SDP-binding down over the X endpoint ICB spoke-SDP only:

  • transition locally to down state

  • receive T-LDP SAP down status bits

  • receive T-LDP SDP-binding down status bits

  • receive status bits of pseudowire not forwarding

If all objects in endpoint Y have any of the following happen, 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:

  • transition locally to down state

  • receive T-LDP SAP down status bits

  • receive T-LDP SDP-binding down status bits

  • receive status bits of pseudowire not forwarding

An Ethernet SAP does not support signaling status notifications.

MPLS entropy label and hash label

MPLS entropy label (RFC 6790) and the Flow Aware Transport label (known as the hash label) (RFC 6391) allow LSR nodes in a network to load-balance labeled packets in a much more granular fashion than allowed by hashing on the standard label stack. For more information, refer to the 7210 SAS-K 2F6C4T, K 3SFP+ 8C MPLS Guide.

The 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C do not support MPLS entropy label or hash label.

VLL service considerations

This section describes various general service features and any special capabilities or considerations as they relate to VLL services.

SDPs

The most basic SDPs must have the following:

  • locally unique SDP identification (ID) number

  • system IP address of the originating and far-end routers

  • SDP encapsulation type, MPLS

SAP encapsulations

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 Epipe service:

  • Ethernet null

  • Ethernet dot1q

  • QinQ

Note:

While different encapsulation types can be used, encapsulation mismatch can occur if the encapsulation behavior is not understood by connecting devices and they 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 potentially be double tagged when it is transmitted out of the dot1q SAP.

QoS policies

On the 7210 SAS-D and 7210 SAS-Dxp, when applied to 7210 SAS device Epipe services, service ingress QoS policies only create the unicast meters defined in the policy. The multi-point meters are not created on the service. Egress QoS policies function as with other services where the class-based queues per port are available.

On the 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C, when applied to 7210 SAS device Epipe services, service ingress QoS policies only create the unicast queues defined in the policy. The multi-point queues are not created on the service. Service egress QoS policies function as with other services where the class-based queues are created as defined in the policy.

Note:

  • Both Layer 2 or Layer 3 criteria can be used in the QoS policies for traffic classification in a service. For more information, refer to the 7210 SAS-D, Dxp Quality of Service Guide and the 7210 SAS-K 2F1C2T, K 2F6C4T, K 3SFP+ 8C Quality of Service Guide.

  • For the 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, and 7210 SAS-K 3SFP+ 8C, multicast queues are also created for the service ingress QoS policy, but only unicast queues are used for traffic.

Filter policies

The 7210 SAS Epipe 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.

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 Epipe implementation does not perform any MAC learning on the service, so Epipe services do not consume any MAC hardware resources.

Configuring a VLL service with CLI

This section describes how to configure Virtual Leased Line (VLL) services using the command line interface.

Basic configurations

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.

Creating an Epipe service for 7210 SAS-D

Use the following syntax to create an Epipe service.

config>service# epipe service-id [customer customer-id] [create] [svc-sap-type {null-star | any | dot1q-preserve}] [customer-vid vlan-id] 

The following is a sample Epipe configuration output:

A:ALA-1>config>service# info
-------------------------------------------
...
        epipe 15 customer 40 svc-sap-type any create
            description "Local Epipe Service with ANY SVC_SAP_TYPE"
            no shutdown
        exit
----------------------------------------------
A:ALA-1>config>service#

Creating an Epipe service for 7210 SAS-Dxp

Use the following syntax to create an Epipe service.

config>service# epipe service-id [customer customer-id] [create] [vpn vpn-id] [svc-sap-type {null-star | dot1q | dot1q-preserve | any | dot1q-range | qinq-inner-tag-preserve}] [customer-vid vlan-id] [uplink-type {l2 | mpls}]

The following is a sample Epipe configuration output:

A:ALA-1>config>service# info
-------------------------------------------
...
        epipe 15 customer 40 svc-sap-type any create
            description "Local Epipe Service with ANY SVC_SAP_TYPE"
            no shutdown
        exit
----------------------------------------------
A:ALA-1>config>service#

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:

*A:7210SAS>config>connprof# info
----------------------------------------------
        ethernet
            ranges 0 2804-2805 2810-2811 2813 2832-2839
        exit
----------------------------------------------

*A:7210SAS>config>service>epipe# info
----------------------------------------------
            description "Default epipe description for service id 292"
            sap 1/1/4:292.* create
                description "Default sap description for service id 292"
                exit
            exit
            sap 1/1/9:cp-292 create
                description "Default sap description for service id 292"
                exit
            exit
            no shutdown
----------------------------------------------

Creating an Epipe service for 7210 SAS-K 2F1C2T

Use the following syntax to create an Epipe service.

config>service# epipe service-id [customer customer-id] [create] [svc-sap-type {null-star |dot1q|dot1q-preserve|any|dot1q-range|qinq-inner-tag-preserve}]

The following is a sample Epipe configuration output:

*A:SAH01-051>config>service>epipe$ info detail
----------------------------------------------
            shutdown
            no description
            service-mtu 1514
            eth-cfm
            exit
            pbb
            exit
----------------------------------------------
*A:SAH01-051>config>service>epipe$

----------------------------------------------

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:

*A:SAH01-051>config>connprof$ info detail
----------------------------------------------
        no description
        ethernet
            no ranges
        exit
----------------------------------------------
*A:SAH01-051>config>connprof$


*A:SAH01-051>config>service>epipe$ info detail
----------------------------------------------
            shutdown
            no description
            service-mtu 1514
            eth-cfm
            exit
            pbb
            exit
----------------------------------------------
*A:SAH01-051>config>service>epipe$

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

config>service# epipe service-id [customer customer-id]
sap sap-id 
accounting-policy policy-id
collect-stats
description description-string
no shutdown
egress
filter {ip ip-filter-name | mac mac-filter-name}
ingress
filter {ip ip-filter-name | mac mac-filter-name}
qos policy-id 
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:

A:ALA-1>config>service# epipe 500 customer 5 create
config>service>epipe$ description "Local epipe service
config>service>epipe# sap 1/1/2 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 1/1/3 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# no shutdown
config>service>epipe>sap# exit

A:ALA-1>config>service# info
----------------------------------------------
...
        epipe 500 customer 5 create
            description "Local epipe service"
            sap 1/1/2 create
                ingress
                    qos 20
                    filter ip 1
                exit
            exit
            sap 1/1/3 create
                ingress
                    qos 555
                    filter ip 1
                exit
            exit
            no shutdown
        exit
----------------------------------------------
A:ALA-1>config>service#

The following are sample SAP configurations output 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"
            sap 221/1/3:21 create
                ingress
                    qos 555
                    filter ip 1
                exit

            exit
        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

            exit
        exit
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:

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# 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# filter ip 1020
config>service>epipe>sap>ingress# exit
config>service>epipe>sap# egress
config>service>epipe>sap>egress# filter ip 6
config>service>epipe>sap>egress# exit
config>service>epipe>sap# no shutdown
config>service>epipe#

The following are sample SAP configuration outputs 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”
sap 221/1/3:21 create
ingress
qos 555
filter ip 1
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
exit
exit
...
----------------------------------------------
A:ALA-2>config>service#

Configuring SDP bindings

SDPs — unidirectional tunnels 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 23. SDPs — unidirectional tunnels

Use the following syntax to create a spoke-SDP binding with an Epipe service.

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

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

The following is a sample SDP binding for the Epipe service between 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”
          sap 1/1/3:21 create
               ingress
                    qos 555
                    filter ip 1
               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
          exit
          spoke-sdp 2:456 create
               ingress
                    vc-label 5500
               exit
               egress
                    vc-label 6600
               exit
          exit
     no shutdown
     exit
...
----------------------------------------------
A:ALA-2>config>service#
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:

-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#

Use the following syntax 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
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:

ALA-1>config>service# epipe 5500 
config>service>epipe# sap 1/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#

The following is a sample Epipe SAP ingress and egress configuration output:

A:ALA-1>config>service#
----------------------------------------------
...
        epipe 5500 customer 5 vpn 5500 create
            description "Distributed epipe service to east coast"
            sap 1/1/3:21 create
                ingress
                    qos 555
                    filter ip 1
                exit
            exit
            no shutdown
        exit
----------------------------------------------
A:ALA-1>config>service#

Configuring VLL resilience

The following figure 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 24. VLL resilience

PE1

The following is a sample configuration output on PE1(a 7210 SAS-K 2F6C4T node):

*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#
Configuring VLL resilience for a switched pseudowire path

The following figure shows an example of VLL resilience with pseudowire switching.

Figure 25. 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):

*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
exit
spoke-sdp 3:300 endpoint "y" create
precedence 1
exit
no shutdown
----------------------------------------------
*A:ALA-48>config>service>epipe#

T-PE2

The following is a sample configuration output 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 is a sample configuration output 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#

Configuring default QinQ SAPs for Epipe transit traffic in a ring scenario in access-uplink mode

Figure 26. Default QinQ SAP for transit traffic in a ring scenario

In the preceding figure, 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:

ALA-1>config>service# epipe 8 customer 1 svc-sap-type null-star create
            sap 1/1/5:*.* create
                statistics
                    ingress
                    exit
                exit
            exit
            sap 1/1/6:*.* create
                statistics
                    ingress
                    exit
                exit
            exit
            no shutdown
        exit

Service management tasks

This section describes the Epipe service management tasks.

Modifying Epipe service parameters

The following shows the command usage to add an accounting policy to an existing SAP:

Example:
config>service# epipe 2 
config>service>epipe# sap 1/1/3:21
config>service>epipe>sap# accounting-policy 14
config>service>epipe>sap# exit

The following is a sample SAP configuration output:

ALA-1>config>service# info
----------------------------------------------
epipe 2 customer 6 vpn 2 create
            description "Distributed Epipe service to east coast"
            sap 1/1/3:21 create
accounting-policy 14
            exit
            no shutdown
        exit
----------------------------------------------
ALA-1>config>service#

Disabling an Epipe service

Use the following syntax to shut down an Epipe service without deleting the service parameters.

config>service> epipe service-id 
shutdown
Example:
config>service# epipe 2
config>service>epipe# shutdown
config>service>epipe# exit

Re-enabling an Epipe service

Use the following syntax to re-enable an Epipe service that was shut down.

config>service# epipe service-id 
no shutdown
Example:
config>service# epipe 2
config>service>epipe# no shutdown
config>service>epipe# exit

Deleting an Epipe service

Perform the following steps before deleting an Epipe service.

  1. Shut down the SAP.

  2. Delete the SAP.

  3. Shut down the service.

Use the following syntax to delete an Epipe service.

config>service
[no] epipe service-id 
shutdown
[no] sap sap-id 
shutdown
Example:
config>service# epipe 2 
config>service>epipe# sap 1/1/3:21
config>service>epipe>sap# 
config>service>epipe>sap# exit
config>service>epipe# no sap 1/1/3:21
config>service>epipe# epipe 2
config>service>epipe# shutdown
config>service>epipe# exit
config>service# no epipe 2

VLL services command reference

Command hierarchy

Epipe service configuration commands

Epipe global commands for 7210 SAS-D
config
    - service
        - epipe service-id [customer customer-id] [create] [svc-sap-type {null-star | dot1q-preserve | any | dot1q-range}] [customer-vid vlan-id]
        - no epipe service-id
            - description description-string
            - no description
            - [no] endpoint endpoint-name [create]
            - sap sap-id [create]
            - no sap sap-id 
            - service-name service-name
            - no service-name 
            - [no] shutdown
Epipe global commands for 7210 SAS-Dxp
config
    - service
        - epipe service-id [customer customer-id] [create] [vpn vpn-id] [svc-sap-type {null-star | dot1q | dot1q-preserve | any | dot1q-range | qinq-inner-tag-preserve}] [customer-vid vlan-id] [uplink-type {l2 | mpls}]
        - no epipe service-id
            - description description-string
            - no description
            - sap sap-id [create]
            - no sap sap-id 
            - service-name service-name
            - no service-name 
            - [no] shutdown
Epipe global commands for 7210 SAS-K 2F1C2T
config
    - service
        - epipe service-id [customer customer-id] [create] 
        - epipe service-id [customer customer-id] [create] [svc-sap-type {null-star | dot1q | dot1q-preserve | any | dot1q-range | qinq-inner-tag-preserve}]
        - epipe service-id [customer customer-id] [create] [svc-sap-type {null-star | dot1q | dot1q-preserve | any | dot1q-range | qinq-inner-tag-preserve}]
        - no epipe service-id
            - description description-string
            - no description
            - sap sap-id [create]
            - no sap sap-id 
            - service-mtu octets 
            - no service-mtu
            - service-name service-name
            - no service-name
            - [no] shutdown
Epipe global commands for 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C
config
    - service
        - epipe service-id [customer customer-id] [create] 
        - epipe service-id [customer customer-id] [create] [svc-sap-type {null-star | dot1q | dot1q-preserve | any | dot1q-range | qinq-inner-tag-preserve}]
        - epipe service-id [customer customer-id] [create] [svc-sap-type {null-star | dot1q | dot1q-preserve | any | dot1q-range | qinq-inner-tag-preserve}]
        - no epipe service-id
            - description description-string
            - no description
            - [no] endpoint endpoint-name [create]
                - active-hold-delay active-endpoint-delay
                - no active-hold-delay
                - revert-time [revert-time | infinite]
                - no revert-time
                - standby-signaling-master
                - [no] standby-signaling-master
            - sap sap-id [create]
            - no sap sap-id 
            - service-mtu octets 
            - no service-mtu
            - service-name service-name
            - no service-name
            - [no] shutdown
            - [no] spoke-sdp
Epipe SAP configuration commands
config
    - service
        - epipe service-id
        - no epipe service-id
            - no sap sap-id 
                - accounting-policy acct-policy-id
                - no accounting-policy acct-policy-id
                - [no] collect-stats
                - description description-string
                - no description
                - eth-cfm
                    - [no] mep mep-id domain md-index association ma-index [direction {up | down}] primary-vlan-enable
                        - [no] ais-enable
                            - [no] client-meg-level [[level [level ...]]
                            - [no] interval {1 | 60}
                            - [no] priority priority-value
                            - no send-ais-on-port-down
                            - send-ais-on-port-down
                        - [no] ccm-enable 
                        - [no] ccm-ltm-priority priority
                        - defect-oper-group name
                        - no defect-oper-group
                        - [no] description
                        - [no] eth-test-enable
                            - [no] bit-error-threshold bit-errors
                            - [no] test-pattern {all-zeros | all-ones} [crc-enable]
                        - [no] fault-propagation-enable {use-if-tlv | suspendccm}
                        - low-priority-defect {allDef | macRemErrXcon | remErrXcon | errXcon | xcon | noXcon}
                        - [no] mac-address mac-address
                        - [no] one-way-delay-threshold seconds
                        - [no] shutdown
                - mac-swap-enable
                - no mac-swap-enable
                - ethernet
                    - [no] ais-enable
                - [no] ignore-oper-down
                - [no] shutdown
Epipe spoke-SDP configuration commands for 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C
config
    - service]
        - epipe service-id
        - no 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
            - no spoke-sdp sdp-id[:vc-id]
                - accounting-policy acct-policy-id
                - no accounting-policy
                - [no] collect-stats
                - [no] control-word
                - [no] description
                - [no] egress
                    - [no] vc-label egress-vc-label
                - eth-cfm
                    - [no] ais-enable
                    - [no] mep mep-id domain md-index association ma-index [direction {up | down}] 
                        - [no] ais-enable
                            - [no] client-meg-level [[level [level ...]]
                            - [no] interval {1 | 60}
                            - [no] priority priority-value
                        - [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} [crc-enable]
                        - [no] fault-propagation-enable {use-if-tlv | suspendccm}
                        - low-priority-defect {allDef | macRemErrXcon | remErrXcon | errXcon | xcon | noXcon}
                        - [no] mac-address mac-address
                        - [no] one-way-delay-threshold seconds
                        - [no] shutdown
                    - mip [mac mac address]
                    - mip default-mac
                    - no mip
                - [no] force-vlan-vc-forwarding
                - hash-label [signal-capability]
                - no hash-label
                - [no] ingress
                    - [no] vc-label egress-vc-label
                - precedence [precedence-value| primary]
                - no precedence
                - no pw-status-signaling
                - pw-status-signaling
                - [no] shutdown
                - vlan-vc-tag 0..4094
                - no vlan-vc-tag [0..4094]
Epipe SAP configuration — QoS and filter commands for 7210 SAS-D and 7210 SAS-Dxp
config
    - service
        - epipe service-id [customer customer-id] [create] [svc-sap-type {null-star | dot1q-preserve | any | dot1q-range}] [customer-vid vlan-id] 
        - epipe service-id [customer customer-id] [create] [svc-sap-type {null-star | dot1q-preserve | dot1q}] [customer-vid vlan-id] 
        - no epipe service-id
            - no sap sap-id [create]
                - egress 
                    - aggregate-meter-rate rate-in-kbps [burst burst-in-kbits] [enable-stats]
                    - no aggregate-meter-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]
                - ingress 
                    - aggregate-meter-rate rate-in-kbps [burst burst-in-kbits]
                    - no aggregate-meter-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]
                    - qos policy-id 
                    - no qos
Epipe SAP configuration — QoS and filter commands for 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, and 7210 SAS-K 3SFP+ 8C
config
    - service
        - epipe service-id [customer customer-id] [create] [svc-sap-type {any | dot1q-range}] 
        - no epipe service-id
            - no sap sap-id [create]
                - egress 
                    - agg-shaper-rate agg-rate
                    - no agg-shaper-rate
                    - dot1p-inner dot1p-inner
                    -  no dot1p-inner
                    -  no dot1p-outer
                    -  dot1p-outer dot1p-outer
                    - filter [ip ip-filter-id]
                    - filter [ipv6 ipv6 -filter-id] 
                    - filter [mac mac-filter-id] (app
                    - no filter [ip ip-filter-id] [ipv6 ipv6 -filter-id] [mac mac-filter-id]
                    - qos policy-id 
                    - no qos
                - ingress 
                    - agg-shaper-rate agg-rate
                    - no agg-shaper-rate
                    - aggregate-meter-rate rate-in-kbps [burst burst-in-kbits]
                    - no aggregate-meter-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]
                    - qos policy-id 
                    - no qos

Show commands

show
    - service
        - id service-id
            - all
            - base
            - sap 
            - stp [sap-id] [detail]]
        - sap-using [sap sap-id]
        - sap-using [ingress | egress] filter filter-id
        - sap-using [ingress ] qos-policy qos-policy-id
        - service-using [epipe] [vpls] [mirror] [cpipe]  [i-vpls] [m-vpls] [sdp sdp-id] [customer customer-id]
show
    - connection-profile [conn-prof-id] [associations]

Clear commands

clear
    - service
        - id service-id
        - statistics
            - id service-id
            - counters
            - sap sap-id {all | counters | stp | l2pt}

Command descriptions

VLL service configuration commands

Generic commands
shutdown
Syntax

[no] shutdown

Context

config>service>epipe

config>service>epipe>sap

config>service>epipe>sap>eth-cfm>mep

Platforms

Supported on all 7210 SAS platforms as described in this document

Description

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.

Services are created in the administratively down (shutdown) state. When a no shutdown command is entered, the service becomes administratively up, then tries to enter the operationally up state.

The no form of this command places the entity into an administratively enabled state.

description
Syntax

description description-string

no description

Context

config>service>epipe

config>service>epipe>sap

config>service>epipe>spoke-sdp

config>connection-profile

Platforms

Supported on all 7210 SAS platforms as described in this document

Description

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.

The no form of this command removes the string from the configuration.

Parameters
description-string

Specifies the description character string. Allowed values are any string up to 80 characters 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.

eth-cfm
Syntax

eth-cfm

Context

config>service>epipe>sap

Platforms

Supported on all 7210 SAS platforms as described in this document

Description

Commands in this context configure ETH-CFM parameters.

mep
Syntax

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

Context

config>service>epipe>sap>eth-cfm

Platforms

Supported on all 7210 SAS platforms as described in this document

Description

This command provisions the maintenance endpoint (MEP).

The no form of this command reverts to the default values.

For more information about ETH-CFM support for different services, see the 7210 SAS-D, Dxp, K 2F1C2T, K 2F6C4T, K 3SFP+ 8C OAM and Diagnostics Guide.

Parameters
mep-id

Specifies the maintenance association endpoint identifier.

Values

1 to 8191

md-index

Specifies the maintenance domain (MD) index value.

Values

1 to 4294967295

ma-index

Specifies the MA index value.

Values

1 to 4294967295

direction {up | down}

Specifies the direction in which the maintenance association (MEP) faces on the bridge port.

up — Sends ETH-CFM messages toward the MAC relay entity.

down — Sends ETH-CFM messages away from the MAC relay entity.

primary-vlan-enable

Keyword that provides a method for linking 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 Ethernet SAPs. This parameter is only supported on the 7210 SAS-Dxp, 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, and 7210 SAS-K 3SFP+ 8C.

VLL global commands
epipe
Syntax

epipe service-id [customer customer-id] [create] [svc-sap-type {null-star|dot1q|dot1q-preserve}] [customer-vid vlan-id]

epipe service-id [customer customer-id] [create] [svc-sap-type {null-star|dot1q-preserve|any|dot1q-range}] [customer-vid vlan-id]

epipe service-id [customer customer-id] [create] [svc-sap-type {any|dot1q-range}]

epipe service-id [customer customer-id] [create] [svc-sap-type {null-star|dot1q|dot1q-preserve|any|dot1q-range|qinq-inner-tag-preserve}]

epipe [customer customer-id] [create] [vpn vpn-id] [svc-sap-type {null-star | dot1q | dot1q-preserve | any | dot1q-range | qinq-inner-tag-preserve}] [customer-vid vlan-id] [uplink-type {l2 | mpls}]

no epipe service-id

Context

config>service

Platforms

Supported on all 7210 SAS platforms as described in this document

Description

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). In a local service, the SAPs may be defined in one 7210 SAS node and in distributed service the SAPs may be defined on two different 7210 SAS nodes.

Note:

  • 7210 SAS-D, 7210 SAS-Dxp, and 7210 SAS-K 2F1C2T platforms only support local SAP to SAP service.

  • 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C platforms support both local and distributed service.

No MAC learning or filtering is provided on an Epipe.

When a service is created, the customer keyword and customer-id must be specified and associate the service with a customer. The customer-id must already exist, having been created using the customer command in the service context. When 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.

When 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 results in an error.

By default, no Epipe services exist until they are explicitly created with this command.

The tables in the following links list the allowed SAPs for a particular value of svc-sap-type on different 7210 platforms:

The no form of this command deletes the Epipe service instance with the specified service-id. The service cannot be deleted until the service has been shut down.

Parameters
service-id

Specifies 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 7210 SAS on which this service is defined.

service-id-epipe

Values

service-id: 1 to 2147483648

svc-name: 64 characters maximum

customer 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 deletion.

epipe customer

Values

1 to 2147483647

svc-sap-type

Keyword that specifies the type of access SAPs and access-uplink SAPs allowed in the service.

vpn

Values

null-star — Specifies that the allowed SAP in the service can be null SAPs, dot1q default, Q.* SAP, 0.* SAP or default QinQ SAP (also known as *.* SAP). This is supported only on 7210 SAS-D and 7210 SAS-Dxp.

dot1q — Specifies that the allowed SAPs in the service are dot1q SAPs and dot1q explicit null SAPs. This is supported only on 7210 SAS-Dxp.

dot1q-preserve — Specifies that the allowed SAPs in the service are dot1q. The dot1q ID is not stripped after packets match the SAP. This is supported only on 7210 SAS-D and 7210 SAS-Dxp.

dot1q-range — Specifies that the access SAP in the service can use VLAN ranges as the SAP tags. The VLAN ranges are configured using the configure>connection-profile CLI command. On ingress of the access dot1q SAP using VLAN ranges, the outermost tag is not removed before forwarding. This is supported only on 7210 SAS-D, 7210 SAS-Dxp, 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, and 7210 SAS-K 3SFP+ 8C.

any — Keyword that allows any SAP type. This is supported only on 7210 SAS-D, 7210 SAS-Dxp, 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, and 7210 SAS-K 3SFP+ 8C.

Default

any

customer-vid vlan-id

Defines the dot1q VLAN ID to be specified while creating the local dot1q SAP for svc-sap-type dot1q-preserve. Applicable only for Access-uplink mode.

Values

1 to 4094

create

Keyword used to create the service instance. The create keyword requirement can be enabled or disabled in the environment>create context.

endpoint
Syntax

[no] endpoint endpoint-name

Context

config>service>epipe

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

This command configures a service endpoint.

Parameters
endpoint-name

Specifies an endpoint name.

active-hold-delay
Syntax

active-hold-delay active-hold-delay

no active-hold-delay

Context

config>service>epipe>endpoint

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

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

A value of zero (default) means that when the MC-LAG transitions the LAG subgroup that hosts the SAP for this VLL endpoint from active to standby, the node immediately sends new T-LDP status bits indicating the new value of standby over the spoke-SDPs that 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 that hosts the SAP from "standby" to "active", or when any object in the endpoint transitions to an operationally up state.

Default

0

Parameters
active-hold-delay

Specifies the active hold delay in 100s of milliseconds.

Values

0 to 60

revert-time
Syntax

revert-time [revert-time | infinite]

no revert-time

Context

config>service>epipe>endpoint

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

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

Specify the time, in seconds, to wait before reverting to the primary SDP.

Values

0 to 600

infinite

Keyword that causes the endpoint to be non-revertive.

standby-signaling-master
Syntax

[no] standby-signaling-master

Context

config>service>epipe>endpoint

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

When this command is enabled, the pseudowire standby bit (value 0x00000020) is sent to T-LDP peer for each spoke-SDP of the endpoint that is selected as a standby.

Default

no standby-signaling-master

service-mtu
Syntax

service-mtu octets

no service-mtu

Context

config>service>epipe

Platforms

7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, 7210 SAS-K 3SFP+ 8C

Description

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 service-mtu defines the payload capabilities of the service. It is used by the system to validate the SAP and SDP binding operational state within the service.

The service MTU and a SAP service delineation encapsulation overhead (that is, 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, the SAP is placed in an inoperative state. If the required MTU is equal to or less than the port or channel MTU, the SAP is able to transition to the operative state.

In the event that a service MTU, port or channel MTU, or path MTU is dynamically or administratively modified, all associated SAP and SDP binding operational states are automatically reevaluated.

The no form of this command reverts to the default service-mtu value for the indicated service type.

Default

epipe: 1514

The following table displays MTU values for specific VC types.

Table 1. MTU values

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 (QinQ with preserved bottom Qtag)

1518

1504

Parameters
octets

Specifies the size of the MTU in octets, expressed as a decimal integer.

Values

1 to 9194

service-name
Syntax

service-name service-name

no service-name

Context

config>service>epipe

Platforms

Supported on all 7210 SAS platforms as described in this document

Description

This command configures an optional service name that adds a name identifier to a specific 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 or administrator to identify and manage services.

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 to identify and reference a specific service when it is initially created.

Parameters
service-name

Specifies a unique service name, up to 64 characters, to identify the service. Service names may not begin with an integer (0-9).

VLL SAP commands
sap
Syntax

sap sap-id [create]

no sap sap-id

Context

config>service>epipe

Platforms

Supported on all 7210 SAS platforms as described in this document

Description

This command creates a Service Access Point (SAP) within a service. A SAP is a combination of port and encapsulation parameters that identify the service access point on the interface and within the 7210 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 does 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.

On the 7210 SAS-D and 7210 SAS-Dxp, in a single physical port only one SAP can belong to one service. Multiple SAPs can be defined over a physical port but each of these SAPs should belong to different services. This restriction does not apply to the 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, or 7210 SAS-K 3SFP+ 8C.

A SAP can be associated with only a single service. A SAP can only be defined on a port that has been configured as an access port. Additionally, in access-uplink mode, SAPs can also be defined on an access-uplink port. Access-uplink SAPs are network-facing SAPs representing dot1q or QinQ tunnels used to transport traffic toward the service nodes.

If a port is shut down, all SAPs on that port become operationally down. When a service is shut down, SAPs for the service are not displayed as operationally down, although all traffic traversing the service is discarded.

The operational state of a SAP is relative to the operational state of the port on which the SAP is defined.

The following encapsulations are supported.

  • Ethernet access SAPs support null, dot1q, and QinQ.

  • Ethernet access-uplink SAPs support only QinQ encapsulation.

The no form of this command deletes the SAP with the specified port. When a SAP is deleted, all configuration parameters for the SAP are also be deleted. For IES, the IP interface must be shut down before the SAP on that interface may be removed.

Special Cases
Default SAPs

A default SAP has the following format: port-id:*. This type of SAP is supported only on Ethernet MDAs, and its creation is only allowed in the scope of Layer 2 services (Epipe and VPLS).

Parameters
sap-id

Specifies the physical port identifier portion of the SAP. See Common CLI command descriptions for command syntax.

create

Keyword used to create a SAP instance. The create keyword requirement can be enabled or disabled in the environment>create context.

accounting-policy
Syntax

accounting-policy acct-policy-id

no accounting-policy [acct-policy-id]

Context

config>service>epipe>sap

Platforms

Supported on all 7210 SAS platforms as described in this document

Description

This command enables 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

Default accounting policy.

Parameters
acct-policy-id

Specifies the accounting policy-id, as configured in the config>log> accounting-policy context.

Values

1 to 99

collect-stats
Syntax

[no] collect-stats

Context

config>service>epipe>sap

Platforms

Supported on all 7210 SAS platforms as described in this document

Description

This command enables accounting and statistical data collection for the SAP, network port, or IP interface. When applying accounting policies, by default the data 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, the counters written to the billing file include all the traffic while the no collect-stats command was in effect.

Default

no collect-stats

ethernet
Syntax

ethernet

Context

config>service>epipe>sap

Platforms

Supported on all 7210 SAS platforms as described in this document

Description

This command configures Ethernet properties in this SAP.

ais-enable
Syntax

[no] ais-enable

Context

config>service>epipe>sap>eth-cfm

Platforms

Supported on all 7210 SAS platforms as described in this document

Description

This command enables the generation and the reception of AIS messages.

client-meg-level
Syntax

client-meg-level [[level [level ...]]

no client-meg-level

Context

config>service>epipe>sap>eth-cfm>ais-enable

Platforms

Supported on all 7210 SAS platforms as described in this document

Description

This command configures the client maintenance entity group (MEG) levels 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.

Parameters
level

Specifies the client MEG level.

Values

1 to 7

Default

1

interval
Syntax

interval {1 | 60}

no interval

Context

config>service>epipe>sap>eth-cfm>ais-enable

Platforms

Supported on all 7210 SAS platforms as described in this document

Description

This command specifies the transmission interval of AIS messages.

Parameters
1 | 60

Specifies the transmission interval of AIS messages, in seconds.

Default

1

priority
Syntax

priority priority-value

no priority

Context

config>service>epipe>sap>eth-cfm>ais-enable

Platforms

Supported on all 7210 SAS platforms as described in this document

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

ccm-enable
Syntax

[no] ccm-enable

Context

config>service>epipe>sap>eth-cfm>mep

Platforms

Supported on all 7210 SAS platforms as described in this document

Description

This command enables the generation of CCM messages.

The no form of this command disables the generation of CCM messages.

ccm-ltm-priority
Syntax

ccm-ltm-priority priority

no ccm-ltm-priority

Context

config>service>epipe>sap>eth-cfm>mep

Platforms

Supported on all 7210 SAS platforms as described in this document

Description

This command specifies the priority value for CCMs and LTMs transmitted by the MEP.

The no form of this command removes the priority value from the configuration.

Default

The highest priority on the bridge-port.

Parameters
priority

Specifies the priority of CCM and LTM messages.

Values

0 to 7

defect-oper-group
Syntax

defect-oper-group name

no defect-oper-group

Context

config>service>epipe>sap>eth-cfm>mep

Platforms

Supported on all 7210 SAS platforms as described in this document, except 7210 SAS-D

Description

This command configures an operational group for fault propagation.

Refer to the 7210 SAS-D, Dxp, K 2F1C2T, K 2F6C4T, K 3SFP+ 8C OAM and Diagnostics Guide for more information about fault propagation in an Epipe service.

The no form of this command removes the operational group.

Parameters
name

Specifies the operational group name, up to 32 characters.

llf
Syntax

[no] llf

Context

config>service>epipe>sap>ethernet

Platforms

Supported on all 7210 SAS platforms as described in this document

Description

This command enables Link Loss Forwarding (LLF) on an Ethernet port or an ATM port. This command provides an end-to-end OAM fault notification for Ethernet VLL service. It brings down the Ethernet port (Ethernet LLF) toward 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.

ignore-oper-down
Syntax

[no] ignore-oper-down

Context

config>service>epipe>sap

Platforms

7210 SAS-D, 7210 SAS-Dxp, 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, 7210 SAS-K 3SFP+ 8C

Description

This command configures the optional command for a specific SAP to ignore the transition of the operational state to down when a SAP fails. Only a single SAP in an Epipe may use this option.

Default

no ignore-oper-down

send-ais-on-port-down
Syntax

[no] send-ais-on-port-down

Context

config>service>epipe>sap>eth-cfm>mep>ais-enable

config>service>vpls>sap>eth-cfm>mep>ais-enable

Platforms

Supported on all 7210 SAS platforms as described in this document

Description

This command specifies that ETH-AIS should be generated for client MEPs immediately when port down event is detected on the port where the server MEP (and the associated SAP) resides. By default, the system generates an ETH-AIS message, if enabled, when CCM messages are not received within the configured time period. On a subsequent port up event, the AIS messages continue to be sent until valid CCMs are received. If there are no remote MEPs configured for the MEP, on a subsequent port up event, the AIS messages are not sent.

The no form of this command reverts to the default value.

Default

no send-ais-on-port-down

eth-test-enable
Syntax

[no] eth-test-enable

Context

config>service>epipe>sap>eth-cfm>mep

Platforms

Supported on all 7210 SAS platforms as described in this document

Description

This command enables the Ethernet test functionality on MEP. For ETH-test to work, users must configure ETH-test parameters on both sender and receiver nodes. The ETH-test can then be performed 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 that 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.

test-pattern
Syntax

test-pattern {all-zeros | all-ones} [crc-enable]

no test-pattern

Context

config>service>epipe>sap>eth-cfm>mep>eth-test-enable

Platforms

Supported on all 7210 SAS platforms as described in this document

Description

This command configures the test pattern for eth-test frames.

The no form of this command removes the values from the configuration.

Parameters
all-zeros

Keyword that specifies to use all zeros in the test pattern.

all-ones

Keyword that specifies to use all ones in the test pattern.

crc-enable

Keyword that generates a CRC checksum.

Default

all-zeros

bit-error-threshold
Syntax

bit-error-threshold errors

no bit-error-threshold

Context

config>service>epipe>sap>eth-cfm>mep>eth-test-enable

Platforms

Supported on all 7210 SAS platforms as described in this document

Description

This command is used to specify the threshold value of bit errors.

one-way-delay-threshold
Syntax

one-way-delay-threshold seconds

Context

config>service>epipe>sap>eth-cfm>mep

Platforms

Supported on all 7210 SAS platforms as described in this document

Description

This command enables eth-test functionality on MEP.

Parameters
seconds

Specifies the one-way delay threshold in seconds.

Values

0 to 600

Default

3

mac-swap-enable
Syntax

[no] mac-swap-enable

Context

config>service>epipe>sap config>service>vpls>sap

Platforms

7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, 7210 SAS-K 3SFP+ 8C

Description

This command configures that the source and destination MAC address for all the packets to be sent out of the SAP is swapped, then the packets are looped back to ingress of the SAP. SAP loopback is typically used with Y.1564 testhead functionality to loop back packets received on the end that is acting as a reflector, looping back packets received from the testhead generator.

This command is available for testing VLL services and VPLS services only. When enabled, no packets egress the service SAP, and packets received on ingress are not processed.

Note:

  • Before enabling this command, turn off all Layer 2 and IP control protocols (such as LACP, EFM, 802.1x and so on) on the device and its peer to prevent errors such as protocol flaps because of timeout and so on.

  • When SAP loopback with MAC-swap is enabled for broadcast and multicast packets (that is, packets received with multicast or broadcast destination address), the source MAC address is used as the destination MAC address and the system MAC address is the source MAC address.

  • The user can enable MAC swap on multiple SAPs in the same service. The user can also configure static MAC on SAPs and traffic to prevent running into the MAC move, relearning issues and unpredictable device behavior.

Default

no mac-swap-enable

mip
Syntax

mip [mac mac-address]

mip default-mac

no mip

Context

config>service>epipe>sap>eth-cfm

config>service>epipe>spoke-sdp>eth-cfm (supported on 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C only)

Platforms

7210 SAS-D, 7210 SAS-Dxp, 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, 7210 SAS-K 3SFP+ 8C

Description

This command allows Maintenance Intermediate Points (MIPs) to be created if mhf-creation for the MA is configured using the default option.

The no form of this command deletes the MIP.

Parameters
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-xx-xx-xx of the MIP. The MAC must be unicast. Using the all zeros address is equivalent to the no form of this command.

default-mac

Using the no command deletes the MIP. If the operator needs to change the mac back to the default mac without having to delete the MIP and reconfiguring this command is useful.

Default

no mip

fault-propagation-enable
Syntax

fault-propagation-enable {use-if-tlv | suspend-ccm}

no fault-propagation-enable

Context

config>service>epipe>sap>eth-cfm>mep

Platforms

7210 SAS-D, 7210 SAS-Dxp, 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, 7210 SAS-K 3SFP+ 8C

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 the continuity check messages.

Connection profile commands
connection-profile
Syntax

connection-profile conn-prof-id [create]

no connection-profile conn-prof-id

Context

config

Platforms

7210 SAS-D, 7210 SAS-Dxp, 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, 7210 SAS-K 3SFP+ 8C

Description

This command creates a profile to configure the list of VLAN values to be assigned to a dot1q SAP in an Epipe service.

A connection profile can only be applied to a dot1q SAP that is part of an Epipe service.

The no form of this command deletes the profile from the configuration.

Parameters
conn-prof-id

Specifies the profile number.

Values

1 to 1000

create

Keyword to create a connection profile.

ethernet
Syntax

ethernet

Context

config>connprof

Platforms

7210 SAS-D, 7210 SAS-Dxp, 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, 7210 SAS-K 3SFP+ 8C

Description

Provides the context to configure the VLAN ranges values.

ranges
Syntax

no ranges

ranges vlan-ranges [vlan-ranges...(up to 32 max)]

Context

config>connprof>ethernet

Platforms

7210 SAS-D, 7210 SAS-Dxp, 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, 7210 SAS-K 3SFP+ 8C

Description

Specifies the list of VLAN ranges or individual VLAN IDs used for mapping the specific VLANs to the Epipe SAP.

The system validates that the values specified are valid VLAN IDs in the range 0 to 4094 (VLAN ID 4095 is reserved). Ranges are specified in the format ‟a-b”, the expression (a < b) should be true. Up to 32 individual VLAN values or VLAN ranges can be specified. A maximum of 8 VLAN ranges are allowed per connection profile.

Parameters
vlan-ranges

Specifies the list of VLAN ranges or individual VLAN IDs to be used for mapping the specific VLANs to the Epipe SAP.

A list of space separated values specified as either a-b or individual VLAN IDs. Both the VLAN IDs and the value used for ‟a” and ‟b” must be in the range of 0 to 4094. Additionally, value ‟a” must be less than value ‟b”.

For example:

ranges

100-200 5 6 4000-4020

ranges

4 5 6 10 11 12

ranges

250-350 500-600 1000-1023

Service QoS and filter policy commands
egress
Syntax

egress

Context

config>service>epipe>sap

Platforms

Supported on all 7210 SAS platforms as described in this document

Description

Commands in this context configure egress SAP parameters.

force-vlan-vc-forwarding
Syntax

[no] force-vlan-vc-forwarding

Context

config>service>epipe>spoke-sdp

config>service>vpls>spoke-sdp

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

This command forces VC VLAN-type forwarding in the datapath for spokes that have either VC-type. This command is not allowed on VC VLAN-type SDPs.

The no version of this command reverts to the default value.

ingress
Syntax

ingress

Context

config>service>epipe>sap

Platforms

Supported on all 7210 SAS platforms as described in this document

Description

Commands in this context configure ingress SAP QoS policies.

If no SAP-ingress QoS policy is defined, the system default SAP-ingress QoS policy is used for ingress processing.

agg-shaper-rate
Syntax

agg-shaper-rate agg-rate

no agg-shaper-rate

Context

config>service>epipe>sap>ingress

Platforms

7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, 7210 SAS-K 3SFP+ 8C

Description

This command configures the aggregate rate for the access SAP shaper. The aggregate SAP shaper is available to limit only the unicast traffic and the BUM traffic across all the FCs of the SAP configured to use ingress queues.

The no form of this command disables the use of the SAP aggregate rate shaper. That is, the SAP can use up the maximum bandwidth available.

Default

no agg-shaper-rate

Parameters
agg-rate

Specifies the rate in kilobits per second.

Values

50 to 3000000 | max (7210 SAS-K 2F1C2T and 7210 SAS-K 2F6C4T)

64 to 20000000 | max (7210 SAS-K 3SFP+ 8C)

Default

max

agg-shaper-rate
Syntax

agg-shaper-rate agg-rate

no agg-shaper-rate

Context

config>service>epipe>sap>egress

Platforms

7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, 7210 SAS-K 3SFP+ 8C

Description

This command configures the aggregate rate for the access SAP shaper. The aggregate SAP shaper is available to limit only the unicast traffic and the BUM traffic across all the FCs of the SAP configured to use egress queues.

The no form of this command disables the use of the SAP aggregate rate shaper. That is, the SAP can use up the maximum bandwidth available.

Default

no agg-shaper-rate

Parameters
agg-rate

Specifies the rate in kilobits per second.

Values

50 to 1000000 | max (7210 SAS-K 2F1C2T and 7210 SAS-K 2F6C4T)

64 to 10000000 | max (7210 SAS-K 3SFP+ 8C)

Default

max

aggregate-meter-rate
Syntax

aggregate-meter-rate rate-in-kbps [burst burst-in-kbits] [enable-stats]

no aggregate-meter-rate

Context

config>service>epipe>sap>egress

config>service>ies>if>sap>egress

config>service>vpls>sap>egress

Platforms

7210 SAS-D, 7210 SAS-Dxp

Description

This command configures the access SAP egress aggregate policer. The rate (PIR) of the SAP egress aggregate policer must be specified. The user can optionally specify the burst size for the SAP aggregate policer. The aggregate policer monitors the traffic sent out of the SAP and determines the final disposition of the packet, which is either forwarded or dropped.

The user can optionally associate a set of two counters to count total forwarded packets and octets and total dropped packets and octets. When use of this counter is enabled, the amount of resources required increases by twice the amount of resources taken up when the counter is not used. If the enable-stats keyword is specified during the creation of the meter, the counter is allocated by the software, if available. To free up the counter and relinquish its use, use the no aggregate-meter-rate command, then recreate the meter using the aggregate-meter rate command.

If egress frame-based accounting is used, the SAP egress aggregate meter rate accounts for the Ethernet frame overhead. The system accounts for 12 bytes of IFG and 8 bytes of start delimiter. Frame-based accounting does not affect the count of octets maintained by the counter (if in use).

Note:

  • Before enabling this command for a SAP, resources must be allocated to this feature from the egress-internal-tcam resource pool using the config system resource-profile egress-internal-tcam egress-sap-aggregate-meter command. Refer to the 7210 SAS-D, Dxp, K 2F1C2T, K 2F6C4T, K 3SFP+ 8C Basic System Configuration Guide for more information.

  • The egress aggregate meter is not FC-aware. The forward and drop decisions are made based on the order in which the packets are sent out of the SAP by the egress port scheduler.

The no form of this command removes the egress aggregate policer from use.

Default

no aggregate-meter-rate

Parameters
rate-in-kbps

Specifies the rate in kilobits per second.

Values

1 to 4000000, max (7210 SAS-D)

1 to 20000000, max (7210 SAS-Dxp)

Default

max

burst-in-kbits

Specifies the burst size for the policer in kilobits. The burst size cannot be configured without configuring the rate.

Values

4 to 16384, default (7210 SAS-D)

4 to 2146959, default (7210 SAS-Dxp)

Default

512

enable-stats

Keyword to specify whether the counter to count forwarded and dropped packets and octets is allocated. If this keyword is used while configuring the meter, the counter is allocated.

aggregate-meter-rate
Syntax

aggregate-meter-rate rate-in-kbps [burst burst-in-kbits]

no aggregate-meter-rate

Context

config>service>epipe>sap>ingress

config>service>ies>if>sap>ingress

config>service>vpls>sap>ingress

config>service>vprn>if>sap>ingress

Platforms

7210 SAS-Dxp, 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, 7210 SAS-K 3SFP+ 8C

IES contexts apply only to the 7210 SAS-Dxp, 7210 SAS-K 2F6C4T, and 7210 SAS-K 3SFP+ 8C

VPRN contexts apply only to the 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

This command allows the user to configure the access SAP ingress aggregate policer. The rate of the SAP ingress aggregate policer must be specified by the user. The user can optionally specify the burst size for the SAP aggregate policer. The aggregate policer monitors the ingress traffic on different FCs using policers to rate-limit the flow and determines the final disposition of the packet. The packet is either forwarded to an identified profile or dropped.

Note:

  • The sum of the CIR of the individual FCs configured under the SAP cannot exceed the PIR rate configured for the SAP. Although the 7210 SAS software does not block this configuration, Nokia does not recommend this configuration.

  • The queued traffic flows are not limited by the aggregate meter. That is, only metered flows can use the aggregate meter. Queue flows can use only the aggregate shaper.

The following table lists the final disposition of the packet based on the operating rate of the per FC policer and the per SAP aggregate policer.

Table 2. Final disposition of the packet based on per-FC and per-SAP policer or meter

Per FC meter operating rate

Per FC assigned color

SAP aggregate meter operating rate

Final packet color

Within CIR

Green

Within PIR

Green or

In-profile

Within CIR

Green

Above PIR

Red and Dropped

Above CIR, Within PIR

Yellow

Within PIR

Yellow or

Out-of-Profile

Above CIR, Within PIR

Yellow

Above PIR

Red or

Dropped

Above PIR

Red

Within PIR

Red or

Dropped

Above PIR

Red

Above PIR

Red or

Dropped

The SAP ingress meter counters increment the packet or octet counts based on the final disposition of the packet.

The no form of this command removes the aggregate policer from use.

Default

no aggregate-meter-rate

Parameters
rate-in-kbps

Specifies the rate in kilobits per second.

Values

1 to 20000000, max (7210 SAS-Dxp)

50 to 3000000, max (7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T)

64 to 20000000, max (7210 SAS-K 3SFP+ 8C)

Default

max

burst-in-kbits

Specifies the burst size for the policer in kilobits. The burst size cannot be configured without configuring the rate.

Values

4 to 2146959, default (7210 SAS-Dxp)

1 to 16384, default (7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, 7210 SAS-K 3SFP+ 8C)

Default

512

filter
Syntax

filter [ip ip-filter-id]

filter [ipv6 ipv6-filter-id]

filter [mac mac-filter-id]

no filter [ip ip-filter-id]

no filter [ipv6 ipv6-filter-id]

no filter [mac mac-filter-id]

Context

config>service>epipe>sap>egress

config>service>epipe>sap>ingress

Platforms

Supported on all 7210 SAS platforms as described in this document

Description

This command associates an IP filter policy with an ingress or egress 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 are not subject to the filter and are always passed, even if the filter default action is to drop.

Note:

For filter support available on different 7210 SAS platforms, refer to the 7210 SAS-D, Dxp, K 2F1C2T, K 2F6C4T, K 3SFP+ 8C Router Configuration Guide.

The no form of this command removes any configured filter ID association with the SAP or IP interface. The filter ID is not removed from the system.

Special Cases
Epipe

Both MAC and IP filters are supported on an Epipe service SAP.

Parameters
ip ip-filter-id

Specifies IP filter policy. The filter ID must already exist within the created IP filters.

Values

1 to 65535

ipv6 ipv6-filter-id

Specifies the IPv6 filter policy. The filter ID must already exist within the created IPv6 filters.

Values

1 to 65535

mac 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

dot1p-inner
Syntax

dot1p-inner [use-rcvd-outer-dot1p | use-rcvd-inner-dot1p]

no dot1p-inner

Context

config>service>epipe>sap>egress

config>service>vpls>sap>egress

Platforms

7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, 7210 SAS-K 3SFP+ 8C

Description

This command defines the dot1p marking values used per SAP on egress for the inner tag when the SAP encapsulation is QinQ (that is, Q1.Q2 SAP).

This command takes effect only if remarking is enabled in the remark policy associated with this SAP (under the egress context). It overrides the marking values defined in the remark policy associated with this SAP, if any.

The following table describes the dot1p values extracted from the packet on SAP (ingress) when dot1p-inner and dot1p-outer CLI commands are configured.

Table 3. Dot1p values extracted from the packet on SAP (ingress) when dot1p-inner and dot1p-outer commands are configured

Ingress SAP type

Dot1p value extracted from the packet

rcvd-inner-dot1p is configured

use-rcvd-outer-dot1p is configured

Null SAP

None

None

Dot1q SAP

Dot1p from the outermost VLAN tag

Dot1p from the outermost VLAN tag

Dot1q Default SAP (that is, * SAP)

None

None

Dot1q Explicit null SAP (that is,:0 SAP)

Dot1p from the outermost VLAN tag (if priority-tagged packet), else none.

Dot1p from the outermost VLAN tag (if priority-tagged packet), else none.

Dot1q range SAP

Dot1p from the outermost VLAN tag

Dot1p from the outermost VLAN tag

Q1.Q2 SAP

Dot1p of the inner tag

Dot1p from the outermost VLAN tag

Q1.* SAP

Dot1p from the outermost VLAN tag

Dot1p from the outermost VLAN tag

0.* SAP

Dot1p from the outermost VLAN tag

Dot1p from the outermost VLAN tag

Q1.0 SAP

Dot1p of the inner priority tag, if available, else from outermost VLAN tag

Dot1p from the outermost VLAN tag

QinQ Default SAP (that is,. *.* SAP)

None

None

The following table describes the dot1p values marked in the packet on SAP egress when dot1p inner and dot1p-outer CLI commands are configured.

Table 4. Dot1p values marked in the packet on SAP egress when dot1p-inner and dot1p-outer commands configured

Egress SAP Type

Dot1p-inner dot1p value marked in the packet sent out from this SAP

Dot1p-outer dot1p value marked in the packet sent out from this SAP

use-rcvd-inner-dot1p is configured

use-rcvd-outer-dot1p is configured

use-rcvd-inner-dot1p is configured

use-rcvd-outer-dot1p is configured

Null SAP

NA

NA

NA

NA

Dot1q SAP

NA

NA

Dot1p bits in the outermost tag

Dot1p bits in the outermost tag

Dot1q Default SAP (that is, * SAP)

NA

NA

NA

NA

Dot1q Explicit null SAP (that is, :0 SAP)

NA

NA

NA

NA

Dot1q range SAP

NA

NA

NA

NA

Q1.Q2 SAP

Dot1p bits from the inner tag

Dot1p bits from the outermost tag

Dot1p bits from the inner tag

Dot1p bits from the outermost tag

Q1.* SAP

NA

NA

Dot1p bits from the inner tag

Dot1p bits from the outermost tag

0.* SAP

NA

NA

NA

NA

Q1.0 SAP

NA

NA

Dot1p bits from the inner tag

Dot1p bits from the outermost tag

QinQ Default SAP (that is, *.* SAP)

NA

NA

NA

NA

Note:

The NA entry in the preceding table means egress encapsulation is not done, and neither the remark policy nor the use-rcvd command will be applicable at that level.

When the no form of this command is executed, the values defined in the remark policy associated with this SAP are used, if any. If no remark policy is associated with SAP egress, the default values are used.

Default

no dot1p-inner

Parameters
use-rcvd-inner-dot1p

For information about this option, see Dot1p values extracted from the packet on SAP (ingress) when dot1p-inner and dot1p-outer commands are configured and Dot1p values marked in the packet on SAP egress when dot1p-inner and dot1p-outer commands configured.

use-rcvd-outer-dot1p

For information about this option, see Dot1p values extracted from the packet on SAP (ingress) when dot1p-inner and dot1p-outer commands are configured and Dot1p values marked in the packet on SAP egress when dot1p-inner and dot1p-outer commands configured.

dot1p-outer
Syntax

dot1p-outer [use-rcvd-outer-dot1p | use-rcvd-inner-dot1p]

no dot1p-outer

Context

config>service>epipe>sap>egress

config>service>vpls>sap>egress

config>service>ies>if>sap>egress

config>service>vprn>if>sap>egress

Platforms

7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, 7210 SAS-K 3SFP+ 8C; IES and VPRN contexts apply only to the 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

This command defines the dot1p marking values to be used per SAP on egress for the outer tag when the SAP encapsulation is QinQ or dot1q. The command takes effect only if remarking is enabled in the remark policy associated with this SAP (under the egress context). It overrides the marking values defined in the remark policy associated with this SAP, if any. For more information, see Dot1p values extracted from the packet on SAP (ingress) when dot1p-inner and dot1p-outer commands are configured and Dot1p values marked in the packet on SAP egress when dot1p-inner and dot1p-outer commands configured.

When the no form of this command is executed, the values defined in the remark policy associated with this SAP are used, if any. If no remark policy is associated with SAP egress, the default values are used.

Default

no dot1p-outer

Parameters
use-rcvd-inner-dot1p

For information about this option, see Dot1p values extracted from the packet on SAP (ingress) when dot1p-inner and dot1p-outer commands are configured and Dot1p values marked in the packet on SAP egress when dot1p-inner and dot1p-outer commands configured.

user-rcvd-outer-dot1p

For information about this option, see Dot1p values extracted from the packet on SAP (ingress) when dot1p-inner and dot1p-outer commands are configured and Dot1p values marked in the packet on SAP egress when dot1p-inner and dot1p-outer commands configured.

meter-override
Syntax

[no] meter-override

Context

config>service>epipe>sap>ingress

config>service>vpls>sap>ingress

config>service>vprn>if>sap>ingress

Platforms

Supported on all 7210 SAS platforms as described in this document.

Description
Note:

The config>service>vprn>if>sap>ingress context is only supported on the 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C.

This command, within the SAP ingress contexts, creates a CLI node for specific overrides to one or more meters created on the SAP through the SAP-ingress QoS policies.

The no form of this command removes any existing meter overrides.

Default

no meter-overrides

meter
Syntax

meter meter-id [create]

no meter meter-id

Context

config>service>epipe>sap>ingress>meter-override

config>service>vpls>sap>ingress>meter-override

config>service>vprn>if>sap>ingress>meter-override

Platforms

Supported on all 7210 SAS platforms as described in this document.

Description
Note:

The config>service>vprn>if>sap>ingress>meter-override context is only supported on the 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C.

This command, within the SAP ingress contexts, creates a CLI node for specific overrides to a specific meter created on the SAP through a SAP-ingress QoS policies.

The no form of this command removes any existing overrides for the specified meter ID.

Parameters
meter-id

Required when executing the meter command within the meter-overrides context. The specified meter-id must exist within the sap-ingress QoS policy applied to the SAP. If the meter is not currently used by any forwarding class or forwarding type mappings, the meter will not actually exist on the SAP. This does not preclude creating an override context for the meter-id.

create

Keyword that is required when a meter 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.

adaptation-rule
Syntax

adaptation-rule [pir adaptation-rule] [cir adaptation-rule]

no adaptation-rule

Context

config>service>epipe>sap>ingress>meter-override>meter

config>service>vpls>sap>ingress>meter-override>meter

config>service>vprn>if>sap>ingress>meter-override>meter

Platforms

Supported on all 7210 SAS platforms as described in this document.

Description
Note:

The config>service>vprn>if>sap>ingress>meter-override>meter context is only supported on the 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C.

This command overrides specific attributes of the specified meter adaptation rule parameters. The adaptation rule controls the method used by the system to derive the operational CIR and PIR settings when the meter 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 this command removes any explicitly defined constraints used to derive the operational CIR and PIR created by the application of the policy. When a specific adaptation-rule is removed, the default constraints for rate and cir apply.

Default

no adaptation-rule

Parameters
pir

Keyword that specifies the constraints enforced when adapting the PIR rate defined within the meter-override meter command. The pir parameter requires a qualifier that defines the constraint used when deriving the operational PIR for the queue. When the meter-override command is not specified, the default applies.

Note:

When the meter mode in use is ‟trtcm2”, this parameter is interpreted as the EIR value. Refer to the 7210 SAS-D, Dxp Quality of Service Guide and 7210 SAS-K 2F1C2T, K 2F6C4T, K 3SFP+ 8C Quality of Service Guide for a description and relevant notes about meter modes.

cir

Keyword that specifies the constraints enforced when adapting the CIR rate defined within the meter-override meter 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 meter, while maintaining a minimum offset.

Values

max — Keyword that is mutually exclusive with the min and closest options. When max (maximum) is defined, the operational PIR for the meter is equal to or less than the administrative rate specified using the meter-override command.

min — Keyword that is mutually exclusive with the max and closest options. When min (minimum) is defined, the operational PIR for the queue is equal to or greater than the administrative rate specified using the meter-override command.

closest — Keyword that is mutually exclusive with the min and max parameter. When closest is defined, the operational PIR for the meter is the rate closest that which is specified using the meter-override command.

cbs
Syntax

cbs size [kbits | bytes | kbytes]

no cbs

Context

config>service>epipe>sap>ingress>meter-override>meter

config>service>vpls>sap>ingress>meter-override>meter

config>service>vprn>if>sap>ingress>meter-override>meter

Platforms

Supported on all 7210 SAS platforms as described in this document.

Description
Note:

The config>service>vprn>if>sap>ingress>meter-override>meter context is only supported on the 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C.

This command overrides the default CBS for the meter. The committed burst size parameter specifies the maximum burst size that can be transmitted by the source while still complying with the CIR. If the transmitted burst is lower than the CBS value, the packets are marked as in-profile by the meter to indicate that the traffic is complying with meter-configured parameters.

The no form of this command reverts the CBS size to the default value.

Default

32 kbits

Parameters
size

Specifies the value in kbits, bytes, or kilobytes.

Values

kbits:

  • 4 to 16384, default (7210 SAS-D)

  • 4 to 2146959, default (7210 SAS-Dxp)

  • 1 to 16384, default (7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, 7210 SAS-K 3SFP+ 8C)

bytes:

  • 512 to 2097152, default (7210 SAS-D)

  • 512 to 274810752, default (7210 SAS-Dxp)

  • 64 to 2097152, default (7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, 7210 SAS-K 3SFP+ 8C)

kbytes:

  • 1 to 2048, default (7210 SAS-D, 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, 7210 SAS-K 3SFP+ 8C)

  • 1 to 268369, default (7210 SAS-Dxp)

mbs
Syntax

mbs size [kbits | bytes | kbytes]

no mbs

Context

config>service>epipe>sap>ingress>meter-override>meter

config>service>vpls>sap>ingress>meter-override>meter

config>service>vprn>if>sap>ingress>meter-override>meter

Platforms

Supported on all 7210 SAS platforms as described in this document.

Description
Note:

The config>service>vprn>if>sap>ingress>meter-override>meter context is only supported on the 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C.

This command overrides the default MBS for the meter. The maximum burst size parameter specifies the maximum burst size that can be transmitted by the source while still complying with the PIR. If the transmitted burst is lower than the MBS value, the packets are marked as in-profile by the meter to indicate that the traffic is complying with meter-configured parameters.

The no form of this command reverts the MBS size to the default value.

Default

32Kbits

Parameters
size

Specifies the value in kbits, bytes, or kilobytes.

Values

kbits:

  • 4 to 16384, default (7210 SAS-D)

  • 4 to 2146959, default (7210 SAS-Dxp)

  • 1 to 16384, default (7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, 7210 SAS-K 3SFP+ 8C)

bytes:

  • 512 to 2097152, default (7210 SAS-D)

  • 512 to 274810752, default (7210 SAS-Dxp)

  • 64 to 2097152, default (7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, 7210 SAS-K 3SFP+ 8C)

kbytes:

  • 1 to 2048, default (7210 SAS-D, 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, 7210 SAS-K 3SFP+ 8C)

  • 1 to 268369, default (7210 SAS-Dxp)

mode
Syntax

mode mode

no mode

Context

config>service>epipe>sap>ingress>meter-override>meter

config>service>vpls>sap>ingress>meter-override>meter

config>service>vprn>if>sap>ingress>meter-override>meter

Platforms

Supported on all 7210 SAS platforms as described in this document.

Description
Note:

The config>service>vprn>if>sap>ingress>meter-override>meter context is only supported on the 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C.

This command overrides the SAP-ingress QoS policy configured mode parameters for the specified meter ID.

The no form of this command reverts the policy defined metering and profiling mode to a meter.

Parameters
mode

Specifies the rate mode of the meter-override.

Values

trtcm1, trtcm2, srtcm (7210 SAS-D, 7210 SAS-Dxp)

trtcm2, srtcm (7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, 7210 SAS-K 3SFP+ 8C)

rate
Syntax

rate cir cir-rate [pir pir-rate]

no rate

Context

config>service>epipe>sap>ingress>meter-override>meter

config>service>vpls>sap>ingress>meter-override>meter

config>service>vprn>if>sap>ingress>meter-override>meter

Platforms

Supported on all 7210 SAS platforms as described in this document.

Description
Note:

The config>service>vprn>if>sap>ingress>meter-override>meter context is only supported on the 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C.

This command within the SAP ingress meter-overrides contexts overrides the SAP-ingress QoS policy configured rate parameters for the specified meter ID.

The no form of this command reverts the policy defined metering and profiling rate to a meter.

Default

max

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.

Parameters
pir-rate

Specifies the administrative PIR rate, in kilobits, 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 specified as a positive integer.

Note:

When the meter mode is set to ‟trtcm2”, the PIR value is interpreted as the EIR value. Refer to the 7210 SAS-D, Dxp Quality of Service Guide and 7210 SAS-K 2F1C2T, K 2F6C4T, K 3SFP+ 8C Quality of Service Guide for more information.

The actual PIR rate is dependent on the queue adaptation-rule parameters and the actual hardware where the queue is provisioned.

Values

0 to 4000000, max (7210 SAS-D)

1 to 3000000, max (7210 SAS-K 2F1C2T and 7210 SAS-K 2F6C4T)

1 to 20000000, max (7210 SAS-Dxp, 7210 SAS-K 3SFP+ 8C)

Default

max

cir-rate

Specifies to override 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 specified as a positive integer.

Values

0 to 4000000, max (7210 SAS-D)

0 to 3000000, max (7210 SAS-K 2F1C2T and 7210 SAS-K 2F6C4T)

0 to 20000000, max (7210 SAS-Dxp, 7210 SAS-K 3SFP+ 8C)

Default

0

qos
Syntax

qos policy-id

no qos

Context

config>service>epipe>sap>ingress

Platforms

Supported on all 7210 SAS platforms as described in this document

Description

This command associates a QoS policy with an ingress SAP.

QoS ingress policies are important for the enforcement of SLA agreements. The policy ID must be defined before associating the policy with a SAP or IP interface. If the policy-id does not exist, an error is returned.

The qos command is used to associate ingress policies. The qos command only allows ingress policies to be associated on SAP ingress. Attempts to associate a QoS policy of the wrong type returns an error.

Only one ingress QoS policy can be associated with a SAP or IP interface at one time. Attempts to associate a second QoS policy of a specific type returns an error.

By default, if no specific QoS policy is associated with the SAP for ingress, 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.

Parameters
policy-id

Specifies the ingress policy ID to associate with SAP on ingress. The policy ID must already exist.

Values

1 to 65535

statistics
Syntax

statistics

Context

config>service>epipe>sap

Platforms

7210 SAS-D

Description

Commands in this context configure the counters associated with SAP ingress and egress.

egress
Syntax

egress

Context

config>service>epipe>sap>statistics

Platforms

7210 SAS-D

Description

Commands in this context configure the egress SAP statistics counter and set the mode of the counter.

This counter counts the number of packets forwarded through the SAP.

ingress
Syntax

ingress

Context

config>service>epipe>sap>statistics

Platforms

7210 SAS-D and 7210 SAS-Dxp

Description

Commands in this context configure the ingress SAP statistics counter.

The ingress counters are not enabled by default for access-uplink SAPs. For access SAPs, if the ingress counter is enabled by default, it can be disabled.

The types of ingress SAP counters are the following:

  • a counter that counts the total packets or octets received on the SAP. This counter is supported only on the 7210 SAS-D.

  • a counter associated with meters defined in the QoS policy of the SAP. This counter counts the in-profile and out-of-profile packets or octets received on the SAP.

forwarded-count
Syntax

[no] forwarded-count

Context

config>service>epipe>sap>statistics>egress

Platforms

7210 SAS-D

Description

This command associates a counter with the SAP. The counter counts the number of packets forwarded through the SAP.

A limited number of such counters are available for use with access SAPs and access-uplink SAPs.

Use this command before enabling applicable accounting record collection on the SAP to associate a counter with the SAP.

The no form of this command disables the packet count.

counter-mode
Syntax

counter-mode {in-out-profile-count | forward-drop-count}

Context

config>service>epipe>sap>statistics>ingress

Platforms

7210 SAS-D and 7210 SAS-Dxp

Description

This command sets the counter mode for counters associated with SAP ingress meters. A pair of counters is available for each meter. These counters count different events based on the configured counter-mode value.

Note:

If an accounting policy is associated with a SAP, the counter mode can be changed. In this case, the counters associated with the meter are reset and the counts are cleared. If an accounting policy is in use when the counter mode is changed, a new record is written into the current accounting file.

Perform the following sequence of commands on the specified SAP to ensure that the correct statistics are collected when the counter mode is changed.

  1. Configure the config>service>epipe>sap no collect-stats command to disable writing of accounting records for the SAP.

  2. Change the counter mode option by configuring the config>service>epipe>sap counter-mode {in-out-profile-count | forward-drop-count} command.

  3. Configure the config>service>epipe>sap collect-stats command to enable writing of accounting records for the SAP.

The no form of this command reverts the counter mode to the default value.

Default

counter-mode in-out-profile-count

Parameters
forward-drop-count

Specifies that one counter counts the forwarded packets and octets received on ingress of a SAP and the other counts the dropped packets. The forwarded count is the sum of in-profile and out-of-profile packets or octets received on SAP ingress. The dropped count is the count of packets or octets dropped by the policer. A packet is determined to be in-profile or out-of-profile based on the meter rate parameters. A packet is dropped by the policer if it exceeds the configured PIR. The in-profile count and out-of-profile count is not individually available when operating in this mode.

in-out-profile-count

Specifies that one counter counts the total in-profile packets and octets received on ingress of a SAP and the other counts the total out-of-profile packets and octets received on ingress of a SAP. A packet is determined to be in-profile or out-of-profile based on the meter rate parameters. A packet is dropped by the policer if it exceeds the configured PIR rate. Dropped counts are not maintained in hardware when this mode is used. The dropped counts are obtained by subtracting the sum of in-profile count and out-of-profile count from the total SAP ingress received count and displayed.

received-count
Syntax

[no] received-count

Context

config>service>epipe>sap>statistics>ingress

Platforms

7210 SAS-D

Description

This command associates a counter with the SAP. It counts the number of packets and octets received on the SAP (ingress).

A limited number of such counters are available for use with access-uplink SAPs.

Use this command before enabling applicable accounting record collection on the SAP.

The no form of this command disables counter.

Spoke-SDP commands
spoke-sdp
Syntax

spoke-sdp sdp-id[:vc-id] [no-endpoint] [create]

spoke-sdp sdp-id[:vc-id] endpoint endpoint-name

no spoke-sdp sdp-id[:vc-id]

Context

config>service>epipe

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

This command binds a service to an existing Service Distribution Point (SDP).

The SDP has an operational state that 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 is down.

The SDP must already exist in the config>service>sdp context before it can be associated with an Epipe or VPL service. If the sdp command is not already configured, an error message is generated. If the sdp-id exists, a binding between the specific sdp-id and the service is created.

SDPs must be explicitly associated and bound to a service to allow far end devices to participate in the service.

The no form of this command removes the SDP binding from the service; the SDP configuration is not affected. When the binding is removed, no packets are forwarded to the far-end router.

Special Cases
Epipe

Only one SDP ID can be bound to an Epipe service. Because an Epipe is a point-to-point service, it can have, at most, two endpoints. The two endpoints can be one SAP and one SDP or two SAPs.

Parameters
sdp-id

Specifies the SDP identifier. Allowed values are integers for existing SDPs.

Values

1 to 17407

vc-id

Specifies the virtual circuit identifier.

Values

1 to 4294967295

no endpoint

Keyword that removes the association of a spoke-SDP with an explicit endpoint name.

endpoint endpoint-name

Specifies the name of the service endpoint.

control-word
Syntax

[no] control-word

Context

config>service>epipe>spoke-sdp

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

This command adds a control word as part of the packet encapsulation for pseudowire types for which the control word is optional. These are Ethernet pseudowires (Epipe).

The configuration for the two directions of the pseudowire must match because the control word negotiation procedures, as 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.

The service comes up only 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 the an ‟Illegal C-bit” status code, according to Section 6.1 of RFC 4447. When the user also enables the control the remote peer, the remote peer withdraws its original label and sends a label mapping with the C-bit set to 1; the VLL service is then up in both nodes.

hash-label
Syntax

hash-label [signal-capability]

no hash-label

Context

config>service>epipe>spoke-sdp

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

This command configures the hash label on VLL or VPLS services that are bound to RSVP SDP, 3107 BGP SDP, segment routing, or LDP SDP, using the auto-bind mode with the ldp, rsvp-te, or mpls options. When this command is enabled, the ingress datapath is modified so that the result of the hash on the packet header is communicated to the egress datapath for use as the value of the label field of the hash label. The ingress datapath appends the hash label at the bottom of the stack (BoS) and sets the S-bit to one (1).

Note:

On 7210 SAS devices, the hash label is not used on the local node for ECMP and LAG hashing. It is available for use by LSR nodes, through which the traffic flows, that are capable of using the labels for hashing.

Packets generated in the CPM that are forwarded with a label 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 0.

Signaling of the hash label capability is enabled by adding the signal-capability option under the VLL spoke-SDP, VPLS spoke-SDP or mesh SDP interface, or PW template instance. In this case, the decision of the local PE to insert the hash label on the user and control plane packets is determined by the outcome of the signaling process and can override the local PE configuration. The following process flow applies when the hash-label and signal-capability options are enabled on the local PE.

  • The 7210 SAS local PE inserts the flow label interface parameters sub-TLV with T=1 and R=1 in the PW ID FEC element in the label mapping message for the specific spoke-SDP or mesh SDP.

  • If a remote PE does not send the flow label sub-TLV in the PW ID FEC element, or sends a flow label sub-TLV in the PW ID FEC element with T=FALSE and R=FALSE, the local node disables the hash label capability. Consequently, the local PE node does not insert a hash label in the user and control plane packets that it forwards on the spoke-SDP or mesh SDP. The local PE also drops user and control plane packets received from a remote PE if they include a hash label. The dropped packets may be caused by the following:

    • a remote 7210 SAS PE that does not support the hash-label command

    • a remote 7210 SAS PE that has the hash-label command enabled but does not support the signal-capability option

    • a remote 7210 SAS PE that supports the hash-label command and the signal-capability option, but the user did not enable them due to a misconfiguration

  • If the remote PE sends a flow label sub-TLV in the PW ID FEC element with T=TRUE and R=TRUE, the local PE enables the hash label capability. Consequently, the local PE node inserts a hash label in the user and control plane packets that it forwards on the spoke-SDP or mesh SDP. The local PE node also accepts user and control plane packets from the remote PE with a hash label. The local PE node drops user and control plane packets from the remote PE without a hash label.

If the hash-label command is enabled on the local PE with the signal-capability option configured and on the remote PE without the signal-capability option configured on the spoke-SDP or mesh-SDP, the hash label is included in the pseudowire packets received by the local PE. These packets must be dropped. To resolve this situation, you must disable the signal-capability option on the local node, which results in the insertion of the hash label by both PE nodes.

If the hash-label option is not supported or is not enabled on the local configuration of the spoke-SDP or mesh-SDP at the remote PE, the hash label is not included in the pseudowire received by the local PE.

If the signal-capability option is enabled or disabled in the CLI, the router 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.

Note:

  • This feature is supported only for VLL and VPLS services. It is not supported for VPRN services. It 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.

  • In 7750 and possibly other vendor implementations, 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 is always in the range [524,288 to 1,048,575] and does not overlap with the signaled/static LSP and signaled/static service label ranges. This also guarantees that the hash label does not match a value in the reserved label range. 7210 SAS devices do not set the MSB in the hash label value for service traffic. Therefore, the user must ensure that both ends are correctly configured to either process hash labels or disable them. The MSB bit is set for MPLS/OAM traffic on 7210 SAS devices.

  • The cpe-ping, mac-ping, and svc-ping commands are not supported on the 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C when the hash-label command is enabled.

The no form of this command disables the use of the hash label.

Default

no hash-label

Parameters
signal-capability

Keyword that specifies to enable the signaling and negotiation of the use of the hash label between the local and remote PE nodes.

precedence
Syntax

precedence [precedence-value | primary]

no precedence

Context

no precedence >service>epipe>spoke-sdp

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

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 be assigned to only one SDP bind, making it the primary SDP bind. When an SDP binding goes down, the next highest precedence SDP binding begins to forward traffic.

The no form of this command reverts the precedence to the default value.

Default

4

Parameters
precedence-value

Specifies the spoke-SDP precedence.

Values

1 to 4

primary

Specifies to make this the primary spoke-SDP.

pw-status-signaling
Syntax

[no] pw-status-signaling

Context

config>service>epipe>spoke-sdp

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

This command enables pseudowire status signaling for this spoke-SDP binding.

The no form of this command disables the status signaling.

Default

pw-status-signaling

vc-label
Syntax

[no] vc-label vc-label

Context

config>service>epipe>spoke-sdp>egress

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

This command configures the egress VC label.

Parameters
vc-label

Specifies a VC egress value that indicates a specific connection.

Values

16 to 1048575

vc-label
Syntax

[no] vc-label vc-label

Context

config>service>cpipe>spoke-sdp>ingress

config>service>epipe>spoke-sdp>ingress

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

This command configures the ingress VC label.

Parameters
vc-label

Specifies a VC ingress value that indicates a specific connection.

Values

2048 to 18431

vlan-vc-tag
Syntax

vlan-vc-tag vlan-id

no vlan-vc-tag [vlan-id]

Context

config>service>epipe>spoke-sdp

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

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

no vlan-vc-tag

Parameters
vlan-id

Specifies a valid VLAN identifier to bind an 802.1Q VLAN tag ID.

Values

0 to 4094

spoke-sdp-fec
Syntax

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

Context

config>service>epipe

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

This command binds a service to an existing 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 that 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 is down.

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 terminates 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 7210 of the MS-PW. The 7210 associates an SDP with a service. If an SDP to that service is not already configured, an error message is generated. If the SDP ID exists, a binding between that SDP ID and the service is created.

This command differs from the spoke-sdp command because the spoke-sdp command creates a spoke-SDP binding that uses a PW with the PW ID FEC. However, the spoke-sdp-fec command enables PWs 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. When removed, no packets are forwarded to the far-end router.

Parameters
spoke-sdp-fec-id

Specifies an unsigned integer value identifying the spoke-SDP.

Values

1 to 4294967295

fec fec-type

Specifies an unsigned integer value for the type of the FEC used by the MS-PW.

Values

129 to 130

aii-type aii-type

Specifies an unsigned integer value for the Attachment Individual Identifier (AII) type used to identify the MS-PW endpoints.

Values

1 to 2

endpoint endpoint-name

Specifies the name of the service endpoint.

no endpoint

Keyword that adds or removes a spoke-SDP association.

auto-config
Syntax

[no] auto-config

Context

config>service>epipe>spoke-sdp-fec

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

This command enables single-sided automatic endpoint configuration of the spoke-SDP. The 7210 SAS 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 sends the initial label mapping message using T-LDP, while the 7210 T-PE for which auto-config is specified acts as the passive T-PE.

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

The no form of this command means that the 7210 T-PE either acts as the active T-PE (if signaling active is configured) or automatically determines which 7210 SAS initiates 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, the 7210 SAS initiates MS-PW signaling without waiting for a label mapping message from the far end. However, if the TAII has the greater value prefix, the 7210 SAS assumes that the far end T-PE initiates MS-PW signaling and waits 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

path
Syntax

path name

no path

Context

config>service>epipe>spoke-sdp-fec

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

This command specifies the explicit path, containing a list of S-PE hops, that should be used for this spoke-SDP. The path name value should correspond to the name of an explicit path configured in the config>service>pw-routing context.

If no path is configured, each next hop of the MS-PW used by the spoke-SDP is chosen locally at each T-PE and S-PE.

Parameters
name

Specifies the name of the explicit path to be used, as configured under the config>service>pw-routing context.

precedence
Syntax

precedence prec-value

precedence primary

no precedence

Context

config>service>epipe>spoke-sdp-fec

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

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 begins to forward traffic.

The no form of this command reverts the precedence to the default value.

Default

42

Parameters
prec-value

Specifies the spoke-SDP precedence.

Values

1 to 4

primary

Keyword that specifies to make this the primary spoke-SDP.

pw-template-bind
Syntax

pw-template-bind policy-id

no pw-template-bind

Context

config>service>epipe>spoke-sdp-fec

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

This command binds a specific PW template to a spoke-SDP.

The no form of this command removes the values from the configuration.

Parameters
policy-id

Specifies the existing policy ID.

Values

1 to 2147483647

retry-count
Syntax

retry-count retry-count

no retry-count

Context

config>service>epipe>spoke-sdp-fec

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

This optional command specifies the number of attempts that should be made 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 to the default value.

Default

30

Parameters
retry-count

Specifies the maximum number of retries before putting the spoke-SDP into the shutdown state.

Values

10 to 10000

retry-timer
Syntax

retry-timer retry-timer

no retry-timer

Context

config>service>epipe>spoke-sdp-fec

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

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 reestablish 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

30

Parameters
retry-timer

Specifies the initial retry-timer value, in seconds.

Values

10 to 480

saii-type2
Syntax

saii-type2 global-id:prefix:ac-id

no saii-type2

Context

config>service>epipe>spoke-sdp-fec

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

This command configures the source attachment individual identifier for the spoke-SDP. This is applicable only to FEC129 AII type 2.

Parameters
global-id

Specifies the global ID of this 7210 SAS T-PE. This value must correspond to one of the global_id values configured for a local-prefix under the config>service>pw-routing>local-prefix context.

Values

1 to 4294967295

prefix

Specifies the prefix on this 7210 SAS T-PE that the spoke-SDP is associated with.This value must correspond to one of the prefixes configured under the config>service>pw-routing>local-prefix context.

Values

an IPv4-formatted address a.b.c.d or 1 to 4294967295

ac-id

Specifies an unsigned integer representing a locally unique identifier for the spoke-SDP.

Values

1 to 4294967295

signaling
Syntax

signaling signaling

Context

config>service>epipe>spoke-sdp-fec

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

This command configures this 7210 SAS as the active or 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, the endpoing waits 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, the 7210 SAS initiates MS-PW signaling without waiting for a label mapping message from the far end. However, if the TAII has the greater value prefix, the 7210 SAS assumes that the far end T-PE initiates 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 this command means that the 7210 T-PE automatically selects the 7210 SAS that will initiate MS-PW signaling based on the prefix values configured in the SAII and TAII of the spoke-SDP.

Default

auto

Parameters
signaling

Configures this 7210 SAS as the active T-PE for signaling this MS-PW.

Values

auto, master

taii-type2
Syntax

taii-type2 global-id:prefix:ac-id

no taii-type2

Context

config>service>epipe>spoke-sdp-fec

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

This command 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

Specifies the global ID of this 7210 T-PE. This value must correspond to one of the global_id values configured for a local-prefix under the config>service>pw-routing>local-prefix context.

Values

1 to 4294967295

prefix

Specifies the prefix on this 7210 T-PE that the spoke-sdp SDP is associated with. This value must correspond to one of the prefixes configured under the config>service>pw-routing>local-prefix context.

Values

an IPv4-formatted address a.b.c.d or 1 to 4294967295

ac-id

Specifies an unsigned integer representing a locally unique identifier for the spoke-SDP.

Values

1 to 4294967295