09-18-2011 07:32 AM
I'm running into an issue with a carrier NNI circuit that is manifesting itself as one-way traffic over an EoMPLS VC. I believe this behaviour to be the result of the ethertype that the carrier requires us to set on this interface.
By and large, the IOS-(XE|XR) default seems to be 0x8100, but in this case, the carrier needs 802.1ad/0x88a8. If I set this ethertype and put an IP address on the subinterface, I can ping across the 802.1ad circuit without issue, like so:
!
interface GigabitEthernet0/0/2
dot1q tunneling ethertype 0x88A8
!
interface GigabitEthernet0/0/2.3000
encapsulation dot1Q 3000
ip address 1.1.1.1 255.255.255.252
!
router#show arp
Protocol Address Age (min) Hardware Addr Type Interface
Internet 1.1.1.1 - c89c.1d1d.c902 ARPA GigabitEthernet0/0/2.3000
Internet 1.1.1.2 0 001c.25be.63da ARPA GigabitEthernet0/0/2.3000
bpe01.151front711#ping 1.1.1.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 58/58/59 ms
router#
Now if I attach an EoMPLS tail to this subinterface, ie:
!
interface GigabitEthernet0/0/2
dot1q tunneling ethertype 0x88A8
!
interface GigabitEthernet0/0/2.3000
encapsulation dot1Q 3000
xconnect 10.10.10.10 69 encapsulation mpls
!
With the far end PE being port based, like so:
!
interface GigabitEthernet0/16
xconnect 11.11.11.11 69 encapsulation mpls
!
And I stick a wireshark enabled laptop on Gi0/16 of the far end PE, I see untagged traffic coming from behind the 802.1ad link, which is correct, but they don't see anything coming back from me.
That leads me to believe that there is something with the ethertype possibly not being re-written to 0x88a8 when it's trying to exit the carrier NNI port. I don't know enough about Ethertype behavior, so I can't be sure this is plausible.
Does anyone have any pearls of wisdom they can share to help me understand what the correct behavior should be so I can try and deterime what the problem might be?
Thanks in advance!
09-22-2011 04:32 AM
Hi Jason,
this reminds me a similar defect which was addressed on 7600 routers, specifically on ES+ cards which were rewriting the ethertype to 0x8100 (which is the 7600 default nad basically also Cisco's default) on the payload.
Since I understand from your TAC case that there is no issue if your ISP changes the ethertype to 0x8100 - hence matching the default ethertype used by the asr1k - I suspect that something like this might be the culprit.
Try tell Pete to have a look at CSCti68153 (the defect I mentioned) and see if the same wrong behavior affects IOS-XE.
Riccardo
09-23-2011 07:31 AM
Hi Jason,
I have updates. I will write you in private.
Riccardo
09-28-2011 12:42 AM
Hi Jason,
case solved
TAC confirmed that issue was caused by CSCti99322 as I was suspecting.
For the sake of proper documentation of the support forum I am adding the release notes of that defect
CSCti99322 EoMPLS: ASR1k dropping QinQ frame received on dot1q subint
Symptom
========
End to end traffic is not passing over EoMPLS or L2TPv3 xconnect, due to traffic being dropped by the ASR1k due to "BadUidbSubIdx" as seen in the output of "sh platform hardware qfp active statistics drop"
Conditions:
=========
When ASR1k is used as PE. When EoMPLS/L2TPv3 is configured under a dot1Q sub-interface on the ASR, and if a QinQ frame is received with the outer tag matching the sub-interface dot1Q value.
Seen in all current IOS software for the ASR1k
Workaround:
==========
Add second dot1q to ASR1k interface.
So if originally we had below
interface Gig0/0.1000
encapsulation dot1q 1000
xconnect x.x.x.x
Change it to:
interface Gig0/0.1000
encapsulation dot1q 1000 second-dot1q any
xconnect x.x.x.x
============
Fixed in 15.1(03)S through CSCtj03141
please flag the question as answered and rate it when you have time.
Riccardo
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide