[c-nsp] Understanding ethertype

[Keegan Holley]

2011/9/17 Jason Lixfeld <jason at lixfeld.ca>

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

I think you may be confusing ethertype and tag type.  A change in ethertype
means you are using a different ethernet based protocol (0x88a8) mac-in-mac
in this case.  0X8100 is a TPID and identifies the type of vlan tag used
within the IPv4/ethernet (ethertype 0x8000).  The choices are usually 0x8100
for normal 802.1Q vlan tags and 0x9100 for service provider tags.  9100 tags
are only used in q-in-q however I think cisco gear simply stacks two 8100
tags by default.

http://en.wikipedia.org/wiki/EtherType


> !
> 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 of the vc 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, I see traffic coming from
> behind the 802.1ad link, 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.
>
> While I wait for a TAC engineer to research and comment on my issue, I
> figured I'd ask hear to maybe learn something in the mean time.
>
>
I've never come across an upstream link that required 0x88a8 ethertypes.
Most equipment that I've seen that uses 0x88a8 can easily translate to
0x8000 so normal gear can read it.  I'd probably start with whoever operates
that next hop link and see if they can hand you 0x8000 and translate it on
their end.  If that's not an option I'd just capture traffic in both
directions and see what's different. 0x88a8 traffic uses fields that the
IOS-XR device may not support.  There are "special" vlan-id's such as ISID
or B-VID that may or may not be generated just by changing the ethertype on
the interface.