#355 Intel Corporation 82599EB based 10gbe SFP+ card does not see VLANed traffic in promiscuous mode

closed
Emil Tantilov
None
standalone_driver
5
2014-08-25
2012-08-23
Mark Carey
No

The most recent edition of the ixgbe driver is not capturing ethernet frames when put into promiscuous mode if the input traffic is tagged in 802.1q mode.

I have confirmed this by enabling promiscuous mode on the card, watching the counters increment rapidly (this is on a tap port), and then using "tcpdump -s 0 -ni eth6" to view traffic. The traffic that arrives is no the amount or expected type of traffic (only a 1 SNAP ethernet frame every 6 or 10 seconds, while the counters increment at about 1.2 GB/s).

I have created a vlan device using "vconfig add eth6 80" and then a "tcpdump -s 0 -ni eth6.80" and observing a large quantity of traffic of the expected type.

My understanding is that in promiscuous mode, the card should disable the rxvlan filters and simply pass all traffic to the host. If this is the intended behavior, then I suspect that there is a bug present. I've looked over the code in ixgbe_main.c and looked at the register setting methods for the VLAN filter stuff and it appears correct to me, so I'm kicking it up to the masters. I've also confirmed that the vlan registers both show disabled in "ethtool -d eth6", with the below results:

0x05080: FCTRL (Filter Control register) 0x00000400
Broadcast Accept: enabled
Unicast Promiscuous: enabled
Multicast Promiscuous: enabled
Store Bad Packets: disabled
<snip>
0x05088: VLNCTRL (VLAN Control register) 0x40008100
VLAN Mode: disabled
VLAN Filter: disabled

Additionally, here's the "lspci -v" output for the device in question:

08:00.0 Ethernet controller: Intel Corporation 82599EB 10-Gigabit SFI/SFP+ Network Connection (rev 01)
Subsystem: Intel Corporation Ethernet Server Adapter X520-2
Flags: bus master, fast devsel, latency 0, IRQ 202
Memory at d9900000 (64-bit, prefetchable) [size=512K]
I/O ports at bcc0 [size=32]
Memory at d98f8000 (64-bit, prefetchable) [size=16K]
Capabilities: [40] Power Management version 3
Capabilities: [50] MSI: Enable- Count=1/1 Maskable+ 64bit+
Capabilities: [70] MSI-X: Enable+ Count=64 Masked-
Capabilities: [a0] Express Endpoint, MSI 00
Capabilities: [100] Advanced Error Reporting
Capabilities: [140] Device Serial Number 90-e2-xx-xx-xx-xx-xx-xx
Capabilities: [150] Alternative Routing-ID Interpretation (ARI)
Capabilities: [160] Single Root I/O Virtualization (SR-IOV)
Kernel driver in use: ixgbe
Kernel modules: ixgbe

Thanks for all that you do folks, it's a great service, and not an easy job.
-Mark.

Related

Bugs: #355

Discussion

<< < 1 2 (Page 2 of 2)
  • Bryan Tong
    Bryan Tong
    2013-08-09

    Hello,

    So without patching the driver the following tdpcump expression works

    tcpdump -i ethX -nvv ip
    

    This is an improvement but I wouldnt consider it a fix. According to Emil the card is stripping all the VLAN tags in PROMISC mode. This I can confirm with the changed tcpdump command. However, if I need to filter a specific VLAN I cannot do that with the new driver version.

     
  • Emil Tantilov
    Emil Tantilov
    2013-08-12

    Bryan, just to make sure we're on the same page - you see the vlan packets if you do not supply a filter to tcpdump, but if you add vlan to the filter then the packets are not shown?

     
  • Bryan Tong
    Bryan Tong
    2013-08-13

    Emil,

    This is correct.

    tcpdump -i eth3 -nvv ip
    

    ^^ Dumps all traffic without any VLAN tags even if the traffic had one.

    tcpdump -i eth3 -nvv vlan and ip
    

    ^^ Dumps nothing since all traffic coming into this interface is VLAN tagged.

    For my specific instance this works and we mainly use this sniffer for DDoS detection. However, if we needed to see traffic on a specific VLAN we would not be able to do this.

    tcpdump -i eth3 -nvv vlan 103
    

    This will not work and should in accordance with how other NIC drivers operate in promiscuous mode.

     
    Last edit: Bryan Tong 2013-08-13
  • Emil Tantilov
    Emil Tantilov
    2013-08-13

    Do you see the vlan packets if you do not use the tcpdump filter?

    tcpdump -i eth3 -nvve

    This would explain why we were not able to reproduce this issue since I did not specifically use expressions with tcpdump. If this is the case - this would seem more of an issue with tcpdump since I don't know how the driver could affect the tcpdump filtering.

     
  • Bryan Tong
    Bryan Tong
    2013-08-13

    Emil,

    Here is how the filtering should work (this is not related to tcpdump itself).

    Using the following

    tcpdump -i eth3 -nvve

    Dumps all traffic, including BOOTP DHCP ARP etc. Thus we add the following filter.

    tcpdump -i eth3 -nvve ip

    This excludes everything except for IP traffic this works fine.

    Since we are sniffing from a port on our distribution switch ALL traffic passing through this interface is VLAN tagged as it is destined for other switches.

    With a normal e1000 interface we use the following expression with success.

    tcpdump -i eth1 -nvve vlan and ip

    This tells tcpdump we want traffic that IS tagged with a VLAN and IS IP traffic.

    If we wanted to inspect traffic destined for a specific switch we would use.

    tcpdump i eth1 -nvve vlan 103 and ip

    This way we only see IP traffic for VLAN 103.

    The ixgbe driver should NOT be stripping VLAN tags when put into promiscuous mode. It should only be removing the rxvlan and txvlan filters that are on by default. The idea is that the tcpdump can see ALL the traffic passing through the NIC.

    Hopefully this helps clear it up.

    Thanks

     
  • Greg Rose
    Greg Rose
    2013-08-13

    Are you running in SR-IOV mode? When the 82599 is running in SR-IOV mode with virtual functions created then it leaves VLAN filtering enabled even while in promiscuous mode. Check if you have any VFs allocated by running "ip link show eth3".

    • Greg

    From: Bryan Tong [mailto:nullivex@users.sf.net]
    Sent: Tuesday, August 13, 2013 3:26 PM
    To: [e1000:bugs]
    Subject: [e1000:bugs] #355 Intel Corporation 82599EB based 10gbe SFP+ card does not see VLANed traffic in promiscuous mode

    Emil,

    Here is how the filtering should work (this is not related to tcpdump itself).

    Using the following

    tcpdump -i eth3 -nvve

    Dumps all traffic, including BOOTP DHCP ARP etc. Thus we add the following filter.

    tcpdump -i eth3 -nvve ip

    This excludes everything except for IP traffic this works fine.

    Since we are sniffing from a port on our distribution switch ALL traffic passing through this interface is VLAN tagged as it is destined for other switches.

    With a normal e1000 interface we use the following expression with success.

    tcpdump -i eth1 -nvve vlan and ip

    This tells tcpdump we want traffic that IS tagged with a VLAN and IS IP traffic.

    If we wanted to inspect traffic destined for a specific switch we would use.

    tcpdump i eth1 -nvve vlan 103 and ip

    This way we only see IP traffic for VLAN 103.

    The ixgbe driver should NOT be stripping VLAN tags when put into promiscuous mode. It should only be removing the rxvlan and txvlan filters that are on by default. The idea is that the tcpdump can see ALL the traffic passing through the NIC.

    Hopefully this helps clear it up.

    Thanks


    [bugs:#355]http://sourceforge.net/p/e1000/bugs/355/ Intel Corporation 82599EB based 10gbe SFP+ card does not see VLANed traffic in promiscuous mode

    Status: open
    Created: Thu Aug 23, 2012 02:16 AM UTC by Mark Carey
    Last Updated: Tue Aug 13, 2013 10:10 PM UTC
    Owner: Emil Tantilov

    The most recent edition of the ixgbe driver is not capturing ethernet frames when put into promiscuous mode if the input traffic is tagged in 802.1q mode.

    I have confirmed this by enabling promiscuous mode on the card, watching the counters increment rapidly (this is on a tap port), and then using "tcpdump -s 0 -ni eth6" to view traffic. The traffic that arrives is no the amount or expected type of traffic (only a 1 SNAP ethernet frame every 6 or 10 seconds, while the counters increment at about 1.2 GB/s).

    I have created a vlan device using "vconfig add eth6 80" and then a "tcpdump -s 0 -ni eth6.80" and observing a large quantity of traffic of the expected type.

    My understanding is that in promiscuous mode, the card should disable the rxvlan filters and simply pass all traffic to the host. If this is the intended behavior, then I suspect that there is a bug present. I've looked over the code in ixgbe_main.c and looked at the register setting methods for the VLAN filter stuff and it appears correct to me, so I'm kicking it up to the masters. I've also confirmed that the vlan registers both show disabled in "ethtool -d eth6", with the below results:

    0x05080: FCTRL (Filter Control register) 0x00000400
    Broadcast Accept: enabled
    Unicast Promiscuous: enabled
    Multicast Promiscuous: enabled
    Store Bad Packets: disabled

    0x05088: VLNCTRL (VLAN Control register) 0x40008100
    VLAN Mode: disabled
    VLAN Filter: disabled

    Additionally, here's the "lspci -v" output for the device in question:

    08:00.0 Ethernet controller: Intel Corporation 82599EB 10-Gigabit SFI/SFP+ Network Connection (rev 01)
    Subsystem: Intel Corporation Ethernet Server Adapter X520-2
    Flags: bus master, fast devsel, latency 0, IRQ 202
    Memory at d9900000 (64-bit, prefetchable) [size=512K]
    I/O ports at bcc0 [size=32]
    Memory at d98f8000 (64-bit, prefetchable) [size=16K]
    Capabilities: [40] Power Management version 3
    Capabilities: [50] MSI: Enable- Count=1/1 Maskable+ 64bit+
    Capabilities: [70] MSI-X: Enable+ Count=64 Masked-
    Capabilities: [a0] Express Endpoint, MSI 00
    Capabilities: [100] Advanced Error Reporting
    Capabilities: [140] Device Serial Number 90-e2-xx-xx-xx-xx-xx-xx
    Capabilities: [150] Alternative Routing-ID Interpretation (ARI)
    Capabilities: [160] Single Root I/O Virtualization (SR-IOV)
    Kernel driver in use: ixgbe
    Kernel modules: ixgbe

    Thanks for all that you do folks, it's a great service, and not an easy job.
    -Mark.


    Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/e1000/bugs/355/

    To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/

     

    Related

    Bugs: #355

  • Emil Tantilov
    Emil Tantilov
    2013-08-13

    I understand this. My question was - if you pass traffic on vlan 103 and run tcpdump without specifying any filters:
    tcpdump -nvve -i eth1

    Do you see the vlan packets with vlan tag 103?

     
  • Bryan Tong
    Bryan Tong
    2013-08-13

    I see the traffic from vlan 103 but it has no tag.

    The NIC seems to be stripping the tags.

    The e1000 did not strip the tags so I would need to use

    tcpdump -i eth1 -nvv vlan 103

    to see the traffic on the interface.

     
  • Emil Tantilov
    Emil Tantilov
    2013-08-13

    OK that makes sense. Which kernel version are you using? Kernels > 2.6.36 should have the tag in the packet regardless of whether the driver strips it. Also for some kernels you may be able to disable vlan tag stripping using ethtool:

    ethtool -K eth1 rxvlan off

     
  • Bryan Tong
    Bryan Tong
    2013-08-14

    I have tried to turning the rxvlan and txvlan off via ethtool and it makes no difference. I believe that is because the drive is stripping all the tags when in promisc mode.

    Kernel info below.

    root@a118:~# uname -a
    Linux a118 3.2.0-4-amd64 #1 SMP Debian 3.2.46-1 x86_64 GNU/Linux
    
     
    Last edit: Bryan Tong 2013-08-14
  • Emil Tantilov
    Emil Tantilov
    2013-08-27

    With this kernel you should see the vlan tags in tcpdump. If you run tcpdump -e (without any filters) are the tags shown in the packet info?

    Also you can download ethregs from this site and check the RXDCTL register (bit 30 is the one that enable/disables the vlan tag stripping). You can check the bit before and after you run ethtool -K eth1 rxvlan off to make sure that the command disables the bit.

     
  • Todd Fujinaka
    Todd Fujinaka
    2014-02-05

    • status: open --> closed
     
  • Todd Fujinaka
    Todd Fujinaka
    2014-02-05

    Closing due to inactivity.

     
<< < 1 2 (Page 2 of 2)