Launching soon: The world's first vendor agnostic bug scrubLearn more & join waitlist
OPERATIONAL DEFECT DATABASE
...
...
Experienced unidirectional traffic to fail from ASR920 to ASR9K when they sending QinQ traffic over the MPLS VC pseudo wires. This behaviour is noticed on multiple occasions. Initial trouble shooting confirmed the VC is up and LDP is fine and the traffic from the opposite direction is looking good. Tested the bi-directional Ping it is working as expected from the CE's devices.
Using two tags on there traffic one outer tag vlan 100. If we look at the TPID, we can see that 100 has TPID 8100 and the TPID from customer utter tag has TPID 9100. And that combination does not the 920 accept! The ASR9k do accept that combination, that why it work there! This command need to be enabled under the Gig port, under which we have the service instances with xconnect. "dot1q tunneling ether type 0x9100" router#conf Configuring from terminal, memory, or network [terminal]? Enter configuration commands, one per line. End with CNTL/Z. router(config)#inte te router(config)#inte tenGigabitEthernet 0/0/1 router(config-if)#dot1q tunneling ethertype 0x9100 router(config-if)#end router# sh run inte tenGigabitEthernet 0/0/1 Building configuration... Current configuration : 974 bytes ! interface tenGigabitEthernet 0/0/1 no ip address dot1q tunneling ether type 0x9100 <<<<<< cdp enable service instance 100 ethernet encapsulation dot1q 100 xconnect 1.1.1.1 encapsulation mpls backup peer 2.2.2.2 3 pw-class MPLS ! .
Latest Customer update ==================== Customer did some more internal testing in their local lab and came back with the below update. The main deference between our customer testing and the End customer Production traffic is as follows. Looks like End customer ( Production traffic) is sending QinQ Streams, towards the Service Instance 3059 on ASR920. QinQ traffic over this single Tag dot1q Encapsulation is getting rejected by ASR920. Where as in case of ASR9K, the ASR9K is accepting the similar QinQ traffic over the single Tag dot1q Encapsulation Service Instance. .
None .
More Analysis ============= BU has suggested the CLI to apply over the physical port, in this they the xconenct VC. dot1q tunneling etype 0x9100 It was confirmed that the End customer has mixed ether type tags which are getting into ISP and plus ISP customer network are adding one more Outer tag with vlan 100 with ether type 0x8100 before sending on the ASR920. Below is the combination. Ie 0x8100 outer tag1 0x9100 outer tag2 0x8100 with inner tag Apparently in the above combination of tags the following CLI is not taking effect as expected to handle the 0x9100 traffic. ?dot1q tunneling ether type 0x9100? <<<<<< We've tried this but it doesn't work, the tagging looks like this, out customer outertag vlan 100 0x8100, end customer outertag 0x9100, end customer inner tag 0x8100 .