Hi Christiaan there is a patch in SVN for this, please update and let us know, in essence kernel is stripping out the first VLAN tag, now pf_ring is pushing it back.
Alfredo > On 15 Apr 2015, at 15:50, Christiaan Schade > <[email protected]> wrote: > > > I did forget some other important information: > Driver: > igb-5.2.5-zc > > $ethtool -k eth4 > Offload parameters for eth4: > rx-checksumming: on > tx-checksumming: on > scatter-gather: on > tcp-segmentation-offload: on > udp-fragmentation-offload: off > generic-segmentation-offload: on > generic-receive-offload: on > large-receive-offload: off > rx-vlan-offload: off > tx-vlan-offload: off > ntuple-filters: off > receive-hashing: on > > I also tried > rx-vlan-offload: on > tx-vlan-offload: on > > with no difference > > On 04/15/2015 03:23 PM, Christiaan Schade wrote: >> >> Hi all, >> >> I think this issue might be related to r8710 (fix for hw vlan strip in case >> of multiple sockets on the same device). >> I've attached two PCAP files: ip_two_vlan.pcap and pfdump.pcap where >> pfdump.pcap is the result of 'pfsend -f ip_two_vlan.pcap' and 'pfdump -w >> pfdump.pcap' between two servers. >> >> The result is that the first (out of two) VLAN tag is stripped out in >> pfdump.pcap. >> >> == Additional info == >> - Using PF_RING 6.0.2, both VLAN tags are stripped out (i.e. there are no >> more VLAN tags in pfdump.pcap). My guess is that r8710 attempts to fix this >> issue (I have not verified if the problem exists >> in r8709). >> - Using r9212, only the first VLAN tag is stripped out >> - Using r9212, packets with 1 VLAN tag are processed correctly (if I pfsend >> the pfdump.pcap it still has 1 VLAN tag after receiving it. Also verified >> with other PCAPs with only 1 VLAN tag) >> >> Other tests performed: >> | Source | Destination | Result | >> ----------------------------------------- >> | pfsend | pfdump | 1 VLAN tag | >> | tcpreplay | pfdump | 1 VLAN tag | >> | tcpreplay | tcpdump | 2 VLAN tags | >> | pfsend | tcpdump | 2 VLAN tags | >> >> PF_RING at destination (where pfdump runs): >> >> $ cat /proc/net/pf_ring/info >> PF_RING Version : 6.0.3 ($Revision: 9212$) >> Total rings : 0 >> >> Standard (non DNA/ZC) Options >> Ring slots : 4096 >> Slot version : 16 >> Capture TX : Yes [RX+TX] >> IP Defragment : No >> Socket Mode : Standard >> Total plugins : 0 >> Cluster Fragment Queue : 0 >> Cluster Fragment Discard : 0 >> >> uname -a at destination (where pfdump runs): >> $ uname -a >> Linux sm-advantech-01 3.13.0-32-generic #57~precise1-Ubuntu SMP Tue Jul 15 >> 03:51:20 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux >> >> [Side note] I see that transparent_mode is now deprecated, does this mean >> that from 6.0.3 on PF_RING is always in transparent mode 0? >> >> If I'm missing any important information please let me know, I'd be happy to >> run any further tests to assist you in understanding the problem >> >> Thanks in advance, >> >> Christiaan Schade >> >> >> >> _______________________________________________ >> Ntop-misc mailing list >> [email protected] <mailto:[email protected]> >> http://listgateway.unipi.it/mailman/listinfo/ntop-misc >> <http://listgateway.unipi.it/mailman/listinfo/ntop-misc> >> > > -- > ------------------------------------------------------------------------ > ATTENTION: > The information in this email message is confidential and may be legally > privileged. It is intended solely for the addressee. > > Should you receive this message by mistake, you are hereby notified that > any disclosure, reproduction, distribution or use of this > message is prohibited and may be unlawful. > _______________________________________________ > Ntop-misc mailing list > [email protected] <mailto:[email protected]> > http://listgateway.unipi.it/mailman/listinfo/ntop-misc > <http://listgateway.unipi.it/mailman/listinfo/ntop-misc>
_______________________________________________ Ntop-misc mailing list [email protected] http://listgateway.unipi.it/mailman/listinfo/ntop-misc
