VPWS with Tag Manipulation
Load vpws.tag.manipulation.init.cfg
Configure the following VPWS services.
CE1 & CE12
Only allow VLANs 10-12 to work
CE11 & CE5
Ensure CE11 on vlan 11 and CE5 on vlan 5 work by removing the tag upon ingress
CE10 & CE6
Ensure CE10 on vlan 10 and CE6 on vlan 6 work without popping the tag
CE8 & CE9
Ensure CE8 on vlan 8 and CE9 unencapsulated traffic work without manipulating the vlan from CE8 upon ingress or egress.
Answer
Explanation
CE1 & CE12 - VLAN restriction
This task requires that only VLANs 10-12 are allowed to be used in the xconnect. This is accomplished by only matching these VLANs in the EFP.
The connect command does not work for service instances, so instead we can bridge the two EFPs together:
We can confirm the bridge-domain configuration and see if MACs are learned (you might need to initiate pings first):
There are four subinterfaces configured on CE1 and CE12:
Verify that traffic on vlan 13 does not work, but traffic on vlans 10-12 does work:
CE11 & CE5 - Removing tags upon ingress
CE11 and CE5 have different VLAN tags at the AC. CE11 uses vlan 11 and CE5 uses vlan 5. There are several ways to make this work, but the simplest is to just remove the tag upon ingress symmetrically. The symmetrical keyword means that the VLAN is added back upon egress. So when the frame comes in with VLAN 5 or 11, the VLAN tag is removed and now there is no VLAN. The frame is transported to the other PE without an tag. When a frame is forwarded out the EFP the locally defined tag via the encapsulation command is pushed upon egress. (When using tag popping, you can only match a single tag with the encapsulation statement, not a range of tags).
We can see the details of the EFP using this show command on IOS-XE:
We can see similar output on IOS-XR using this show command:
In general, these above show commands don’t really give us any more info than the running config does, so it may not be worth using these over simply viewing the running config.
CE10 & CE6 - Tag translation
This task requires that traffic between CE10 Gi0/0.10 and CE6 Gi0/0.6 work without removing tags. An alternative to popping tags would be to translate tags. At R2 we can translate tag 10 to tag 6, and on XR2 we can translate tag 6 to tag 10.
This appears that it would be enough to get the VPWS working, however there is an MTU mismatch:
The reason for this is that IOS-XE and IOS-XR treat MTU differently. On the IOS-XR side, the MTU for the subinterface is 1518 and 14 is subtracted for the Ethernet header. This was the case on XR1 as well in the previous tag, however the tag was popped so the router also subtracted an additional 4 bytes, leaving the result as 1500. This is why we didn’t have to manipulate MTU in the previous task.
To make both sides match for this task, we can increase the IOS-XE side to 1504 or subtract 4 from the IOS-XR side. Note that if you change the XR side, you must add 14 bytes to the mtu command.
Traffic between CE6 and CE10 should now be working. When CE10 sends a frame, R2 will translate the dot1q value of 10 to a value of 6. XR2 sends this unmanipulated to CE6. The same action happens when CE6 sends a frame - 6 is translated to 10 at XR2 upon ingress.
We can see the rewrite action on IOS-XE with a slightly different command from before:
The same command as seen on the previous on IOS-XR works. Interestingly we can see that the internal action for translation is to first pop the tag and then push the translated tag:
CE8 & CE9 - Pushing a tag
This task requires that CE8 Gi0/0.8 and CE9 Gi0/0 can directly work. We are prohibited from manipulating the frame at the CE8 AC. Our only option is to push the correct tag upon ingress at the CE9 side.
The symmetric keyword causes the tag of 8 to be stripped upon forwarding a frame out the AC (egress towards CE9). Upon ingress, the tag value of 8 is pushed onto the frame.
Note that you can use either encap default or encap untagged. This is because the symmetric keyword causes the router to pop tag 8 off upon egress, so we don’t need to restrict the service instance to a particular single VLAN ID. However, we should techincally use untagged to meet the task requirements, since only untagged traffic should have vlan 8 pushed on top.
Summary
In this lab we’ve seen how VLAN tags can be manipulated at the AC. We can pop/push/translate tags upon ingress and egress. (Egress was not demonstrated in this lab). When popping or pushing upon ingress, we can do this symmetrically so that the reverse action is preformed upon egress. We also have the ability to manipulate two tags. For example, we can pop two tags or push two tags.
Besides VLAN tag manipulation, we also have flexibility in how we match L2 traffic onto an EFP or l2transport interface on IOS-XR. We can match based on the basic dot1q tag value. We can match a range of dot1q values which we saw in this lab. We can also match specifically untagged traffic. We can match two tags (encapsulation dot1q 23 second-dot1q 40 or encapsulation dot1ad 23 dot1q 40). When matching the outer tag using encapsulation dot1q 100 it will also match vlan 100 traffic with an additional inner tag of any value. To only match single tagged traffic with vlan 100 we can use the exact keyword. In addition to matching the vlan tag, we can also match the cos value and the ethernet payload type in the L2 header.
Last updated
