VSR pseudowire ports

This chapter provides information about Virtualized Service Router (VSR) pseudowire ports (PW ports), process overview, and implementation notes.

Pseudowire ports

This chapter provides information about pseudowire ports (PW ports), process overview, and implementation notes.

PW port list

Each port eligible to transmit traffic on a Flex PW port, must be added to a pw-port-list.

config>service>system> PW port list# port ?
 - no port <port-id> [<port-id>... (16 max)]
- port <port-id> [<port-id>... (16 max)]

Only hybrid ports (configure port port-id ethernet mode hybrid) can be members of a PW port list.

A port used by Flex PW port can be shared with any other Layer 2 or Layer 3 service. For example, a Layer 3 interface using a regular SAP can be associated with a VPRN service, while the underlying port is also used by a Flex PW port. Another regular SAP from the same port can be associated with a VPLS or Epipe service at the same time.

Follow these rules when populating a PW port list:

A port must be in hybrid mode before it is added to a PW port list.
Before a port is removed from or added to a PW port list, all PW ports must be dissociated from the corresponding Epipe services (the PW ports must be unconfigured). This implies that all PW SAPs be deleted.
Network interfaces (configured in Base routing context) can be configured only on ports that are in the PW port list.
A port mode (access, network, or hybrid) cannot be changed while the port is in the PW port list.

From this, a user can consider adding all ports that are in hybrid mode to a PW port list from the beginning of the system configuration. This ensures that those ports can be used by Flex PW port at any later time, independently of their current use.

Failover times

Traffic loss during port switchover depends on the following factors:

Routing convergence; this depends on the number of routes in the network and the deployed routing protocol.
The time it takes to associate PW SAPs with a new port. This action is performed within the VSR and the timing depends on the number of PW SAPs that are being moved from the old port to the new port. Note that PW SAPs are not recreated, instead the existing PW-SAPs are re-mapped to a new port.

The egress queues on the new port must be recreated. However, this does not incur additional downtime because a spare egress queue is always present on a port (referred to as a failover queue) and is used while per PW SAP egress queues are being created.

Depending on the scale and network load, downtime during a switchover can range from the sub-second range to a several seconds.

QoS

Egress queues are attached to the port that is used by a Flex PW port to forward traffic (a Flex PW port is bound to one of the ports in the PW port list). In similar fashion, if an egress port scheduler is used, it is attached to the same port. However, the egress port schedulers must be associated by configuration with every port in the PW port list while egress queues are instantiated only on a single port. During a port switchover, egress queues are recreated on the new port and while this is occurring, the failover queue is used to forward traffic. Each port has a single egress failover queue that is used to forward traffic while SAP or subscriber queues are being recreated during transitioning events.

On the other hand, egress port scheduler must be configured by the user in advance on each port in the PW port list so that it can be ready to treat traffic immediately after its children queues are recreated on this port.

Policers are used on ingress and they do not need to be recreated during port switchover. Instead, they are re-mapped to a new port.

An example QoS configuration is provided below:

Egress port scheduler definition

   
   port-scheduler-policy ‟flex" create
       max-rate 1000000
       group "test" create
       exit
       level 1 rate 100000
   exit

Association between the egress port scheduler and ports

   
   configure  port 1/1/1 
       ethernet
          mode hybrid
          encap-type qinq
          egress-scheduler-policy ‟flex"
       exit
   no shutdown
   configure  port 1/1/2 
       ethernet
          mode hybrid
          encap-type qinq
          egress-scheduler-policy ‟flex"
       exit
   no shutdown

Association between subscriber queues or policers and the egress port scheduler

   
   configure  qos sap-egress 2 
       queue 1 create
          port-parent level 1
          rate 10000
       exit
       queue 2 create 
          port-parent level 1
          rate 10000
       exit
       queue 3 create
          port-parent level 2
          rate 1000
       exit

Applying queue policy to an object:

Subscriber management

   
   configure  subscriber-mgmt sla-profile "sla-profile-1"  
       egress 
          qos 2  
       exit

PW SAP in a Layer 2 service

   
   configure  service epipe 10
       sap pw-1:1.2
          egress
          qos 2
       exit

PW SAP in a Layer 3 service

   
   configure  service vprn 11
       interface ‛flex-int’
          address 1.1.1.1/24
          sap pw-1:1.3
             egress
                qos 2
             exit
       exit
   exit

PW port termination for various tunnel types

The MPLS-based spoke SDP and L2oGRE-based spoke SDP tunnel types are supported on a Flex PW port.

MPLS-based spoke SDP

An MPLS-based spoke SDP can be rerouted between the ports defined in the PW port list and still be mapped to the same PW port based on the service label. Ethernet payload within the spoke SDP can be extracted onto a PW SAP with minimal traffic loss during port switchover.

Provisioning

The termination of a MPLS-based spoke SDP on a Flex PW port follows the common provisioning framework:

Create a PW port list.
Add ports that are in hybrid mode to the PW port list.
Create a PW port.
Configure a tunnel.
Terminate a tunnel on a PW port via an Epipe service. A PW port must be configured within the Epipe before a spoke SDP is added to the same Epipe.

The steps for MPLS-based spoke SDP termination on a Flex PW port are displayed in Provisioning MPLS-based spoke SDP termination on a flex PW port.

Figure 1. Provisioning MPLS-based spoke SDP termination on a flex PW port
When a Flex PW port is associated with a tunnel, a payload from the tunnel can be extracted using service delimiting tags (Ethernet VLANs to S-tags, C-tags in the inner Ethernet header) on a PW SAP on a Layer 2 or Layer 3 service. See PW SAP configuration example

Figure 2. PW SAP configuration example

Flex PW-port operational state for MPLS based spoke SDP

The operational state of the Flex PW port is driven by the ability of the Epipe service (that ties the PW port to the spoke SDP) to forward traffic. The following events renders the PW port non-operational and triggers propagation of the PW status bits toward the remote end:

The Epipe service is shut down. This raises the following flags on the local end:

lacIngressFault
lacEgressFault
psnEgressFault

The corresponding PW status bits that are propagated to the remote end raises the counterpart flags on the remote end.

The PW port within the Epipe service is shutdown. This raises the following flags on the local end:

lacIngressFault
lacEgressFault

The corresponding PW status bits that are propagated to the remote end raises the counterpart flags on the remote end.

MTU mismatch. This raises the following flags on the local end:

lacIngressFault
lacEgressFault
pwNotForwarding

The corresponding PW status bits that are propagated to the remote end raises the counterpart flags on the remote end.

In addition, PW port transitions into a non-operation state without propagating any PW status bits if the remote end cannot be reached.

The operation state of the Flex PW port state can be observed through the state of the underlying tunnel and the corresponding service via the following show command:

show pw-port 10 detail 
===============================================================================
PW Port Information
===============================================================================
PW Port            : 10
Encap              : dot1q
IfIndex            : 1526726666
Description        : PW Port
Dot1Q Ethertype    : 0x8100
Service Id         : 10239
Admin Status       : up
Oper Status        : up
===============================================================================

Statistics

Statistics for the number of forwarded or dropped packets per octets per direction on a Flex PW port associated with a MPLS based spoke SDP are maintained per the spoke SDP. Octets field counts octets in customer frame (including customer’s Ethernet header with VLAN tags).

The following command is used to display Flex PW port statistics along with the status of the spoke SDP associated with the PW port:

config>service>epipe# show pw-port 10 statistics 
===============================================================================
Pw-Port 10
===============================================================================
 
Statistics            :
I. Fwd. Pkts.        : 110                   I. Dro. Pkts.      : 0
I. Fwd. Octs.        : 23060                 I. Dro. Octs.      : 0
E. Fwd. Pkts.        : 76                    E. Fwd. Octets     : 16660
 
Grp Enc Stats         :
I. Dro. Inv. Spi.    : 0                     I. Dro. OthEncPkts.: 0
E. Dro. Enc. Pkts.   : 0                     
===============================================================================

L2oGRE-based spoke SDP

L2oGRE is supported for IPv4 and IPv6 transport with a termination IP address that must reside in the base router. Multiple L2oGRE tunnels can share the same termination IP address.

Each L2oGRE tunnel is represented by a unique pair of tunnel-end IP addresses. As the local endpoint address in VSR is usually shared between the tunnels, the tunnel far-end IP address becomes a differentiating field.

In VSR, an L2oGRE tunnel is represented by an SDP, which is then mapped as a spoke-SDP to a Flex PW port. Although it is mandatory to configure a VC-ID, in spoke-SDP the VC-ID loses its meaning because of the nature of L2oGRE tunnel: no sub-tunnels based on an MLPS label can be multiplexed within the two L2oGRE endpoints.

Provisioning

Perform the following common provisioning steps to terminate an L2oGRE tunnel on a Flex PW port:

Create a PW port list.
Add ports that are in hybrid mode to the PW port list.
Create a PW port.
Configure an L2oGRE tunnel using spoke-SDP.
Terminate a tunnel on a PW port using an Epipe service.

A PW port must be configured within the Epipe before a spoke-SDP is added to the same Epipe.

The steps for L2oGRE termination on a Flex PW port are displayed in Provisioning L2oGRE spoke-SDP termination on a flex PW port.

Figure 3. Provisioning L2oGRE spoke-SDP termination on a flex PW port

After a Flex PW port is associated with a tunnel, a payload from the tunnel can be extracted using service delimiting tags (such as S-tags or C-tags in the inner Ethernet header) on a PW SAP in a Layer 2 or Layer 3 service.

Flex PW-port operational state for L2oGRE-based spoke SDP

The operational state of the Flex PW port is determined by the ability of the stitching service (that is, the Epipe that ties the PW port to the tunnel using L2oGRE spoke-SDP) to forward traffic. This relationship can cause the stitching service’s operational status to transition to a down state in the following cases:

the SDP far-end is not reachable
the route-table entry is missing
SDP is down
the Epipe service is administratively or operationally down

Reassembly

Reassembly of L2oGRE over IPv4 transport is supported through a generic reassembly function that requires a vISA. Filters redirect fragmented traffic, as it enters the VSR node, to a vISA. After the traffic is reassembled in the vISA, it is re-inserted into the vFP where normal processing continues, as if the non-fragmented traffic had originally entered the node.

Perform the steps in Configuration steps for L2oGRE reassembly to configure reassembly for L2oGRE.

Table 1. Configuration steps for L2oGRE reassembly
Step	Example CLI	Comments
1. Create a NAT-group that contains MS-ISAs	`configure isa nat-group 1 mda 1/1`	The reassembly function is performed in a NAT group that contains a vISA.
2. Reference a reassembly-group that is used for traffic in the base routing context	`configure router reassembly-group 1`	The reassembly-group that is used for traffic in the base routing context is identified. Upon reassembly, traffic is re-inserted in the same base routing context. The reassembly-group id corresponds to the nat-group id (in this case, the ID is 1).
3. Identify and direct fragmented traffic to the reassembly function	`configure filter ip-filter id default-action forward entry id create match protocol gre fragment true exit action reassemble exit`	Fragmented GRE traffic is identified using a filter and is then redirected to the reassembly function. This filter must be applied to all ingress interfaces on which GRE traffic is expected to arrive.