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

<figure><img src="https://3072390383-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkUz2C3GqnZcWhoVL6jfk%2Fuploads%2FtQourOtPfC5D2zcdf2ly%2Fimage.png?alt=media&#x26;token=d5377de4-288e-4259-b2c4-1617ddf2a956" alt=""><figcaption></figcaption></figure>



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 <a href="#id-047914a6-b06c-4776-a6e0-12e550f65b51" id="id-047914a6-b06c-4776-a6e0-12e550f65b51"></a>

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:

<div align="left"><figure><img src="https://3072390383-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkUz2C3GqnZcWhoVL6jfk%2Fuploads%2F7FAlXikuXJNxJbC4CKN9%2Fimage.png?alt=media&#x26;token=a698eadf-1324-40eb-9021-0fced099fcdb" alt=""><figcaption></figcaption></figure></div>



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:

<div align="left"><figure><img src="https://3072390383-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkUz2C3GqnZcWhoVL6jfk%2Fuploads%2FLfhcU1RrBbrBAR2GfCvZ%2Fimage.png?alt=media&#x26;token=b67d9884-d070-4cc2-ac87-43f9cbad4a28" alt=""><figcaption></figcaption></figure></div>



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.

<div align="left"><figure><img src="https://3072390383-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkUz2C3GqnZcWhoVL6jfk%2Fuploads%2FVtQNM7CRtvSPAZZXsL3a%2Fimage.png?alt=media&#x26;token=2ca369cd-5fcb-4a8f-bc22-9ec1f79dd469" alt=""><figcaption></figcaption></figure></div>



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:

<div align="left"><figure><img src="https://3072390383-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkUz2C3GqnZcWhoVL6jfk%2Fuploads%2FVugMnKPX8AoThIohCNe8%2Fimage.png?alt=media&#x26;token=4e075451-b205-448f-a610-74c85b406fbd" alt=""><figcaption></figcaption></figure></div>



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

<div align="left"><figure><img src="https://3072390383-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkUz2C3GqnZcWhoVL6jfk%2Fuploads%2FhsWntaZW1AAKmKi2zsTh%2Fimage.png?alt=media&#x26;token=97af65a7-785f-4e01-89e4-d62da908fc97" alt=""><figcaption></figcaption></figure></div>



### EXP Passthrough <a href="#fc577b1b-7b7b-4437-ae90-b37a5832ed99" id="fc577b1b-7b7b-4437-ae90-b37a5832ed99"></a>

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 <a href="#id-870e43f9-e87e-4b04-9bdc-c31bf8cdebab" id="id-870e43f9-e87e-4b04-9bdc-c31bf8cdebab"></a>

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



### Verification <a href="#adcda302-4723-46f5-98fd-d085fc677f8e" id="adcda302-4723-46f5-98fd-d085fc677f8e"></a>

CE1 and CE5 should have reachability:

<div align="left"><figure><img src="https://3072390383-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkUz2C3GqnZcWhoVL6jfk%2Fuploads%2Fo9P5O35BZ4EPGDxfsq2r%2Fimage.png?alt=media&#x26;token=f7d8a27f-2921-41fe-93d4-4aea9bf1ec88" alt=""><figcaption></figcaption></figure></div>



At R1 and XR1 we see two stitching points:

<div align="left"><figure><img src="https://3072390383-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkUz2C3GqnZcWhoVL6jfk%2Fuploads%2FEVCh2YysKuJ6UkMLQ86o%2Fimage.png?alt=media&#x26;token=e7c6bf23-3d50-44a4-be4f-3d8abaf2cf9c" alt=""><figcaption></figcaption></figure></div>

<div align="left"><figure><img src="https://3072390383-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkUz2C3GqnZcWhoVL6jfk%2Fuploads%2Fp21wEOG7W1kSI9N98v4C%2Fimage.png?alt=media&#x26;token=b237c8ff-b07d-4d20-8ef3-dd49c55c9772" alt=""><figcaption></figcaption></figure></div>



If XR1 brings down Gi0/0/0/3, this causes a “chain reaction”, resulting in the PW being down on R1 as well.

```
#XR1
int gi0/0/0/3
 shut
```



The stitching routers consider each PW as an access circuit. So when one PW goes down, the fault is that a local AC has gone down:

<div align="left"><figure><img src="https://3072390383-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkUz2C3GqnZcWhoVL6jfk%2Fuploads%2F4PJYq4aKfi3XVrBppQax%2Fimage.png?alt=media&#x26;token=bb467d23-9f77-4df6-81a8-eae42ef216d8" alt=""><figcaption></figcaption></figure></div>



As a result, R1 sees that the remote peer’s AC has gone down:

<div align="left"><figure><img src="https://3072390383-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkUz2C3GqnZcWhoVL6jfk%2Fuploads%2FJ2lpDuPBuLKcCZRxyTsc%2Fimage.png?alt=media&#x26;token=5b508e1a-2a92-4b82-9d83-9d78c7a54102" alt=""><figcaption></figcaption></figure></div>
