Understanding ethertype

[jlixfeld]

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!

[rsimoni]

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

[rsimoni]

Hi Jason,

I have updates. I will write you in private.

Riccardo

[rsimoni]

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 encapsulation

Change it to:

interface Gig0/0.1000

encapsulation dot1q 1000 second-dot1q any

xconnect x.x.x.x encapsulation

============

Fixed in 15.1(03)S through CSCtj03141

please flag the question as answered and rate it when you have time.

Riccardo