DEI Bit Behavior

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello Community,

 

I've been working on a project that requires a very simple setup:

 

Packet Generator ---> ETH0 --- Bridge --- ETH1 ---> Packet Capture

 

What I want to see are packets going through my setup unmodified but instead I'm seeing an interesting behavior when I send QnQ Ethernet traffic.

While sending double tagged packets, I’ve noticed that the DEI bit in the VLAN tag is getting reset to zero.  This only happens if my SVLAN tag uses the TPID value 0x88A8 or 0x8100. If I use a non-standard TPID like 0x9100, the value of the DEI bit is passed through the system unmodified (as desired).

 

To be honest, I'm not sure if this is intentional or unexpected but I've done a lot of investigating and everything seems to imply that packets should not be modified as it goes through the setup.

 

I have run my experiment on multiple devices, different interfaces and different Linux distributions/Kernels.

As far as I can tell, the behavior seems consistent.

 

Is the resetting of the DEI bit intentional (seeing how it is not reset when I pass a non-standard TPID, kind of makes me think it is)? If so, why?

Is there a way to prevent this from happening?

 

Here are some details:

Packet Generator Used: JDSU test set and Ostinato

Packet Capture: Wireshark running on a Windows

Bridge Commands used (pretty basic):

brctl addbr mybr

brctl addif mybr eth0

brctl addif mybr eth1

ifconfig mybr up

 

Version of Linux used:

Ubuntu 14.04, Kernel: 3.10

Ubuntu 15.10 Kernel: 3.10

Raspbian Jessie, Kernel: 4.1

Red Hat 7.1, Kernel 3.10

 

Thank you for any help and clarity you can provide.

Andrew Mao


[Index of Archives]     [Netdev]     [AoE Tools]     [Linux Wireless]     [Kernel Newbies]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]     [Video 4 Linux]

  Powered by Linux