MS-PS (Pseudowire stitching)

Load ms.pw.init.cfg

#IOS-XE (R1-R6, CE1,5,8,10)
config replace flash:ms.pw.init.cfg

#IOS-XR (XR1, XR2)
configure
load ms.pw.init.cfg
commit replace
y

ISIS, LDP, and CEs are preconfigured. There are now two separate ISIS areas, and some routers are L1-only routers. Additionally, a VPWS between R2 and R6 is configured, but is not coming up. Explain why.

Fix the VPWS between R2 and R6, which is for CE8 and CE10.
Setup a VPWS between CE1 and CE5.

Do not make any changes to the IGP to accomplish this task.

Answer/Explanation

The xconnect between R2 and R6 is not coming up because R2 does not have a /32 route to 6.6.6.6. Because R2 is an L1-only router, it can reach R6 using the 0/0 route, but this is not sufficient for an LSP to R6. A /32 route is needed in the FIB to allow the router to resolve an LSP to the egress PE.

We can see the error with the VPWS:

To fix this we must either leak L2 routes into L1 (which is prohibited by the task instructions), or use pseudowire stitching. We can stitch two pseudowires together at either R3 or R4. We’ll use R3 just to demonstrate an LSP that has a longer path.

#R2
l2vpn xconnect context CE8_CE10
 no member 6.6.6.6 810 encapsulation mpls
 member 3.3.3.3 810 encap mpls

#R3
l2vpn xconnect context CE8_CE10
 member 2.2.2.2 810 encap mpls
 member 6.6.6.6 810 encap mpls

#R6
l2vpn xconnect context CE8_CE10
 no member 2.2.2.2 810 encap mpls
 member 3.3.3.3 810 encap mpls

CE8 and CE10 should now have reachability with each other:

Interestingly we can use the following command to see the stiching point(s) for the end-to-end pseudowire. R2 learns of the stitching points via LDP in the mapping message from R3.

These are two separate LSPs, so the control word cannot be carried end to end. However, sequencing can be used - the stitching router will blindly forward the sequencing number in each direction.

We can use the following command on R3 to quickly see both PWs at once, including their local/remote service labels:

We also have “status proxying” enabled by default when using pseudowire stitching. If we bring down the AC on R2, notice that R3 brings down the PW with 6.6.6.6.

#R2
int Gi4
 shut

EXP Passthrough

At the stitching point, the EXP value may or may not be passed through to the next pseudowire.

We can test this by configuring R1 to set EXP to some value, such as EXP=5, for all labeled traffic towards R3.

#R1
policy-map SET_EXP
 class class-default
  set mpls exp topmost 5
!
int gi2
 service-policy output SET_EXP

At R3, I see the MPLS headers outgoing on Gi2 have no EXP value. In Russo’s guide, his CSR1000v does copy the EXP marking through to the next PW.

Configuring CE1-CE5

To create a VPWS between CE1 and CE5, we need three separate LSPs. R1-R3, R3-R5, and R5-XR1.

#R1
int gi4
 no ip address
 service instance 1 eth
  encap default
!
l2vpn xconnect context CE1_CE5
 member gi4 service-instance 1
 member 3.3.3.3 15 encap mpls

#R3
l2vpn xconnect context CE1_CE5
 member 1.1.1.1 15 encap mpls
 member 5.5.5.5 15 encap mpls

#R5
l2vpn xconnect context CE1_CE5
 member 3.3.3.3 15 encap mpls
 member 11.11.11.11 15 encap mpls

#XR1
int gi0/0/0/3 l2transport
 no shut
!
l2vpn xconnect group VPWS
 p2p CE1_CE5
  int gi0/0/0/3
  neighbor 5.5.5.5 pw-id 15